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:
1

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 NIHfunded 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. (www.10blade.com,
2
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; www.bostonmedflight.org, March 2009) under a grant from the National
Institutes of Health. BMF is one of America’s largest, non-profit critical care transport services,
3
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 painstaking 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
4
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 decisionmaking, 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
5
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
6
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. Underresuscitation 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.
7
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
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
8
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
9
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
10
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].
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.
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
11
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 schemabased 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
12
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
13
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
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
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
14
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
6.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 timestamp 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.
15
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
16
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-andplay 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.
17
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
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 userdefinable 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
18
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.
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
19
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.
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.
20
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.
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
21
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.
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:
22

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.
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:
23

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,
24
enabling traditional SQL querying and use of report-generating tools such as Crystal
Reports.
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.
25
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
26
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
27
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 centralized1 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
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.
28
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 exceed2 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.
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
2
This argument is an extension of Gaynor and Brander’s work on the innovation of network based
services.
29
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.
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
30
XML patient care record, the target schema is populated using the XML version of the target
patient care record.
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.
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
Source.Vitals.Vital_time
Source.Vitals.pulse_rate
Source.Vitals.SBP
Source.Vitals.DBP
Source.Exam_CNS.GCS_Eye
Source.Exam_CNS.GCS_Verbal
Correspondence-NEMSIS
Mediator.Vitals.Date_and_Time
Mediator.Vitals.PulseRate
Mediator.Vitals.SystolicBP
Mediator.Vitals.DiastolicBP
Mediator.Vitals.GCSEye
Mediator.Vitals.GCSVerbal
31
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.
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.
32
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
Naming
Key
Missing Data
Description
Different vocabulary for
similar concept.
Different keys to identify a
record.
Different data captured
Level of
Abstraction
Different granularity
Scaling
Different size attributes
Accuracy
Incompatible
coding
Different measurement units
Different Coding standards
Example
ref_pulse vs. pulse_rate
SSN vs. drivers license # to
identify a patient record
Home phone number vs.
emergency contact phone
number
4 locations for pulse in prehospital vs. single location for
pulse in hospital ED
25 vs. 50 characters for patient
name
Seconds vs. minutes
ICD 9 vs. SNOMED
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
33
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
iRevive-nTRACS
iRevive–nTRACS
NEMSIS-iRevive
iRevive-NEMSIS
Patient Demographics
Initial vital signs
Patient Demographics
Initial vital signs
80%
100%
68%
80%
Information
Loss w/o
converters
None
14%
15%
12.5%
Information Loss
w/converters
None
None
None
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.
34
Data Matching Results
Using the data mediation tools described in the previous section, we linked our prehospital 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.
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:
35
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
Query 1
nTRACS
iRevive
#
Records
4295
286
Query 2
Query
3
Misses
Matches Misses
1302
2993
226
(80%)
60
Matches Misses Matches
2395
1900
4294
277
286
(97%)
9 (100%)
1
0
We found that de-identified fields, especially gender + initial vital signs, provided a
fairly unique signature, with 80% record matching. By adding patient age and home state to
query 1, we increased anonymous record matching to 97%. Full, 100% record matching could
only be achieved with the addition of limited patient data fields, such as date of admission, zip
code and date of birth. These findings indicate that iRevive’s context-specific data mediator can
reliably broker patient data with nTRACS; however, 100% record matching could only be
achieved by adding limited patient data fields.
These findings suggest that the initial set of vital signs captured in the field by EMTs
could be used as an anonymous means for patient identification in nTRACS and other in-hospital
patient care information systems. Vital signs from the field are captured in nTRACS for research
purposes. Adding initial diastolic blood pressure, SPO2 (oxyhemoglobin saturation), end-tidal
36
CO2, and perhaps tissue perfusion (StO2) from the pre-hospital record to the NTRACS database
would, we believe, greatly facilitate anonymous data linkage and future research. These results:
1. Illustrate the value of sharing vital sign information between different electronic patient care
systems, and
2. Raise the possibility of using detailed vital sign information to create a unique patient
signature, which could then be used to link multiple phases of patient care.
Information Matching Between iRevive, iBEX and nTRACS
In this experiment we compared diagnostic ICD-9 patient information between Boston
MedFlight and two different patient care information applications at Boston Medical
Center: NTRACS and ibex . The former is the trauma database that is used at BMC; the latter is
a proprietary system that is actively used by emergency department nurses and physicians to
document ED care and assessment. There were 231 true patient matches between Boston
MedFlight, ibex and NTRACS. Exact 5 digit ICD-9 code matches were uncommon between
BMF and both NTRACS (4%) and ibex (8%) patient information systems (see Table 5).
Table 5 – Data Matching
BMF to
nTRACS
BMF to ibex
ibex to
nTRACS
Exact 5 Digit
Match
11/231 (4%)
4 Digit Match
3 Digit Match
83/231 (36%)
14/231 (6%)
(5 + 4 + 3)
Digit Matches
108/231 (47%)
19/231 (8%)
44/231 (19%)
23/231 (10%)
86/231 (37%)
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
37
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 prehospital 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.
38
Acknowledgements
This work was supported by NIH 1 R41 RR018698-01A1, NSF PFI-0227879, NSF ACI0330244, 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.
39
[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”,
http://www.cdc.gov/ncipc/pub-res/deedspage.htm, 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 "www.xml.org," 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.
40
[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. http://www.hl7.org/,
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, http://www.cdc.gov/nchs/icd9.htm, 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 Prehospital Dataset” http://www.nemsis.org, March 2009.
41
[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. 692696.
[62] Shanaberger, CJ. The Unrefined Art of Documentation. J Emerg Med Svcs 17(1): 15515, 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, http://www.ihtsdo.org/, March 2009.
[66] SOAP, The World Wide Web Consortium. SOAP Version 1.2 Part 1: Messaging
Framework. W3C Recommendation 24 June 2003. http://www.w3.org/TR/SOAP, 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:1623.
[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.
42
[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. http://www.w3.org/TR/wsdl, March 2009.
[80] XML, The World Wide Web Consortium. “Extensible Markup Language” (XML).
http://www.w3.org/XML, March 2009.
43
Figures
Major Medical Center
Accident Scene
(1) Dispatch
(2) Pickup
(3) Transport
(4) Drop off
Data capture with mobile wireless devices
(5) Database/Billing
Figure 1 – High Level Application View
Cellular/Satellite
Network
802.11
Internet
iRevive on tablet PC
Sensor
802.15.4
Helicopter-based
Sensor Gateway
with
multi-frequency
transmitter
Trauma center
Figure 2 – iRevive Use Case
44
45
Outside
World
Data
Processing
Database
Graphical User Interface
Sensors
Data
Display/Capture/
Synchronization
Semantic
Interpretation
Future
Rules
Meta
Data
PCR
Data
Figure 4 – iRevive Detailed Architecture
Figure 5 – Demographic Screen
46
Figure 6 – Burn Exam Screen
Figure 7 – Pregnancy Exam with Meta-data
47
Figure 8 – Vital Sign Synchronization
Figure 9 – Tagged Vital Sign Record
48
PulseOx
GPS
BP
Sensor Network Interface
DATA Storage
State Machine
HL7 Web Services Methods
Client
Figure 10 – Sensor Gateway
Services
Standards
Standards
Services
Ambulatory
Nemesis
HL7v[3,2.X]
Emergency
Dept
Fire Dept
State Specific
Paramedics
Proprietary
iRevive
DEEDS
Proprietary
Trauma
Centers
Figure 11 – Data Exchange Via Mediator
49
Pre-Hospital
In-Hospital
Pre-Hospital
HL7
Nemesis
HL7
iRevive
iRevive
Nemesis
iRevive
In-Hospital
HL7
iRevive
Proprietary
Proprietary
Proprietary
Proprietary
iRevive
iRevive
(a) Centralized
(b) Distributed
Figure 12 – Centralized Vs Distributed Infrastructure
EMR
Gender
Race
Type of
Medication
Time of
Medication
Medication
Dosage
Dosage Unit
Figure 13 – Section of Mediation Schema for Pre-Hospital Care
50
<Mediator>
<MedicationsAdministered>
<Record>
<MedicationTime/>
<MedicationType/>
<MedicationDosage/>
<MedicationRoute/>
</Record>
</MedicationsAdministered>
<Vitals>
<Record>
<VitalTime/>
<PulseRate/>
<SystolicBP/>
<DiastolicBP/>
<RespiratoryRate/>
</Record>
</Vitals>
</Mediator>
Figure 14 – Sample Subsection of an XML EMR
51