abstract
Emergency Medical Services (EMS) are not only responsible for providing prompt and efficient medical care to many different types emergencies, but also for fully documenting each and every event. Unfortunately, the vast majority of EMS events are still documented by hand. The documents are then further processed and entered manually into various billing, research, and other databases. Hence, such a process is expensive, labor intensive, and error prone. There is a dire need for more research in this area and for faster, efficient solutions. We present a solution for this problem: Prehospital Patient Care Record (PCR) for emergency medical field usage with a system called iRevive that functions as a mobile data base application. iRevive is a mobile database application that is designed to facilitate the collection and management of prehospital data. It allows point-of-care data capture in an electronic format and is equipped with individual patient sensors to automatically capture vital sign data. Patient information from the field is wirelessly transmitted to a back-end server, which uses Web service standards to promote interoperability with disparate hospital information systems, various billing agencies, and a wide variety of research applications. In this topic, we describe the current state of EMS, the iRevive application, a mini-trial deploying iRevive in real scenarios, the results, and a future direction for our solution.
Introduction
There are times when an individual’s life may depend on the quick reaction and competent care of emergency medical technicians (EMTs). These highly trained, prehospital healthcare providers are dispatched by 911 operators to incidents as varied as motor vehicle crashes, heart attacks, near-drowning events, childbirth, and gunshot wounds. Their first priority is to stabilize a patient’s cardiopulmonary status. They must then determine the nature and severity of the patient’s condition and whether the patient has any preexisting medical problems. EMTs follow strict rules and guidelines in their provision of emergency care and often use special equipment such as backboards, defibrillators, airway adjuncts, and various medications before placing patients on stretchers and securing them in an ambulance for transport. At a medical facility, EMTs transfer the care of their patients to emergency department personnel by reporting their observations and actions to staff.
Equally important is EMS personnel documenting the care they provide. They do so in the form of a prehospital record, which must be completed for each patient who is treated or transported by them. The prehospital record is a medical and legal document used by emergency medical technicians to record a variety of data concerning a patient’s current illness or injury, past medical history, treatment rendered, and subsequent improvement or worsening of the patient’s condition (Mann, 2002). This type of prehospital documentation is used to support the actions of the crew, the transfer of care, and to justify reimbursement from various insurance companies; it is also used for quality improvement programs and research. Unfortunately, the vast majority of EMS events are still documented manually by hand on paper. This leads to an extensive amount of manual data processing as the often illegible handwritten data must sometimes be deciphered, then manually entered into various billing, research, and other databases. The whole process is expensive, labor intensive, and error prone.
The rest of this topic is sectioned as follows: first, an overview of the current state of EMS workflow, documentation methods, and research is provided. This section emphasizes the National Highway Traffic Safety Association’s goals for EMS in the future, including the call for a national EMS database and improved information systems, so that prehospital information can be linked with the hospital record. The next section is a description of one solution called iRevive, a mobile database for EMS professionals that streamlines data capture, communication, reimbursement processing, quality assurance, and research. It takes advantage of tiny wireless sensors to automatically record vital sign data. It permits multilevel decision support; the local EMT over his/her patient, the regional commander over a selected vicinity, and the central level of control over all the events occurring at a particular time. Actual deployment of iRevive, for live field-testing by Professional Emergency Services of Cambridge, Massachusetts, is examined and critiqued. This trial version was conducted without sensors or multilevel decision support. Finally, a future vision of iRevive is described, including the addition of many different types of sensors such as chemical sensors and GPS devices for location information. All exchange of data will be interfaced through Web services and conform to standards such as HL-7 to help the increase of data exchange and interoperability.
Background
Ambulances of the early 1900s were regarded as a means of transportation for the sick and injured from homes, work site, and public places to hospitals, where real treatment could begin. It was not until the advent of cardiopulmonary resuscitation (CPR) and the 1966 publication of a National Academy of Sciences paper entitled, “Accidental Death and Disability: The Neglected Disease of Modern Society,” that modern EMS systems came into being (Callahan, 1997). Later, with the introduction of cardiac defibrillation by trained crewmembers and more extensive airway training, the back of ambulances became the sites of true life-saving treatments. While emergency medical services have grown rapidly over the past 30 years, the scope of EMS research has not. Most EMS research focuses on a single intervention or health problem, and it rarely addresses the inherent complexities of EMS systems (Delbridge, Bailey, & Chew, 1998).
It is estimated that EMS systems treat and transport up to 30 million patients per year (NHTSA, 2001) and it is assumed that EMS intervention positively affects patient outcomes, but this is difficult to quantify. Studies have shown that early defibrillation and administration of certain drugs save lives, but other interventions including certain instances of intubations in the field may in fact cause more harm than good (Adnet, La-postolle, Ricard-Hibon, Carli, & Goldstein, 2001; Vahedi, Ayuyao, & Parsa, 1995). The fact that so few therapies have been examined in outcome studies illustrates a lack of evidence regarding the benefits of many prehospital interventions.
The lack of EMS systems data can be attributed in part to the healthcare industry’s delay in utilizing technology; it is one of the last industries to transition to the use of computers for daily operation (Cheung et al., 2001; Foxlee, 1993; Mik-kelsen & Aasly, 2001; Tello, Tuck, & Cosentino, 1995). Although some elements of the system are automated (e.g., computer automated dispatch), most EMS personnel record clinical information and other run data using paper and pen. Data collection is therefore limited and highly inefficient. In addition, the patient care report (PCR) that is completed after each EMS transport does not contain data regarding overall patient outcome. The reason for this is that outcome data is held by several different entities, sometimes including other ground and air transport services, hospitals, rehabilitation centers, and physician offices. These various healthcare entities may be affiliated with each other, but seldom are they officially linked and rarely do they exchange prehospital patient information. This lack of information exchange is further hampered by patient privacy laws, incompatible (proprietary) systems, limited data mining methods, and little impetus to form a continuous patient care record. The resultant lack of outcome data severely limits the type and amount of EMS research that can be carried out (Dunford, 2002). Compounding the overall problem is the recognition that serious medical errors can arise in the setting of incomplete data (Foxlee, 1993; Tello et al., 1995). These errors in the handing off of patient care can range from duplicative or delayed therapy to complete lack or inappropriate therapy.
current Methods
EMS personnel usually work in teams of two and divide the workload at a particular event. While one provider tends to the patient, the other interviews family members or bystanders, sizes up scene conditions, and searches for medications, identification cards, and insurance cards. The NHTSA currently mandates a data set of 40 items to be collected for each patient for each event, including such items as incident location, crewmember identification numbers, patient’s social security number, and physical exam findings. Additional insurance and billing information is required by ambulance services so that patients can be billed, while Medicare calls for waivers and prescription forms. It is when the patient’s condition is more critical that EMS team members must give their full attention to patient care, forgoing any attempts at data capture or documentation. It is data from these types of events, however, that are of greatest interest to emergency department personnel, researchers, and system administrators. And as EMS systems evolve to offer more advanced care, more time is needed for hands-on patient care and, in turn, more information must be documented (Mears, Ornato, & Dawson, 2002). To overcome these obstacles to better patient care, EMS systems must adopt information systems that streamline the recording, storage, retrieval, and application of quality information.
New methods are being developed to quantify and organize the plethora of data. In 1996, the NHTSA published an article entitled, “EMS Agenda for the Future: Implementation Guide”. This article stressed the need for a standardized EMS information system, based on uniform data elements and uniform definitions (NHTSA, 2001). In order to accurately draw conclusions there must be more information regarding care in the field, transportation, emergency department care, hospital care, and final patient disposition. To achieve these goals, EMS information systems must develop new ways to store and retrieve patient data so that patient information is always available. Data must be pooled from a communications center, ambulance personnel, emergency department staff, and finally, other agencies including fire departments, police departments, and medical examiners. Only then can there be a complete database containing all of the information necessary to describe an entire EMS event and facilitate continuous EMS system evaluation and research across multiple systems and to support patient care and EMS-related research (Delbridge, 1998). Our system, iRevive, attempts to address these problems and provides a novel solution in streamlining the data collection. The next section describes the iRevive system built to generate prehospital patient care record.
iRevive: The Mobile Database system
In working toward this vision of compatible EMS database systems that support healthcare data integration, changes must start with regard to how data is originally collected. iRevive is a mobile prehospital database system that allows point-of-care data capture in an electronic format. It consists of a network of wireless, handheld computers running the iRevive application. Wireless vital sign sensors, called VitalDust motes, automatically capture and integrate patient vital sign data directly into each developing patient care record. All of this information can be sent wirelessly from the field to a server that stores and relays selected patient information to receiving hospitals. The stored data is accessible to authorized users for billing and research purposes using Web services (Figure 1).
Figure 1. Current iRevive system architecture
iRevive explores improved documentation of EMS events by streamlining data capture and providing essential prehospital information for subsequent integration with the developing hospital record. Data entry is designed to be logical and intuitive. iRevive can “walk” an EMT through an assessment and remind him/her, for example, to evaluate a patient’s neurological response, an essential step that could easily be left out during the high-paced transport of a critically ill patient. Real-time sensors, which collect heart rate and blood oxygen saturation, provide realtime monitoring and enrich the data collection process. During transport or soon after arrival at a hospital, the EMT may choose to complete the PCR using a preset narrative template on the handheld computer. Alternatively, he/she can enter his/her own narrative using either the handheld computer’s pen pad or a computer terminal in the receiving hospital’s emergency department. Once the PCR is complete and electronically signed, it can be saved (in the central database) and printed (at the hospital) so that it can be included in the patient’s paper-based hospital record. The administrative back end aggregates the raw data into summary reports and statistics for operational analysis, performance measurement, and effective managerial decision making.
Prehospital Patient care Records
The iRevive prehospital patient care record consists of and captures three types of data. The first type of data is the information captured by the EMT which contains the preexisting conditions and the current conditions. Specially, it contains demographic information, a history of the patient’s illness or injury (HPI), past medical history (PMH, including medications and allergies), procedural information (e.g., IV access, splinting, and endotracheal intubations), and disposition information (Figure 2). The HPI section includes standardized narratives for more than 30 common complaints, which range from allergic reactions to “dead on scene.” The use of standardized narratives allows EMTs to quickly describe each incident using a series of drop-down option boxes, rather than writing an entire incident out in prose—a difficult task on a PDA. The addition of pertinent negatives and additional information in the event of special circumstances is also allowed. These narratives enrich the database and, in the future, will aid in the development of new knowledge-based treatment algorithms.
The second type of data captured is the documentation of critical examinations. It is devoted to an extensive physical exam including head, neck, chest, abdomen, pelvis, extremities, and nervous system. From the physical exam main menu, users may select and describe any part of the anatomy that has been found to be abnormal (Figure 3a). Selecting an “abnormal” button brings the user to additional pages where abnormal physical findings may be documented in detail using a series of pull-down lists (Figure 3b).
Figure 2. iRevive patient care report sections
Finally, the third type of data captured and recorded is the sensor data from motes such as the pulse-Oxometer and Vital Dust (Figure 4). The vital signs, such as the pulse rate and SP02 levels, from the patient are automatically recorded and sent continuously from the sensor to the PDA. Critical changes can be immediately noted by the EMT. The EMT no longer has to physically monitor the patient’s vital at regular intervals. He/she is automatically provided with more readings which results in a more accurate state of the patient at any particular time.
Figure 3a. iRevive physical exam main menu. If a normal button is selected, a statement is entered in the PCR indicating a normal exam. If an “abnormal” button is selected, then a detailed exam screen opens (CNS = central nervous system; PNS = peripheral nervous system; Cranial Nn = cranial nerves).
current Application Architecture
The iRevive application is written in C# under the .NET environment and therefore built to run on many types of mobile devices including PDAs, laptops, and wearable computers (Figure 5). iRevive provides a graphical user interface that users can navigate with a stylus. The application is primarily menu driven with customizable dropdown menus that increase efficiency by allowing for quick navigation and data collection. Once the data have been uploaded to a central database, a Web-based interface can be used to edit the PCR on any Internet-enabled PC.
Once field data have been synchronized with the iRevive database, EMS and hospital personnel can instantaneously track current patients and a complete patient care report can be generated and printed. Specific providers have access to the entire record base for billing, supply tracking, and continuous quality improvement (CQI) applications. Other users have the ability to access deidentified data that are nonconfidential for use in overall emergency service research and systems management. All data transfer is Health Insurance Portability and Accountability Act (HIPAA) compliant and the security is end-to-end (using standard Transport Layer Security). Users must be authenticated to use the system and only authorized users can view specific types of data.
Figure 3b. A detailed exam screen for the central nervous system (CNS) is shown (GCS = Glascow Coma Score, React. = papillary reactivity).
Figure 4. Sensor Data information transmitted wirelessly to the PDA.
Figure 5. The Future iRevive System Architecture
To encourage interoperability, the iRevive system is built around emerging standards such as the National Highway and Traffic Safety Board Uniform Prehospital EMS Data Set (NHTSA-UPDS) and the Data Elements for Emergency Departments Standard (DEEDS), which is the Centers for Disease Control and Prevention’s (CDC’s) specification for emergency department data that was created to assist data integration across information resources.
Field Trial Analysis Without sensors
One ambulance from Professional Emergency Services (Pro) of Cambridge, Massachusetts, was selected to field test iRevive. Pro is a moderate-sized private ambulance company with eight ambulances and 5 0 emergency field providers who respond to over 16,000 emergency calls per year. iRevive was used in parallel with the service’s existing handwritten documentation methods during emergency responses. Data were collected using a Hewlett Packard iPAQ Pocket PC, which was synchronized with a laptop satellite station before being uploaded to the server at the end of each shift. In an attempt to steer further product development, users focused on how the iRevive application could be improved. The effectiveness of iRevive in integrating and streamlining data capture was studied, along with its ability to merge with the current workflow of EMS professionals. Factors examined included ease of use, documentation completion, and content. The use of iRevive in the field was observed by a proficient user and ambulance crew chief. This was further examined via interviews with other ambulance crew members. Printouts of iRevive PCRs were then compared to handwritten reports from the same events.
A case study
In one real-life scenario, a call concerning chest pain and difficulty breathing was dispatched to an ambulance. While en route to the location, one EMT began to enter data into iRevive. Information included the incident location, type of response, and other pertinent dispatch information known at the time; the time of response was recorded in the times and mileage page. Upon arrival at the scene, time was recorded again while dispatch was notified of arrival via the radio. The time of arrival at the patient’s location in the third-floor apartment was also recorded. The first EMT began an initial assessment, obtaining vital signs, attaching a heart monitor, administering oxygen, and prepping an IV site. At the same time, the second EMT interviewed the patient and bystanders in order to gain a detailed account of the patient’s medical history, allergies, medications, and a history of the present illness. All pertinent information was recorded using pull-down menus within the iRevive program.
After recording placement of an IV catheter, oxygen delivery rate, and the type of oxygen device used, the medics determined that the patient should receive one dose each of nitroglycerine and aspirin. This was also recorded in iRevive. Once the patient was placed in the ambulance, a second set of vital signs indicated the need for a second dose of sublingual nitroglycerine, which was recorded in iRevive with a time stamp. En route to the hospital, the first EMT took over use of iRevive to record the time of transport and to complete additional sections as necessary. At the hospital, a verbal report was given to the emergency department staff as the patient’s care was transferred to an emergency physician. The iRevive PCR was then completed by an EMT with additional supplemental data pertaining to the transport and final patient disposition. A standardized narrative was completed to finish the event documentation. The PCR was then saved on the handheld and uploaded to the 10Blade server allowing immediate access to the PCR for emergency department, ambulance service, and billing.
Results
iRevive was used in conjunction with the standard method of EMS documentation at Professional Ambulance for 16 emergency transports. Of these transports, 12 were calls for medical help, 3 for trauma, and 1 for an assist. iRevive was used by 12 of the 50 field providers at Pro.
It was noted that both the methods captured the same type of data. However, as the iRevive data were electronic, once captured, they were easily ported to the necessary storage and are now available for any further research or analysis. There were difficulties encountered while capturing the data using iRevive which are presented in the next subsection. These difficulties were taken into consideration for the next version of iRevive.
Difficulties
The main goal behind deploying iRevive in the field was to obtain feedback and find out what problems should be addressed for the next release. Problems experienced can be categorized into two main categories: usage problems and need for more data points (Tollefsen, 2003).
Usage Problems:
• History of present illness page had to be navigated prior to discovering key information. This page would be better placed at the end of the report.
• Placement of times and mileage page at the beginning of the PCR required jumping back from pages in use to record times during procedures.
• Dispatch, scene arrival, scene departure, and hospital arrival times are recorded by the dispatch center; this information could be automatically synchronized with the 10Blade server in place of manually recording each time in iRevive.
• Program did not allow a PCR to be saved unless certain fields were completed.
• Inability to return to saved PCR until synchronized with server caused inability to continue to update report.
• Lengthy pull-down menus for certain items took too long to navigate; these could be improved by reordering or starting in a more appropriate range.
Need for More Data Points:
• Lack of appropriate values in some pull down menus required manual entry of these values.
• Insufficient space to record multiple allergies.
• Inability to draw a picture of patient or scene. Addition of human figure in order to point to areas injured is recommended. Integration with a digital camera was suggested.
Discussion
Overall, the ability of capturing data in an electronic manner proved to be a huge success. Having electronic data available automatically and as soon as the data are captured is a huge gain from the current state of the art. However, in this domain, the granularity for the type of data and the data content are very important. Even though the current version of iRevive contains all 40 points of the Massachusetts Office of EMS prehospital data set, the need for additional data points was recognized. In order to capture as many data points as possible and make iRevive more attractive to a broader number of EMS providers, several additions have been proposed, including the following:
• Type of response: lights and sirens vs. with traffic flow.
• Location type: to explain difficulties or irregularities (e.g., if the incident occurred at a school, parents would not be present).
• Additional patient information, such as estimated weight.
• Signs and symptoms of chief complaint, such as headache or syncope associated with a cut on a patient’s head.
• EMT’s impression of the event and patient state (e.g., psychiatric issues).
• Cause of trauma and additional information about the cause, such as severity of automobile damage, and whether the patient was wearing a seat belt.
• Reason for transport (e.g., generalized weakness).
• Additional information about the pain a patient is experiencing during the physical exam.
• Condition of the patient’s skin.
• Additional transport information, including position of patient and traffic delays.
• Signature page for capture of patient receipt.
Future version of irevive
The future version of iRevive aims to increase the usability and efficiency of the complete system. This will be done by the addition of more devices and functionality and increasing the role the ambulance plays (Figure 5).
It was observed the ambulance can play a key role in helping communications and transactions that take place during a response. In the future version of iRevive, the ambulance will play the role of a hub bridging real-time communication from the PDA to the hospital housing the central command. The ambulance will contain a wireless network connection (satellite, cell) as well a global positioning system (GPS) tracking its location and time. Information from the PDA to the central command will be exchanged in real time; the EMTs will be able to receive the patient’s information immediately as well as be able to send the condition right away allowing for the hospital to make important decisions such as which hospital can facilitate to the patient’s needs. This real-time data exchange will help routing of the ambulances efficiently. Furthermore, the PDAs as well as the sensor motes will also be equipped with GPS and wireless connections. EMTs will be required to match the PDA with the sensor mote of the patient to acquire the vital sign information.
The New Architecture
We plan to acquire and implement the following components (devices):
1. Sensors: We plan to integrate additional customizable sensors, medical and nonmedi-cal, that are capable of patient monitoring, data filtration, and ad-hoc networking. An example of such sensors would be chemical sensors to detect levels of toxicity and the GPS sensors to record time and location.
2. Web services: In order to ease construction of exchange partnerships and increase flexibility ofintegration with hospital legacy systems and yet-to-be-released communication protocols, the exchange of data will be transitioned into using Health Level-7 (HL-7) Web services. HL-7 is a widely used data definition and delivery standard that has been recommended by the National Committee on Vital and Health Statistics. The HL-7 data format, a Web service based on open standards that are being accepted by the medical community at large, allows any client to access iRevive’s Web service as long as he/she has permission and follows the standards set forth in calling the data. A server node will be the manager of sensor streams. A default is a manager of sensor streams on ambulance which manages data for connected PDAs and GPS sensors. Other modes for the server node may include: o Operating with attached databases for further storage.Acting as a forwarder to another server that is running with an attached database.
Act as an aggregator of multiple server nodes running on multiple ambulances. An example of such a server node would be a daemon running on the ambulance listening for PDAs and hospital databases.
3. Client device: A PDA will subscribe to an ambulance to receive sensor streams as well as send PCR data for storage/transmission. Laptops may also be employed at different locations that receive the complete information of which ambulance and sensors are in which locations, and the type of conditions that are being treated. This will help create a FedEx routing of the ambulances.
Accepted data formats, a new level of prehospital care is on the horizon. In time, broad deployment of prehospital applications such as iRevive will allow healthcare providers to monitor and document in real time how various procedures and types of therapy affect patient status and outcome. As more data are accrued, new algorithms will be developed to accurately guide and control all types of medical care. Eventually, automated acute care algorithms will be developed to enable sensor-based, computer-controlled patient care.
conclusion
The current methods employed by the EMS for gathering and recording data are out-dated, time consuming, and error prone. New technologies and solutions must be employed to improve the system. iRevive provides a solution to overcome many of the problems. EMTs can save time and efficiently capture the necessary information. Furthermore, the data are in electronic format readily available for exchange and analysis with many different systems. A wireless environment for the exchange of data saves time and provides up-to-date real-time information. Also, iRevive can be employed on a variety of different platforms and devices, including but not limited to PDAs, laptops, tablets, and so forth. It was tested in the field and many improvements were made. More innovative changes are in the process: addition of many more emerging sensor and sensor network technology, embracing of industry standards and