Disaster Relief Coordination using a Documentation

Disaster Relief Coordination using a Documentation System for Emergency Medical Services Marko Hassinen, Maija Marttila-Kontio Department of Computer Science University of Kuopio P.O.Box 1627, FIN-70211 Kuopio, Finland Email: {marko.hassinen,maija.marttila}@cs.uku.fi

Abstract— In our earlier work we introduced a Mobile Documentation System for Emergency Medical Services. The system delivers more comprehensive and detailed documentation of prehospital care than existing systems. Also, it makes documentation and patient monitoring easier and gives paramedics more time to treat the patient. Technical solutions for implementing the documentation system are described in this paper. Based on our documentation system we introduce a novel system for coordinating resources in disaster medicine. The system utilizes the triage method in prioritizing patients and provides an up-to-date view of the emergency scene. This allows better coordination of relief effort by providing better control over manpower and equipment.

I. I NTRODUCTION Emergency medical care is a field where the workers face rapidly changing and stressfull tasks daily. Treating a critically injured or otherwise emergent patient requires prompt action and decision making. As the workers have their hands full treating a patient, there is not much time for documenting the treatment. At the same time the documentation is very important for both the traceability of the treatment and the decision making in hospital care. Pre-hospital care is a major factor in the expected outcome of the whole treatment cycle and thus a good documentation can greatly benefit the patient at a later date. Current documentation is mostly based on paper forms with some exceptions such as ECG (Electrocardiogram). The very limited time for filling paper forms can result in lack of documentation in cases where they would be most valuable. Furthermore, copying information into a hospital patient record system by hand is both time consuming and error prone. Using an automated documentation system that can do a more detailed electronic documentation, which can then be transmitted to a hospital system, can both save time and decrease errors. Furthermore, a more detailed documentation can greatly benefit the research on emergency medical care. Large amount of observations on certain physiological variables with exact timing of administered medication can give new material for new clinical trials. Coordinating Emergency Medical Services (EMS) crews in disaster situations is not easy. The goal is to deliver as good medical care as possible with limited resources to as many patients as possible. This process requires dividing the workload among the crews as well as prioritizing the care so that it benefits the largest possible part of the patients.

This means that the person in charge of coordinating the relief effort has to have up-to-date knowledge of the whole disaster, patients, medical resources, and several other factors [1]. Furthermore, keeping track of the medical personnel is a major factor in their work safety [1].This article shows how the EMS documentation system can be used to implement an information system that can provide concise picture of the disaster scene for medical care coordination purposes. To bring new technology in emergency medical care has recently been very attractive research area [2], [3], [4], [5], [6]. The research of handheld and remote data acquisition systems is also increasing along with fast developing mobile technology [7], [8], [9], [10], [11], [12]. Using this new technology to create an exact, up-to-date picture of the key factors of a disaster scene and relief effort would enable better coordination of resources [13]. Some systems for very large scale disasters, such as the RISEPAK (Relief Information System for Earthquakes - Pakistan) [14] used in the earthquakes in Pakistan, have been implemented. Our focus is on a single patient level on generally smaller scale disasters. The rest of the paper is organized as follows. In Section 2 we give an overall description of our EMS documentation system, and in Section 3 we discuss the different aspects of the documentation system implementation in more detail. In Section 4 we describe the security architecture of our EMS documentation system. In Section 5 we discuss basics of coordinating emergency medical crews in a multipatient disaster, and introduce an information system supporting the coordination work. Finally, in Section 6, we give our conclusion. II. EMS D OCUMENTATION S YSTEM Our Documentation System for Emergency Medical Services is based on an architecture of secure two way transfer of measurement data [15]. The system consists of wireless data acquisition devices and a collector device (see Figure 1). Measurement devices, such as, an oxygen saturation meter or a pulse and blood pressure measurement device send data to the collector device via Bluetooth. In addition, personal data and treatment data can be acquired with the help of a wireless barcode reader, a digital pen and a headset. All collected data is stored with time information. In our system we use a Tablet PC as a collector device, but also a laptop

Fig. 1.

The documentation system overview.

or a personal digital assistant (PDA) can be used [16]. In our experience, the Tablet PC suits to both acquiring and viewing data in hectic situations very well. We have tested a PDA as a collector device but it turned out to be too slow and unstable to handle and view several incoming and outgoing data. Also, we consider a laptop to be too big and heavy to handle in certain emergency situations. The main idea of our system is that paramedics do not have to pay a lot of attention to the documentation process. In addition, it is important that all the familiar routines the paramedics have, do not change by the introduction of the new documentation system. Descriptions have been previously written down manually with an ordinary pen. In many cases, using keyboard turns out to be much slower than a handwriting. For that reason we use a digital pen for acquiring handwritten text and transform it into digital format. Also, it is possible to use a headset to record speech. In that case, the paramedic can fully concentrate on patient treatment and, at the same time, document the process and condition of the patient. Whether using a digital pen or a headset, we need a recognition system for handwriting and speech. When using Nokia digital pen [17], a suitable commercial handwriting recognition software [18] and digital paper technology [19], [20] are available. III. D OCUMENTATION S YSTEM IMPLEMENTATION We have designed the measurement system to be as easy and unnoticeable as possible. For that reason, all digital measurement devices are wirelessly connected to a data collector device. Wireless connection is handled with Bluetooth protocol. We are using a FujitsuSiemens LifeBook Tablet PC [21] as a collector device.

Next we will introduce the documentation system implementation with three different data acquisition and data input devices. These devices are wirelessly connected to the Tablet PC. We are using Nonin 4100 pulse oximeter [23] for measuring patients oxygen saturation level and pulse, Baracoda Roadrunner barcode reader [22] for reading barcodes, and Nokia SU-1B Digital Pen [24] for digital handwriting. The documentation system is based on an official SII (Social Insuration Institution) paper form that paramedics in Finland have to fill out for every patient they treat (Finnish paper form can be seen in Figure 4). Simplifying the documentation process, written data is transformed into digital form and all measurement values are automatically acquired and viewed by the system. The user interface is designed and implemented using the original SII form. Because the functionality of the system has to be as simple and, at the same time, as robust as possible, a lot of control and double-checking can be found behind the UI. Figure 2 represents the user interface of the documentation system. UI consists of several pages (tab controls), for example, incident information page and a page showing all measured data. Most of the actions can be done by selecting a radio button or by picking the right choice from a list. This way we reduce the risk of picking two alternative choices that is possible when crossing boxes on paper form. The documentation system is implemented with visual programming language LabVIEW [25], [26]. Visual program code is built using virtual instruments (shortly VI:s) that represent either functions or entities placed on a user interface. Because LabVIEW is specialized in offering predefined and adaptive tools for implementing data acquisition, data presentation, analyzing, and controlling systems [8], it is highly suitable for our needs. Using tools and functions that have already been

Fig. 2.

User interface of the documentation system; the measurement information page.

Fig. 3.

Visual program code for reading data via Bluetooth from a measurement device.

tested, we get simple and fast program code with less errors. For example, a communication operation (IrDA, TCP, UDP or Bluetooth) is easy to implement with the help of LabVIEW’s communication and data transmission tools. In Figure 3, a simple visual program code is presented. The reading process is implemented with three predefined Bluetooth instruments. First a connection to a remote data acquisition device, such as, pulse oximeter is opened with Bluetooth Open Connection VI. With Bluetooth Read VI data is read and then the connection is closed with Bluetooth Close Connection VI. Comparing to conventional text based programming languages, the visual code is simpler to create and understand [27], [28], [29]. A new data acquisition instrument can be quickly introduced to the system. Depending on the task, virtual instruments are quickly replaced by other ones without radical changes in the whole program code. Therefore, the system is dynamic and flexible, maintenance and modifications are simple, and usability of the system is good. Before the documentation system is mobilized, all wireless data acquisition and data input devices are introduced into the system. Two things have to be done in the introduction process. First, the collector device and the measurement device have to be paired together. Secondly, the address of the measurement device is set to the system. When the documentation system is turned on, it starts to dis-

cover the measurement devices introduced previously. When a correctly functioning device is found, the system starts reading data from it using the data acquisition frequency defined by the user. Properly functioning connection is informed by a green led in the user interface. Only after first succeeded connection, the system launches an error if there is a communication or data acquisition problem with the remote device. This reduces unnecessary interaction between the system and the paramedic. Usually, every error message has to be dismissed by a user and each such action means less time for a treatment. Therefore, if everything works fine, no user interaction is required. A. Data input and data acquisition devices Free form data, such as, incident information, can be inputted to a documentation by using a digital pen or keyboard. Most often it is much faster to write text using ordinary pen than using a keyboard. A digital pen can store handwritten text and transfer it to the collector device. Several different digital pens are available and the features depend on the device. For example, we are using Nokia SU-1B [24] that can send handwritten data via Bluetooth or through USB port. The digital pen requires a special paper. In addition to written data, we also need information about the field in which the text was written. The true benefit of digitalized data comes with a structure and semantics with recorded, digitalized data.

Fig. 4.

Written text in digital document and the digital pen.

In Figure 4, the handwritten text is acquired into the system and shown as an image. To transform the image into character data we have to use a handwriting recognition software, like OCR (optical character recognition). Barcodes are used in a variety of purposes to quickly and reliably read information using a specified reader device. The barcode reader is used in the same way as a keyboard to input data into the system. Where the system has to open a connection to a Bluetooth device, the wireless barcode reader can be used immediately. In our system we have adopted the usage of bar codes to identify medicines and treatment procedures (see Figure 5). When a patient is administered medicine it is very important that the medicine, the amount, and the time are documented. Medicines are often in glass ampules and these ampules can be identified with barcodes. When medicine is given to the patient, the paramedic takes the ampule through the reader, which will document the medicine and the time it was given. Also the barcode reader can be used to document treatment, for example inserting a cannula into a vessel could be documented by taking the cannula through the reader, provided that the instrument has been tagged with a barcode. In our system, we use a wireless barcode reader, the Baracoda Roadrunner [22], which is lightweight and has multiple setting options. In hectic situations, it is important, that paramedics do not have to carry a barcode reader in their hands, or push a trigger button every time they want the device to read a barcode. The Baracoda reader can be set to autoscan mode, in which the trigger button is not necessary. We also found an adhesive velcro very practical. We attached the other side of the velcro to the back of the Baracoda and another side can be attached almost where ever the reader needs to be positioned. Because the barcode reader is lightweight, a piece of adhesive velcro can hold it right in place. Figure 5 also illustrates a wireless pulse oximeter, Nonin 4100 [23]. The device consists of two separate components: a finger tip sensor and a wristband with Bluetooth radio. Pulse

oximeter measures the pulse (18 to 300 pulses per minute) and oxygen saturation (0 to 100 percent). Bluetooth connection range is approximately 30 feet (10 meters) between the Nonin device and the collector device. Data is viewed both digitally and graphically and the user can define how often the data has to be read and viewed on the user interface. All data with a time stamp is saved to a local database where it can be retrieved to the documentation. B. Global Positioning System GPS is a satellite based system, where satellites transmit time information to a device that can receive the signal. Given three or more satellite signals, the device can calculate accurate position in the coordinate system. GPS positioning has been used in logistics for a number of years [30]. Trucks and delivery vans have been monitored using GPS in a number of applications. Locating the nearest EMS unit using the GPS based location of the unit and the location of the emergency has also been implemented [31]. In addition to dispatch decision support, the GPS can also provide assistance in locating the emergency scene [31]. The address of the emergency scene can be provided to the system by the Emergency Response Centre during dispatch. The device will show on a map the location of the emergency as well as the location of the unit. Also, the map program can help the EMS unit to find the fastest route to the scene. On the emergency scene, GPS information can be used to create a map with locations of each individual EMS unit. Location information of both the EMS unit and known patients is then used to estimate the workload of the unit and the need of additional resources. Bluetooth enabled GPS receivers, like the TomTom SiRF III Bluetooth GPS Receiver [32], have become quite cheap, often less than 100 euros [33]. Our EMS documentation system can communicate with such a system using Bluetooth and hence implement the functionality described above. Furthermore, some modern PDA’s have built-in GPS receivers and can provide accurate location information.

Fig. 5.

Wireless barcode reader, pulse oximeter and the UI of the documentation system.

C. RFID

E. Discovered restrictions

RFID (Radio Frequency Identification) has become widely discussed tehcnology lately. It is not a new technique, applications utilizing RFID have been around for decades. Most common areas where RFID has been used include industry logistics and traffic, e.g. paytolls. RFID technology utilizes tags and readers. Tags can be either active or passive [34]. Active tags are battery powered, whereas passive tags get their power from electromagnetic induction generated by the reader. An RFID tag can contain information and some tags can be written to. Memory capacity of RFID tags vary, up to 1 MB [35]. RFID systems have different frequency ranges they operate on. The frequency also affects the reading range. Active tags can be read from a longer distance as the battery increases the transmission power of the tag. The low frequency (125134 KHz) has the range of up to 18 inches while UHF (Ultra High Frequency) can have operating range up to 30 feet[34].

When prototyping the documentation system we met several problems mainly with the digital pen. The wireless digital pen is very practical enabling us to send written data via Bluetooth to a collector device. The drawback is that data can be sent wirelessly only to a system supporting General Access (GAP), Serial Port (SPP), Object Push or Dial-Up Networking (DUN) profiles. To that kind of device, data is sent in image form. Unfortunately, it seems to be impossible to send the image data wirelessly to a laptop, or in our case to a Tablet PC. The Nokia digital pen will send written data to a PC only in pen generated document form (.pgd vector form) and only via USB port [24]. Not only the connection between the collector device and the pen is not wireless anymore, we also need commercial software to handle received data. The software requires too much user interaction to be practical for our documentation system. In this phase, we are investigating the possibility to control the software with help of LabVIEWs Call Library Function Node enabling us to use the softwares DLL. To make handwriting option possible we have implemented an extra feature utilizing the touchscreen of the Tablet PC. The same pen a paramedic uses to select radio buttons and list boxes can also be used to write on the surface of the touchscreen. Certainly, we have to use some OCR to transform written text to a digital character format. Another problem appears with the barcode reader. Using a barcode reader, the key focus has to be set to where we want the data to be positioned. When emphasizing the importance of high usability, setting the key focus manually does not fullfil our requirements. For this reason, if the received data contains, for example, information of given medicine or social security number of a patient, this data has to be placed correctly. Fortunately, we can select the barcodes to contain both the data and the data type. LabVIEW is also laying a restriction to the system implementation. When installing the driver of a data acquisition

D. Documentation All collected data is combined to a patient record that can be exported into several different forms, such as, XML [36], HTML or plain text. When patient is admitted to a hospital, the documentation is transferred to the hospital server. Because the documentation system is based on two-way transfer of measurement data [15], the required information can be transferred between the hospital server and the collector device during a treatment process in emergency area. In that case, pre-hospital care information can be utilized in the hospital and, therefore, better preparation for patients arrival can set the scene for a coming treatment process. The documentation system increases the quality of treatment documentation, simply, by having more specific information of the treatment process. Also, traceability of the treatment process improves both paramedics and patients legal protection.

device we have to make sure that LabVIEW is supporting the driver. LabVIEW only works with Bluetooth devices having Microsoft Bluetooth driver included with Windows XP Service Pack 2. IV. S ECURITY OF THE D OCUMENTATION S YSTEM Security of patient data is always very important. Patient data usually contains information that can identify the patient and is hence confidential. Two basic security aspects that are important considering the patient are privacy and data integrity. Furthermore, concerning the EMS system and its users, nonrepudiation and user authentication are important factors for both patient security and the traceability of treatment measures. Privacy is achieved with strong encryption which hides all traces of patient identity from outsiders without the correct encryption key. Data integrity means that no data can be manipulated by unathorized parties after it has been created by an authorized party. Authentication in our solution is obtained using a Public Key Infrastructure (PKI). The system uses strong two-factor authentication, hence an authorized user must posses a valid smartcard and know the relevant PIN (Personal Identification Number). Digital signatures created with this system can provide both authentication and non-repudiation. Non-repudiation means that a user can not deny having created a document at a later date. As the EMS crew logs into the system, they will use a private key either on a smart card or in a secure software container to access the system. With the private key they can also digitally sign any document they create, effectively stating their responsibility for that document. Bluetooth communication has a built-in security system, that encrypts data in transit. The security system also uses check sums to provide data integrity. Although there have been some debate about Bluetooth security, we feel that for time being the security is adequate. Breaking the Bluetooth security still requires a considerable effort. In our case, the data transmitted through Bluetooth is mostly measurement data that does not have any monetary value and hence is unlikely to be of any interest to an adversary. Our Bluetooth devices have been configured to be invisible, hence one needs to know the address in order to communicate with a device. The digital pen forms a security issue that may be serious if it is not taken into consideration. As the pen contains a small camera that creates images which are stored on the pen, losing the pen may compromize considerable amount of confidential data. This threat can be minimized by deleting all data from the pen after each treatment. Communication outside the system is also a critical point in security. Any outside communication from the documentation system uses TLS (Transport Layer Security) [37]. This protocol protects the data against tampering and observing. Authentication with outside systems is carried out as within the documentation system.

TABLE I T HE FOUR CATEGORY TRIAGE CLASSIFICATION Red Yellow Green Black

Emergent. High risk patients that require immediate transport Urgent. High risk patients that can wait until emergent patients have been transported Non urgent. Walking patients. Deceased.Patients who are either dead or very severely injured and not expected to survive

The documentation data can also be used for research purposes and it provides vast amount of data that earlier has not been available. Clinical trials and evidence based medicine can both use the detailed documentation. However, there is a security issue as the people conducting research are often not the same people who treat patients. Furthermore, there may be a need to aggregate the data of a single patient that has been treated by several different units and the identity of the patient should still remain secret. In all these cases the patient should not be identified. A solution to this problem exists [38] that allows accredited parties to access all identification data of a patient and at the same time allow researches use the same data without the ability to identify any patient. Also, aggregation of data coming from different sources is possible without revealing the identity of patients. V. R ESOURCE MANAGEMENT IN DISASTER MEDICINE In large scale accidents or disasters the resources of medical personnel are limited. Often in such cases it is not possible to provide all the victims the same treatment they would receive in a normal small accident. Correct distribution of medical resources in a multipatient accident can have tremendeous effect on the survival rate. A. Triage For overall result it is sometimes better to concentrate on patients that have better chances of survival than to spend resources on patients that are not expected to survive. Triage is a method of classifying patients in different categories based on their injuries and survival expectance. The origin of the word comes from French word ”trier”, which means ”to sort”. Triage originated from the military, when the medical care could not cope on the battlefield with multiple casualties. The main idea of triage is to achieve the greatest good for the largest number of people [39]. In Finland, the common triage classification has four categories [40]. Similar classifications are also common in other countries [41]. Table I summarizes these categories. Other classifications are also in use and the methods for classification differ [39]. Triage should be an ongoing process, in which patients are frequently reclassified. The reclassification can shift the balance and the location of resource needs on the scene and this information is very important to the EMS coordinator. Accurate and up-to-date information about the amount of patients and extent of their injuries is cricial for good coordination of the relief effort. In addition to classifying the patients, they also need to be tagged for later identification. Since especially

Fig. 6.

Overview of an imaginary large scale chemical accident on a railroad.

patients with minor or no injuries are bound to move around the emergency scene, it is vital to know that they have been accounted for. Also, for reclassification, one needs to identify the patient. We have adopted the RFID approach in classifying the patients. RFID has been used in Emergency Medical Care for patient identification [42] and it has shown to expedite patient care notably. B. Resource management Using the GPS system, we can position EMS crews on a map. As the crew locates a patient and assigns a color denoting the triage status of the patient, the exact location of the crew is recorded. With this information the location and status of each located patient can be drawn on a map. This map then provides a general view of the disaster area and can be used to estimate the amount of resources that is needed. At the same time the location of each EMS crew is shown on the same map so that the coordinator can reposition crews and assign patients for these crews. Patients on the map in Fig. 6 are shown as coloured dots with the colour indicating the triage classification of a particular patient. EMS crews are shown with a blue colour and their radio call identifier. With this overall picture, the EMS coordinator can redistribute patients among the EMS units to even the workload, relocate EMS units to get a more optimal coverage of the patient mass and estimate the need of additional EMS staff. Patient identification is important in this scenario, since the coordinator can ask for an arriving EMS crew to take over patients from another crew that is overloaded. In this case it is very important for both these crews to know which patients are their responsibility. In the coordination view the coordinator can place the cursor over some unit to see which patients are assigned to that particular unit. These patients, see Fig. 7, are shown with large size dots. A similar view to Fig. 6 can be included into the EMS

documentation system, where the crew will see patients under their care on a map. This map can also show an identification of each patient. During triage, each patient is given a coloured RFID tag which contains patients identification. In case the patient can give some personal details, those details are recorded into the tag. The tag will then follow the patient into the hospital and all data collected from the pre-hospital treatment of that patient can be retrieved either from the tag or from the information system using the identification on the tag. This gives additional security in the way that misidentification of the patient at a later time is less likely to occur. The EMS documentation system also facilitates following the patients condition when there is not enough personnel for individual follow-up. Using the oxygen saturation measurements the heart rate and oxygen saturation can be monitored. A change that exceeds some predetermined threshold would create an alarm on the EMS documentation system that would draw the attention of the EMS crew. VI. C ONCLUSION Sometimes in emergency medical care minutes can make a big difference. The first five minutes can contain more decisions and procedures than the rest of the treatment period all together. Obviously, the patient is the main priority and there simply is no time for documenting the treatment adequately. Our solution uses state-of-the-art technology to automatize large part of treatment documentation. Automatic documentation will give paramedics more time to concentrate on the patient and a more thorough treatment history to refer to later on. The hospital will get a thorough documentation of pre-hospital care and medical research can have extensive database of treatment data. Research based on this data can help improve practices in emergency medical care. A central piece of our system is a TabletPC, which collects data wirelessly from patient monitoring devices. In addition

Fig. 7.

Coordinator view with patients of one unit shown with large size dots.

to monitoring devices, input of values can be done by using a barcode reader and a digital pen. The digital pen and a paper technology have presented us with several challenges to which we still have to find proper solutions. The documentation system has been implemented with visual programming language LabVIEW. Because of predefined programming tools and instruments the implementation has been quite easy and the application can also be easily modified for different situations and users. We have also paid great attention to making our system as secure as possible without sacrificing usability. The core of our security solution lies in a PKI infrastructure that utilizes smart card technology in authentication. Availability of data to accredited parties has been one of our main motivations in design of communication and third party interfaces. The decisions made in interface design have been based on using current mainstream standards, which help others in utilizing the data collected in our system. With minor modificaditions the EMS documentation system can serve as a platform for coordinating disaster relief effort in large scale accidents. Selecting suitable parts of the documentation with the help of location information, a concise view of the disaster scene can be created. An up-to-date view of the disaster is essential in coordinating the relief effort and determining the amount of resources needed. VII. F UTURE WORK Communication between the EMS documentation system and the resource management system relies on a GSM network. While suitable in multipatient accidents, this communication scheme is quite likely to collapse in a disaster situation either due to network overload or damages the disaster has caused on the network structure. Investigation of an ad-hoc network structure that does not require fixed, hence vulnerable, network structures would be in order. We are

currently investigating suitable ad-hoc network technologies where devices used for documentation could create an adhoc network controlled by the resource management system. Things to consider, among others, include power consumption, communication range, data transmission speed and security. This netwok would not be dependent on any outside infrastructure and as such would be much more robust in a disaster situation. One of the technologies we are currently investigating is the Wi-Fi technology. Our EMS documentation system uses Bluetooth for communication between the system and devices. Bluetooth, however, has some limitations that make this communication difficult to arrange in a situation where a single documentation system should monitor several patients. Bluetooth devices form piconets, where one node is a master and others are slaves. A limitation that is problematic in our case is that one master can have maximum of seven slaves. As there may be several measurement devices per patient, this limitation comes very quickly restrictive in a multipatient situation. We are looking for a communication system other than Bluetooth to overcome this obstacle. One promising technique might be ZigBee, which aims to be a simpler and cheaper technology than Bluetooth. However, the availability of measurement devices using some other wireless technology than Bluetooth seems very limited. R EFERENCES [1] United States Fire Administration: Fire, Police and EMS Coordination at Apartment Building Explosion. Harlem, New York City. Technical Report Series. http://www.interfire.org/res file/pdf/Tr-068.pdf [2] Thomas G. Holzman, Computer-Human Interface Solutions for Emergancy Medical Care, ACM interactions, vol 6(3), 1999, 13-24. [3] C. Despont-Gros, C. Boeuf, A. Geissbuhler, C. Lovis, The Digital Pen and Paper Technology: Implementation and Use in an Existing Clinical Information System, Connecting Medical Informatics and BioInformatics, ENMI 2005.

[4] A. Tura, M. Badanai, D. Longo, L. Quareni, A Medical Wearable Device with Wireless Bluetooth-based Data Transmission, Measurement Science Review, 3(2), 2003. [5] J. Light, A. Bhuvaneshwari, Mobile IP Infrastructure for Emergency Medical Services, proc. of TELEHEALTH 2005. [6] R. Rudi, B.G. Celler, Improving Data Security of Home Telecare Systems, proc. of TELEHEALTH 2005. [7] David R. Loker, P.E.Collin G. Frampton, Titan J. McElhaney, Jonathan R. Mook, Anthony M. Sansone, Remote Data Acquisition using Bluetooth, Proceedings of the 2005 American Society for Engineering Education Annual Conference and Exposition, 2005. [8] Nikunja K. Swain, James A. Anderson, Ajit Singh, Mrutyunjaya Swain, Marvin Fulton, Joseph Garrett, Omaria Tucker, Remote Data Acquisition, Control and Analysis using LabVIEW Fron Panel and Real Time Engine. Proc. of the IEEE Southeastcon 2003, 1-6. [9] Ping Yu, Hui Yu, Lessons Learned from the Practice of Mobile health application development, Proceedings of the 28th Annual International Computer Software and Applications Conference, 2, 2004, 58-59. [10] Greg Mason, A Handheld Data Acquisition System for Use in an Undergraduate Data Acquisition Course, IEEE Transactions on Education, 45(4), 2002, 388-393. [11] Marc A. Viredaz, Lawrence S. Brakmo, William R. Hamburgen, Features: Energy Management on Handheld Devices, Queue 1(7), 2003. [12] Lin Zhong, Niraj K. Jha, Power and energy: Graphical user interface energy characterization for handheld computers, Proceedings of the 2003 international conference on Compilers, architecture and synthesis for embedded systems, 2003. [13] World Bank: Research Data & Techniques Enable Better Disaster Relief Coordination http://econ.worldbank.org [14] Relief Information System for Earthquakes - Pakistan http://www.risepak.com/ [15] Hassinen M., Marttila-Kontio M., Saesmaa M. and Tervo H. Secure TwoWay Transfer of Measurement Data. Proceedings of the 3rd International Conference on Information and Technology: New Generations, 2006, 426431. [16] Brad A. Myers, Jeffrey Nichols, Jagob O. Wobbrock, Rober C. Miller, Taking Handheld Devices to the Next Level, Computer 37(12), 2004, 40-51 [17] Nokia Digital Pen SU-1B support http://europe.nokia.com/nokia/0,8764,41843,00.html [18] VisionObjects, MyScript Notes: http://www.vision-objects.com/ [19] Anoto: http://www.anotofunctionality.com/ [20] PenBook Sweden AB: http://www.penbook.net/ [21] FujitsuSiemens: http://www.fujitsu-siemens.com/products/mobile/notebooks/lifebook p.html [22] Baracoda: http://www.baracoda.com/baracoda/products/p 23.html [23] NoninMedical, Inc. :http://www.nonin.com/products/oem/4100.asp [24] Nokia:http://www.nokia.com/. [25] National Instrument’s LabVIEW website http://www.ni.com/labview [26] Kevin Bisking, Building a PDA-based measurement system, National Instrument, http://www.ni.com [27] Geoffrey G. Roy, Joel Kelso, Craig Standing, Towards a visual programming environment for software development. Software Engineering: Education and Practice, 1998, 381-388. [28] Brad A. Myers, Visual Programming, Programming by Example, and Program Visualization: A Taxonomy, ACM SIGCHI Bulletin, Proceedings of the SIGCHI conference on Human factors in computing systems, 1986 [29] Masahito Hirakawa and Tadao Ichikawa, Advance in visual programming, Systems Integration. ICSI ’92, Proceedings of the Second International Conference, 1992, 538-543. [30] Yoo T.: Study of the Real Time Logistics Control System Using Wireless Data Communication Network Proceedings of the 5th World Congress on Intelligent Transport System. 1998 [31] Ota F., Muramatsu R., Yoshida B., Yamamoto L.: GPS computer navigators to shorten EMS response and transport times. The American Journal of Emergency Medicine. 2001 May;19(3):204-5. [32] TomTom, manyfacturers website. http://www.tomtom.com/ [33] PDAShop.ln website http://www.pdashop.nl/product/17548

[34] Sandoval-Reyes, S., Soberanes Perez, J.L.:Mobile RFID reader with database wireless synchronization. Proceedings of the 2nd International Conference on Electrical and Electronics Engineering, 2005 7-9 Sept. 2005 Page(s):5 - 8 [35] David Dressen: Considerations for RFID Technology Selection. Atmel Applications Journal www.atmel.com/dyn/resources/Prod documents/secrerf 3 04.pdf [36] T. Bray et al (eds.), Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, October 2000. Available at http://www.w3.org/TR/REC-xml. [37] Open Mobile Alliance: Wireless Transport Layer Security.Wireless Apˆ plication Protocol Forum, 2001: http://www.openmobilealliance.org.xA§ [38] Hassinen M., Mussalo P.: Client controlled security for web applications. Proceedings of the IEEE Conference on Local Computer Networks, 2005. [39] Kennedy K., Aghababian R., Gans L., Lewis C.: Triage:Techniques and Applications for decision making. Annals of Emergency Medicine 28:2, Aug. 1996. pp. 135-144. [40] Ensihoitajalehti: Suuronnettomusseminaari Mikkeliss¨a. (in Finnish) http://www.sehl.fi/ensihoitajalehti/lehdet/numero 1 2004/ suuronnettomuusseminaari mikkeli/ [41] Derlet R.: Triage Sept. 14, 2004 http://www.emedicine.com/emerg/topic670.htm [42] Hang-I Chen et al.: Pervasive Observation Medicine: The Application of RFID to Improve Patient Safety in Observeation Unit of Hospital Emergency Department. Connecting Medical Informatics and Bio-Informatics, IOS Press 2005.