A Standardized Pre-Hospital Electronic Patient Care System

Keywords: Electronic Medical Records, Interoperability, Clinical Documentation, Emergency Medical Response, Trauma, Standards, Data mediation.. The application, called iRevive, uses wire

A Standardized Pre-Hospital Electronic Patient Care

System

Mark Gaynor, Dan Myung, Amar Gupta, Steve Moulton

Biographical notes:

Mark Gaynor PhD holds a PhD in Computer Science from Harvard University and is an

Assistant Professor in the Graduate School Management at Boston University His research interests include distributed sensor networks for medical applications, innovation with

distributed architecture, IT/HealthCare standardization, designing network based-services, IT for healthcare, emergency medical services He has been Co-PI on several grants from NSF, NIH, and the US army He is technical director and network architect at 10Blade He His first book, Network Services Investment Guide: Maximizing ROI in Uncertain Markets, is in press with Wiley (2003) Dr Gaynor has accepted a new position at the School of Public Health at Saint Louis University

Dan Myung AB is the Director of Application Development at 10Blade, Inc., where he is

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

Recently his projects have included:

• Core engineering for the smartcard-based national medical records system for the Republic

of Zambia funded by the US Centers for Disease Control Global AIDS Program

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

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

NIH-• 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,

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

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 themajor 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 reviewingand abstracting data from every handwritten transport record, maintaining verbal lines of

communication with receiving hospitals, and following up on all adverse outcomes This staking review process has led to the creation of a large database with disparate tables of

pain-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 informationinfrastructure 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 automaticcollection of real-time vital sign information, an expressive and rich Extensible Markup

Language (XML) markup of all data fields, and a data mediator to facilitate data exchange

between overlapping documentation standards The data mediator promotes interoperability It

allows pre-hospital patient care information collected in the iRevive system to be made available

to in-hospital providers prior to patient arrival, so that acute patient care needs can be anticipatedand 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 accomplishedusing 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 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

decision-interpreted, and meaningfully conveyed to a coordinated group of local and downstream

healthcare providers

The potential benefits of electronic medical records are numerous and multi-faceted, with direct and indirect advantages to heath care providers, vendors of health care goods and services, insurance companies, medical researchers, and most importantly, those receiving medical and surgical treatment In aggregate, savings from existing EMRs have been estimated

to be as high as $77 billion per year [Walker et al 2005] Hospitals benefit from safer, more efficient systems, which reduce medical errors while cutting costs Physicians who have

transitioned to electronic medical records cite improved documentation to support higher levels

of billing, the convenience of prescription writing, and the seamless integration of laboratory reporting and x-ray viewing [Baron 2005; Davidson, 2004] Vendors and service providers benefit from a standards-based infrastructure to facilitate the exchange of medical information This has translated into a rich eco-system of vendors and service providers, similar to what developed around the Internet and Web standards Insurance companies benefit by requiring more accurate billing, fewer redundant tests and fewer clinical errors Medical researchers benefit from higher quality data capture Patients benefit from fewer errors, less overlap in testing and querying, and the projected lowering of health care costs The overall advantages of electronic medical records are too significant to ignore in today’s environment of rising health care costs

Improving electronic data capture leads to better evidence-based treatment protocols, better outcomes and lower healthcare costs [Mackenzie, Hu, et al 2008] This is especially true

in the field of trauma, which is complex, data intensive, difficult to study, and traditionally under-funded Trauma is also common: it is the leading cause of death and disability during the first three decades of life Here in the United States, more than 150,000 people die each year as aresult 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 [Anonymous2000] Evidence-based guidelines for the management of severe traumatic brain injury have

been developed, yet a wide spectrum of methods still characterizes most treatment strategies [Bennett et al 1991] [ Bickell et al 1992] [Bickell et al 1994] Fluid resuscitation strategies are also poorly understood, difficult to study, and variably practiced Under-resuscitation poses the risk of hypotension and end organ damage Conversely, aggressive fluid resuscitation can dislodge clots from vascular injuries, causing further blood loss, hemodilution and death [Bickelland 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 overUnder-resuscitation 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 isthe fact that both pre-hospital and in-hospital EMRs generally function in isolation, with little or

no electronic communication with patient-related devices (e.g cardiopulmonary monitors, ventilators, and IV pumps) or downstream systems, This has led to the creation of several competing and proprietary standards, which increase the cost and complexity of automating the collection, analysis, display and electronic transfer of patient care data between different

healthcare providers, settings and systems We developed iRevive with the vision of linking

physiological, observational and interventional patient data with hospital data, in order to

produce an end-to-end EMR for individual illness events

Related Work

Prior work can be found in many areas, including Human Computer Interaction (HCI),sensor network infrastructure, standards for medical documentation and information transfer, anddata 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 assuranceand quality improvement process (including approval of each completed EMR by a senior

medical officer), and reporting functions These reporting functions include internal reporting, aswell 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 toless 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 toaddress and adapt to dynamic and uncertain environments This architecture forces the

separation of the GUI from the application code

The advent of smaller, more powerful mobile wireless devices such as PDAs, tablet PCs, and small wireless sensors have created new challenges that HCI researchers need to address, including new interaction styles such as small-displays, tilt and touch interfaces,

displays of multi-modal input, and voice activation [Ichello and Terrenghi 2005] Research indicates that Health Information Systems are roughly 10 years behind expectations, despite the fact that wireless mobile devices can have a tremendously positive impact on medical

applications [Gururjan and Murugesan 2005]

Research efforts relating to HCI in healthcare are vast There are many overviews describing the types of applications that work best [Jamar et al 1998], as well as general design

guidelines for medical software development [Gosbee et al 1997] In line with the general research demands on the HCI community, emergency medical IT applications require a flexible and adaptable interface for long term evolution, due to emerging technologies, medical concepts,procedures, and new regulations [Amouh et al 2005] (Why the double bracket?) Similar to the ARTHOR [Amouh et al 2005] architecture, we base all of our meta-data on XML representation

to ensure future flexibility

Previous studies in Human Computer Interaction (HCI) for medical applications and emergency response have focused on: 1) effective information capture in dynamic real-time environments [Boukachour et al 2003; Iachello and Terrenghi 2005]); 2) HCIs with mobile wireless devices [Gururajan and Murugesan] [Kuhn 2001] [Gururajan and Murugesan 2005; Kuhn 2001]?; and 3) decision support [Kuhn and Giuse 2001] What has not been addressed is

an overall scheme to combine and enhance these ideas to build an effective application for the creation of electronic pre-hospital medical records Furthermore, to be an effective tool for first responders, information systems must function well in chaotic environments and be supported bycomplex computer interactions that meet dynamic and uncertain needs By combining emerging

technology with new developments in human-computer interfaces, iRevive contributes to the

longstanding challenge of improving the quality of pre-hospital documentation [Clayton 2001; Kuhn and Guise 2001]

Schema Matching

We based our mediation infrastructure [Sarnikar et al.] on two matching techniques that can be broadly classified into linguistic instance and schema-based matching techniques [Rahm and Bernstein 2001] Linguistic techniques are based on identifying linguistic similarities

between table names and data elements of the source and target schemas [Bright et al.,1994), andare 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 theintegrated 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

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 wheninterpreting 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 based data translation process more manageable Mediating schemas formed because of

schema-integration of multiple client schemas can be complicated and inefficient; however, when

considering specialized contexts, the mediating schemas can be predefined based on detailed

domain analysis to suit most scenarios This can enable efficient data transfer while ensuring the accurate exchange of critical information

Standards for Medical Data Exchange

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

A safe and secure method to exchange emergency department data with public health agencies is another important HITSP area of study Our technology embraces this goal by enabling “semantic” field data (that is, field data that is richly descriptive) to be transmitted to public health organizations in an anonymous way This semantic data is further enhanced by our application’s ability to capture real-time vital sign data in parallel with human observations and interventions All of this information could be transmitted via a layered protocol stack of

interoperable standards to public health and homeland security applications seeking to quickly identify natural and/or man-made biological or other hazardous material events

The many components of an EMR complicate the interoperability of health care applications The key modules of a typical in-hospital EMR are administrative systems,

laboratory, radiology, pharmacy, physician order entry, and clinical documentation These areas sometimes have overlapping and competing standards developed by different standard

development organizations that include Health Level 7 (HL7), European Committee for

Standardization (CEN), and American Society for Testing and Materials (ASTM) Examples of overlapping terms include 11 different ways to define and spell “Total cholesterol” [Stanford and

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

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 stamp common events such as starting IVs, administering medication, or intubating a patient These common medical interventions are flagged for later, more complete documentation when the medic has time Different documentation modes help the medic balance the need to treat vs the need to document

Figure 2 illustrates how the iRevive application [Gaynor 2004; Gaynor 2005; Gaynor

2006; Gaynor 2007] will be used by a typical EMS service provider The arriving medic places wireless vital sign sensors on one or more patients Each medic is equipped with a ruggedized tablet PC that captures and displays the real-time sensor data and allows the documentation of observations and treatments Data capture is automated for vital sign data, which is similar to [Mackenzie, et al 2008] Data on observations and treatments is manually entered by the medics.Local medics are linked to the transport aircraft or ground vehicle via an 802.11 wireless

infrastructure, thus enabling centralized situational awareness Each transport vehicle is equippedwith a base station that links local technicians, command centers, and destination hospitals This broadband WAN linkage is valuable to EMS [Careless and Erich 2008] providers because it enables global allocation of resources, and increased awareness of the condition of incoming

patients at the destination hospital During patient transport, iRevive continues to capture both sensor data and data recorded by medical personnel The iRevive application enables the creation

and transfer of an electronic patient care record that combines automated capture of vital signs with manually entered data on observations and interventions performed

Figure 2

A detailed conceptual architecture of iRevive is shown in Figure 3 This illustrates how data is transferred between components of the iRevive application system Central to the

architecture is a sensor gateway that aggregates data from multiple sensory devices The

aggregated data is available for consumption by different applications, including the

documentation component of iRevive The data is delivered from the gateway to applications by

a set of web services These services permit the exchange of data in a manner that is compliant with HL7v3 Patient care data from the documentation component is transferred to the

organizational data repository, in this case the main office database, using web services

compliant with the HL7v3 standard The only proprietary or non-standard transfer of data is between the sensor gateway and the array of emerging medical sensors and devices, which is unavoidable as these new devices employ proprietary mechanisms for data exchange and

because the technology in these devices is evolving The standards-based infrastructure of

iRevive promotes interoperability with a wide variety of IT systems at receiving hospitals It also

offers the flexibility to choose from a set of best-of-breed components, as it permits play integration of sensors and supports interoperability as it uses web services and HL7v3

In the above example, our system will prompt the medic to document the route of nitroglycerin administration (topical or sublingual), the reason for administration (e.g chest pain), and will highlight any pertinent contraindications for giving the medication (e.g systolic blood pressure <

90, patient currently taking sildenafil, etc.) Finally, although the system enforces rules for documentation, the user can break these rules by simply making a note indicating the reason for the discrepancy As protocols and standards continue to evolve, so too can the rules of the system

The software architecture for iRevive is based on the three logical layers illustrated in

Figure 4 The following describes these layers, their functionalities, and how they interact with one another:

• The database layer includes a formal representation of the rules, the patient care data, and themetadata 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 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

user-phases of patient care and transport During these user-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

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

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 changesthat 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-timegraph of patient vital signs, including pulse-ox data alongside a set of touch-sensitive buttons on the screen As procedures are performed on the patient, the medic taps the button that signifies the event Each event is marked in the context of real-time vital sign information While in

transport, iRevive has the ability to transmit this real-time vital sign data, overlaid with events, to

the receiving hospital This data collection phase continues during the entire patient transport

Figure 8

The documentation phase can begin at any point by opening or creating a patient record that contains a stream of vital sign data with synchronized events This is displayed in Figure 9, where the graph of vital signs is overlaid with events, and the events are detailed on theright 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 whatdetail, 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:

• Synchronization of manually-entered information with streaming vital signs This function time stamps medic-initiated data entry, such as interventions and observations, with real-timesensor 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 qualitativeand 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 Forexample, 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:

• 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, andpatient vital signs The data is stored with XML tags to semantically define the

information iRevive also allows conversion of this XML data into standard SQL tables,

enabling traditional SQL querying and use of report-generating tools such as Crystal Reports.

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