An intelligent pre-hospital patient care system

Download PDF
0 downloads 0 Views 1015KB Size Report
Comment
Services Investment Guide: Maximising ROI in Uncertain Markets, is in press with Wiley ... cyclical quality management activity demands complete and accurate end-to-end ... In those settings where electronic patient data ... A transport plan is ..... much research to be done as iRevive moves from development to deployment.
Int. J. Electronic Healthcare, Vol. 3, No. 1, 2007

An intelligent pre-hospital patient care system Mark Gaynor*, Dan Myung and Nada Hashmi Boston University School of Management 595 Commonwealth Ave. Boston MA, 02138, USA and also of: 10Blade, Inc. E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author

G. Shankaranarayanan Boston University School of Management 595 Commonwealth Ave. Boston MA, 02138, USA E-mail: [email protected]

Steve Moulton 10 Blade, Inc., c/o BMF Robins Street, Hangar 1727 Hanscom Air Force Base Bedford, MA 01730, USA E-mail: [email protected] Abstract: iRevive is a sensor-supported, pre-hospital patient care system for the capture and transmittal of electronic patient data from the field to hospitals. It is being developed by 10Blade and Boston MedFlight. iRevive takes advantage of emerging technologies to offer a robust, flexible, and extensible IT infrastructure for patient data collection. Keywords: mobile computing; sensors; electronic Patient Care Records (PCRs); emergency medical services; aeromedical; web services; HL7. Reference to this paper should be made as follows: Gaynor, M., Myung, D., Hashmi, N., Shankaranarayanan, G. and Moulton, S. (2007) ‘An intelligent pre-hospital patient care system’, Int. J. Electronic Healthcare, Vol. 3, No. 1, pp.107–122. Biographical notes: Mark Gaynor 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 sensor/RFid networks and applications, architecture promoting innovation, applying emerging technology, IT for medical applications, standardisation in the IT Copyright © 2007 Inderscience Enterprises Ltd.

107

108

M. Gaynor et al. area, designing network-based services, and wireless internet services. He is a Co-PI on an NSF grant studying virtual markets on a wireless grid. He is Technical Director and Network Architect at 10Blade. His first book, Network Services Investment Guide: Maximising ROI in Uncertain Markets, is in press with Wiley (2003). Dan Myung received his AB in Computer Science from Harvard University where his main interests were communications and developing new networking services. While at Harvard, he interned at software companies developing communication tools and services. Myung is now Head of software development at 10Blade. Nada Hashmi received her MS in Computer Science in 2004 from the University of Maryland, College Park (UMd). Her research interests at UMd involved exploring the semantic web technologies and applying them in the life sciences domain. She has also done extensive work in software testing of Java-based applications. While at UMd, she interned with the Decision Systems Group of Harvard/MIT at Brigham and Women’s Hospital as well as the Bio-informatics Group at Fujitsu Laboratories of America. She is now a Lecturer and directs efforts for Quality Assurance at the College of Business Administration, Jeddah, Saudi Arabia. G. Shankaranarayanan is an Assistant Professor in the Information Systems Department in Boston University School of Management. His research areas include schema evolution in databases, heterogeneous and distributed databases, data modelling requirements and methods, and structures for and the management of metadata. Specific topics in metadata include metadata implications for data warehouses, metadata management for knowledge management systems/architectures, metadata management for data quality, and metadata models for mobile data services. His work has appeared in Decision Support Systems, Journal of Database Management, and in the Communications of the ACM. Steve Moulton, MD is an Associate Professor of Surgery and Pediatrics at Boston University School of Medicine and Boston Medical Center, where he is the Chief of Pediatric Surgery and the Director of Pediatric Trauma. 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), a startup company developing application software, sensors and sensor network infrastructure for the management of critically ill and injured patients.

1

Introduction

This paper describes a next generation patient care system for pre-hospital airmedical transport. The system, called iRevive, is being developed1 by 10Blade, Inc., the University of Arizona and Boston MedFlight (BMF)2 under a grant from the National Institutes of Health. BMF is one of US largest, non-profit critical care transport services and as such, plays a central role in our local and regional Emergency Medical Services (EMS) systems. BMF 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 centres in Boston each year.

An intelligent pre-hospital patient care system

109

Maintaining a high quality of service is critical to the success of BMF and an integral part of BMFs organisational philosophy. BMF 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. 2 The clinical record is incompletely captured, poorly accessible, and unable to support a rigorous QA/QI process. Emergency Medical Services systems play a critical role in the initial evaluation and management of ill and injured people. These services are overseen at the national, state and local levels and most are publicly supported. Providing emergency pre-hospital care with limited financial resources means that scarce extra funds are usually directed toward the purchase of new vehicles and basic medical equipment, rather than new information technology. A majority of our EMS systems therefore rely upon handwritten reports (called Patient Care Records, or PCRs) to document the pre-hospital care they provide (Shanaberger, 1992; Anderson, 1999). In those settings where electronic patient data capture has been implemented, there is no facility for the electronic exchange and integration of pre-hospital with in-hospital patient data systems. This is a major flaw in our emerging IT healthcare infrastructure, for it fails to recognise the potential value of complete and continuous datasets – a fault that iRevive seeks to redress. iRevive employs new and emerging technology to capture, transmit and integrate the pre-hospital phase of patient care with in-hospital care. Real-time patient data capture is provided by wireless physiologic sensors and a mobile database with embedded rules to guide documentation. The combined patient data can be forwarded in real-time to an awaiting hospital, where it can be evaluated by unencumbered healthcare professionals. They may be able to provide valuable input to the transport team, but more likely will use the pre-hospital information to better prepare and anticipate the immediate needs of critically ill patients who are enroute to their facility. By later combining pre-hospital data with hospital outcomes data, the opportunity to identify best practices should lead to better outcomes and lower overall heathcare costs. This paper makes several interesting contributions. First, it offers a set of technologies that permit continuous and real-time capture of vital signs. Second, it describes an application that allows medical personnel to electronically document the pre-hospital care provided. Specifically, it proposes a rule-based component that ensures that the documentation is performed in the correct order, is complete, and is accurate. The iRevive infrastructure enables a seamless integration of the real-time sensor data with manual documentation on treatments and observations. Third, it identifies a set of emerging standards that appear mandatory for the successful acceptance of a medical IT application. Finally, it proposes an architecture that integrates all of the above to create a robust, flexible, and intelligent infrastructure for iRevive.

110

2

M. Gaynor et al.

System architecture

The high level view of the iRevive system is illustrated in Figure 1. This figure illustrates the five phases of a typical BMF mission: request for service, patient assessment, patient transport, patient delivery and finally documentation completion and data transfer. Data capture begins when BMF receives a request for patient transport. A transport plan is then filed and the closest, most appropriate transport vehicle (helicopter, jet or ground ambulance) is dispatched to the scene of the accident or medical facility for patient pick-up. Upon arrival at the scene, BMF nurses and paramedics are briefed by first responders. Then a vital sign sensor is placed on the patient and the patient is assessed, ongoing treatment is reviewed, and additional treatment may be carried out and, time permitting, the documentation process is started. The data capture phase ends when patient care is transferred to the physicians and nurses at the receiving hospital or trauma centre. At this point patient data can be transferred into in-hospital medical IT systems. The final phase requires completing all necessary documentation of the mission and transferring this data to the BMF database for billing, storage and future retrieval. The system and its infrastructure are built using emerging technologies such as mote-based sensors, mobile wireless devices, next generation Wide Area Networks (WANs), the Data Elements for Emergency Department Systems (DEEDS) data standard, web services, Health Level 7 version 3 (HL7v3) messaging, and rule-based data capture. Inexpensive wireless vital sign sensors, such as mote-based pulseoximeters,3 can support the continuous and real-time capture of vital signs. These vital sign datasets can be correlated with field observations and interventions as they are entered into the iRevive application running on a mobile tablet PC with wireless capabilities. When data exchange is necessary, data is transported using web services with HL7v3 compliant messaging. Traditional data capture is augmented with rule-based intelligence that ensures complete and consistent capture and tracking of the data. This data is stored into a DEEDS compliant relational database that forms the back-end of this application. Figure 1

High-level view

Major Medical Centre

Accident Scene

(1) Call

(2) Pickup

(3) Transport

(4) Drop off

Data capture with mobile wireless devices

(5) Database/Billing

An intelligent pre-hospital patient care system

111

Figure 2 illustrates how the iRevive application (Gaynor et al., 2004; 2005) will be used by BMF. The arriving medic will place wireless vital sign sensors on one or more patients to automate vital sign capture by the application. Each medic will be equipped with a ruggedised tablet PC that captures and displays the real-time sensor data and allows the manual documentation of observations and treatments. Manual data entry is guided by a set of rules that enforce consistent and complete capture of data. Captured data will be used to support the QA/QI process, billing and research. Each transport vehicle is equipped with a base station that links both to local technicians, command centres, and destination hospitals. This WAN linkage will enable global allocation of resources, and increased awareness of the condition of incoming patients at destination hospitals. A detailed conceptual architecture of iRevive is shown in Figure 3. It 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 data exchange in a manner that is compliant with the HL7v3 data exchange standards. Patient care data from the documentation component is transferred to the organisational data repository, in this case BMFs 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 plethora of emerging medical sensors and devices. This 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 because it permits plug-and-play integration of sensors and supports interoperability as it uses web services and HL7v3. Figure 2

iRevive use case

802.11

Cellular/Satellite Network

Internet Tablet PC and iRevive

802.15.4

Base Station GPS-enabled with multi-frequency transmitter and Sensor Gateway

VitalDust sensor on patient

Figure 2 – iRevive Use Case

Central Command Site 1

Site 2

1 –critical 1 – moderate 1 - minor

2 –critical 1 – moderate 1 - minor

112 Figure 3

M. Gaynor et al. Conceptual architecture of iRevive

Satellite, EVDO (cellular), 802.11 HL7v3/Web Services

HL7v3 Web Services Proprietary Protocols

Sensor Gateway

Organization Database of Electronic Health Record with Real-Time Sensor Data

Basic Web Services

Figure 3 – iRevive Application We have adopted the sensor gateway architecture because it provides the flexibility to manage the uncertainty of not knowing what protocols and standards medical sensors may adopt in the future. Similar to the layered internet architecture that enables internet applications to work over any type of LAN, the sensor gateway enables applications to consume sensor data from a group of heterogeneous medical sensors with a common interface. The gateway supports drivers for multiple different sensors, ranging from sensors developed by established vendors such as Welch Allyn to sensors developed in non-commercial research environments such as Vitaldust (described in Section 3.1). This gateway approach decouples sensors from applications, thus providing flexibility in sensor choice and the ability of applications to evolve independently of the sensors that provide data to the applications. A unique feature of iRevive is the integration of fine-grained real-time vital sign data with manually recorded human observations and interventions. As sensor data streams into iRevive it is correlated with manually entered data to create a patient time-line of observations and procedures. This integrated data offers a time-synchronised view of vital signs, observed changes in patient conditions, and treatments/interventions performed. It should enhance the ability of researchers to gauge the effectiveness of in field interventions in the context of long-term outcomes. The logical system architecture for iRevive has three layers: the Graphical User Interface (GUI), the Data Processing (DP) layer, and the database (DB) layer. These layers and their interactions are illustrated in Figure 4. The bottom layer is the database layer. This layer includes a repository in which the rules that guide data capture are formally represented and stored, a data repository for the patient care data, and a metadata repository that helps reorganise the captured data for auditing, billing, and mining. The middle is a data processing layer that has two main modules: the semantic interpretation component that evaluates rules based on input data and the data

An intelligent pre-hospital patient care system

113

display/capture module that pulls and pushes data between the underlying database(s) and GUI. During the transfer of data between the database and the GUI, the data display/capture module interacts with the semantic interpretation component to apply and verify rules for data capture and to validate the input data. This layer ensures the capture of a complete set of data elements that are consistent with the patient’s clinical characteristics, condition, and the applicable medical protocols associated with various procedures. The GUI is the layer that the clinician will interact with to enter clinical data for documenting the patient’s care and changing conditions. This layered structure is motivated by the medical industry and its evolving standards for patient care, as well as the ever changing set of requirements for medico-legal documentation. Each layer is examined in more detail in the following sub-sections. Figure 4

Layered architecture in iRevive

GUI

Data Processing

Database

User Interface

Semantic Interpretation

Rules

Data Display/Capture

Meta Data

PCR Data

Figure 4 – iRevive Details

2.1 Database layer The data layer in the iRevive architecture has three main components: 1

A metadata repository that 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 and formatting requirements for BMF (or any other clinical care organisation) documentation and reporting needs.

2

Patient data is captured in a state-of-the-art relational database management system. It includes not only the description of the patient, his or her injuries or condition, treatments and procedures, but also detailed clinical and administrative documentation (e.g., specific data points defining the physical exam, qualitative and quantitative descriptors for medications and interventions) that must be associated with the more structured patient data. This database is also capable of storing the real-time sensor data collected by the sensor gateway and pulled in using web service requests. The fields in the metadata repository index the patient data containing clinical or administrative documentation.

114 3

M. Gaynor et al. A rule-base to validate and enforce complete data entry. These rules represent the complex inter-dependencies between the data. 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 must be displayed and the sequence in which the data must be captured. The rules are currently represented using XML data encoding. These three layers interact to ensure consistent and complete data capture.

The reporting metadata structure is designed to allow a clinician to specify and codify data points in forms and fields. This allows BMF 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 organisations such as BMF do not need frequent alterations. An advantage of the reporting metadata is that it facilitates sharing of iRevive’s clinical documents with various other data sources. The data types and fields are defined by HL7’s XML Implementation Technology Specifications and the DEEDS data definition standard. This allows sharing iRevive’s schema and facilitating the semantic understanding of iRevive’s data. It also makes iRevive compatible with messaging protocols that are currently being defined for data exchange between pre-hospital care providers and emergency departments. The rules guide and streamline the workflow of the medics as they enter patient data. For example, ‘if the skull is fractured, then the pupils must be checked’, or ‘the dosage and time administered must be recorded if the drug is aspirin and the patient has a cardiac condition’. Parameters for drug dosages and administration-intervals are defined within the rules as well. While the documentation requirements for drugs such as aspirin can be pulled from the metadata, information on when and how it must be administered must be encoded within the rules. Rules might also be used to define templates for ‘regular’ patients based on the 90% rule. For example, in most trauma cases ALL other measurements are normal except the actual point of injury. However, for the PCR to be complete and sound, it must be documented that certain body parts were examined and found to be normal and uninjured. The rules become even more complex when contextual data plays a role, e.g., ‘for an adult with a history of hypertension, document the administration of certain drugs in certain conditions’. The semantics of what defines an adult, what are the drugs, and the conditions captured are represented as rules. These rules are interpreted in the semantic interpretation function of the DP layer.

2.2 Data Processing Layer (DPL) The Data Processing Layer (DPL) contains the Semantic Interpretation (SI) function that evaluates and interprets the rules. This guides the medic to enter complete and consistent data and guide the Data Display and Capture (DDC) module that displays information to the medic including real-time vital signs and processes data input. The DDC queries the SI, requesting it to contextually validate incoming data in the context of data that was entered earlier. The DDC also consults the SI to ensure that the data entered is complete in the context of the current event that is being monitored or documented. This interaction is very dynamic and as information about the patient is entered, the relevant rules may change:

An intelligent pre-hospital patient care system •

115

Validation for the correctness of the individual field This is both a qualitative and quantitative check of the field. For example, an adult over 200 kg must be administered some drug (say, lidocaine) at a higher dosage, but within a certain range, whereas a child with the same condition has a different set of constraints for the same drug. The SI interacts with the DDC to verify data based on the current context. If the constraint is not met, an error message is returned to explain why the data is out of normal bounds. This helps to eliminate any errors in data entry as well as tag abnormal cases for research purposes.

•

Fulfilment of mandatory data/documentation Certain fields and situations trigger the need for additional information. For example, cardiac patients may require that aspirin be administered. The DDC tells the SI that the patient has a cardiac condition (as specified by the medic) and queries the rules to discover the mandatory data entry form needed for documenting the administration of aspirin. Furthermore, the form for aspirin has some mandatory fields and optional fields. The SI identifies the set of mandatory fields that are not completed, sending a message to the DDC querying the medic to explain why or to correct the error.

The DDC and SI work as a middle layer helping to both guide the practitioner as well as verify that the data entered is correct. This layer uses metadata to define WHAT is the expected data, WHAT IS STORED, and RULES for intelligent data entry to ensure consistent and complete data capture. This flexible layer also enables a data capture mechanism that improves over time. As data is collected, and later mined for patterns, new rules, forms and fields may be identified and suggested. Reconfiguring this layer does not require recompiling the application, just updating the metadata. The results of data mining should, therefore, provide feedback and enhance the forms and rules that will ultimately improve the quality of the medical data captured.

2.3 User interface The GUI of iRevive is designed to meet the needs of mobile flight nurses and paramedics. Using feedback from BMF, the GUI of iRevive has been tailored to their particular needs for transporting the most critical 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 such as PDAs, or even cell phones. The fields and there 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, and the ability to evolve in the context of adding new fields and forms. To meet this flexibility requirement the GUI’s input components are driven by data definitions and meta information from the data and rules. The specifications are defined 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 for BMF, as a static user interface and database schema will not be functional in the face of the rapidly changing needs for medical documentation. Below in Figure 5 is an example of what the user views. The GUI allows high level views of the entire body, or a zoomed in display for a particular body region. It includes pull down menus appropriate for the current view.

116

M. Gaynor et al.

Figure 5

iRevive GUI

Figure 5 – iRevive GUI 2.4 Network infrastructure The mobile application can be a standalone application without any network connectivity, but is significantly enhanced with LAN and WAN network interfaces to allow local distribution of global data, and global distribution of local data. The wireless mobile devices are 802.11 compliant, which allows iRevive to exchange data over the LAN infrastructure enabling the integrate of real-time sensor data into the patient care record. Sensor data can be delivered to a local application by a web service, thus de-coupling this sensor data from the application to allow easy application development, maintenance and a choice of sensors. This 802.11 connectivity is used to download patient data captured on the mobile wireless devices into BMF’s central database. In addition, each mobile device may include an optional cellular WAN connection for wide area connectivity to the receiving hospitals4 and the central database at BMF. This has been tested with Verizon’s 3G EVDO cellular network in the Boston area. In the future, we plan to include more ubiquitous WAN networks such as the LEO satellite based Iridium network. The LAN/WAN infrastructure, while optional to the operation of iRevive, is a powerful enhancement allowing better and faster data flow.

3

Emerging technologies in iRevive

A unique aspect of iRevive is the combination of emerging technologies that create a flexible system. This will meet current requirements and evolve to meet future needs that are not yet known. Integrating real-time physiological sensor data into the electronic patient care record, and leveraging wireless communication standards, enables improved situational awareness for medical first responders. Displaying and capturing data on a mobile device with wireless capabilities offers a whole range of benefits related to improved communication and access to more current information. Below we discuss these emerging technologies within the iRevive system.

An intelligent pre-hospital patient care system

117

3.1 Sensors Our research team has built a simple sensor shown in Figure 3 based on a commercial pulse oximeter sensor for OEM products. Our unit is called Vitaldust5 (Gaynor et al., 2004). It streams a patient’s heart rate and level of blood oxygen saturation over a wireless link. Vitaldust is based on small, low-power nodes (often called motes, or smartdust) consisting of simple embedded micro controllers and low-bandwidth radios operating in the microwave (2.4GHz) spectrum range, which are known as the IEEE 802.15.46 and Zigbee7 standards. This emerging wireless sensor networking technology has enabled a new state of the art infrastructure for EMS. Sensor data must be ‘application friendly’ if it is to facilitate the widespread integration of real-time sensor data within medical IT applications. The emerging web services and HL7 standards are becoming the dominant design technology for the exchange of data between distributed medical applications. Our infrastructure has adopted these standards for both local and wide area exchange of real-time patient vital sign data. Local connectivity of sensors to iRevive does not depend on the internet. However, when connected via a cellular or satellite link, access to the real-time sensor data is available, as a web service, to a centralised or a set of distributed command centres (a temporary ‘head-quarter’ established at/near the accident-site that coordinates activities and resources). The easy application environment promoted by web services will help fuel the inclusion of sensor data into medical applications.

3.2 Standards Section 2 described how our infrastructure is built from emerging standards that promote interoperability allowing data exchange with heterogeneous medical IT systems. There are standards to be adopted at the different layers for exchanging (for example, between iRevive and the receiving hospital) and storing data used to accomplish this goal. These standards include the emerging suite of web service protocols for building distributed computing environments, DEEDS to define the structure of emergency medical data, and HL7 to define the context and message protocol for exchanging medical information between heterogeneous systems. All of these standards were developed independently and are now evolving to allow compatibility and interoperability. DEEDS, HL7, and XML are standards that work together to define the structure, format, and content of electronic medical records in iRevive.

3.2.1 Web services Web services (Gaynor et al., 2002) represent the first widely accepted set of standards to define a distributed computing environment. The strategic advantage of the web services architecture is the flexibility to integrate heterogeneous information systems within and across organisational boundaries. The technology of web services includes standards such as Extensible Markup Language (XML) that can encode all types of data including medical records (Sokolowski and Dudeck, 1999), Simple Object Access Protocol (SOAP),8 Web Service Description Language (WSDL) (Graham et al., 2002),9 and Universal Description, Discovery, and Integration (UDDI).8 Below is a short description of these fundamental standards surrounding web services:

118

M. Gaynor et al.

•

XML is a standard for describing data independent of platform and application that is becoming the lingua franca of the internet. XML is the foundation on which the remaining web services standards are built upon.

•

SOAP is a standard for packaging the information exchanged with web services. Using XML, SOAP defines the format of messages passed back and forth between the web service client and the server.

•

WSDL provides a standard method for describing what a web service does and how it should be invoked. It documents how to invoke a web services in a machine-readable format.

•

UDDI is the standard for registries, which describe large numbers of web services and thereby facilitate the search (possibly at run time) for appropriate services to meet application requirements. UDDI is a ‘yellow pages’ of web services.

3.2.2 Health Level 7 (HL7) Health Level 7 (HL7)10 provides standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, its mission is to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems. HL7 compatibility implies semantic compatibility for healthcare messaging. It provides a messaging schema along with storyboards and scenarios to specify the correct context these messages are used in, in addition to protocols for a developer seeking to do such exchanges. A schema and protocol for messaging is defined for unique situations, for example the defining of messages for an emergency department’s IT system to allow for patient admission, specialist consult and finally patient discharge. The next version of HL7’s messaging framework is Version 3 – it is fully defined in XML for long-term compatibility and flexibility. For example, the XML schema is flexible and allows varying date formats (for the USA, it will be MMDDYYYY, whereas in Europe the date format may be DDMMYYYY). The emerging HL7 standards promise at least the technical requirements for interoperability. One example of a wide reaching HL7 initiative is defining the Electronic Health Record (EHR)11 that seeks to define a holistic set of functionality that a system must or should have to be compliant. For example – an EHR system must have password authentication and it must have a logging method for tracking user access. It should keep timestamps on all data alterations, but must be able to query patients by first and last name, as well as a government issued ID. A recent movement in the HL7 space has been to integrate some of the principles of the EHR with the development of messaging and functionality in the emergency departments of hospitals. The development of DEEDS 2.0 and HL7’s EHR and v3 messaging has presented itself as a unique ecosystem. Where DEEDS defines data points, v3 messaging is about how they are communicated, and the EHR defines how they are used. They all depend on feedback between each other as the standards are developed. For example, EHR mandates the ability to delineate transfer of care from one person or organisation to another; this will not be possible unless the messaging protocol supports such an event, and the messages will not be used unless compatibility exists

An intelligent pre-hospital patient care system

119

between fields such as the timestamps and identifiers which are required for collection in the first place. Adhering to the HL7 set of standards is an important step towards interoperability between iRevive and emerging hospital data sets. These changing standards present an interesting design challenge for the iRevive system. Since changes to functionality and data definition requirements can be injected anywhere (on the data definition, the functionality, or the messaging side) it becomes ever more important that the components for iRevive be flexible to accommodate such changes. Hence, we created our 3-tier architecture such that the data component (the database), the HL7 messaging component, as well as the functional components are independent of each other. Independence in this case implies not making assumptions of structure or content, but still being compatible should changes occur within other components.

3.2.3 DEEDS The Data Elements for Emergency Department Systems (DEEDS) (NCIPC, 2005) standard is defined to assist in the storage of clinical data and its retrieval during direct patient care as this is the primary function of the Emergency Department (ED) record system (Pollock and Daniel, 1999). The primary focus of DEEDS is defining the data elements in current clinical use. The National Committee on Vital and Health Statistics states that the specifications for DEEDS data elements incorporate national standards for healthcare data, particularly standards applicable to electronic patient record systems (Pollock and Daniel, 1999). Data types and other relevant specifications in Version 1 of DEEDS conform to HL7 Version 2.3, and an appendix maps DEEDS data elements to HL7 fields and segments. HL7v2.xml is intended to help bridge from non-XML HL7 to the emerging XML only encoding in HL7v3. Other related standards include the US Bureau of the Census industry and occupation codes,12 Office of Management and Budget standards for classifying race and ethnicity,13 the X12 healthcare provider taxonomy (Sokolowski and Dudeck, 1999), Logical Observation Identifiers Names and Codes (LOINC) (Huff et al., 1998)14 – for laboratory result types, and the International Classification of Diseases 9th Revision (ICD-9)15 external cause of injury and condition codes. The availability and adoption of the DEEDS standard has important implications for the design of pre-hospital patient-care documentation systems such as the one described here. By conforming to this standard, the integration of the pre-hospital patient care data with other electronic documents (such as patient history (old PCRs) for that patient or the PCR reflecting subsequent in-hospital care provided to the patient) is made easier. Further, the available mapping of specifications between DEEDS and HL7 facilitates the automated generation of a ‘transferable’ PCR that can be electronically communicated to the receiving (hospital ED). The receiver can then reverse the mapping and obtain the DEEDS-compliant pre-hospital PCR that can then be integrated with the patient’s data in the EDs system, thus completing a seamless data transfer that preserves the integrity and consistency of the data. The DEEDS standard is important for ensuring the interoperability between iRevive and emerging IT systems in the hospital ED.

120

M. Gaynor et al.

3.3 Mobile wireless devices Our infrastructure utilises wireless mobile devices to enable the users the ability to access and capture data as they roam at will in the local area. The main requirement is that the mobile device has at least a wireless 802.11 link, and preferably be multi-frequency with a 3rd generation cellular interface. The data entry component of the iRevive application promotes the collection and capture of a consistent and complete record starting with the initial call to BMF and ending at patient drop off. At patient drop off iRevive can electronically transfer the current patient data to the receiving hospital. Finally, this electronic patient care record is transferred via a wireless network16 into the central database when the BMF team arrives back at its base of operations. Based on requirements specified by BMF it was decided to employ a tablet PC with wireless communication interfaces for data entry. Experimentation with PDAs17 found the screen size and form factor too small for easy use. However, as PDAs become available with larger displays and higher resolution or in situations where size and weight are critical factors, then PDA’s and even cell phones could be viable options for data entry and display. The use of heads-up display technology and voice recognition software to further free the medic while performing various tasks is also being investigated. Although the current application runs on a standard tablet PC, the flexible GUI design allows its easy porting to any mobile device. By combining numerous emerging technologies such as sensors, broadband 3G cellular networks, interoperability standards, and mobile devices, iRevive creates a unique pre-hospital EMS documentation system. Our design is modular to allow these technologies to evolve independently within of the iRevive application. There is still much research to be done as iRevive moves from development to deployment.

4

Conclusions and future work

This paper discusses a mobile wireless pre-hospital patient care application called iRevive. We are nearing the end of the development phase and will soon begin joint testing of the GUI with the medics who will be using the application. In-flight testing should begin in the summer of 2006. The iRevive application will enable BMF to create electronic patient care records on mobile wireless devices, transfer this data to BMF for management and billing, as well as to traditional in-hospital database systems. The iRevive application is an important step both in the creation of pre-hospital electronic patient information, and the integration of real-time sensor data into this electronic data. By combining several emerging technologies such as wireless sensors, web services, medical data and messaging standards, intelligent rule processing, and mobile wireless devices iRevive will add value to BMF’s operation by allowing complete and consistent documentation. The sensor technology will allow a detailed record of vital signs data that will enhance evidence-based medical research; and the use of mobile wireless devices will allow situational awareness of local medics and receiving hospitals. The iRevive infrastructure creates a robust, intelligent, and flexible infrastructure for capturing out-of-hospital patient data. Our team is working to build a more flexible implementation of iRevive because these emerging standards such as XML, DEEDS, and HL7 are moving targets. This has three contexts: flexibility to interface to HL7 compliant systems (emerging v3 and previous

An intelligent pre-hospital patient care system

121

versions), flexibility to exchange data with legacy systems, and flexibility in granularity of access to data by allowing requests of an entire patient care record (a set of related fields) or a single field within. There are several solutions for interoperability with legacy systems that do not comply with emerging standards for data exchange such as XML, DEEDS, and HL7. One efficient method uses a mediated approach (Gupta, 1989) that utilises a common format that all standards are translated into and out of. An architecture for this approach is a ‘web-services’ wrapper converting proprietary data formats to an intermediate format, and then into the DEEDS/HL7/XML standard data encoding. This will involve building an XML based mapping scheme to convert many heterogeneous legacy systems (such as the Trauma Registry of the American College of Surgeons (TRACS))18 and HL7v3 standards into and out of the intermediate format. The interoperability of these many standards is an open question for further investigation.

Acknowledgements We wish to thank the following organisations for helping fund our research: NIH grant (NIH 1 R41 RR018698-01A1), NSF (PFI-0227879, ACI-0330244, IIS-0529798), and BUILDE at Boston University School of Management. We also thank Verizon and Lucent for donating several PDA’s, PMCIA cards, and service that interface to Verizon’s new 3rd generation cellular EVDO network.

References Anderson, C.W. (1999) ‘Patient care documentation’, Emergency Medical Services Magazine, Vol. 28, No. 3, pp.59–62. Gaynor, M., Iver, B., Wyner, G. and Freedman, J. (2002) Web Services Tutorial AMCIS 2003 in Tampa, FloridaXML, www.xml.org. Gaynor, M., Seltzer, M., Moulton, S. and Freedman, J. (2005) ‘A dynamic, data-driven, decision support system for emergency medical services’, Proceedings of the International Conference on Computational Science 2005. Gaynor, M., Welsh, M., Moulton, S., Rowan, A., LaCombe, E. and Wynne, J. (2004) Integrating Wireless Sensor Networks with the Grid IEEE Internet Computing, Special Issue on the Wireless Grid, July–August. Graham, S., et al. (2002) Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI, Sams, Indianapolis. Gupta, A. (Ed.) (1989) Integration of Information Systems: Bridging Heterogeneous Databases, IEEE Press. Huff, S.M., Rocha, R.A., McDonald, C.J. and De Moor, T. (1998) ‘Development of the Logical Observation Identifier Names and Codes (LOINC) vocabulary’, Journal of American Medical Information Assoc. (j-amia.org). National Center for Injury Prevention and Control (NCIPC) (2005) DEEDS – Data Elements for Emergency Department Systems, http://www.cdc.gov/ncipc/pub-res/deedspage.htm. Pollock, A. and Daniel, A. (1999) Report of the Work Group on Computer-Based Patient Records, National Institute of Vital and Health Statistics, May. Shanaberger, C.J. (1992) ‘The unrefined art of documentation’, J Emerg Med Svcs, Vol. 17, No. 1, pp.155–157. Sokolowski, R. and Dudeck, J. (1999) ‘XML and its impact on content and structure in electronic health care documents’, Proc AMIA Symp.

122

M. Gaynor et al.

Notes 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

We are in the latter stages of development with plans for in-flight testing in the summer of 2006. BMF; www.bostonmedflight.org This device is a non-invasive sensor to measure a person’s pulse rate, and the level of oxygen saturation in their blood and is discussed further in Section 3.1. This assumes that the receiving hospital has the IT infrastructure and data sharing agreements in place. Vitaldust is a wireless pulse oximeter built from off the self hardware at Harvard University by Matt Welch and his research group. IEEE 802.15 WPAN™ Task Group 4 (TG4), http://www.ieee802.org/15/pub/TG4.html. Zigbee Alliance Home Page, http://www.zigbee.org. The World Wide Web Consortium SOAP Version 1.2 Part 1: messaging framework, W3C Recommendation 24 June 2003, http://www.w3.org/TR/SOAP. The World Wide Web Consortium, ‘Web Services Description Language (WSDL) 1.1’, W3C Note 15 March 2001, http://www.w3.org/TR/wsdl. Health Level Seven 1997 – 2005 Health Level Seven, Inc. http://www.hl7.org/. We refer to this as the Patient Care Record. Census of Fatal Occupational Injuries (CFOI) – Current and Revised Data, http://stats.bls.gov/ iif/oshcfoi1.htm. Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity, http://www.whitehouse.gov/omb/fedreg/ombdir15.html. Logical Observation Identifiers Names and Codes, www.regenstrief.org/loinc/ (LOINC®) American Medical Association, ICD-9-CM 2005 – International Classification of Diseases, AMA. Future enhancements will allow the transfer of patient information to BMF and hospitals during patient transport. Verizon and Lucent have donated several PDA’s, PMCIA cards, and service that interface to Verizon’s new 3rd generation cellular EVDO network. The American College of Surgeons Trauma Programs, http://www.facs.org/trauma/.