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 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. (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 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

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 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

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. 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.

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 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

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 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.

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-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.

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 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

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

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.

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

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

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

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

29

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

XML patient care record, the target schema is populated using the XML version of the target

patient care record.

30

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 CorrespondenceElement-Element Correspondence-NEMSISSource.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

31

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.

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.

32

Table 2 – Schema IncompatibilitiesType 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. minutesIncompatible coding

Different Coding standards 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

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

33

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 TranslationSource Target Schemas

Information Subset Coverage Information Loss w/o converters

Information Loss w/converters

iRevive-nTRACS Patient Demographics 80% None NoneiRevive–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

34

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:

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).

35

Table 4 – Query Performance

Query 1 Query 2Query 3

# Records Matches Misses Matches Misses Matches

Misses

nTRACS 4295 1302 2993 2395 1900 4294 1

iRevive 286226

(80%) 60277

(97%) 9286

(100%)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

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.

36

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 MatchingExact 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.

37

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.

38

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.

39

[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.

[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.

40

[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 Pre-hospital Dataset” http://www.nemsis.org, 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).

41

[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, 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: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.

42

[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

44

Accident Scene

(2) Pickup (3) Transport (4) Drop off

(5) Database/Billing

Data capture with mobile wireless devices

Figure 1 – High Level Application View

Major Medical Center

(1) Dispatch

Cellular/SatelliteNetwork

iRevive on tablet PC

Trauma center

Helicopter-based Sensor Gateway

withmulti-frequency

transmitter

InternetInternet

802.15.4

802.11

Sensor

Figure 2 – iRevive Use Case

45

Figure 4 – iRevive Detailed Architecture

Graphical User Interface

FutureRules

MetaData

PCRData

SemanticInterpretation

Data Display/Capture/Synchronization

Database

Outside World

Data Processing

Sensors

46

Figure 5 – Demographic Screen

Figure 6 – Burn Exam Screen

47

Figure 7 – Pregnancy Exam with Meta-data

48

Figure 9 – Tagged Vital Sign Record

Figure 8 – Vital Sign Synchronization

Figure 10 – Sensor Gateway

Sensor Network Interface

DATA Storage

State Machine

HL7 Web Services Methods

GPS BP

PulseOx

Client

49

Figure 11 – Data Exchange Via Mediator

Services

Ambulatory

Fire Dept

Paramedics

State Specific

Standards

Nemesis

Proprietary

Services

EmergencyDept

TraumaCenters

DEEDS

Standards

HL7v[3,2.X]

Proprietary

iRevive

50

Figure 12 – Centralized Vs Distributed Infrastructure (a) Centralized (b) Distributed

iRevive

Proprietary

HL7

Proprietary

Nemesis HL7Nemesis

ProprietaryProprietary

Pre-Hospital Pre-Hospital In-HospitalIn-Hospital

iRevive

iRevive

iRevive

iRevive

HL7iRevive

Figure 13 – Section of Mediation Schema for Pre-Hospital Care

EMR

Time of Medication

Dosage Unit

Gender

MedicationDosage

Type ofMedication

Race

51

Figure 14 – Sample Subsection of an XML EMR

<Mediator><MedicationsAdministered>

<Record><MedicationTime/><MedicationType/><MedicationDosage/><MedicationRoute/>

</Record></MedicationsAdministered><Vitals>

<Record><VitalTime/><PulseRate/><SystolicBP/><DiastolicBP/><RespiratoryRate/>

</Record></Vitals>

</Mediator>