1 - Pace University in New York | PACE UNIVERSITY



A Standardized Pre-Hospital Electronic Patient Care System

Mark Gaynor, Dan Myung, Amar Gupta, Steve Moulton

Biographical notes:

Mark Gaynor PhD holds a PhD in Computer Science from Harvard University and is an Assistant Professor in the Graduate School Management at Boston University. His research interests include distributed sensor networks for medical applications, innovation with distributed architecture, IT/HealthCare standardization, designing network based-services, IT for healthcare, emergency medical services. He has been Co-PI on several grants from NSF, NIH, and the US army. He is technical director and network architect at 10Blade. He His first book, Network Services Investment Guide: Maximizing ROI in Uncertain Markets, is in press with Wiley (2003). Dr Gaynor has accepted a new position at the School of Public Health at Saint Louis University.

Dan Myung AB is the Director of Application Development at 10Blade, Inc., where he is the lead architect for iRevive.  Dan graduated with an AB in computer science from Harvard University.  Dan's role at 10Blade has since shifted to one of consultation on architectural and technical matters.  Since 2007, Dan has been Senior Engineer at Dimagi, Inc in Boston, MA where he has continued to build upon his portfolio of critical engineering for medical records system.   

Recently his projects have included:

• Core engineering for the smartcard-based national medical records system for the Republic of Zambia funded by the US Centers for Disease Control Global AIDS Program

• Project manager and core engineer for a cell-phone based remote screening and consultation system for cervical cancer in Zambia

• Core engineer for a system for anonymous text message reminders for HIV patients, an NIH-funded study on ART adherence

• Core engineer for an Android phone based SMS monitoring and alert system for asset and crisis management

Amar Gupta is Tom Brown Endowed Chair of Management and Technology; Professor of Entrepreneurship, Management Information Systems, Management of Organizations, and Computer Science; all at the University of Arizona.  In addition, he is Visiting Professor at MIT for part of the year. Earlier, he was with the MIT Sloan School of Management (1979-2004); for half of this 25-year period, he served as the founding Co-Director of the Productivity from Information Technology (PROFIT) initiative. He has published over 100 papers, and serves as Associate Editor of ACM Transactions on Internet Technology. At the University of Arizona, Professor Gupta is the chief architect of new multi-degree graduate programs that involve concurrent study of management, entrepreneurship, and one specific technical or scientific domain. He has nurtured the development of several key technologies that are in widespread use today, and is currently focusing on the area of the 24-Hour Knowledge Factory.

Steve Moulton is Professor of Surgery at University of Colorado, School of Medicine. He is board certified in general and pediatric surgery. His research is in the areas of trauma and medical informatics. His bibliography includes over 50 publications, several active grants, and one patent. Dr. Moulton is also the Founder and Chairman of 10Blade, Inc. (, March 2009), a startup company developing application software, sensors and sensor network infrastructure for the management of critically ill and injured patients.

Abstract

This paper describes the design, development and testing of a pre-hospital documentation and patient monitoring application called iRevive. The application utilizes a sensor gateway and data mediator to enable semantic interoperability with a wide variety of medical devices and applications. Initial test results indicate that complete and consistent pre-hospital Electronic Medical Records (EMR) can be semantically exchanged with two heterogeneous, in-hospital IT applications.

Keywords: Electronic Medical Records, Interoperability, Clinical Documentation, Emergency Medical Response, Trauma, Standards, Data mediation.

Introduction

We have designed and developed a robust pre-hospital patient care application to improve the quality, distribution and value of pre-hospital patient care information. The application, called iRevive, uses wireless sensors to automatically collect and store vital sign data on a timeline, in parallel with manually entered patient care information. It adheres to current and emerging health care standards for the storage and transfer of electronic patient data. It is, in addition, interoperable, semantically flexible, extensible, and therefore tolerant of changing documentation standards.

iRevive was developed by 10Blade, Inc., the University of Arizona, and Boston MedFlight (BMF; , March 2009) under a grant from the National Institutes of Health. BMF is one of America’s largest, non-profit critical care transport services, and as such, plays a central role in our local and regional Emergency Medical Services (EMS) systems. Boston MedFlight uses three helicopters, a fixed wing aircraft, and two specially equipped ground vehicles to transport approximately 2700 critically ill and injured patients to the major academic medical centers in Boston each year.

Maintaining a high quality of service is critical to the success of BMF and an integral part of BMF’s organizational philosophy. Boston MedFlight continuously reviews its internal functions and protocols to identify and address all patient care and transport-related problems. This cyclical quality management activity demands complete and accurate end-to-end documentation. To date, this documentation process has been carried out by manually reviewing and abstracting data from every handwritten transport record, maintaining verbal lines of communication with receiving hospitals, and following up on all adverse outcomes. This pain-staking review process has led to the creation of a large database with disparate tables of information (e.g. dispatch, patient care, transport, billing, and quality assessment/quality improvement [QA/QI]) that are not amenable to cross-system querying. The current information infrastructure is therefore plagued by two major problems: 1) the standing clinical record is a handwritten piece of paper, and 2) the clinical record is incompletely captured, poorly accessible, and unable to support a rigorous QA/QI process. iRevive was designed to address these specific problems.

The iRevive system consists of several components that work together to create a complete electronic patient care record based on emerging standards. These components include a flexible graphical user interface (GUI) to guide data entry, a sensor gateway enabling automatic collection of real-time vital sign information, an expressive and rich Extensible Markup Language (XML) markup of all data fields, and a data mediator to facilitate data exchange between overlapping documentation standards. The data mediator promotes interoperability. It allows pre-hospital patient care information collected in the iRevive system to be made available to in-hospital providers prior to patient arrival, so that acute patient care needs can be anticipated and planned for. It also allows pre-hospital patient care information to become part of each patient’s in-hospital record. This will facilitate creating an end-to-end record of each illness event, thus allowing for comprehensive data sharing and quality assurance. This is accomplished using linguistic mapping techniques to create mappings into and out of current and emerging nomenclature and communication standards.

Motivation

Our research focus falls within the early resuscitative phase of patient care, when a patient’s physiology is in constant flux due to acute injury or major illness, and clinicians are attempting to intervene and stabilize the patient. The pre-hospital phase of patient care is characterized by excitement, high levels of concentration, occasional life and death decision-making, and high expectations for performance. This phase demands an accurate assessment of physical exam findings, correct interpretation of physiological changes, and an understanding of treatment priorities. These actions occur over a relatively short period of time—from minutes to hours—during which a large amount of information must be quickly gathered, accurately interpreted, and meaningfully conveyed to a coordinated group of local and downstream healthcare providers.

The potential benefits of electronic medical records are numerous and multi-faceted, with direct and indirect advantages to heath care providers, vendors of health care goods and services, insurance companies, medical researchers, and most importantly, those receiving medical and surgical treatment. In aggregate, savings from existing EMRs have been estimated to be as high as $77 billion per year [Walker et al 2005]. Hospitals benefit from safer, more efficient systems, which reduce medical errors while cutting costs. Physicians who have transitioned to electronic medical records cite improved documentation to support higher levels of billing, the convenience of prescription writing, and the seamless integration of laboratory reporting and x-ray viewing [Baron 2005; Davidson, 2004]. Vendors and service providers benefit from a standards-based infrastructure to facilitate the exchange of medical information. This has translated into a rich eco-system of vendors and service providers, similar to what developed around the Internet and Web standards. Insurance companies benefit by requiring more accurate billing, fewer redundant tests and fewer clinical errors. Medical researchers benefit from higher quality data capture. Patients benefit from fewer errors, less overlap in testing and querying, and the projected lowering of health care costs. The overall advantages of electronic medical records are too significant to ignore in today’s environment of rising health care costs.

Improving electronic data capture leads to better evidence-based treatment protocols, better outcomes and lower healthcare costs [Mackenzie, Hu, et al. 2008]. This is especially true in the field of trauma, which is complex, data intensive, difficult to study, and traditionally under-funded. Trauma is also common: it is the leading cause of death and disability during the first three decades of life. Here in the United States, more than 150,000 people die each year as a result of trauma. Another 8 to 9 million people suffer disabling injuries, resulting in a staggering $400 billion economic impact [Anonymous 1996 and 2000]. Traumatic brain injury (TBI) and exsanguination are the two most common causes of traumatic death, making the management of head injury, hemorrhage and fluid resuscitation an integral part of early trauma care [Anonymous 2000]. Evidence-based guidelines for the management of severe traumatic brain injury have been developed, yet a wide spectrum of methods still characterizes most treatment strategies [Bennett et al 1991] [ Bickell et al 1992] [Bickell et al 1994]. Fluid resuscitation strategies are also poorly understood, difficult to study, and variably practiced. Under-resuscitation poses the risk of hypotension and end organ damage. Conversely, aggressive fluid resuscitation can dislodge clots from vascular injuries, causing further blood loss, hemodilution and death [Bickell and Waal 1994]. How to best proceed when one is dealing with a multiply-injured patient, who has a traumatic brain injury and exsanguinating hemorrhage, can be especially difficult. Under-resuscitation can harm the already-injured brain, whereas overresuscitation can reinitiate intracranial hemorrhage and exacerbate brain swelling, leading to brain herniation, permanent neurological injury, and oftentimes death.

At the present time, detailed data regarding pre-hospital resuscitation efforts is poorly captured and rarely integrated with hospital based records, making the study of resuscitation strategies and their end points both complex and time-consuming. Compounding this problem is the fact that both pre-hospital and in-hospital EMRs generally function in isolation, with little or no electronic communication with patient-related devices (e.g. cardiopulmonary monitors, ventilators, and IV pumps) or downstream systems, This has led to the creation of several competing and proprietary standards, which increase the cost and complexity of automating the collection, analysis, display and electronic transfer of patient care data between different healthcare providers, settings and systems. We developed iRevive with the vision of linking physiological, observational and interventional patient data with hospital data, in order to produce an end-to-end EMR for individual illness events.

Related Work

Prior work can be found in many areas, including Human Computer Interaction (HCI), sensor network infrastructure, standards for medical documentation and information transfer, and data mediation between heterogeneous overlapping standards [Gaynor et al 2008]. Portable wireless computing devices promise significant benefits for applications that focus on dynamic real-time events, yet their optimization still presents many research challenges

1 HCI

Human computer interaction (HCI) research generally encompasses the development of interfaces for dynamic, real-time environments [Burns 1991]. These include: 1) task-based methodologies [Lewis and Reiman 1993]; 2) effective use of mobile wireless devices such as tablet PCs/PDAs and wireless sensors [Gaynor et al 2004]; 3) use of HCI to promote safety and efficiency; 4) use of multi-modal data sources; and 5) general HCI metrics [Salman and Karhoca]. Application-focused research includes HCIs for emergency response [Turoff et al 2004], emergency medical services, emergency departments, and general medical applications. Our research extends this previous work by combining disparate ideas to develop an effective HCI interface for environments that are challenging, dynamic, uncertain, and require mobility.

Our efforts embrace the task-centered approach pioneered by Lewis and Rieman [Lewis and Reiman 1993], in which the user interface is designed and evaluated within the context of how effective the human computer interaction is when users try to accomplish a particular task. The specific tasks that we identified include the creation of a pre-hospital electronic medical record (EMR) via multimodal input, the underlying need for quality assurance and quality improvement process (including approval of each completed EMR by a senior medical officer), and reporting functions. These reporting functions include internal reporting, as well as reports to monitoring agencies such as the Centers for Disease Control and Prevention (CDC). For the first task, we selected several existing, paper-based records and created the associated electronic medical record de novo. This analysis resulted in a significant improvement in the time required to enter an “average” record into the GUI—from 30 minutes to less than 10.

While task-based principles are powerful, they cannot address the inherent uncertainty of dynamic tasks [Boukachour et al. 2003]. Coskun discusses safety-critical systems and how HCIs need to support users who are in pressure situations [Coskun and Grabowski 2003]. Testing HCIs for these types of situations can be challenging, as it is difficult to mimic life and death decision-making under conditions of high uncertainty within a laboratory environment [Bennett et al 2006]. Our GUI is designed around a flexible meta-language approach, in order to address and adapt to dynamic and uncertain environments. This architecture forces the separation of the GUI from the application code.

The advent of smaller, more powerful mobile wireless devices such as PDAs, tablet PCs, and small wireless sensors have created new challenges that HCI researchers need to address, including new interaction styles such as small-displays, tilt and touch interfaces, displays of multi-modal input, and voice activation [Ichello and Terrenghi 2005]. Research indicates that Health Information Systems are roughly 10 years behind expectations, despite the fact that wireless mobile devices can have a tremendously positive impact on medical applications [Gururjan and Murugesan 2005].

Research efforts relating to HCI in healthcare are vast. There are many overviews describing the types of applications that work best [Jamar et al 1998], as well as general design guidelines for medical software development [Gosbee et al 1997]. In line with the general research demands on the HCI community, emergency medical IT applications require a flexible and adaptable interface for long term evolution, due to emerging technologies, medical concepts, procedures, and new regulations [Amouh et al 2005] (Why the double bracket?). Similar to the ARTHOR [Amouh et al 2005] architecture, we base all of our meta-data on XML representation to ensure future flexibility.

Previous studies in Human Computer Interaction (HCI) for medical applications and emergency response have focused on: 1) effective information capture in dynamic real-time environments [Boukachour et al 2003; Iachello and Terrenghi 2005]); 2) HCIs with mobile wireless devices [Gururajan and Murugesan] [Kuhn 2001] [Gururajan and Murugesan 2005; Kuhn 2001]?; and 3) decision support [Kuhn and Giuse 2001]. What has not been addressed is an overall scheme to combine and enhance these ideas to build an effective application for the creation of electronic pre-hospital medical records. Furthermore, to be an effective tool for first responders, information systems must function well in chaotic environments and be supported by complex computer interactions that meet dynamic and uncertain needs. By combining emerging technology with new developments in human-computer interfaces, iRevive contributes to the longstanding challenge of improving the quality of pre-hospital documentation [Clayton 2001; Kuhn and Guise 2001].

Schema Matching

We based our mediation infrastructure [Sarnikar et al.] on two matching techniques that can be broadly classified into linguistic instance and schema-based matching techniques [Rahm and Bernstein 2001]. Linguistic techniques are based on identifying linguistic similarities between table names and data elements of the source and target schemas [Bright et al.,1994), and are the best suited for machine-supported mapping in the healthcare context [Sarnikar et al].

1 Heterogeneous Data Translation

Data translation between a source and a target schema is enabled by using a mapping between two schemas as input. Middleware based on data translation mechanisms proposed in the literature involve generating a single integrated schema from multiple client schemas to enable data translation [Haas et al., 1997;Milo and Zohar, 1998; Abiteboul et al., 2002; Shaker et al., 2002; Roman and Calvillo 2008]. An integrated mediating schema has several associated problems, however, including the need to capture all possible data elements and relationships manifested in the client data. As the number of client schemas increases, various semantic conflicts can arise due to the heterogeneity among the client schemas. Also, any change in a client schema results in a cascade of changes in the integrated schema and mappings between the integrated and client data [Reddy and Gupta 1995]. As an alternative to integrated schemas, Reddy and Gupta proposed a lattice-based context interchange approach that copes with changes in semantics of data in source or target schemas.

2 A Mediating Schema Approach for Data Translation

Several mediator-based schema integration mechanisms have been proposed [Wiederhold) 1993; Gupta 1989] and implemented, for example the mediator based approach used to transfer codified pharmacy and allergy data between the Veterans Affairs (VA) and Department of Defense (DoD) [Bouhaddou and Warnekar 2008]. We have extended the previously proposed heterogeneous data translation mechanisms to suit the context of healthcare. Most heterogeneous data translation mechanisms proposed in the literature attempt to address a more general context and a broad variety of problems. The issues specific to heterogeneous data translation in the healthcare context are of the following types:

1. In the healthcare context, the main objective of information exchange is to exchange and share patient information, as opposed to the ability to support arbitrary queries; the latter need is addressed by general data translation mechanisms;

2. The data elements and semantics of patient care records are well defined in specialized contexts. For example, standards such as National EMS Information System (NEMSIS) and DEEDS (Data Elements for Emergency Department Systems) specify the core data elements of a patient care record in the context of pre-hospital care and emergency department care, respectively;

3. The information being exchanged is patient-centric. This allows greater uniformity when interpreting data elements because the data is grouped according to individual patients. This reduces the conflicts arising due to variation in cardinalities between patient care records; and

4. Privacy and accuracy are major concerns that must be addressed when linking electronic patient care data between EMS systems and the hospitals they serve. Efforts at data linkage and methods for anonymous data querying have been offered, but fundamental problems related to incomplete data capture, HIPAA compliance, and reliable data transfer still remain.

Restricting the problem space to the healthcare arena renders the mediating schema-based data translation process more manageable. Mediating schemas formed because of integration of multiple client schemas can be complicated and inefficient; however, when considering specialized contexts, the mediating schemas can be predefined based on detailed domain analysis to suit most scenarios. This can enable efficient data transfer while ensuring the accurate exchange of critical information.

Standards for Medical Data Exchange

The importance of common standards to exchange medical information cannot be over-emphasized [Gaynor et. al. 2008; Krohn 2009; Ohmann and Kuchinke 2009]. This topic was summarized in a report from the July 2006 hearing on the Functional Requirements for a Nationwide Health Information Network. The Healthcare Information Technology Standards Panel (HITSP) is recomending a group of standards that harmonize the many heterogeneous standardization efforts into a manageable group, in order to promote interoperability that will improve treatment and reduce costs. Our work is compatible with and mindful of these emerging standards.

A safe and secure method to exchange emergency department data with public health agencies is another important HITSP area of study. Our technology embraces this goal by enabling “semantic” field data (that is, field data that is richly descriptive) to be transmitted to public health organizations in an anonymous way. This semantic data is further enhanced by our application’s ability to capture real-time vital sign data in parallel with human observations and interventions. All of this information could be transmitted via a layered protocol stack of interoperable standards to public health and homeland security applications seeking to quickly identify natural and/or man-made biological or other hazardous material events.

The many components of an EMR complicate the interoperability of health care applications. The key modules of a typical in-hospital EMR are administrative systems, laboratory, radiology, pharmacy, physician order entry, and clinical documentation. These areas sometimes have overlapping and competing standards developed by different standard development organizations that include Health Level 7 (HL7), European Committee for Standardization (CEN), and American Society for Testing and Materials (ASTM). Examples of overlapping terms include 11 different ways to define and spell “Total cholesterol” [Stanford and

1 Service Oriented Architecture (SOA)

iRevive’s service oriented architecture provides pre-hospital providers with the necessary agility and flexibility to link a wide variety of internal and external healthcare applications. Using web services standards [Gaynor et al 2002; Graham 2002] such as Extensible Markup Language (XML) XML data encoding [XML 2007; Sokolowski and Dudeck, 1999], Simple Object Access Protocol (SOAP) [SOAP 2003] message envelopes, and Web Services Description Language (WSDL) [WSDL 2001] service description, iRevive provides an API that is easy to program, thus promoting data exchange. SOA architecture to achieve interoperability in health care has been shown to have theoretical value in an empirical study by Daskalakis [Daskalakis and Mantas 2009] as well as practical value as demonstrated by the BioMoby project [Wilkinson and Senger 2008]. The architecture is reusable and can be extended to meet the data collection and data processing needs of many different types of acute and chronic healthcare applications, ensuring compatibility between heterogeneous applications and systems.

iRevive System

1 Overview

A high level view of the iRevive system is shown in Figure 1. This figure illustrates the five phases of a typical EMS mission: dispatch, pickup, transport, drop-off, and documentation completion with data transfer. Data capture begins when a call comes into an EMS dispatch center and continues throughout the first four phases of a mission. After dispatch the EMS transport vehicle (helicopter, jet, or ground ambulance) arrives at the patient pick up point, which may be a medical facility or injury scene. Here iRevive is used by EMTs and paramedics to enter data, including the patient’s current condition. As transport commences, emergency medical specialists treat the patient and, time permitting, continue the documentation process. The data capture phase ends when patient care is transferred to the physicians and nurses at a receiving hospital. The EMR is then completed, and patient data transferred into an in-hospital medical IT system. The final phase requires completing all necessary documentation of the mission and transferring this data to the EMT database for billing, storage and future retrieval.

Figure 1

2. Detailed Description

Different mission phases demand different modes of documentation. While iRevive utilizes a traditional form-driven GUI for the early and final phases of each mission, medics tell us that during pickup, transport and drop off, documentation is difficult because of the chaotic and stressful work environment. During these middle phases of a mission, iRevive can be used in an event-driven mode, in which medics need only touch a button on the tablet PC to time-stamp common events such as starting IVs, administering medication, or intubating a patient. These common medical interventions are flagged for later, more complete documentation when the medic has time. Different documentation modes help the medic balance the need to treat vs. the need to document.

Figure 2 illustrates how the iRevive application [Gaynor 2004; Gaynor 2005; Gaynor 2006; Gaynor 2007] will be used by a typical EMS service provider. The arriving medic places wireless vital sign sensors on one or more patients. Each medic is equipped with a ruggedized tablet PC that captures and displays the real-time sensor data and allows the documentation of observations and treatments. Data capture is automated for vital sign data, which is similar to [Mackenzie, et al. 2008]. Data on observations and treatments is manually entered by the medics. Local medics are linked to the transport aircraft or ground vehicle via an 802.11 wireless infrastructure, thus enabling centralized situational awareness. Each transport vehicle is equipped with a base station that links local technicians, command centers, and destination hospitals. This broadband WAN linkage is valuable to EMS [Careless and Erich 2008] providers because it enables global allocation of resources, and increased awareness of the condition of incoming patients at the destination hospital. During patient transport, iRevive continues to capture both sensor data and data recorded by medical personnel. The iRevive application enables the creation and transfer of an electronic patient care record that combines automated capture of vital signs with manually entered data on observations and interventions performed.

Figure 2

A detailed conceptual architecture of iRevive is shown in Figure 3. This illustrates how data is transferred between components of the iRevive application system. Central to the architecture is a sensor gateway that aggregates data from multiple sensory devices. The aggregated data is available for consumption by different applications, including the documentation component of iRevive. The data is delivered from the gateway to applications by a set of web services. These services permit the exchange of data in a manner that is compliant with HL7v3. Patient care data from the documentation component is transferred to the organizational data repository, in this case the main office database, using web services compliant with the HL7v3 standard. The only proprietary or non-standard transfer of data is between the sensor gateway and the array of emerging medical sensors and devices, which is unavoidable as these new devices employ proprietary mechanisms for data exchange and because the technology in these devices is evolving. The standards-based infrastructure of iRevive promotes interoperability with a wide variety of IT systems at receiving hospitals. It also offers the flexibility to choose from a set of best-of-breed components, as it permits plug-and-play integration of sensors and supports interoperability as it uses web services and HL7v3.

Figure 3

As the data is entered the iRevive application begins to interpret what it has been told. Simple rules ensure consistent and complete documentation of each unique mission. iRevive has a rule processing engine to manage the data as it is entered, while it simultaneously establishes what future data needs to be collected [Hashmi 2006]. A rule-based system is one that, when presented with a certain piece of information, automatically triggers a set of pre-defined actions. In the above example, our system will prompt the medic to document the route of nitroglycerin administration (topical or sublingual), the reason for administration (e.g. chest pain), and will highlight any pertinent contraindications for giving the medication (e.g. systolic blood pressure < 90, patient currently taking sildenafil, etc.). Finally, although the system enforces rules for documentation, the user can break these rules by simply making a note indicating the reason for the discrepancy. As protocols and standards continue to evolve, so too can the rules of the system.

The software architecture for iRevive is based on the three logical layers illustrated in Figure 4. The following describes these layers, their functionalities, and how they interact with one another:

Figure 4

• The graphical user interface (GUI). Practitioners interact with the GUI to view real-time vital sign data and input clinical information.

• The data processing layer (DPL). The DPL pulls and pushes data from and to the underlying database(s), while applying and verifying rules for data capture and validating the input data. The DPL ensures complete data capture in a manner consistent with the patient’s clinical presentation, and reinforces any applicable protocols.

• The database layer includes a formal representation of the rules, the patient care data, and the metadata necessary to reorganize the captured data for audit, billing, and subsequent data mining.

iRevive GUI

1 Two-Phase Documentation Approach

The iRevive GUI [Gaynor et al 2007] is based on a two-phased documentation approach that is ideal for dynamic environments where resources are limited. During less busy phases of patient transport (dispatch, en route to the scene, and after patient drop off), iRevive utilizes a forms-based methodology, in which the user steps through a group of forms in a user-definable order. Form-based data entry is suitable for traditional data input, such as patient demographics and general background information about each call. This manner of data collection is inefficient, however, during dynamic, rapidly changing, and resource-intensive phases of patient care and transport. During these phases a faster, event-driven mode can be used by a medic to quickly flag when events occur, without interrupting the primary goal of patient treatment. Subsequently, after patient drop off, the medic can fill out forms that are related to the flagged events. For example, flagging an IV event will eventually require data input regarding the type of solution, flow rate, and total volume given. These parameters can be easily recalled at the completion of a mission. The availability of two documentation modes for data collection promotes effective use of limited resources, while still maintaining complete and accurate data collection.

2 Form-Driven GUI

Figure 5 shows the “Demographic Screen,” where patient information is collected along with the “Criteria for Critical Care Transport.” Note that the medic signs off at the bottom of this screen at the completion of all data entry for the entire transport. In the workspace section on the left hand side of the screen is a check mark indicating that the “Demographic” screen is open. The blue icon next to this indicates that data has been entered into this form. Similarly, because there is a blue icon preceding medical necessity, information has been input into this section. By clicking on other forms in the workspace, one can easily navigate throughout the entire application. Figure 6 shows a screen from the burn physical exam section of the application.

Figure 5

Figure 6

The “Burn” for (form?) is one of many forms combining a point-and-select GUI to document physical exam findings with a more traditional field-based method for data entry. The graphicial body picker enables the EMT to quickly select burn locations, as well as the associated severity of the injury. Note also the vital sign window on the left side of the GUI. This provides the EMT with real-time physiological patient data. In the middle vertical bar are the terms “new” and ”remove.” Clicking on either one of these will open a new instance of the current form, to allow documentation of multiple instances of the same event—for example, if the patient has to be re-intubated because of tube dislodgement. The ability to enter multiple instances of similar events applies to all of the intervention forms.

3 Metadata-driven documentation

Using a task-based methodology, the GUI of iRevive has been tailored to documenting the transport and care of critically ill and injured patients. Although the figure displays this interface on a tablet PC, we have developed a metadata-driven approach to define data input screens, which will allow the GUI to run on a range of devices from PDAs to large monitors at central locations. The fields and their sequence on each screen, and the order of forms to fill out are dynamic, and determined as each unique emergency transport unfolds. Our GUI strategy is to allow flexibility in the choice of platforms, the ability to evolve in the context of adding new fields and forms, and the capacity to incorporate new medical devices, drugs, and treatments.

To meet this flexibility requirement, the GUI’s input components are driven by data definitions and Meta information described. The specifications are based on XML encoding, and this data is parsed and displayed at run time, thus allowing dynamic changes to the GUI. This is a critical design feature, as a static user interface and database schema will not be functional in the context of the rapidly changing needs for medical documentation. Figure 7 illustrates the pregnancy data input screen, along with its metadata definition.

Figure 7

The reporting metadata structure is designed to allow a clinician to specify and codify data points in forms and fields. This allows the flexibility in the scenario where state and federal requirements differ for clinical documentation. Fields can be added or subtracted in an ad-hoc manner. While the system facilitates the alteration of the fields that comprise a data record, the reality is that most organizations have specific, well-defined data collection needs that do not require frequent alteration.

Currently, there are 65 forms with 628 unique fields, organized to capture detailed information about each patient transport. Of these 628 fields, there are 64 fields for trended data. These include, for example, vital signs, lab reports, Glasgow Coma Scale (GCS), end-tidal carbon dioxide (ETCO2), hemodynamic monitoring, etc. The way in which a form is used to document an event is changeable by the administrator of the application at any time, and changes that are made propagate to the application in near real-time. This centralized administration capability greatly facilitates version maintenance.

4 Event-Driven GUI

Feedback from EMTs drove the innovation of our event-driven mode of documentation because we discovered that most detailed documentation is completed after the patient is dropped off. This is particularly true of air medical transport. Yet, even in this type of situation, the need to focus on patient care does not mitigate the need to synchronize treatment, observations and vital signs. Figure 8 illustrates the data collection view that includes a real-time graph of patient vital signs, including pulse-ox data alongside a set of touch-sensitive buttons on the screen. As procedures are performed on the patient, the medic taps the button that signifies the event. Each event is marked in the context of real-time vital sign information. While in transport, iRevive has the ability to transmit this real-time vital sign data, overlaid with events, to the receiving hospital. This data collection phase continues during the entire patient transport.

Figure 8

The documentation phase can begin at any point by opening or creating a patient record that contains a stream of vital sign data with synchronized events. This is displayed in Figure 9, where the graph of vital signs is overlaid with events, and the events are detailed on the right side of the GUI. Each event is linked to one or more forms that document the event. For example, at 02:23:27 the medic placed an IV into the patient. Later, when time permits, clicking the event initiates the detailed data entry required for each event.

Figure 9

This two-phased combination of form and event-driven data entry is unique because it enables the automatic collection of vital sign data without any user intervention, and allows the medics to quickly correlate their interactions and observations with time -stamping information. It gives the medic a quick and simple way to record the time of key procedures, allowing the details to be filled in later after patient drop off. The flexibility of when to document, and at what detail, is important in the dynamic environment of first responders.

5 Data Processing Layer (DPL)

The data layer of iRevive is responsible for coordination of medic interventions, observations with streaming real-time vital sign data, and promoting complete and consistent documentation. More complete and consistent pre-hospital medical information improves the overall data quality, which could be used to evaluate the efficacy of various therapeutic options. The following are the various functionalities that the data processing layer is responsible for:

• Synchronization of manually-entered information with streaming vital signs. This function time stamps medic-initiated data entry, such as interventions and observations, with real-time sensor data arriving from the sensor gateway. This enables post-mortem fine-grained analysis of patient treatment and response.

• Validation for the correctness of each individual field. This functionality provides qualitative and quantitative checks for each field. The DPL works in the background to note contextual information and verify that all data input conforms to standard protocols. If a constraint is not met, the DPL returns a query to the user, prompting the user to either correct the error or explain why the input information is out of normal bounds.

• Fulfillment of mandatory documentation. Certain fields and situations trigger the need for additional information. Forms are queued to assist in creating complete medical records. For example, if a medication is given, then the dosage must be input.

• Fulfillment of mandatory information within forms/documentation. Within each form, and depending on the clinical situation, certain fields must be filled out. For example when documenting insertion of an IV, the fluid hung and the volume given must specified

In essence, the DPL works as a middle layer to coordinate many types of information and guide the practitioner during data entry, constantly verifying that the information entered is consistent with what is expected, as specified by the rules.

6 iRevive Database

The data layer in the iRevive architecture contains three main datasets: metadata defining the dynamic screen structure, a set of rules to promote complete and consistent documentation, and the demographic and medical information in the EMR:

• Screen Metadata – This database contains metadata defining data-entry screens and linking information to drive the order of data input. This is carried out by dynamically altering the screen order and the required fields, based on the evolving medical event. The metadata repository contains metadata on the forms used for reporting and data capture, the set of fields in each form (form-fields), and the association between each form-field with its corresponding (patient-data) database field(s). The metadata is stored in a set of tables that richly define and express the data in a manner consistent with any formatting requirements.

• Documentation Rules – iRevive’s rule-based infrastructure is based on a sophisticated, yet flexible set of rules stored in the iRevive database. The rule-base validates and enforces complete data entry. The rules represent the complex inter-dependencies that exist between the data elements. For example, depending on the value entered in a specific field, the rules identify if the data is within range, what other data must be captured, determine the data entry forms that contain the form-fields corresponding to this data, and define the sequence in which the identified data-entry forms will be displayed and the sequence in which the data should be captured. The rules are represented using XML data encoding. These layers interact with one another to ensure consistent and complete data capture.

• EMR Information – This is the data pertaining to call information, patient demographics, physical exam findings, treatments and observations during transport, and patient vital signs. The data is stored with XML tags to semantically define the information. iRevive also allows conversion of this XML data into standard SQL tables, enabling traditional SQL querying and use of report-generating tools such as Crystal Reports.

7 Sensor Gateway Architecture and Details

We believe that real-time vital sign capture and information processing will play an important role in the future of healthcare systems, including automated patient care systems. At present, most vital sign data is displayed and discarded because most medical instruments are unable to exchange data because they lack basic interoperability [Gumudavelli and McKneely 2008; Thongpithoorat and McKneely 2008]. In a closely monitored setting, such as a trauma resuscitation or in the operating room, vital sign data is collected and manually entered into an electronic medical record every five or ten minutes. In an intensive care setting, once an hour usually suffices, and on the wards, once every four to six hours is the norm. The point is that a great deal of patient care information is being thrown away without regard to the potential usefulness of this information.

The emerging Service Oriented Architecture (SOA) that is based on web services provides a nice set of standards for the consumption of vital sign data [Gaynor et. al. 2004; Gaynor et. al. 2008; Laleci and Dogac 2009]] These Standards include XML, SOAP, Universal Description, Discovery and Integration (UDDI), and WSDL. They are supported by most major vendors, and include Microsoft’s .Net, Sun’s J2EE, IBM’s Dynamic e-Business initiative, as well as open-source Web services development environments such as Axis in the Apache framework. These development environments promote easy access to data provided by web services, which are usable by any client, on any host, with any operating system, as long as they are in compliance with web services standards.

Recognizing the potential usefulness of vital sign information processing in future healthcare applications [Giansanti, et al.], as well as the need to link sensor data into the iRevive application, we built a sensor gateway called VitalTrac [Baird et al 2006]. This gateway uses HL7v3 messaging and web services to define messaging interactions between a data client and its sensor data server. This standards-based approach gives application developers a fixed target with respect to controlling and consuming data from real-time sensors, while giving designers the flexibility to experiment with sensors from many different vendors. Currently, the gateway communicates with the off-the-self Welch Allyn Propaq and the smaller Nonin AVANT® 4100, as well as several research-oriented sensors such as 10Blade’s Vitaldust [Gaynor et al 2004] and Harvard’s CodeBlue [Lorincz et al 2004] sensor network infrastructure. The Propaq provides pulse oximetry, systolic blood pressure, diastolic blood pressure, and end-tidal CO2 data to the iRevive application. The Nonin wireless pulse oximeter transmits traditional pulse oximetry; however, the Nonin is also far less expensive than the Propaq, and much smaller and easier to attach to a patient. The point of the sensor gateway is that the application is de-coupled from the sensor providing the data.

Our patient sensor-to-sensor gateway communication model is shown in Figure 10. Patients are monitored with pulse oximetry, blood pressure, and GPS sensors that measure vital signs and physical location at constant intervals. The sensor gateway communicates with sensors via open or proprietary standards. Sensors “inject” their data into the Gateway. The gateway stores this information and waits for a client to request it with a web services HL7 query. Thus, applications have a stable platform for their API to consume sensor data.

Figure 10

The sensor gateway removes the complexity of proprietary and cumbersome protocols for exchanging and controlling physiological sensor data. The gateway enables heterogeneous applications to access data from heterogeneous sensors with a standard-based API that mitigates the complexity of integrating sensor data away from the application. This architecture allows application designers to focus on how to use real-time data, rather than the often complex protocols that most sensors adhere to for data exchange. Our SOA sensor gateway de-couples applications from sensors as it uses emerging standards to exchange medical vital sign data.

Data Exchange

Enabling data exchange between pre-hospital systems and the hospitals they serve is a difficult problem, requiring a large number of transformations between complicated standards [Gupta et al 2006]. iRevive uses a data mediator to exchange information (developed by our colleagues at the University of Arizona, in cooperation with researchers at 10Blade, Inc). We aimed to reduce the number of translations between pre-hospital systems (m) and hospital systems (n) from (m x n) transformations to (m + n) transformations, using iRevive as the overarching schema. To achieve this, iRevive was designed as a flexible superset of schemas, which can morph into any component schema. The high-level architecture is illustrated in Figure 11. Transformation into a common data format that is a superset of all the overlapping standards is far more scalable than translating each standard to every other standard. This data mediator approach allows adding another pre-hospital or hospital organization with incompatible standards, and only requires a translation to and from the new standard, not the n (or m) translations for a non-mediated scheme.

Figure 11

Our method is flexible in the context of deployment architecture. Figure 12 illustrates that either a centralized or a distributed version of the data mediator is possible. The centralized model has one mediator that communicates with all data producers and users, as depicted in Figure 12 (a). The distributed model places a wrapper around each application, which converts to and from each standard, as illustrated in Figure 12 (b). Our methodology also allows hybrid infrastructure. For example, each organization could have a local mediation server. The flexibility to use a range of architecture from distributed to centralized[1] is one important aspect of our mediation infrastructure.

Figure 12

There are advantages and disadvantages to both models:

• Centralized

1. More efficient management

2. Easy to monitor

• Distributed

1. Controlling your own data

2. Robust to failure

The end-2-end principle is a large part of the design philosophy behind the Internet [Seltzer et al 1984]. According to the end-2-end principle, networks should provide only the simplest of services. The end systems should have responsibility for all applications and any state information required for these applications. The idea is to keep the network simple, and build any needed complexity into the end, or edges, of the network. Distributed architecture fits well with the end-2-end argument because it promotes increased innovation.

A key problem in the implementation of current EMRs is vendor non-conformance to standards. Both Boston Medical Center (BMC) and Partner’s Health Care have integrated IT infrastructures; however, BMC and Partners cannot exchange information with semantic meaning. This lack of interoperability limits the value of EMRs to all users. Network economics [Katz and Shapiro 1985] tell us that greater interoperability creates greater value. For example, in the networking world a single phone network in which all users can connect with all other users is more valuable to each user than two distinct phone networks where users can only connect to users in their own network. If, however, the two different phone networks are interoperable, then the value of the two distinct networks to each user might exceed[2] that of the single network. Similarly, medical IT infrastructure is more valuable to all users if data transfers between heterogeneous applications happen with semantic meaning intact.

1 Context Specific Mediating Schema

A mediating schema is used to develop reusable mappings from client schemas to their conceptual equivalents. We use the labeled graph approach to model the mediating schema [Milo and Zohar 1998; Abiteboul et al. 2002]. The elements in the mediating schema are defined at a high level of granularity that equals or exceeds the granularity of the potential source schemas. The root node in the mediating schema represents the data elements that serve as the patient care record identifier. In the pre-hospital case, the patient care record identifier is a combination of the patient identifier and the incident identifier. Elements in the schema that can be uniquely identified using a patient care record identifier form the child nodes of the root node. The mediating schema does not have any data types associated with it, as the sole purpose of the mediating schema is to serve as a reference point that can be re-used for matching between different schemas. A mediating schema can be generated for various contexts by extensive domain analysis or from well-developed standards. Examples of such standards used in the United States include the NEMSIS standard for pre-hospital care, which is supported by the National Highway Traffic Safety Administration (NHTSA), and the DEEDS specification for emergency medicine, developed by the National Center for Injury Prevention and Control.

1 Client Schema to Mediator Mappings

Our focus is exchanging patient care information between pre-hospital transport services and the many hospitals they serve. Specification of the patient care record is, therefore, a central step in the data translation process between these heterogeneous systems. In addition, as most client schemas are likely to include additional fields that are not related to the EMR, explicit specification of the EMR serves as a data-filtering step. The EMR is specified as a set of SQL queries projecting the records integral to the EMR. The database administrator or an application specialist familiar with the source database can easily specify such a query. The records output by the sequence of SQL queries are then wrapped in a simple XML file that represents the patient care record. We use the two-phase translation mechanism proposed by Popa et al. [2002] to automatically generate an XML patient care record from the records output by the SQL queries. The XML file is a flat representation of the tables of the source schema. The next step involves transforming the source EMR in the form of an XML file into an XML file conforming to the target EMR. After transforming the source patient care record into the target XML patient care record, the target schema is populated using the XML version of the target patient care record.

2 Mediation Case Study

In this section, we present a case study illustrating our approach to the exchange of information between a pre-hospital transport service and two heterogeneous in-hospital patient care applications. Included is an overview of the entire process, from development of the mediating schema, to client-mediator mappings, specification of patient care records, and the data translation process.

1 Mediating Schema

The mediating schema was developed using the data elements specified by the National Transportation and Highway Safety Authority (NHTSA). The NHTSA prescribes a core set of data elements for use by emergency medical service (EMS) agencies. The NHTSA data standards are widely implemented by most pre-hospital agencies. A subset of the mediating schema developed using the NHTSA prescribed data elements defined in the National Emergency Medical Services Information System (NEMSIS) standard is shown in Figure 13.

Figure 13

|Table 1 – Schema Element to Mediator Element Correspondence |

|Element-Element |Correspondence-NEMSIS |

|Source.Vitals.Vital_time |Mediator.Vitals.Date_and_Time |

|Source.Vitals.pulse_rate |Mediator.Vitals.PulseRate |

|Source.Vitals.SBP |Mediator.Vitals.SystolicBP |

|Source.Vitals.DBP |Mediator.Vitals.DiastolicBP |

|Source.Exam_CNS.GCS_Eye |Mediator.Vitals.GCSEye |

|Source.Exam_CNS.GCS_Verbal |Mediator.Vitals.GCSVerbal |

A mapping between the client schemas and the mediating schema was manually developed. The mappings consist of element-to-element correspondence between the client schema and the mediating schema. Sample mappings from the source schema to the mediator schema are given in Table 1.

Figure 14

Records obtained from the SQL queries are transformed into an XML file using the two phase transformation method as proposed by Popa et al. The schema matching and EMR generation process is followed by the data translation process. The data translation process is completely automated and is executed without human involvement. The translation process involves generating an XML-to-XML transformation using element-to-element mappings that are inferred based on the schema mappings. A sample XML EMR encoding is shown in Figure 14. The resulting target XML file is used to populate the target schema.

3 Mediation Results and Analysis

In this section we present a summary of our observations from a data translation process between two pre-hospital schemas (NEMSIS and iRevive , and two in-hospital schemas (the Trauma Registry of the American College of Surgeons [nTRACS] and Data Elements for Emergency Department Systems [DEEDS]) using the context-specific mediating schema approach. More specifically, we present a categorization of the schema incompatibilities encountered during the schema matching and translation process, followed by a preliminary analysis of the performance of the proposed data translation process in the healthcare context.

1 Schema Incompatibilities

Several schema incompatibilities were encountered during the schema matching and data translation process. We present a summary of some of the incompatibilities using the Reddy et al. [1994] framework in Table 2.

|Table 2 – Schema Incompatibilities |

|Type of Conflict |Description |Example |

|Naming |Different vocabulary for similar concept. |ref_pulse vs. pulse_rate |

|Key |Different keys to identify a record. |SSN vs. drivers license # to identify a patient|

| | |record |

|Missing Data |Different data captured |Home phone number vs. emergency contact phone |

| | |number |

|Level of Abstraction |Different granularity |4 locations for pulse in pre-hospital vs. |

| | |single location for pulse in hospital ED |

|Scaling |Different size attributes |25 vs. 50 characters for patient name |

|Accuracy |Different measurement units |Seconds vs. minutes |

|Incompatible coding |Different Coding standards |ICD 9 vs. SNOMED |

2 Performance Analysis

We analyzed the performance of the automated data translation and exchange mechanism by measuring the amount of information lost during the data translation process. Coverage is defined as the number of data elements in the target schema that can be populated using information from the source schema. Information loss is defined as the percentage of data elements in the target schema covered by the source schema that could not be populated using the automated data translation mechanism. Information loss is a function of mediating schema coverage and schema conflicts. Special converters or filters are required to enable data transformation when type conflicts, scaling conflicts, coding incompatibilities and differences in accuracy levels arise.

We observed that the use of a standardized mediating schema resulted in a minimal loss of information. A summary of the information loss statistics is shown in Table 3. These results are similar to Bouhaddou’s [Bouhaddou and Warnekar 2008] data mediation between the VA and DoD that found a success rate of over 92% for pharmacy and 60% for codified pharmacy and allergy data. Most information loss was due to type conflict or aggregation of multiple data items into a single data element in one of the schemas. The use of converters and filters to handle the type conflict and aggregation problems mitigated the information loss problem.

|Table 3. Information Lost in Data Translation |

|Source Target Schemas |Information Subset |Coverage |Information Loss w/o |Information Loss w/converters |

| | | |converters | |

|iRevive-nTRACS |Patient Demographics |80% |None |None |

|iRevive–nTRACS |Initial vital signs |100% |14% |None |

|NEMSIS-iRevive |Patient Demographics |68% |15% |None |

|iRevive-NEMSIS |Initial vital signs |80% |12.5% |None |

Although naming conflicts were the most predominant, they were the easiest to resolve. We observed that type conflicts and missing data were the next most prevalent conflicts when matching schemas. Overall, we observed that the information lost due to the scope of the mediating schema was minimal. We believe this is due to the high level of standardization achieved in the pre-hospital arena.

Data Matching Results

Using the data mediation tools described in the previous section, we linked our pre-hospital EMR with two heterogeneous in-hospital applications, keeping the patient anonymous. We explored several different methods to accurately link pre-hospital patient care information at Boston MedFlight with in-hospital patient care information at Boston Medical Center. To test our data mediation infrastructure, we entered historical Boston MedFlight data into the iRevive SQL database. The data mediation process was then carried out using de-identified and limited patient data sets, which were derived from 373 trauma patients transported by Boston MedFlight to Boston Medical Center between September 2004 and September 2006. Of the total 373 patients, 100 were females, 248 were males, and 25 were unknown; 27 were 14 years of age or younger.

In our first experiment we exchanged information between Boston MedFlight and the Trauma Registry of the American College of Surgeons (nTRACS) at Boston Medical Center. Then we exchanged primary ICD-9 diagnostic codes between Boston MedFlight and both nTRACS and iBEX, which is the emergency department EMR application at Boston Medical Center.

1 Information Exchange Between iRevive and nTRACS

In this experiment we generated 286 true matches between Boston MedFlight and nTRACS at Boston Medical Center. The reason for the significant drop off in patient numbers is that not all BMF transports are trauma cases. All true matches were confirmed by comparing manually recorded medical record numbers from the two-year period. The data mediator was used to broker the following queries:

1. de-identified data query 1: gender + initial vital signs from the field (systolic BP, HR, GCS);

2. de-identified data query 2: query 1 + patient age + state;

3. limited data query 3 (query 1 + query 2 + date of admission + pt. zip code + pt. date of birth).

Performance was measured based on the probabilistic accuracy of a correct match (see Table 4).

|Table 4 – Query Performance |

| |

| |Exact 5 Digit Match |4 Digit Match |3 Digit Match |(5 + 4 + 3) Digit Matches|

|BMF to nTRACS |11/231 (4%) |83/231 (36%) |14/231 (6%) |108/231 (47%) |

|BMF to ibex |19/231 (8%) |44/231 (19%) |23/231 (10%) |86/231 (37%) |

|ibex to nTRACS |77/231 (33%) |83/231(36%) |14/231 (6%) |174/231 (75%) |

One interesting result is a less than 50% correlation between the primary diagnoses in the iRevive (pre-hospital) data set, versus the two in-hospital patient information systems. From a knowledge development standpoint, poor diagnostic correlation for the same patient, evaluated for the same injury event, using three different information systems, is not ideal. Also surprising is that the ibex (emergency department) primary diagnosis had a poorer correlation with the pre-hospital data than did the nTRACS primary diagnosis. We believe this is because the ibex diagnostic data is collected within minutes to hours of the pre-hospital data, whereas nTRACS data is collected during hospitalization and after patient discharge.

The findings in these two experiments validate the need for improved data mediation and data sharing between pre-hospital and hospital-based data systems. This is especially true if we plan to use these combined data sets for outcomes studies and the development of new knowledge bases.

Conclusion

We have designed and developed a robust pre-hospital patient care system called iRevive with Boston MedFlight, 10Blade, and researchers at the University of Arizona, under a Phase 1 SBIR/STTR award. The iRevive EMR is composed of automatically-collected physiological patient data and manually-entered patient information, including dispatch information, history, physical exam findings, procedural information, and response to treatment. Patient information can be captured at the point of care and wirelessly transferred to a central server using the emerging standards of web services and HL7 v3 compliant messaging. The application includes a data mediator, which allows the application to safely match and exchange electronic pre-hospital patient care information with heterogeneous healthcare information systems. The entire system is built upon open standards. It is robust, semantically flexible, web service enabled and forward compatible.

Acknowledgements

This work was supported by NIH 1 R41 RR018698-01A1, NSF PFI-0227879, NSF ACI-0330244, and NSF IIS-0529798). We would like to thank the staff at BMF for guidance.

References

1] Abiteboul, S., Cluet, S. and Milo, T. (2002) “Correspondence and translation for heterogeneous data” Theoretical Computer Science, 275, pp 179–213.

2] Amouh, Teh, Gemo, Monica, Macq, Benoit, Venderdonckt, Jean, Wahed, Abdul, Reynaert, Marc, Stamatakis, Lambert, and Thys, Frederic. Versatile Clinical Information System Design for Emergency Departments, IEEE Transactions on Information Technology in medicine, Vol 9, No 2, June 2005.

3] Anderson, C.W. Patient Care Documentation. Emergency Medical Services Magazine, 28(3): 59-62, 1999.

4] Anonymous, Guidelines for the management of severe head injury. Brain Trauma Foundation, American Association of Neurological Surgeons, Joint Section on Neurotrauma and Critical Care. J Neurotrauma 1996; 13:641-734.

5] Anonymous, Resuscitation of blood pressure and oxygenation. The Brain Trauma Foundation, American Association of Neurological Surgeons, Joint Section on Neurotrauma and Critical Care. J Neurotrauma 2000; 17:471-8.

6] Anonymous, Guidelines for cerebral perfusion pressure. The Brain Trauma Foundation, American Association of Neurological Surgeons, Joint Section on Neurotrauma and Critical Care. J Neurotrauma 2000; 17:507-11.

7] Baird S, Dawson-Haggerty S, Myung D, Gaynor M, Welsh M, Moulton S. Communicating data from wireless sensor networks using the HL7v3 standard. In: Proceedings of the 2006 IEEE International Workshop on Wearable and Implantable Body Sensor Networks (BSN 2006).

8] Bennett, G., Lindgaard, G., Tsuji, B., Connelly, Kay, and Siek, K., Reality testing: HCI challenges in non-traditional environments, Conference on Human Factors in Computing Systems, 2006.

9] Bickell WH, Bruttig SP, Millnamow GA, et al. The detrimental effects of intravenous crystalloid after aortotomy in swine. Surgery. 1991;110:529-536.

10] Bickell WH, Bruttig SP, Millnamow GA, et al. Use of hypertonic saline/dextran versus lactated Ringer’s solution as a resuscitation fluid after uncontrolled aortic hemorrhage in anesthetized swine. Ann Emerg Med. 1992;21:1077-1085.

11] Bickell WH, Waal MJ, Pepe PE, et al. Immediate versus delayed fluid resuscitation for hypotensive patients with penetrating torso injuries. N Engl J Med. 1994;331:1105-1109.

12] Bouhaddou, O., P. Warnekar, et al. (2008). "Exchange of computable patient data between the Department of Veterans Affairs (VA) and the Department of Defense (DoD): terminology mediation strategy." J Am Med Inform Assoc 15(2): 174-83.

13] Boukachour, H., Galinho, T., Person, P., and Serin, F., Towards an architecture for the representation of dynamic situations, Ph.D. Thesis for Boukachour from University of lehavre (France), Presented at IC-AI 2003 Las Vegas.

14] Burns, A., The HCI component of dependable real-time systems, Software Engineering Journal, Jul 1991.

15] Careless, J. and J. Erich (2008). "Making connections. Voice and data solutions for EMS." EMS Mag 37(8): 107-14.

16] Clayton, D, Paul. The state of clinical information systems after four decades of effort. In Yearbook of Medical Informatics 2001, pages 333–-337.

17] Coimbra R, Loomis W, Melbostad H, et al. Role of hypertonic saline and pentoxifylline on neutrophil activation and tumor necrosis factor-α synthesis: a novel resuscitation strategy. J Trauma 2005;59:257-265.

18] Coskun, E., and Grabowski, M, Impacts of User interface Complexity on User Acceptance and performance in Safety Critical Systems, Journal of Homeland Security and Emergency Management, Vol2, 2005.

19] Daskalakis, S. and J. Mantas (2009). "The Impact of SOA for Achieving Healthcare Interoperability." Methods Inf Med 48(2): 190-5.

20] DEEDS, “Data Elements for Emergency Department Systems”, , March 2009.

21] Dries DJ. Hypotensive resuscitation. Shock. 1996;311-316.

22] Feinstein AJ, Patel MB, Sanui M, Cohn SM, Majetschak M, Proctor KG. Resuscitation with pressors after traumatic brain injury. JACS 2005;201:4.

23] Gaynor, M., Iver, Bala, Wyner, George, and Freedman, Jim, Web Services Tutorial AMCIS 2003 in Tampa, FloridaXML "," March 2009.

24] Gaynor, M., Network Service Investment Guild: Maximizing ROI in uncertainty markets. Wiley, Jan 2003.

25] Gaynor, M., Bradner, S. A Real Options Metric to Evaluate Network , Protocol, and Service Architecture, Computer Communication Review(CCR), Oct 2004.

26] Gaynor, M., Welsh, M, Moulton, S, Rowan, A, LaCombe, E, and Wynne, J, Integrating Wireless Sensor Networks with the Grid IEEE Internet Computing, special issue on the wireless grid, July/Aug 2004.

27] Gaynor M, Seltzer M, Moulton S, Freedman J. A Dynamic, Data-Driven, Decision Support System for Emergency Medical Services. In: Proceedings of the International Conference on Computational Science 2005.

28] Gaynor M, Myung D, Hashmi N, Ganesan S, Moulton S. An intelligent pre-hospital patient care system. International Journal of Electronic Healthcare, 2007.

29] Gaynor, M. Myung, D., Gupta, A., and Moulton, S., Interoperability of Medical Applications and Devices, HICSS 2008.

30] Giansanti, D., V. Macellari, et al. (2008). "Telemonitoring and telerehabilitation of patients with Parkinson's disease: health technology assessment of a novel wearable step counter." Telemed J E Health 14(1): 76-83.

31] Gosbee, J., and Ritchie, E., Human-computer Interaction and Medical Software Develoment, ACM Press, 1997.

32] Graham, S., et al. Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI, Sams, Indianapolis, 2002.

33] Gross D, Landau EH, Lkin B, Krausz MM. Quantitative measurement of bleeding following hypertonic saline therapy in “uncontrolled” hemorrhagic shock. J Trauma. 1989;29:79-83.

34] Gumudavelli, S., P. K. McKneely, et al. (2008). "Medical instrument data exchange." Conf Proc IEEE Eng Med Biol Soc 2008: 1809-12.

35] Gururajan, R., and Murugesan, San, Wireless Solutions Developed for Australian Healthcare: A Review, International Conference on Mobile Business (ICBM’05), 2005.

36] Haas, L., Miller, R., Niswonger, B., Roth, M., and Wimmers E. (1997) “Transforming Heterogeneous data with database middleware: Beyond Integration” IEEE Data Engineering Bulletin.

37] HL7, Health Level Seven. 1997 - 2005 Health Level Seven, Inc. , March 2009.

38] Iachello, G., and Terrenghi, L., Mobile HCI: Experience and Reflection, IEEE Pervasive Computing, Jan-March 2005 (Vol. 4, No. 1). National Center for Health Statistic.

39] ICD-9, , March 2009.

40] Jamar, P., Mattison, J., Orland, M., Giatt, J., Karat, J., and Coble, J., Human-computer interaction in health care: what works? What doesn’t, Conference on Human Factors in Computing Systems (CHI’98) 1998.

41] Katz, M. and Shapior, C. Network Externalities, Competition and Compatibility, American Economic Review 75:3:424-440.

42] Konrad Lorincz, David Malan, Thaddeus R. F. Fulford-Jones, Alan Nawoj, Antony Clavel, Victor Shnayder, Geoff Mainland, Steve Moulton, and Matt Welsh, Sensor Networks for Emergency Response: Challenges and Opportunities, In IEEE Pervasive Computing, Special Issue on Pervasive Computing for First Response, Oct-Dec 2004.

43] Kramer, Andrew, Bennett, Rachael, …, Case Studies of Electronic Health Records in Post-Acute and Long-Term Care, U.S. Department of Health and Human Services, August 18, 2004.

44] Krohn, R. (2009). "Tower of babble. Can data standards drive healthcare interoperability?" J Healthc Inf Manag 23(1): 12-3.

45] Kuhn, K,A and D.A. Giuse. From hospital information systems to health information systems - problems, challenges, perspectives. Methods of Information in Medicine, 40(4):275-–287, 2001.

46] Laleci, G. B. and A. Dogac (2009). "A semantically enriched clinical guideline model enabling deployment in heterogeneous healthcare environments." IEEE Trans Inf Technol Biomed 13(2): 263-73.

47] Lewis, Claton and Reiman, J, Task-centered user interface design, A practical introduction, Shareware book, 1993.

48] LOINC, Logical Observation Identifiers Names and Codes, 2007.

49] Milo, T. and Zohar, S. (1998) “Using schema matching to simplify heterogeneous data translation” Proceedings of the 24th International Conference On Very Large Data Bases, pp. 122–133.

50] Mackenzie, C. F., P. Hu, et al. (2008). "Automatic pre-hospital vital signs waveform and trend data capture fills quality management, triage and outcome prediction gaps." AMIA Annu Symp Proc: 318-22.

51] NEMSIS, National EMS Information System “NHTSA Version 2.2 Uniform Pre-hospital Dataset” , March 2009.

52] Ohmann, C. and W. Kuchinke (2009). "Future developments of medical informatics from the viewpoint of networked clinical research. Interoperability and integration." Methods Inf Med 48(1): 45-54.

53] Popa, L., Velegrakis, V., Miller, R., Hernandez, M. and Fagin, R. (2002) “Translating Web Data”, Proceedings of the Very Large Databases Conference, Hong Kong, China .

54] Rahm, E. and Bernstein, P. (2001) “A survey of approaches to automatic schema matching” Very Large Database Journal, 10(4):334–350.

55] Reddy, M. and Gupta, A. (1995) “Context interchange: a lattice based approach”, Knowledge-Based Systems, 8 (1).

56] Reddy, M. P., Prasad, B. E., Reddy, P. G. and Gupta A., (1994) "A Methodology for Integration of Heterogeneous Databases" IEEE Transactions on Knowledge and Data Engineering, Vol. 6, No. 6.

57] Roman, I., J. Calvillo, et al. (2008). "Improving healthcare middleware standards with semantic methods and technologies." Stud Health Technol Inform 137: 181-9.

58] Salman, Y., Karhoca, A., Measuring Usability of Iconic Based GUIs of Mobil Emergency Services Software BY Using HCI, 35th International Conference on Computers and Industrial Engineering

59] Sarnikar S, Gupta A. A context-specific mediating schema approach for information exchange between heterogeneous hospital systems. Int. J. Healthcare Technology and Management (accepted for publication).

60] Saltzer, J, and Reed, and Clark, D. 1984., “End-To-End Arguments in System Design.,” ACM Transactions in Computer Systems 2, 4 , Nov: 1984 p 277–-288.

61] Shaker, R., Mork, P., Barclay, M. and Tarczy-Hornoch, P. (2002) "A rule driven bidirectional translation system for remapping queries and result sets between a mediated schema and heterogeneous data sources." Proceedings of the AMIA Symposium, pp. 692-696.

62] Shanaberger, CJ. The Unrefined Art of Documentation. J Emerg Med Svcs 17(1): 155-15, 1992.

63] Shires GT. Principles and management of hemorrhagic shock. In: Shires GT, ed. Principles of Trauma Care. New York: McGraw-Hill; 1985:3-42.

64] Shoemaker WC, Peitzman AB, Bellamy R, et al. Resuscitation form severe hemorrhage. Crit Care Med. 1996;24:12S-23S.

65] SNOMED, , March 2009.

66] SOAP, The World Wide Web Consortium. SOAP Version 1.2 Part 1: Messaging Framework. W3C Recommendation 24 June 2003. , March 2009.

67] R, Sokolowski, and Dudeck, J XML and its impact on content and structure in electronic health care documents, Proc AMIA Symp, 1999.

68] Standord, Jean and Thornton, Pamela, Electronic Health Records Overview, MITRE technical report.

69] Stern SA, Wang X, Mertz M, et al. Under-resuscitation of near-lethal uncontrolled hemorrhage: effects on mortality and end-organ function at 72 hours. Shock. 2001;15:16-23.

70] Stern SA, Jwayyed S, Dronen SC, Wang X. Resuscitation of severe uncontrolled hemorrhage: 7.5% sodium chloride/6% dextran-70 vs. 0.9% sodium chloride. Acad Emerg Med. 2000;7:847-856.

71] Stern SA, Kowalenko T, Younger J, Wang X, Dronen SC. Comparison of the effects of bolus vs. slow infusion of 7.5% NaCl/6% dextran-70 in a model of near-lethal uncontrolled hemorrhage. Shock. 2000;14;616-622.

72] Thongpithoonrat, P., P. K. McKneely, et al. (2008). "Networking and plug-and-play of bedside medical instruments." Conf Proc IEEE Eng Med Biol Soc 2008: 1514-7.

73] Trunkey D, D. Trauma. Sci Am. 1983; 249:28-35.

74] Thurman DJ, Alverson C, Dunn KA, et al. Traumatic brain injury in the United States: a public health perspective. J Head Trauma Rehabil 1999; 14: 602-615.

75] Turoff, Murray, Chumer, Michael, Walle, Bartel, and Yao, Xiang, The design of a Dynamic emergency Response Management Information System (DERMIS), Journal of Information Technology Theory and Application, 5:4, 2004, 1-35.

76] U.S. Department of Health and Human Services. Interagency Head Injury Task Force Report. Washington, DC: U.S. Department of Health and Human Services; 1989.

77] Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates, D. W. and Middleton, B. (2005) "The Value Of Health Care Information Exchange And Interoperability." Health Affairs.

78] Wilkinson, M. D., M. Senger, et al. (2008). "Interoperability with Moby 1.0--it's better than sharing your toothbrush!" Brief Bioinform 9(3): 220-31.

79] WSDL, The World Wide Web Consortium. “Web Services Description Language (WSDL) 1.1.” W3C Note 15 March 2001. , March 2009.

80] XML, The World Wide Web Consortium. “Extensible Markup Language” (XML). , March 2009.

Figures

[pic]

-----------------------

[1] See Gaynor’s book [Gaynor 2003], and Gaynor and Brander’s [Gaynor and Bradner 2004] work on network-based services for an argument about the value of this flexibility.

[2] This argument is an extension of Gaynor and Brander’s work on the innovation of network based services.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download