CALL FOR PARTICIPATION: This spec can be viewed without registration. But if you think what we are doing can produce something useful, please join us in the forum .

Next Exchange Technical

Section I: Overview

This system uses TWiki. If you are new to it, please familiarize yourself with TWiki quick start or the user's guide. Click Main Web on the left navigation bar to come back to this page.

OpenCARE stands for Open exchange for Collaborative Activities in Response to Emergencies. It was first proposed in the Regional Conference on Open Standards: The Key to an Open ICT Ecosystem, Bangkok, Thailand. 2-4 May 2006. The OpenCARE presentation (called e-CARES then) can be downloaded from attachements at the end of this page.

Table of Contents

1. Overview
   • Why OpenCARE?
   • Requirement Analysis and Functional Design
     • Who are the users? What do they need?
   • How OpenCARE works?
     • What does it take to implemement OpenCARE?
2. The OpenCARE Exchange
   • Communication among nodes
   • Plug-ins
3. Technical Details
   • Data Formats
     • People Finder Interchange Format (PFIF 1.1)
   • OASIS Emergency Data Exchange Language (EDXL)
     • Common Alerting Protocol (CAP 1.1)
     • EDXL Distribution Element (EDXL-DE 1.0)
     • Hospital Availability Exchange (HAVE)

This wiki is meant for formulating ideas and functional specifications. Progress, activities, related developments, and anything else is reported on the OpenCARE's blog and forums.

OpenCARE is an information middleware that enables incompatible systems to work together. At the same time, it is also an information/alert dissemination system. OpenCARE supports multiple input and output incident/progress reports. It works across borders and supports multiple languages by mean of ISO 10646/Unicode. An OpenCARE node receives information about incidents from external sources and disseminates those information to other OpenCARE nodes where other external systems are connected to. An external system is what has been already deployed today. An external system always communicates in its native data format to an OpenCARE node. Data format conversion (to OpenCARE internal one) is done at the boundary of the network; an OpenCARE node where information enters the network. In this way, information, needs, warnings, logistics, and medical arrangements may reach a wider audience -- faster and with more accuracy. If available information is indeed an XML object, OpenCARE is an XML router with translation capability. OpenCARE nodes are placed on the Internet. Each one talks to other nodes to exchange information. At the same time, OpenCARE also talks to proprietary relief/emergency systems to make sure that the latest information can be shared among relief agencies. With OpenCARE acting as a middleware, information on proprietary systems can reach a wider audience. Conversion is done before entering or leaving OpenCARE making each interfacing system speaks its native information format. OpenCARE does not replace any of the existing relief system. It simply extends their reaches to wider audiences.

The last thing we want to do is recreate what already exists. So far, we have not seen any implemention on the scale we have long wished to see -- a scale that can handle a multi-culture, cross-border cooperative network with scalability and no single point of failure.

At present, we are verifying the design. We are also looking for a few pilot feeds to (1) feed data to OpenCARE as a proof the concept, and (2) to get a node engine running. For most of the incidents, one node for each country should be sufficient. Major catastrophies may require multiple OpenCARE nodes working along side to share the load.

OpenCARE relies on open data format standards and will be an opensource implementation.

Why OpenCARE?

The idea of OpenCARE is to provide a scalable infrastructure to facilitate multi-agency handling of emergency situations.

The need for OpenCARE came from analysing handling of the 2004 South Asian Tsunami incident in Thailand. While relief efforts have been widely praised by victims of the tsunami, embassies, governments and relief organizations around the world, lessons learned from this incident can be shared and improvements can be made in order to prepare ourselves for the handling of disasters in the future.

A day after the tsunami struck, despite panic/disbelief at the degree of devastation, there were dozens of special-purpose bulletin boards/webboards in the private sector that popped up around Thailand to provide information. Government agencies also stepped in, notably Emergency Medical Services and the Department of Disaster Prevention and Mitigation.

Owing to the urgent nature of the situation, information provided on an ad-hoc basis had many negative aspects.

Causes	Effects
Various systems used a Thai language interface	Difficult for non-Thais to locate anything quickly
Information was scattered all around	Difficult to find information
	Duplicated reports of missing persons
	Relatives who had reported missing persons eventually lost track of where find the status
Formats were totally incompatible	With fax scan, database table dump, spreadsheet, pdf, and free-form text, data consolidation was virtually impossible
No time property attached to the record	Failure to see which status was the latest
Insufficient Internet bandwidth	Huge increase in bandwidth demand made it difficult to get through. Browsing was painful. Servers were placed close to information sources rather than users
Coordination with various embassies were primarily voice-based	Possible misinterpretation
	Voice channels were highly congested during the first few days after the tsunami struck. It was primarily due to the enormous load of people trying to find the whereabouts of their loved ones. The load was amplified by phone companies' generous donation of air-time from anywhere in the country to disaster areas. Some phone exchanges/base stations in beach areas along 100-km coastlines were also taken out by the tsunami. Short messaging over cell phones still worked well due to allocated capacity but, unfortunately, not many people were aware of that fact
	Fax didn't work well due to congested voice channels
The catastrophe caught media attention. In terms of bringing relief to affected people, delay from getting information propagated through the mass media through sending what was needed to the areas was not taken into account. Not too much detail could be broadcast as either.	While it was better than nothing, supplies did not match demand. And many did not arrive at the right time. This was partly due to lack of coordination and reliance on one-way/non-interactive communication channels
Interpol Disaster Victim Identification (DVI) process while being adopted globally, had low awareness. The process called for a high degree of positive identification (fingerprints, dental record matching, DNA identification) which were to commenced by highly skilled personnel.	The DVI process should work very well for a smaller scale disaster. But for an incident with hundreds of thousands of casualties, a better awareness was required so that volunteers could help after attending a crash course. Relatives of victims must also be aware that in order to identify a body, an ante-mortem form must be filed with the authorities. If the filed record later matched a post-mortem record, a body was then identified

Apart from an information aspect, relief operations also left more things to be desired.

Causes	Effects
Needs finding process was not sensitive enough to the psychological condition of victims. Every time other groups asked similar questions, victims were reminded of their struggles again and again.	Post Traumatic Stress Disorder. It both helps and hurts.
Each relief group came from a different place at different time. Findings were not shared.	Lack of continuity. Waste of time and resources
In a major disaster like this, volunteers play a very important role. The Thai Department of Disaster Prevention and Mitigation reported that there was a peak of some 60,000 civilian volunteers deployed in the field. The actual count for the number of volunteers is unknown but it should be much higher as volunteers can work independent of the government.	Logistics was a problem. Effective scheduling was a must. So was up-to-date information about the needs of affected people. NGOs and Volunteers went there on their own time and expense. They could not stay in the areas forever. Each individual had different skill sets. Proper coordination would help voluteers do more effective work during their stay.

OpenCARE addresses two sets of problems:

• information sharing (agreement and format), and
• infrastructure to enable such sharing needs (implementation).

Against the grain, we must work together because together we achieve more. When lives may be in jeopardy, feeling sorry won't be good enough.

Next Exchange Technical

Comment	Username	Time
Are we on the right track? Comments integrated into the document will be removed.	Admin	06 May 2006
As from yesterday, May 24, 2006, NECTEC resume a new duty of the missing person registration website for the flood in the north of Thailand. I afraid that we need to use the "most-thai" approach for the language on this system. We may assume that most victims are Thai. The website was operated in conjunction with the "I am alive" registration concept from Japan. - Thaweesak.	ThaweesakKoanantakool	25 May 2006 - 23:17

-- TrinTantsetthi - 05 May 2006

payday loans

secured loans

debt advice

link building

pension transfer

life insurance quote