research report - edxl patient tracking messaging standard · repository has been developed...

E m e r g e n c y D a t a

E x c h a n g e L a n g u a g e

( E D X L )

Emergency Patient Tracking

Data & Messaging Standards

(Title changed May 2009 to

“Tracking of Emergency Patients“)

Initial Research Report

January 12, 2009

Prepared by Evolution Technologies, Inc.

at the direction of the DHS S&T-OIC EDXL Program

Practitioner Steering Group and STEP Steering Committee

Re

se

ar

ch

Re

po

rt

Patient Information Tracking Table of Figures

Executive Summary .................................................................................. 1

Background ................................................................................................................................ 2

Purpose & Observations ........................................................................................................... 2 Overview ..................................................................................................................................... 3

Introduction ............................................................................................... 6

Purpose and Objectives ............................................................................................................ 7 Methodology ............................................................................................................................... 7 Definitions ................................................................................................................................. 13

Results ..................................................................................................... 14

Overview ..................................................................................................................................... 1

General Findings ........................................................................................................................ 1 Non Profit Efforts ....................................................................................................................... 2

COMCARE’s Integrated Patient Tracking Initiative (IPTI)................................................................... 2 HIMSS/COMCARE Integrated Emergency Medical Response Initiative (IEMRI) .............................. 4 Coordinated Assistance Network (CAN) ............................................................................................. 4

Federal Programs ....................................................................................................................... 5 AHRQ Initiatives .................................................................................................................................... 5 FCC Joint Action Committee ................................................................................................................ 6 DHS WeBMEDIS ..................................................................................................................................... 6 DoD Tracking Systems ......................................................................................................................... 7

Standards .................................................................................................................................... 8 HITSP EREHR ........................................................................................................................................ 8 HL7 CCD ................................................................................................................................................. 9 ASTM Continuity of Care Record (CCR) .............................................................................................. 9 Vehicular Emergency Data Set (VEDS) .............................................................................................. 10

State and Local Systems ......................................................................................................... 10 Boston Patient Tracking System ........................................................................................................ 10 Christiana Care Health System Emergency Department Patient Tracking .................................... 11 National Capital Region RFP for Patient Tracking ............................................................................ 11 New York’s Health Emergency Response Data System (HERDS) ................................................... 12 San Francisco Electronic Patient Tracking System ......................................................................... 13 St. Louis’ Emergency Patient Tracking System (EPTS) ................................................................... 13

Vendor Products ...................................................................................................................... 14 Pre-Hospital Solutions ........................................................................................................................ 14 In-Hospital Solutions ........................................................................................................................... 17

Suggestions for Follow Up .................................................................... 34

Overview ................................................................................................................................... 21

Re

se

ar

ch

Re

po

rt

Patient Information Tracking Table of Figures

Conclusion ............................................................................................... 25

Supporting External Resources ............................................................ 27

Appendices .............................................................................................. 29

Appendix A: Project Templates .............................................................................................. 30 Quick Reference Guide ....................................................................................................................... 30 High Level Project Snapshot .............................................................................................................. 31

Appendix B: Sample Listing of Health Record Vendors ...................................................... 32 Electronic Health Records .................................................................................................................. 32 Personal Health Records .................................................................................................................... 33

Appendix C: Project Definitions ............................................................................................. 35

Appendix D: IPTI Patient and Victim Information Elements ................................................ 38

Appendix E: IEMRI Candidate Set of System Groups .......................................................... 40 Appendix F: AHRQ PTL Prototype Data Elements ............................................................... 41

Appendix G: HITSP EREHR IS04 Recommended Standards .............................................. 48

Appendix H: ASTM Continuity of Care Record (CCR) Document Object .......................... 50 Appendix I: VEDS Document Object Model .......................................................................... 51

Appendix I: Metro Boston Patient tracking System Data Elements ................................... 58 Appendix K: Sample Triage Tag ............................................................................................. 61 Appendix J: San Francisco Patient Tracking System Data Elements ................................ 62

Daily Patient Data Element Description ............................................................................................. 62 The fields required for creation of a new MCI triage patient record are: ........................................ 64

Table 1: Initiatives Included in This Report ..................................................................................... 10 Table 2: Initiatives Eliminated after Initial Research....................................................................... 12

Figure 1: Patient/Victim Information tracking Stakeholders ............................................................ 1

Executive Summary

Re

se

ar

ch

Re

po

rt

Patient Information Tracking

Executive Summary

Background In response to the threat of mass casualty incidents, members of the emergency response and medical communities are performing studies and adopting patient information tracking systems. These range from limited, single web-based applications, to systems that link various electronic applications using customized interfaces. Effective patient tracking systems serve as a means to improve emergency response and preparedness capabilities by electronically capturing and distributing patient and victim information. However, systems and customization is only part of the answer. Broad sharing of this information to various stakeholders such as EMS, emergency managers and local hospitals, throughout the response continuum will fully realize the benefits of these systems Data, communications and interoperability (XML messaging) standards need to be developed to facilitate interoperability of these existing and planned disparate systems. These interoperability standards may be facilitated through Federally-sponsored cross-profession practitioner efforts in partnership with public Standards Development Organizations (SDO) and private industry. The Office for Interoperability and Compatibility within the Department of Homeland Security Science and Technology Directorate facilitates such a practitioner-driven Standards Initiative. The program has recently launched a project at the request of the Practitioner Steering Group (PSG) for the development of interoperability standards to track patients and patient information during emergencies and disasters. As appropriate in collaboration with other standards efforts, the standard will be incorporated into the suite of standards referred to as EDXL (Emergency Data Exchange Language).

This preliminary report summarizes the results of initial research launched to develop an inventory of past or present ―efforts‖ (e.g. projects, processes, systems, standards, tools etc.) that in some way address sharing or processing of ―Patient and Victim Information‖ during emergencies or disasters of any scale. This research was conducted to ensure that the standard development process does not ―reinvent the wheel‖, and to identify coordination points, potential stakeholders and participants, areas for adoption or re-use, and information providing input and guidance to the standards effort. At this writing, the precise scope of the effort is being refined and may not precisely match the scope of the various efforts referenced herein.

Purpose & Key Observations

While not all inclusive, research across current and past ―Patient Tracking‖ efforts was conducted for over forty (40) initiatives that could potentially contribute to this project. These initiatives were divided into Non-Profit, Federal, State and Local, Standards, and Vendor Products categories. A document repository has been developed containing a more detailed synopsis of each effort, with a collection of documents, reports and other related artifacts.

The purpose of this report is to provide a one-stop-shop reference to that research, as a ―jumping off point‖ to leverage the detailed documentation. This information will be utilized for refinement of project objectives and requirements, to leverage adoption and re-use of those efforts as applicable, and to consider recommendations presented. The report provides a high-level overview and definition of each effort, data elements of importance across the continuum of care, and stakeholder organizations and contact information.

Following is a summarized list of findings collectively culled from the research:

Re

se

ar

ch

Re

po

rt


Executive Summary

Information requirements for each stakeholder group1 vary significantly.

The diversity of patient and victim tracking system stakeholders are facilitating the convergence of healthcare, public health, emergency response, social services and disaster relief, all working with the goal to provide the patient and victim with the best outcome possible.

Patient tracking systems are deployed for a variety of reasons: patient care visibility, family reunification, resource allocation and management, patient distribution guidance, humanitarian, disease outbreaks, among others.

Most pre-hospital programs recognize the need for sharing information using a standardized

approach. ―Patient tracking‖ does not just mean tracking the physical location of the patient or a victim, but

also includes information that is helpful in patient/victim care and emergency response and recovery, e.g. complaints, care provided, disposition, special needs, etc.

Most of the current deployed systems are aimed at use for mass casualty incidents. Although it is recognized that everyday use can add to the effectiveness of such systems.

The start of the patient/victim tracking process may occur in a number of ways. This first encounter starts at the point where the patient or victim first presents himself which could mean any point in the chain of response from 9-1-1 to a hospital emergency department to a temporary shelter. The initial Standards Working Group for the Emergency Patient Tracking Standard has indicated that this project scope will be patient-centric, beginning with EMS / other medical professional first touch with a patient or potential patient.

Most patient tracking systems being used today have been deployed using Commercial-Off-The-Shelf (COTS) products with heavy vendor participation. Only Federal level solutions and one state system were developed in-house.

Overview This section provides a synopsis of overall objectives, trends and focus of the various initiatives researched. The Gulf Coast hurricanes and other emergency events continue to confirm that the United States faces a legitimate threat of intentional and natural mass casualty incidents. In response to these mass causality incidents numerous efforts have been launched at the federal, state, and local levels to strengthen America‘s emergency response infrastructure and ensure that the emergency response community is adequately prepared, resourced, and organized to overcome the unique challenges of mass casualty patient care. One such effort is the development or acquisition of ―patient tracking systems‖ as a means to improve emergency response and preparedness capabilities electronically by capturing and distributing patient information to various stakeholders, such as emergency managers and local hospitals, throughout the continuum of care during an emergency event. That approach was documented in the Emergency Responder Electronic Health Record Use Case published by the American Health Information Community

2 (AHIC) and processed into an Interoperability Specification

1 Stakeholder groups include fire, EMS, law enforcement, public health, HazMat, emergency management,

transportation, search and rescue, hospital and healthcare providers, 9-1-1/dispatch, telematics service providers, and disaster services.

2 The American Health Information Community (AHIC) is a federal advisory body, chartered in 2005 to make

recommendations to the Secretary of the U.S. Department of Health and Human Services on how to accelerate the development and adoption of health information technology.

Re

se

ar

ch

Re

po

rt


Executive Summary

by the Health Information Technology Standards Panel3 (HITSP). This Interoperability Specification

includes the sharing of patient health information as well as the collection of information from external sources such as telematics service providers and emergency contact databases. Another trend that has also developed is the physical tracking of both patients and victims for the purposes of family reunification, evacuation management, resource allocation (hospital beds, transportation assets, shelters, etc.), and incident management. For instance, tracking systems have been used to track special needs shelter residents, points of dispensing resources, influenza vaccine dispensing, evacuees, surviving patients, victims of fatal injuries, personnel, volunteers, pets of evacuees, supplies, equipment, and other resources. The tracking of these would create a log identifying the item or person, the location or movement of the item or person, their status (contaminated, decontaminated, task completed, etc), the time of the entry (or start and end times) and any other details that should be tracked. Tracking of people serves multiple purposes. Accounting for employees, volunteers, patients and victims allows an incident commander to identify individuals who may have been exposed to dangerous chemicals, how many and who are on the scene and in the case of a crime scene, who had contact with the evidence. This capability allows for rapid requests for resupply, replacement and reimbursement with immediate cost capture. Inventories managed accurately and efficiently will greatly reduce the system wide impact of an incident. End users have identified a variety of expectations for patient tracking systems. Some expect to simply implement computerized triage tools or transmit casualty counts to incident managers; others expect to determine the exact location of patients on the scene of an incident and track their movement through the medical and health care system. Still others are unaware of the potential systemic impacts of each particular entry in the system. Most recognize improvements in responder deployment and ―load balancing‖ of hospitals would occur if they had near real-time access to hospital status and tying that information to scene specific information. Emergency Departments have tracked patients for many years, allowing caregivers access to necessary information which has gained efficiencies and greatly improved patient safety. This has not been the case for emergency medical response. While many communities have been early adopters of tracking systems, most still do not have this capacity. Of those who have this capability, many have standalone systems that are ―shelved‖ until a mass casualty incident occurred. Unfortunately, standalone ―break glass in case of emergency‖ systems have limited value. To increase their value, electronic patient tracking systems require the integration and interoperability with other disparate systems.

Typically the tracking process starts with the assignment of a unique identifier that can be automated with bar codes on triage tags or wrist bands that are applied to each individual at their first encounter. The bar code can then be scanned as the patient, victim, or evacuee moves through the continuum of care. Other techniques may incorporate the use of temporary assigned Radio Frequency Identification Device (RFID) tags or ―smart chips‖, magnetic strip readers to retrieve data from drivers‘ licenses, and electronic health care records saved on a variety of devices such as USB drives, smart cards, or dog tags like those used in the armed forces.. The person‘s identification as well as all other pertinent information is then processed into a system used by responders, healthcare providers, or relief workers to which the individual had first contact. Subsequent encounters can continue to use this identification to record additional or enhanced information about the individual. However, to be effective, this information must be seamlessly shared

3 The Healthcare Information Technology Standards Panel (HITSP) is a cooperative partnership between the

public and private sectors. The Panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems.

Re

se

ar

ch

Re

po

rt


Executive Summary

with a variety of entities for a variety of reasons, including as family reunification, resource allocation (hospital beds, transportation assets, medical supplies, etc), distribution guidance of EMS patients during a disaster and visibility of a patient‘s or victim‘s location and status throughout the chain of response and recovery. While many projects have been launched and systems deployed for these purposes by a variety of public and private organizations, none were found to use a standard messaging protocol, designed for this purpose, to exchange this specific type of information from one entity to another. Some entities have adapted by modifying existing standards such as the Public Health Information Network (PHIN) Messaging Standard for this purpose. In addition, standards for the data elements themselves have not been adopted, though efforts such as the National EMS Information System (NEMSIS), DEEDS and SNOMED.

Introduction

Purpose and Objectives

As stated above, the purpose of this report is to provide a reference to research performed across current and past ―Patient Tracking‖ efforts, to assist with refinement of project objectives and requirements, and to leverage adoption and re-use of those efforts as applicable. The report provides a high-level overview and definition of each effort, data elements of importance across the continuum of care, stakeholder organizations and contact information, and a set of recommendations for consideration during the project. The Research Task of the Emergency Patient Tracking Standards Project used a systematic process for collecting and analyzing information about patient information tracking efforts in order to increase understanding of the current landscape. Its primary goal was to create insight that is not just reliable, but actionable throughout the standards development process. Research Task objectives included: Use of a quantitative/qualitative research blend that includes the collection and interpretation of

facts, findings, and observations; Research-based recommendations so that informed decisions concerning the development of

Emergency Patient Tracking Standards can be made; A deep understanding of the needs that drove stakeholders to deploy patient tracking solutions

and the information elements that are included in a definition of patient information tracking; and Integration of key attributes or critical elements from these efforts into the standards

development process.

Methodology The approach used to complete the Research Task was to collect, organize and standardize information about projects, programs, and products involved with patient and victim information tracking. Research was conducted by: Collecting information from first hand involvement in related projects; Performing Web-based searches about existing systems, vendors in the patient/victim tracking

solutions arena, and other related programs; and

Contacting subject matter experts involved with existing programs, systems, or products

Research into the characteristics of each effort resulted in a moderate understanding of each effort and was documented in standardized Quick Reference Guides and High Level Project Snapshots (Appendix A). Supplemental documents about each effort were also collected and uploaded to the Patient Information Tracking SharePoint repository. For organization purposes, efforts were divided into the following categories: Non-Profit, Federal, Standards, State and Local, and Vendor Products. Vendor Products were further divided into Pre-Hospital and In-Hospital solutions. It is important to note that the vendor products that were researched did not include any vendor products related to electronic health records or personal health records. A sample listing of these products can be found in Appendix B.

The efforts and products listed in Table 1 below represent the list of efforts researched for this project. Although it is not all inclusive, it does provide a representative sample of the types of programs being launched. The table also highlights the potential contribution that each effort can make to the Emergency Patient Tracking Standards project.

Re

se

ar

ch

Re

po

rt

Patient Information Tracking Introduction

PROGRAM PROJECT CONTRIBUTION

NON PROFIT

COMCARE/HIMSS4

Integrated Emergency Medical Response Initiative (IEMRI)

Proof-of-concept demo diagram indicating the technology components needing to share information throughout the continuum of care.

Advisory Board and Task Force members as potential members of Stakeholder Work Group (SWG).

COMCARE Integrated Patient Tracking Initiative (IPTI)

Information needs and data elements derived for a broad range of stakeholder groups.

Extensive list of Subject Matter Experts (SMEs) as potential members of SWG

Coordinated Assistance Network (CAN)

An excellent example of a system used by disaster services groups like the American Red Cross or United Way.

The CAN Portal is a secure web site acting as a repository of citizen data collected by local and national agencies that could act as both a sender/receiver of victim information and the services they are receiving.

FEDERAL

HHS AHRQ Patient Tracking Locator (PTL)

List of potential data elements for both patient and evacuee tracking across systems which were also mapped to DEEDS

5 and NEMSIS

6

SMEs as potential candidates for SWG

HHS AHRQ Evacuee Movement

Expands tracking to include evacuee movement during mass casualty incidents (MCIs)

Contacts as potential members of SWG.

DoD Systems TRAC2ES AHLTA Mobile

(aka BMIST) JPTA TacMedCS

An example of integrated systems for tracking patients from theater to and through hospital care

Custom interfaces across systems could provide valuable input to standards efforts, especially since systems have been used for non-military events such as Hurricane Katrina/Rita.

Potential users of standard.

FCC JAC Justification for standards Contacts as potential members of SWG

WebMedis DHS requested the system which is a potential user of this standard. Claims to meet all of IPTI‘s Phase I requirements Plans to integrate with HAVE and WebEOC

STANDARDS

ASTM Continuity of Standard for provider-to-provider exchange of patient health information

4 HIMSS (Health Information and Management Systems Society) is the healthcare industry's membership

organization exclusively focused on providing global leadership for the optimal use of healthcare information technology (IT) and management systems for the betterment of healthcare. See http://www.himss.org/ASP/index.asp

5 DEEDS (Data Elements for Emergency Department Systems) - uniform specifications for data entered in

emergency department (ED) patient records. See http://www.cdc.gov/ncipc/pub-res/deedspage.htm

6 NEMSIS (National EMS Information System) - an effort to standardize the collection of EMS data.. See

http://www.nemsis.org/

http://www.himss.org/ASP/index.asp

http://www.cdc.gov/ncipc/pub-res/deedspage.htm

http://www.nemsis.org/

Re

se

ar

ch

Re

po

rt



Care Record (CCR) in summary form

HITSP EREHR Recommended standards for the AHIC Emergency Responder Electronic Health Record Use Case

Defined process for patient information tracking from an emergency medical perspective, but no real standards recommended for tracking per se.

HL7 Continuity of Care Document (CCD)

Recommended standard for patient information exchange and the documentation of each emergency encounter throughout the chain of response.

Public Health Information Network (PHIN) Messaging Standards

PHIN messaging standards used by some deployments such as the ones in Boston and New York State.

Vehicular Emergency Data Set (VEDS)

Contains data elements needed for patients of car crashes

STATE AND LOCAL

Boston PTS for Public Health

Tracks patients across EMS, hospitals, public health and volunteer services using XML interfaces

Christiana Care Health System, Newark, DE

Example of in hospital patient tracking Uses ED tracker Potential recipient of patient information from EMS

HERDS - NYS An integrated architecture supporting a wide array of health information exchange applications.

NCR Although not implemented, the RFP is a resource for Patient Tracking requirements.

San Francisco Uses EMTracker and EMResource products from EMSystem to track patients and map them to available resources (beds, transport, etc.)

Defined data elements for both day-to-day and mass casualty incidents.

STARRS – St. Louis, MO

Interfaces patient tracking across 8 counties in 2 states, 18 hospitals, 10 EMS agencies and EOC‘s across the region

Potential user of standard.

VENDOR PRODUCTS

PRE-HOSPITAL

Disaster Management Solutions

Focuses on patient, equipment, and supplies tracking. Several major deployments http://www.dmssolutions.com/

EMSystem EMTracker has largest market share for pre-hospital patient tracking Developed custom interfaces between EMS and EDs, Public Health

agencies, EOCs, etc. http://corp2.emsystem.com/?home

http://www.dmssolutions.com/

http://corp2.emsystem.com/?home

Re

se

ar

ch

Re

po

rt



Raytheon Custom interfaces with EMS, EOCs, Hospitals, and Red Cross Focuses on MCIs Has very similar features to DMS and EMSystem. http://www.raytheon.com/capabilities/products/epts/

Salamander Leading vendor for tracking solutions in all phases of emergency response.

It was used to track evacuees from Houston during Hurricane Ike. Regularly partners with other solutions like Raytheon and EMSystem to

enhance functionality in a given region. http://www.salamandertechnologies.com/Brix?pageID=1

Sydion All hazards emergency management solution http://www.sydion.net/

Zoll Data Systems More of a Fire/Ems solution than patient tracking, but could potentially a user of a patient tracking messaging standard.

http://www.zolldata.com/index.aspx

IN HOSPITAL

Emergisoft Solid experience in all types of emergency department information systems (EDIS).

Vendor should be included in the SWG and or invited in to present to the group.

http://www.emergisoft.com/Solutions.aspx?id=Hosted

Intermec http://www.intermec.com/solutions/healthcare/patient_tracking_admin.aspx

Patient Care Technology Systems

Its Amelior EDTracker product is used by Christiana Health Care System, Wilmington Delaware

http://www.pcts.com/

PatienTrak A simple managed service patient tracking solution that can be used throughout a hospital.

http://www.patienttrak.net/

Picis Solid experience in ED systems. Used at Washington Hospital DC. Another good potential participant on the SWG http://www.picis.com/

Statcom Focus is on hospital wide patient tracking and logistics. http://www.statcom.com/

Versus RFID tracking solution http://www.versustech.com/

Table 1: Initiatives Included in This Report

http://www.raytheon.com/capabilities/products/epts/

http://www.salamandertechnologies.com/Brix?pageID=1

http://www.sydion.net/

http://www.zolldata.com/index.aspx

http://www.emergisoft.com/Solutions.aspx?id=Hosted

http://www.intermec.com/solutions/healthcare/patient_tracking_admin.aspx

http://www.intermec.com/solutions/healthcare/patient_tracking_admin.aspx

http://www.pcts.com/

http://www.patienttrak.net/

http://www.picis.com/

http://www.statcom.com/

http://www.versustech.com/

Re

se

ar

ch

Re

po

rt


Other efforts were also identified and researched in May 2009 including the Federal Programs listed in Table 2 below. Therefore, this document does not contain additional information on those efforts. In addition, other efforts initially researched were eliminated for a number of reasons including: No or little relevance to Patient Information Tracking; Findings and/or implementation mirrored other efforts already documented; Available information was incomplete or inconclusive. These efforts are referenced in Table 2 below.

PROGRAM DESCRIPTION

FEDERAL

DHS NBIS The National Biosurveillance Integration System (NBIS) is a program that integrates the areas of health surveillance (human, animal and plant), intelligence and environmental monitoring (air, agriculture, food, and water) to achieve the following three initial goals: (1) enable early detection and characterization, (2) provide situational awareness to guide response and (3) sharing of information amongst Federal partners (Agencies). While the system is an important part of our Biodefense strategy and may be a recipient of anonymized patient information, its contribution to this project is minimal and covered by other efforts.

DOD HOSPITAL

EMERGENCY

PLANNING

INITIATIVE -HEPI

The HEPI Program analyzes all aspects of the coordination between DOD and civilian healthcare, including required links between civilian healthcare agencies, the local emergency management jurisdiction and DOD facilities.

DISASTER CLIENT

DATA EXCHANGE The Disaster Client Data Exchange Project is a directed effort aimed at improving the circulation of reliable client information within the American Red Cross and partner agencies during disasters.

MANAGEMENT

INFORMATION

SYSTEMS (HMIS) DATA AND

TECHNICAL

STANDARDS –HUD

Development of a data standard that specifies the types of information homeless providers are expected to collect from homeless clients.

STATE AND LOCAL

Florida PT Program

An RFP was issued for a pilot program. Orange County Florida was selected for the pilot that would extend throughout the state. The survey conducted with responders as a result of the pilot provides excellent insight into the practical needs of these responders using the system. While the pilot system is still operational, further expansion throughout the state has not occurred. Also, since the pilot uses EMTracker from EMSytem, this implementation is very similar to others using this product.

Re

se

ar

ch

Re

po

rt


PROGRAM DESCRIPTION

Long Beach The Long Beach Network for Health, hereafter referred to as LBNH, is a public/private partnership of healthcare providers and stakeholders serving the City of Long Beach and its surrounding area from the South Bay of Los Angeles County to Southwestern Orange County including Torrance, San Pedro, the greater Long Beach area, Los Alamitos, and Seal Beach. The LBNH Health Information Exchange and Patient Tracking Pilot Project represented the first of a multi-phased approach to develop a community wide infrastructure for data exchange. Unfortunately very little information could be retrieved for this project.

San Mateo County San Mateo County is still in the process of reengineering their emergency medical processes and are not yet at the stage to fully utilize the capabilities of patient tracking systems.

Texas The Houston Texas implementation is very similar to other EMTracker implementations and offered no additional insight for this project.

VENDOR PRODUCTS

PRE-HOSPITAL

Iomedex Although involved in incident management and patient tracking with IRIS (Incident Response Information System). They are no longer in business.

JPL Aid-N The Advanced Health and Disaster Aid Network (AID-N) develops and provides technology-based solutions to enable medical personnel at large-scale incidents to more efficiently triage, track, and transport patients while sharing the most accurate and real-time patient information. However, no activity with it has occurred since a mass casualty field exercise in August 2006.

http://www.jhuapl.edu/AID-N/

IN HOSPITAL

Awarepoint Awarepoint‘s Active RFID technologies and real-time location systems (RTLSs) include its real-time awareness platform, firmware, RFID tags, sensors, and bridges. Its technologies collect raw sensor data and transform that data into high-value positioning information that can be used to add location awareness to a variety of healthcare and business applications. Although its technologies have been used to track patients and monitor patient flow, its primary function is to track equipment and supplies. http://www.awarepoint.com/

Logicare LOGICARE produces Emergency Department information systems and automated patient and family education applications that includes basic ED patient tracking similar to many other products of this type. http://www.logicare.com/

Mobile Aspects Mobile Aspects is a healthcare technology supplier focused on providing an integrated suite of Clinical Resource Management solutions to automate the management of supply, asset, drug, and patient tracking leveraging RFID technology. No implementations for patient tracking use were identified. http://www.mobileaspects.com/

Table 2: Initiatives Eliminated after Initial Research

http://www.jhuapl.edu/AID-N/

http://www.awarepoint.com/

http://www.logicare.com/

http://www.mobileaspects.com/

Re

se

ar

ch

Re

po

rt


Definitions While definitions varied slightly from project to project, it is important to be consistent when documenting the results and recommendations derived from the research. The definitions of terms used in this report and related documentation can be found in Appendix C.

Results

Re

se

ar

ch

Re

po

rt


Results

Overview The research effort conducted for the Emergency Patient Tracking Standards effort examined a number of projects and programs that could potentially add value to the standards process. A summary of findings have been documented in this section of the report. Details about each effort have been uploaded to the project SharePoint repository for approved stakeholder review and reference.

General Findings A number of initiatives have addressed the issue of patient and victim information tracking for a variety of reasons. Some have made recommendations and suggestions for the need for messaging standards. Some have required that all stakeholders use one, common application system to retrieve information. Others have used messaging standards already available, and others have integrated their applications using customized interfaces. Only one effort, the Health Information Technology Standard Panel Emergency Response Electronic Health Record (HITSP EREHR) Interoperability Specification, recommended standards that can be used for patient information tracking from a patient care perspective. Following is a list of findings collectively culled from these researched initiatives: There is a diversity of stakeholder groups needing information about patient and victim tracking.

There are the patient care givers such as EMS and emergency medical personnel. There are the other emergency responders such emergency managers and 9-1-1. There are also requirements from public health departments, social services agencies and disaster relief organizations. Only three efforts addressed all of these stakeholder groups: COMCARE‘s Integrated Patient Tracking Initiative (IPTI), the HIMSS/COMCARE Integrated Emergency Medical Response Initiative (IEMRI), and the HITSP EREHR workgroup addressing the Emergency Responder Electronic Health Record Use Case. Figure 1 below from IPTI provides a good representation of the stakeholders having patient and victim tracking information needs.

Figure 1: Patient/Victim Information tracking Stakeholders

Re

se

ar

ch

Re

po

rt


Results

Because of the diversity of stakeholder groups needing patient and victim information, there is no

common set of data elements, common terminology, or common data structures that can apply and be used across all of these domains.

Patient tracking systems are deployed for a variety of reasons: patient care visibility, family reunification, resource allocation and management, patient distribution guidance, humanitarian, disease outbreaks, among others.

Some systems/efforts have focused solely on a system‘s use during mass casualty events while

others have seen the advantage of using a system for all hazards knowing that systems that perform best during a crisis are ones that are used every day. Data collected for day-to-day emergencies are typically more extensive than data collected during a MCI. Conversely, the data needs across practitioners become greater as emergency events intensify. Large scale disasters need this information for a variety of reasons depending on the type of event, but especially for resource allocation and management, evacuee movement and family reunification.

Most pre-hospital programs recognize the need for sharing information using a standardized

approach. To prove that point, some have adapted current messaging standards from PHIN and HL7 not specifically designed for patient information tracking purposes.

―Patient tracking‖ does not just mean tracking the physical location of the patient or a victim, but

also includes information that is helpful in patient/victim care and emergency response and recovery, e.g. complaints, care provided, disposition, special needs, etc.

Patients and victims enter and leave the emergency medical response and victim care systems in

different ways. There is no specific point from which the process starts. Instead the process starts wherever a patient or victim is first presented. This first encounter can be documented by a variety of domains, from 9-1-1 to hospital emergency departments to disaster relief organizations.

Federal systems were typically custom-developed while state and local deployments relied on

Commercial-Off-The-Shelf (COTS) software with close vendor participation. Only the State of New York HERDS system was developed within the agency with no vendor involvement. Therefore, vendors are key contributors to the deployment of patient and victim tracking solutions, especially when there are system integration needs.

The next section of this report provides overviews of each researched initiative. Although in summary form, the overviews should help provide a better understanding of patient and victim tracking systems and how they are deployed.

Non Profit Efforts Three non-profit projects were investigated during the research phase of the Emergency Patient Tracking Standards project: COMCARE‘s Integrated Patient Tracking Initiative (IPTI), the HIMSS/COMCARE Integrated Emergency Medical Response Initiative (IEMRI), and the Coordinated Assistance Network (CAN). Both IPTI and IEMRI included a wide array of stakeholder groups that required information about patients and victims throughout the chain of response. Both also recognized the need for messaging standards to exchange information across stakeholder domains.

COMCARE’s Integrated Patient Tracking Initiative (IPTI) COMCARE launched the Integrated Patient Tracking Initiative (IPTI) to provide emergency medical response practitioners with the tools they need to make decisions about patient tracking systems for

Re

se

ar

ch

Re

po

rt


Results

their respective communities, and to do so in ways that enhance overall emergency data communications and interoperability. During Phase I – Requirements Definition, COMCARE brought together a representative group of experts from over 70 national and regional organizations representing Fire/EMS, Emergency Medicine/Hospitals, Emergency Management, Public Health, 9-1-1, Disaster Services, federal, state, and local agencies, and academia. Requirements were presented at a national summit and subsequently published online and released for public comment. IPTI requirements include information needs for both patient and victim tracking, for all hazards, and all domains, throughout the continuum of care where information is continually being added and/or enhanced. IPTI‘s value can be found in its identification of required information elements for each stakeholder group during each step in the continuum of care: patient/victim identification, triage, treatment, location of patient/victim within the system, incident management, family reunification and post event analysis and reporting. IPTI recognized that electronic pre-hospital patient tracking systems must be designed to accommodate and represent the different needs of the whole emergency response community—not just individual segments. These needs cross jurisdictional, professional and organizational boundaries. For example: Emergency Managers need a pre-hospital patient tracking system to provide an accurate, real

time account of the location and condition of casualties, personnel and resources in the event of a disaster. Providing emergency managers with this event data electronically will not only enhance their ability to manage the event as it is occurring but will allow them to keep an accurate record of the event for review at a later time.

Hospitals have multiple needs that are addressed by an electronic pre-hospital patient tracking system. First, during any emergency, hospitals need an ability to receive real time patient information about patient‘s being transported to their hospital. They need this information so that they can adequately prepare for the patient‘s arrival as well as to offer treatment recommendations to providers in the field. In the event of a mass casualty incident, hospitals need this information from the field so they can make decisions about, and post, their availability and diversion status. In a mass casualty incident mutual aid agreements may require them to be able to access this information from areas usually not within their jurisdiction or coverage area. In addition, hospitals need an ability to transfer patient information collected in the field to their in-hospital electronic health records service.

EMS needs a pre-hospital patient tracking system that gives them the ability to collect patient information, including care provided, electronically to allow for accurate documentation in run reports and billing. EMS also needs a pre-hospital patient tracking system that gives them the ability to transfer patient information to hospitals before arrival to allow the hospitals to offer treatment care and recommendations. In the event of a mass casualty incident EMS needs a system that allows for the rapid triage and transport of numerous patients to the appropriate destination. This requires EMS to have the ability to monitor and be made aware of changes to the status and availability of area hospitals in order to make responsible transport decisions.

Public Health needs a pre-hospital patient tracking system that allows electronic health data collected in the field, such as the location where the patient was found and their major complaint, to be populated in existing public health databases to help monitor disease and injury trends. Public Health especially needs this functionality of pre-hospital patient tracking to assist in homeland security activities such as bio-surveillance. For instance the unique identifying number given to the patient could also be attached to any samples collected (such as potentially contaminated clothes). This would allow public health officials to match positive lab results not only to the patient they were taken from but any responders who may have been contaminated as well.

9-1-1 needs a pre-hospital patient tracking system that provides accurate incident information. This information will allow 9-1-1 to offer appropriate advice to callers and emergency dispatchers.

Re

se

ar

ch

Re

po

rt


Results

Disaster Relief organizations needs a pre-hospital patient tracking system that allows them to track the location of patients to help facilitate the reuniting of families and the coordination of volunteer efforts.

The list of information elements resulting from IPTI‘s multi-domain process can be found in Appendix D.

HIMSS/COMCARE Integrated Emergency Medical Response Initiative (IEMRI)

The Healthcare Information and Management Systems Society (HIMSS) and COMCARE Emergency Response Alliance launched a partnership to improve the sharing of patient health information throughout the emergency response process. Under the Integrated Emergency Medical Response Initiative, the two organizations hoped to advance interoperability between emergency response and healthcare stakeholders. The IEMRI vision represents a more efficient and informed emergency medical care process through the widespread use of integrated, interoperable healthcare and emergency response information systems. These systems enable the electronic capture and exchange of patient and incident information among stakeholders. When emergency information is exchanged across domains and jurisdictions, enriched by external data sources, a more informed response process can be achieved. The IEMRI Advisory Board and Task Force identified a candidate set of systems that would be used throughout the continuum of care. During an emergency, these systems would need to send and receive patient and victim information, preferably using Emergency Patient Tracking Standards. The candidate set of systems includes: Technology infrastructure needed to support information sharing ( core services, message

brokers, transport, and data standards); External data providers such as telematics service providers, special needs registries, personal

health records, and predictive algorithms; and Application systems used by each domain (9-1-1, emergency responders, hospitals, DoD/VA,

emergency management and public health). This candidate set of systems can be found in Appendix E.

Coordinated Assistance Network (CAN)

Scope: Supports disaster relief case management for large scale disasters.

Standards: None

Integration: Receives data feeds from American Red Cross and FEMA as well as other disaster relief groups.

Status: Operational 2004

Galvanized by the tragic events of September 11, 2001 seven of the nation's leading nonprofit disaster relief organizations

7 came together to assess the lessons learned from that unprecedented

tragedy. One of the most important findings of this assessment was that disaster relief agencies, whether national or local, did not have a unified way of sharing information with one another. While each

7 These groups include: Alliance of Information & Referral Systems (AIRS), American Red Cross, 9/11 United

Service, and United Way of America.

Re

se

ar

ch

Re

po

rt


Results

agency might have a high degree of information management competence within its own sphere, they were not able to fluently share data. To ease this burden, the Coordinated Assistance Network (CAN) was established. The CAN Interagency Portal is a single, secure web site that acts as a repository of client

8 data

collected by all local and national partners. It enables collaboration between partner organizations and ensures timely delivery of services, without partners or disaster victims duplicating effort. This collaboration creates a single point of case data that provides local organizations with the information needed to effectively delegate resources and best serve those in need. The CAN Portal is an ideal recipient of victim and patient information from response organizations and would be an ideal candidate for use of an Emergency Patient Tracking Standard. The CAN using community represents all major disaster service and relief organizations and would provide valuable insight into the requirements of these stakeholders.

Federal Programs While there are a number of federal initiatives that relate to patient and victim tracking, five efforts were chosen for in depth research. Two were led by the Department of Health and Human Services Agency for Healthcare Research and Quality (AHRQ), one by the Federal Communications Commission, one application system requested by DHS FEMA Chemical Stockpile Emergency Preparedness Program (CSEPP), and a suite of application systems deployed by the Department of Defense.

AHRQ Initiatives AHRQ‘s National Mass Patient and Evacuee Movement, Regulating and Tracking System outlined a proposed strategy for this type of system. It focused on mass casualty incidents, tracking the movement of patients and victims from initial contact to ultimate disposition and using this information for estimating the need for resources such as hospital beds and transportation assets. The strategy required that only minimal patient/evacuee information be collected, enough so that resources can be matched, persons can be found, and emergency managers can determine the breadth and depth of the event. During this project, a second effort was launched to design and implement a prototype tracking and locator system. Called Patient Tracking/Locator (PTL), RTI International (Research Triangle Park, North Carolina), under contract with AHRQ and in consultation with an Expert Panel, developed the prototype system to: Unambiguously identify patients Give person location(s) Track people over multiple locations and over time Communicate information across systems. The PTL prototype was designed as an umbrella system to aggregate information from various patient tracking systems during mass casualty incidents. The primary focus was on tracking and locating a person (disaster victim/patient), and not on collecting and maintaining a person‘s medical information or the treatment they receive during the emergency event. The team and panel recognized the need for data standards to support external data exchange and created a Data Standards ―Subcommittee‖ that mapped PTL data elements to other standards, such as DEEDS and NEMSIS. The consensus PTL data elements can be found in Appendix F. The mapping of these elements is included in the PTL High Level Snapshot, which can be found in the SharePoint repository.

8 The use of the term ―client‖ in CAN is synonymous with ―victim‖.

Re

se

ar

ch

Re

po

rt


Results

FCC Joint Action Committee The Joint Advisory Committee on Communications Capabilities of Emergency Medical and Public Health Care Facilities (JAC) was created by Congress to examine the communications capabilities and needs of emergency medical and public health care facilities. One of JAC‘s findings was the revelation that there is no comprehensive system to track patients or their records. According to the report, ―Patient tracking and bed inventory systems are essential components of a comprehensive emergency communications system. But the system today is ill-prepared to track patients as they are received, evacuated to other hospitals, their condition throughout the process, and whether family members have been notified. Such systems are essential to facilitate family reunification, to track those people not hospitalized, and create victim registries.‖

9

While some states and regions are working to put patient tracking systems in place, the JAC found that many of the existing bed and patient tracking systems were not linked to EMS or other emergency agencies needing the information. The JAC made a number of recommendations in their report to Congress, three of which provide support for the Patient Information Tracking project. The committee recommended that: Congress establish a federal interagency coordinating committee on emergency communications

systems to establish strong, consistent national (federal) guidance, standards and direction to insure consistent development of compatible communication systems across the nation.

The federal government renews its commitment to develop, harmonize, and ensure widespread adoption of shared standards and protocols. Develop and deploy patient and bed tracking systems with nationally mandated information

sharing provisions through the use of common standards. The Department of Homeland Security lead an effort to create and coordinate a geospatial

Command and Coordination System, based on open enterprise architecture, to allow common patient and emergency vehicle tracking for better situational awareness for all Emergency, Medical and Public Health Care Facilities.

DHS WeBMEDIS

Scope: Mass casualty incidents in CSEPP communities.

Standards: None

Integration: Receiving hospitals with plans to integrate with WebEOC

Status: Still being deployed

FEMA Chemical Stockpile Emergency Preparedness Program (CSEPP) contacted Oak Ridge Institute for Science and Education (ORISE) to develop a Web-based patient tracking system that would provide hospitals and other emergency response functional locations with patient information (medical and contamination status) that can increase the efficiency and effectiveness of care for those patients. Called WeB-MEDIS, this system is a highly portable system for inputting, sharing and tracking patient data from the field. ORISE continues to expand the patient tracking capability of WeB-MEDIS and has been conducting related training and exercises at CSEPP sites and in Oak Ridge. As a follow-up to recent WeB-MEDIS training involving 11 hospitals, ORISE is working with those communities to establish a

9 Joint Advisory Committee on Communications Capabilities of Emergency Medical and Public Health Care

Facilities. February 4, 2008. Report to Congress. http://energycommerce.house.gov/Press_110/JAC.Report_FINAL%20Jan.3.2008.pdf

http://energycommerce.house.gov/Press_110/JAC.Report_FINAL%20Jan.3.2008.pdf

Re

se

ar

ch

Re

po

rt


Results

community-wide patient tracking system. The one challenge is the agreement on how the system will be used day-to-day. ORISE has not been focusing on the HAVE standard but has evolved the resource management data fields into a bed availability capability that was demonstrated at an exercise following recent training. Integration with WEBEOC is planned as a future requirement. Unfortunately, requests to discuss system data elements and interfaces have not been successful. It may be prudent to include system personnel in the EDXL standards development process.

DoD Tracking Systems

Scope: Individual and mass casualty evacuations Military operations and natural disasters

Standards: Proprietary Interfaces

Integration: Integrated with a variety of other DoD systems

Status: Operational

The Defense Health Information Management System (DHIMS) information management/information technology (IM/IT) solutions help capture, manage and share health data across the Department of Defense (DoD) enterprise. DHIMS includes garrison systems and theater systems. The latter is where most of the tracking systems reside and includes: AHLTA Mobile

AHLTA Mobile (previously called BMIST) is the first responder handheld data capture device. AHLTA Mobile allows for immediate documentation of injury, illness and care, and stores medical data until it is transferred to AHLTA Theater, DoD‘s electronic medical record. AHLTA Mobile can electronically store medical reference documents and replaces pounds of books and paper previously carried by medics.

Transportation Command Regulating and Command & Control Aero-medical Evacuation

System (TRAC2ES) TRAC2ES monitors and tracks patients leaving theater via Air Force aero-medical evacuation. The system provides visibility of the logistics of incoming and outgoing flights and enables scheduling of patients' departures. TRAC2ES interfaces with the Theater Medical Data Store (TMDS), receiving pertinent health care information from the electronic medical record and sending information to enable patient movement visibility.

Although not part of DHMIS, DoD‘s Joint Patient Tracking Application (JPTA) was designed to ensure that all service members who become ill or are injured in theater are properly accounted for, and that information on their location and status is available to commanders, health care providers and service liaisons in near real-time through a user-friendly web-based application. It collects, manages, analyzes and reports data on patients arriving at medical treatment facilities and is used in conjunction with TRAC2ES to help coordinate and manage patient flow. While TRAC2ES provides patient visibility up to entry into a military hospital system, JPTA, from the medical facility perspective, tracks patient evacuations and movement, and allows care providers the ability to input patient treatment notes and stores in-hospital logistics information. Patient information and transport history is pre-populated from TRAC2ES. Unfortunately, there are conflicting reports as to the status of this system.

The Tactical Medical Coordination System (TacMedCS) began as a patient tracking prototype developed at the Pacific Northwest National Laboratory (PNNL) for the Navy. The project was done in collaboration with the Naval Aerospace Medical Research Laboratory (NAMRAL) of Pensacola, Florida. It is a wireless communication system utilizing Radio Frequency (RF) technology to capture,

Re

se

ar

ch

Re

po

rt


Results

store and display real-time casualty data in the field. Its functionality is similar to commercial pre-hospital patient tracking systems. These DoD systems were investigated in part because of their use during Hurricane Katrina and to learn about the interfaces built to a variety of systems. Unfortunately, this information is not in the public domain, but military personnel involved in these systems has been active on a number of patient tracking initiatives and could significantly contribute as members of the Stakeholder Working Group.

Standards Research efforts in this category started with the Health Information Technology Standard Panel

10

Emergency Response Electronic Health Record (HITSP EREHR) Interoperability Specification which recommends standards that can be used for patient information tracking from a patient care perspective. Research then progressed to the HL7

11 Continuity of Care Document (CCD) standard

and the ASTM12

Continuity of Care Record (CCR) standard. Consideration was also given to the Vehicular Emergency Data Set (VEDS) and should continue with the Pubic Health Information Network

13 (PHIN) Messaging Standard since it was used in two deployments (Boston and New York

State).

HITSP EREHR In late 2006, the American Health Information Community (AHIC) and the Department of Health and Human Services Office of the National Coordinator (ONC) for Health Information Technology developed a use case to describe the role of electronic health records (EHRs) in emergency response for both day-to-day and mass casualty events. In 2007, the use case was assigned to the Health Information Technology Standards Panel (HITSP) Care Delivery (now Provider Perspective) Technical Committee, tasked with identifying data standards and technical guidance for implementation of the use case. The ER-EHR Interoperability Specification (IS04) marks the first formal and national presentation of how information can be collected and exchanged during the entire emergency medical Episode of Care, from the first notification/presentation to an emergency response organization (e.g. a call to 9-1-1) through the completion of the last encounter (e.g. definitive care in a hospital). It outlines how data generated during the emergency medical response process combined with real time and historical data available from external sources can support the identification, assessment, stabilization and medical treatment of the victims during the full range of emergency incidents. It provides a standardized roadmap for making emergency response and healthcare applications, as well as external data sources, interoperate.

10

The Healthcare Information Technology Standards Panel (HITSP) is a cooperative partnership between the

public and private sectors. The Panel was formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems.

11 Health Level Seven (HL7) is an American National Standards Institute (ANSI) accredited Standards

Developing Organization (SDO) operating in the healthcare arena. HL7‘s domain is standards for electronic interchange of clinical, financial, and administrative information among healthcare oriented computer systems.

12 ASTM International (ASTM), originally known as the American Society for Testing and Materials, is an

international standards organization that develops and publishes voluntary consensus technical standards for a wide range of materials, products, systems, and services.

13 The Public Health Information Network (PHIN) is a national initiative to improve the capacity of public health to

use and exchange information electronically by promoting the use of standards and defining technical requirements.

http://www.ansi.org/

Re

se

ar

ch

Re

po

rt


Results

The HL7 CCD has been recommended for use as the patient information tracking mechanism of choice. It is intended to provide initial clinical information to the emergency responders and then is used at each hand off of care to provide clinical information to the Emergency Care Department, Definitive Care, transfer or final disposition of the Episode of Care. Since the use case focused solely on patients and not victims or evacuees, no other tracking standard was identified. While the work on ISO4 is ongoing, its current list of recommended standards for use can be found in Appendix G. It is important to note that IS04 is the first specification to include all organizations that participate in emergency medical response, it is unique in that it is the only use case each National Health Information Network (NHIN) Prototype is required to implement. Once IS04 is formally recognized by HHS, federal agencies will be required to incorporate the specification into new systems or upgrades, and/or to buy products that comply with the standards.

HL7 CCD The HL7 Continuity of Care Document (CCD) is the result of a collaborative effort between the Health Level Seven and ASTM organizations to ―harmonize‖ the data format between ASTM‘s Continuity of Care Record (CCR) and HL7‘s Clinical Document Architecture (CDA) specifications. The Continuity of Care Document (CCD) specification is an XML-based markup standard intended to specify the encoding, structure and semantics of a patient summary clinical document for exchange. It is a constraint on the HL7 Clinical Document Architecture (CDA) standard. The CDA specifies that the content of the document consists of a mandatory textual part (which ensures human interpretation of the document contents) and optional structured parts (for software processing). The structured part relies on coding systems (such as those from SNOMED and LOINC) to represent concepts. The patient summary contains a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. Its primary use case is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient. Detail specifications for the implementation of this standard can be found in the SharePoint repository.

ASTM Continuity of Care Record (CCR) The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. he primary use case for the CCR is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient. To ensure interchangeability of electronic CCRs, this standard specifies XML coding that is required when the CCR is created in a structured electronic format. Conditions of security and privacy for a CCR instance must be established in a way that allows only properly authenticated and authorized access to the CCR document instance or its elements. The CCR consists of three core components: the CCR Header, the CCR Body, and the CCR Footer. The CCR high level object model can be found in Appendix H. Detailed documentation of this standard can be found in the SharePoint repository.

Re

se

ar

ch

Re

po

rt


Results

It should be noted that while the HL7 CCD was intended to replace the CCR, it did not do so as electronic and personal health record products have continued to use both standards. For example, Microsoft‘s Health Vault solution accommodates both standards while Google Health supports a subset of CCR.

Vehicular Emergency Data Set (VEDS) The Vehicular Emergency Data Set (VEDS) is a XML based data standard that determines useful and critical elements needed to prove an efficient emergency response to vehicular emergency incidents. The Protocol identifies crash and medical data elements.

Initially designed to transmit ACN crash data to an emergency agency, VEDS also serves as a data receptacle, collecting important bits of information as the response effort unfolds. The data set can contain data transmitted directly from the vehicle like vehicle speed, airbag deployment, direction of force and rollover as well as information from the telematics provider about the vehicle and its owner. Questions asked by a 9-1-1 operator about the age and gender of the occupants and data from responders and witnesses at the scene can also be added. When fed into URGENCY software, the likelihood of serious injury can be computed.

When in use, ACN, VEDS and URGENCY can positively impact the outcome of vehicle crashes. With electronic notification and injury detection, these technologies have the ability to reduce Emergency Medical Services (EMS) notification and response times while, at the same time, identifying specialized response needs such as air medical services and trauma center support before responders arrive on scene. More importantly these technologies can save lives and prevent permanent disabilities. The VEDS Document Object Model and pertinent data elements can be found in Appendix I.

State and Local Systems A number of state and local patient tracking system implementations were identified. However, many of them were very similar using commercial solutions from EMSystem. The initiatives described in this section offer unique perspectives to the patient tracking problem from both a requirements and information sharing perspective. These initiatives include: Boston Patient Tracking System, Christiana Care Health System ED Patient Tracking, the National Capital Region RFP for Patient Tracking, New York‘s Health Emergency Response Data System (HERDS), San Francisco Electronic Patient Tracking System, and the St. Louis‘ Emergency Patient Tracking System (EPTS).

Boston Patient Tracking System

Scope: Mass Casualty Incidents and Major Disease Outbreaks

Standards: Public Health Information Network (PHIN)

Integration: Hospital Registration Systems, Incident Management System (WebEOC)


In 2003, the need for a system to track and manage patient status and location was identified by Boston EMS and the Conference of Boston Teaching Hospitals. After consultation with EMS (municipal, fire based, and private), hospital, local and state public health and emergency management stakeholders, a core group from Boston EMS and the Boston Public Health Commission (BPHC) developed guidelines for a Metro Boston Patient Tracking System. The system is a secure, web based application designed to collect demographic and health care information on individuals involved in a Mass Casualty Incident (MCI). It uses barcodes and hand scanners to track patients throughout the health care system, from the field incident to hospital to

http://www.comcare.org/urgency.html

Re

se

ar

ch

Re

po

rt


Results

release from care. The patient tracking core group developed system requirements utilizing the PHIN functional requirements

14 as a reference point and has since used the system for a public health

purposes including flu shot tracking. Defining a shared set of data elements for the system took approximately 6 months; data selection for the public health emergency component was facilitated by the parameters set in the Public Health Information Network (PHIN) document. A list of these data elements can be found in Appendix J. Ongoing discussions with stakeholders identified additional target capabilities, including integration with hospital registration systems and a feed of summary data to WebEOC, Boston‘s web-based incident management tool. In addition, several data fields required by FEMA for disaster management were added.

Christiana Care Health System Emergency Department Patient Tracking

Scope: In Hospital ED patient tracking

Standards: HL7 messaging standards

Integration: Hospital registration, laboratory and radiology systems


The Christiana Emergency Department Patient Tracking System provides a good example of in-hospital patient tracking that could potentially be a recipient of pre-hospital tracking information facilitated by an EDXL Patient Information Tracking Messaging Standard. In November 2003, Christiana applied for a Federal bioterrorism grant to purchase the technology. In 2004, they documented current and future processes, acquired, installed and configured the EDTracker technology for implementation in late 2004. EDTracker automates the patient and staff tracking process and orchestrates patient flow within the emergency department. Real-time location data is collected using wireless personnel and equipment tags which identify their location through a sensory network. When patients arrive at Christiana's emergency department they receive a triangular badge-which measures 2.5 inches by 1 inch-that clips to their clothing. Once the badge number is activated in the tracking system, whenever patients enter a new care area the badge sends a signal to the tracking application. Clinicians then can call up a self-developed electronic dashboard on a computer that shows the patient's location anywhere in the emergency and radiology units. The ED triage process was redesigned to take advantage of the electronic tracking system. On arrival at the emergency department, patient conditions are assessed, and that data-along with registration information and badge number-is entered into the hospital's admission-discharge-transfer application, from McKesson. The system interfaces with the EDTracker application using HL7 messaging standards.

National Capital Region RFP for Patient Tracking

Scope: All hazards

Standards: NIMS, GJXDM

Integration: Reception centers (hospitals, clinics, off site treatment centers), hospital bed availability programs, CIMS

14

PHIN Preparedness: Countermeasure/Response Administration Functional Requirements. Center for Disease

Control. Version 1.0. April 26, 2005.

Re

se

ar

ch

Re

po

rt


Results

Status: NA

Prince Georges County in Maryland issued a Request for Proposals for a patient tracking system that would be utilized by all 17 jurisdictions in the National Capitol Region. The purpose of the system is to identify patients encountered by EMS, hospitals, and public health and then track that patient‘s movement through the health care system and collect certain data about that patient, their medical status and treatment. Entry requirements specified the use of a NIMS compliant patient tracking form, a triage tag, a prophylaxis/vaccination tracking form or an epidemiology investigation form

15. Patient identification

needs to be accommodated with barcodes, RFID tags, driver‘s licenses and/or pre-existing patient identification numbers. The RFP tied patient tracking to resource management and situational awareness needs.

Unfortunately, the status of this project is unclear.

New York’s Health Emergency Response Data System (HERDS)

Scope: All hazards

Standards: PHIN Messaging Standards

Integration: Variety of emergency, public health and hospital systems statewide


The Health Emergency Response Data System (HERDS) was created as a direct result of New York City hospitals response to the World Trade Center disaster of September 11, 2001. Hospitals responding to the disaster, and those at Ground Zero were inundated by hundreds of calls and inquiries from federal, state, and local authorities asking for specific information concerning beds, victims, personnel, supplies, etc, as well as citizens, businesses and others looking for people involved in the disaster, while they were trying to respond to patient needs. HERDS is a statewide electronic web based data collection system linked to health care facilities (all NYS hospitals) through a secure internet site that allows hospitals to relay resources or needs to the Department of Health during emergencies, or respond immediately to rapid request surveys in preparedness planning efforts. It includes the following critical functions to support the emergency response process: alert system and a facility specific communications directory of accurately maintained contact

information that allows immediate alerting capability to hospitals regarding a HERDS activation on a 24/7 basis;

patient locator and tracking system that lets the general public inquire about missing persons or for EMS, fire and police to track individuals moved from the scene;

real time secure electronic discussions that are key to the incident command and resource mobilization/ exchange processes; and

data output and visualization including incident command summary reports, geographic displays of hospital fixed assets, needs, available resources, and SAS graphical analyses for trending and real time tracking.

HERDS is fully compliant with CDC Public Health Information Network (PHIN) standards for interoperability, using standard formats for file transfer between its critical components (e.g., XML and PHIN Messaging System).

15

There are a number of different patient tracking forms that are used by healthcare and public health officials as

well as disaster relief agencies. Samples of these forms can be found in the SharePoint repository. A sample triage tag can be found in Appendix K.

Re

se

ar

ch

Re

po

rt


Results

HERDS SMEs have participated in numerous patient tracking initiatives including those sponsored by COMCARE and AHRQ.

San Francisco Electronic Patient Tracking System

Scope: All hazards

Standards: NEMSIS

Integration: None. All authorized can use the Web-based tracking system to get information.

Status: Operational late 2006

The San Francisco Electronic Patient Tracking System allows for the real-time tracking of patients from the scene of a routine call or mass-casualty incident, through intermediate destinations, such as triage or treatment areas, to tertiary destinations, such as hospitals or alternate treatment centers. To enable electronic tracking, each patient is tagged with a bar-coded triage tag or arm band, which is scanned with an Internet-connected bar code scanner at first contact with the patient, and at each step in the field treatment and transportation process, until the patient reaches the concluding destination. San Francisco selected EMTrack and EMRsource from EMSystm for this project. A patient‘s tracking information is available to authorized users through any web-enabled computer; thus, incident commanders can better manage the transportation of scene patients. Those coordinating patient transport from multiple sites to multiple destinations can quickly determine the triage and transportation status of each patient in the system. Hospital personnel are alerted of pending patient arrival through their EMResource screen and can enter EMTrack to view or add detailed patient information. Operations Centers can monitor patient volume and activities in real time, determine the scope of the incident, and more rapidly coordinate resources to support first responders and receivers. Finally, reunification centers can timely track patients to unite them with loved ones. System data elements can be found in Appendix K. They provide an excellent example of data requirements for both day-to-day and mass casualty incidents.

St. Louis’ Emergency Patient Tracking System (EPTS)

Scope: All hazards tracking for 8 counties across two states, 18 Tier 1 and Tier 2 Hospitals, and 10 EMS Agencies

Standards: None

Integration: Integrated with other regional applications such as Rapid Response and E-Team.

Status: Implemented in 2006 in St Louis; still being rolled out to other counties.

The emergency patient tracking system (EPTS) helps to track patient movement during critical incidents commonly associated with mass casualty type situations. However, the system is designed for all-day, every-day use by identifying and tracking patient movement from field emergency medical system (EMS) units to the St. Louis region‘s hospital emergency departments. The system utilizes barcoded patient identification bracelets with triage information and wireless scanning and data transmitting devices, to a secure, web-based database. The initial phases of St. Louis‘ Emergency Patient Tracking System (EPTS) began soon after September 11

th with a Raytheon solution. It became ―live‖ on May 8, 2003. However the Raytheon

could not meet the needs of the using communities. So, in 2005, STARRS16

selected IBM to provide

16

The St. Louis Area Regional Response System (―STARRS‖) is a regional organization developed to

coordinate planning and response for large-scale critical incidents in the bi-state metropolitan region.

Re

se

ar

ch

Re

po

rt


Results

a new real-time patient tracking system that will improve response times in any emergency, from a simple traffic accident to a large-scale disaster. The Raytheon system was then replaced with EMTrack from EMSystem.

Tennessee Mass Casualty Incident – Patient Tracking

Scope: Pre-Hospital, Mass Casualty Incident, defined by the state of TN as ―MCI is when local resources are or will be exhausted/overwhelmed and support is needed from other jurisdictions.‖

Standards: NEMSIS

Status: Detailed requirements doc released August 2007

The Tennessee Mass Casualty Incident – Patient Tracking program is the automated process of documenting the location, condition, treatments, and movement of patients thru the continuum of care. This also includes the sharing of information about the incident and initial resource requirements typically gathered by 9-1-1 or Emergency Communications Centers and providing to those responding to the incident. MCI-PT is designed to be a ‗patient centric‘ effort where each patient will be uniquely identified and associated with an incident. The information collected and shared will support disaster/incident management and analysis. In addition, TNEMA the Tennessee Emergency Management Agency and the Tennessee Department of Safety‘s Office of Homeland Security will continue to be involved in the design and subsequent implementation to help guide and ensure that the MCI-PT is part of an overall interoperable set of preparedness and response systems.

Vendor Products

Pre-Hospital Solutions

Disaster Management Solutions

Disaster Management Solutions (DMS) began in 1996 with the creation of the triage tag and has extended its expertise into information technology for emergency responders. DMS presents itself as having a comprehensive scene data collection system, called First Trak which includes hardware and software to track patients, personnel and equipment during a disaster. First Trak PTS, deployed by over 60 entities, can be used for: Mass casualty incidents (Patient counts by status and destination in real time, complete patient

history with time stamps – when they were entered into the system, when they were treated, when they departed the scene, and where they were sent, optionally take picture of patient when no other identification is available, and track evidence collected from patient via same barcode number.)

Daily run reports Inter-hospital transfers Mass prophylaxis Mass vaccination

First Trak INV includes:

Re

se

ar

ch

Re

po

rt


Results

MCI equipment tracking Daily EMS inventory management Strategic National Stockpile and Point of Dispensing (POD) Inventory Management First Trak POD can help control catastrophic outbreaks through mass vaccination and prophalaxis. DMS has implemented solutions for several hundred clients, including regions responsible for several million residents, such as Kansas City, Orange County CA, Riverside County CA, and North Carolina.

EMSystem EMSystems was founded in 1998 by Emergency Department physicians who were intent upon developing a solution to improve communication processes between hospitals and emergency medical service agencies regarding bed status and availability. EMSystems is now recognized as the leading provider of web-based healthcare information management solutions used by greater than 35% of the nation‘s population in medical emergency event preparation, detection, and response. It offers a suite of four products on a managed service basis: EMTrack, EMResource, EMRecord, and EMCredential. EMTrack is a robust Web-enabled, browser-based system that facilitates patient entry through scan-and-go technology, equips hospitals to manage surges, evacuations, and alternate site movements, and enables Emergency Operations Center users to view, report, and manage transport activities. EMTrack exceeds HRSA regional emergency requirements, allowing officials to rapidly input, easily search and securely view patient information in day-to-day use, during mass casualty incidents, and during hospitals evacuations. EMResource, tracks the supply-side of the medical systems, namely bed availability. EMRecord is an online personal health record that allows users to easily collect and disseminate critical EMS patient information. EMCredential is an ESAR-VHP/NIMS compliant volunteer registry application that effectively manages volunteers, critical in emergency preparedness and response. Current customers include: Houston, TX, St. Louis STARRS, San Francisco, Santa Clara County CA, Kansas City, Orlando, North Carolina, Boston, Michigan, Arizona, Louisiana, and New York (FDNY). Raytheon The Electronic Patient Tracking System (EPTS) was developed by Raytheon to manage critical information during Mass Casualty Incidents (MCI). The system automates the collection and dissemination of patient information through use of patient medical identification tags containing bar codes with the patient‘s location, medical status and personal records. Personal digital assistants (PDAs) transfer this information wirelessly to a secure web-enabled database. The database provides the patient‘s information to hospitals and emergency personnel. Centralized patient information allows authorities to balance resources and minimize hospital overcrowding. Casualty scene information, stored in a central database, is disseminated to command centers, hospitals and support agencies over the Internet. Various users and agencies have the ability to search the database for detailed information about the incident and patients. The EPTS transfers patient medical condition, initial assessments and personal records before the patient arrives at the hospital. Patient records are transferred to admissions personnel and the appropriate medical staff is alerted to arriving patients. Patient data continues to be collected until the patient is released, admitted, or transferred to another hospital. The system also provides an audit trail, enabling emergency response organizations to generate reports and comply with regulatory requirements. This technology has allowed real-time communication between first responders, emergency management, and hospital officials, allowing authorities to balance resources, minimize hospital

Re

se

ar

ch

Re

po

rt


Results

overcrowding, and increase survival rates. Responses to inquiries by family, friends and the media can be handled more quickly and accurately. Emergency medical healthcare customers include: BJC Health Care – St. Louis, MO, Missouri Hospital Association, University of Kansas – Kansas City Kansas, and Blue Cross Blue Shield Health Systems – Detroit. Salamander Salamander Technologies is the leading supplier of accountability solutions in the USA with more than 400 automated systems installed and over 3,000 manual accountability customers nationwide. Prominent customers include the United States Capital Police, Dallas-Ft. Worth Dept. of Health, City of Richmond, Dept. of Defense Fire Training Academy, Redstone Arsenal, State of Michigan USAR, Pocono Raceway, and Michigan State Police - Super Bowl Security. It was used in Houston, TX to manage the evacuation of the city during Hurricane Ike. Its interTRAX suite integrates the elements of Identification, Incident, and Interoperability into a comprehensive solution for tracking resources at an incident, event, or disaster. To maximize interoperability, the same system architecture is used to track responders, MCI patients, evacuees, or site visitors. To maximize interagency coordination, incident data that is managed on-scene at the command post can also be monitored by off-scene facilities and agencies via the internet to provide total resource visibility. The interTRAX suite for Medical Personnel rapidly and accurately tracks patients at a mass casualty incident or disaster. Incident and medical branch managers uniquely identify each victim, assign a triage status, and track victims through treatment and transport - with all activities time and date stamped. This information is available on-scene for incident management, off-scene for trauma center preparedness, and after-incident for full accountability and a chain-of-custody.

The Evacuee Management Solution enables remote incident communications, tracking, and monitoring of evacuees throughout the entire emergency experience and utilizes the same hardware as other solutions in the interTRAX Suite. The solution is also able to link not only family members, but the family pet as well. It makes family reunification easier by the keeping track of the family as a unit, and as individuals when they are sent to different destination sites.

Sydion

Sydion, LLC specializes in mobile data collection and information dissemination for evacuee, shelter, patient, animal, asset and inventory tracking with focus on Surge Capacity, Family Reunification, Pandemic Flu Tracking, Triage and Treatment Area Tracking and Field Managed Inventory Tracking. It also provides solutions for inventory, resource and asset management, point of dispensing for mass vaccination or pandemic flu, volunteer management, animal/pet tracking and mass casualty tracking.

eMET (Emergency Management Event Tracking ) is its flagship system. This system enables the remote scanning and tracking individuals or items in an MCI event or in everyday events. The system contains modules for tracking patients, people and inventory. Data is remotely collected via barcode scanner or magnetic stripe reader equipped handheld units that wirelessly transmit data and camera images to the dashboard. All data is aggregated and stored in the remote database ready for real-time analysis and reporting.

System uses Include:

Re

se

ar

ch

Re

po

rt


Results

ZOLL Data Systems ZOLL Data Systems offers solutions that solve fire and EMS challenges, providing the only fully integrated RescueNet suite of products that includes computer-aided dispatch, billing, field data collection, crew scheduling, fire records management, and mobile data software for the fire and emergency medical services (EMS) market. RescueNet is a fully integrated information management system that allows fire and EMS organizations to manage critical information for maximum performance. RescueNet ePCR Suite is NEMSIS-compliant and helps to streamline data collection in the field, deliver accurate electronic patient care reports, and improve overall operations. RescueNet FireRMS is an enterprise-class, NFIRS/NEMSIS compliant Records Management System designed to streamline reporting, and dramatically reduce report completion time for first responders. Systems would need to be modified to support a fully functioning patient tracking solution. ZOLL Data systems has over 1,400 customers, including Fairfax County Fire and Rescue Department in Fairfax, Virginia that purchased the RescueNet® ePCR Suite and RescueNet FireRMS solutions to improve fire rescue response.

In-Hospital Solutions Emergisoft Since 1990, Emergisoft Corporation has developed, implemented and supported three generations of Emergency Department Information Systems (EDIS). Emergisoft leads the EDIS industry in interface experience with full system interfaces to Siemens, McKesson, Eclipsys, Meditech, CPSI, Cerner and other Hospital Information System (HIS) solutions. EmergisoftED is a completely browser-based and Microsoft .NET Framework Emergency Department Information System that automates each step of the patient management and patient documentation process in the Emergency Department including: Triage, Tracking, Charting (Physician & Nursing), Electronic Charting Forms with Digital Pen Option, Orders / Results, Real-time Automated Vital Sign Monitoring, Charge Capture, Disposition, Discharge Instructions, Scanning & Digital Imaging and Expanded Real-time Management Reporting including Syndromic Surveillance. Many of America's leading healthcare institutions rely on Emergisoft healthcare information solutions. Emergisoft products are in operation in leading single and multi-hospital systems across North America with annual emergency visits ranging from 15,000 to over 300,000 in facilities such as: Northern Dutchess Hospital, Oakwood Hospital System of Michigan, Trinitas Health System of New Jersey, and Tri-Health Good Samaritan of Ohio. Patient Care Technology Systems (PCTS) Patient Care Technology Systems (PCTS) develops intelligent workflow automation solutions for health care providers. Its Amelior™ software suite comprises hospital-wide and department-specific workflow information systems to improve patient flow and reduce the risk of medical errors. PCTS is a pioneering developer of real-time location based automatic patient and asset tracking software and is a leading provider of emergency department documentation systems. Its emergency department products include:

Hospital Mass Casualty/Fatality Management Hospital Triage, Treatment and Transport Surge Capacity/Bed Tracking Management Family Reunification Pre-hospital Triage, Treatment and Transport POD Point of Dispensing for Bio-Terrorism Pandemic Flu Tracking

Hospital Evacuations Public Health Alternate Care Centers NDMS Patient Tracking Multi-state Patient Movement Day-to-Day Patient Tracking On-site Disaster Daycare

Re

se

ar

ch

Re

po

rt


Results

Amelior ED 2.1, a comprehensive EDIS that manages patient information from triage to

disposition. Designed by emergency clinicians, it incorporates category leading automatic tracking, computerized provider order entry simplicity, and context-sensitive clinical decision support. It is the first EDIS to embed automatic tracking within the system to provide the power of real-time patient and asset location and tracking information while caregivers chart.

Amelior EDTracker, a computerized patient and asset tracking system that helps staff and management in the Emergency Department (ED) make better, more informed decisions when managing patient care and department resources. It is available both as a stand-alone tracking solution for your emergency department or as an integrated component of the Amelior ED™ 2.1

Most tracking systems on the market are active systems meaning that someone has to enter every single piece of data the system displays. In all PCTS tracking solutions, patients and staff wear small badges, which emit an infrared (similar to that of a TV remote control), active RFID, ultrasound or ultra-wideband signal roughly every three seconds. The badge signal uniquely identifies the badge. The locating signals that badges emit are received by sensors located in the ceilings throughout the department and ancillary areas (i.e. for an emergency department this would include radiology, ultrasound, nuclear medicine, etc.) that patients frequently visit. These sensors collect the infrared light or radio frequency signal from the badges, translate it into electrical impulses, and forward those impulses to hardware devices that filter the signals to find the location signatures they contain. These devices—known as collectors and concentrators—then convert the location signatures into badge location data that software can understand. Through Amelior automatic tracking systems, users associate badge numbers with individual patients, staff, or equipment. Likewise, the system links individual sensors to specific locations. PatienTrak

PatientTrak.net was created in order to easily and affordably allow Emergency Departments and Healthcare Organizations to track and monitor patients via a simple web browser. The design of PatientTrak.net is suitable to an Emergency Department and user-configurable options and features within the product make it perfectly suitable for any healthcare department or organization. PatientTrak.net provides a high-level of product features, while still maintaining the simplicity that is fundamental in the initial design of the product. In addition to the hosted service, the system can also be implemented on an in-house server for those who desire an internally hosted application. The architecture of PatientTrak.net allows for the system to be used on a PDA, with PDA-compatible screens, without requiring any software installation and maintenance on the PDA itself.

Picis Picis is a global provider of innovative information solutions that enable rapid and sustained delivery of clinical, financial and operational results in the acute care areas of the hospital — the emergency department (ED), operating rooms (ORs), post-anesthesia care units (PACUs) and intensive care units (ICUs).

Picis provides a comprehensive and well-integrated emergency department information system

(EDIS). From EMS radio call management and triage to disposition, Picis ED PulseCheck®, part of

the CareSuite® family of high-acuity solutions, manages the entire emergency department

experience. ED PulseCheck is a Web browser-based system that combines the following:

Patient tracking Complete online ED record Real-time documentation for physicians and nursing staff Reliable risk management Comprehensive charge capture Precise prescription writing

Re

se

ar

ch

Re

po

rt


Results

Integrated voice recognition Biosurveillance management HIS interoperability

Customers include Exempla St. Joseph Hospital, Inova Fair Oaks Hospital, Henry Ford Wyandotte

Hospital, Daughters of Charity, Mount Sinai Hospital, Rush University Medical Center, Lawrence

General Hospital, Washington Regional Hospital, Altoona Hospital, Rush University Medical Center,

Washington Regional.

Statcom StatCom's hospital-wide workflow, communications and patient tracking system coordinates activities in real time and completes the gaps in communication between departments. In short, it synchronizes activities such as bed management / bed placement, environmental services, transportation, discharge coordination, patient LOS management, OR patient flow and ED patient flow. The application creates a common workflow infrastructure across the healthcare system. Information enters StatCom seamlessly through a variety of sources including intuitive touch pads, wireless button devices, standard web forms, VOIP, or interactive voice recognition (IVR). It also interfaces directly from HIS and RFID tracking systems and can be integrated with existing healthcare information systems Versus Versus Information System (VIS), is a real-time locating system (RTLS) that puts a hospital in touch with its resources (people and equipment) the moment they are needed for workflow optimization. By using infrared (IR) and active RFID technology, VIS streamlines patient flow and resource deployment to improve safety and efficiency while reducing costs. Versus pioneered the concept of patient flow management in clinical environments resulting in the most widely deployed RTLS for automatic patient tracking within ED, OR and outpatient settings. VIS operates as a stand-alone system, or easily integrates to nurse call, security, asset management, operating room, and emergency department information systems to enhance them with the power of real-time tracking.

http://www.statcom.com/healthcare-software-solutions/patient-tracking.aspx

Suggestions for Follow-up

Re

se

ar

ch

Re

po

rt


Suggested Follow-up

Overview Maintaining separate stove-piped systems for healthcare, public health and emergency response that cannot share information presents a situation that at best could lead to harmful delays, and at worst could unnecessarily expose the public to avoidable threats. That is why it is so important to develop data and messaging standards that enable entities to share information in a simple straightforward manner. A large number of initiatives and technology solutions were examined during the research phase of this project. In almost all instances, the need to integrate with other systems were abundantly evident as implementations of patient tracking systems developed custom interfaces or retro fitted messaging from public health and healthcare to exchange information. Research performed should reinforce the need to develop patient information tracking messaging standards and possibly data standards. However, research also indicates that the process should proceed prudently. With that in mind the following recommendations are being offered for consideration to the Standards Working Group team to help the resulting standards become welcome by the wide variety of stakeholders and systems that need to use them.

Suggested Follow-up

SUGGESTION 1: Emergency Patient Tracking Standards initial scope should be defined to be affordable and achievable in increments of no more than 6 – 8 months. The scope exercise should clearly define what is in and out of initial scope, and should identify areas outside of initial scope that should be considered for subsequent efforts or phases.

SUGGESTION 2: Emergency Patient Tracking Standards should be designed allowing each stakeholder to request or otherwise receive needed information in a form that can be incorporated into the disparate application system in use.

Solutions must address the need to identify, triage, and track individuals and their care and needs as they move through a community‘s system of care that *may* include 9-1-1, medical services, emergency services, social services, and family reunification efforts (TBD-possible phased approach). Each of these domains use an application system(s) tailored to their work processes.

Consideration should be given to standards that define the full set of information needed by various receivers at defined process points. But defined in a flexible manner that allows each receiver to easily apply portions that focuses in on the various needs of these stakeholders and the systems they use. These systems *could* include a 9-1-1 Computer Aided Dispatch (CAD), emergency management Crisis Information Management Software (CIMS), or hospital registration and electronic health record systems – TBD. For instance, emergency managers may have no need for personal identification or individual medical information but do need certain aggregated information. SUGGESTION 3: To understand the current state of patient tracking systems, it may be prudent to invite vendors from each patient tracking category to demonstrate their products and discuss how they have integrated their solutions with other systems. Demonstrations should be designed around the scenarios being used during the standards development process, and should include information about each vendors custom integrations and the data elements included in each interface. Research suggests that the following vendors could possibly provide valuable input to the standards development process: Pre-Hospital Vendors: Disaster Management Solutions, EMSystem, Salamander In-hospital Vendors: Emergisoft, Patient Care Technology Systems, Picis

Re

se

ar

ch

Re

po

rt


Suggested Follow-up

SUGGESTION 4: As scope and requirements for the Emergency Patient Tracking Standards effort become solidified, the effort should perform a formal or informal GAP analysis to determine whether existing standards (e.g. STM CCR, HL7, PHIN messaging standards, NEMSIS) currently map to and support any components of the effort. For those mapping to requirements, consideration should be given to adoption of the existing standard to meet the need. Where no agreed-upon standard exists, consideration should be given to submission of those requirements into a public Standards Development Organization (SDO) process.

For example, the work performed by the Health Information Technology Standards Panel (HITSP) for the Emergency Responder Electronic Health Record Use Case provided a recommended standard (HL7 Continuity of Care Document) for patient health information, the EDXL process should examine this standard to determine if it could also accommodate patient and victim tracking during the chain of response.

The key to this examination should be the standard‘s ability to accommodate the data elements for all stakeholders and the standard‘s ability to offer subsets of information to specific stakeholders. For instance, emergency managers may have no need for personal identification or individual medical information but do need certain aggregated information.

SUGGESTION 5: The design of Emergency Patient Tracking Standards should apply to all hazards (mass casualty incidents and day-to-day emergency events) even though different information element requirements may exist and the process could be triggered in a variety of ways. The nature of the disaster, the rapidity with which it develops, and the phase of the disaster – impact, rescue or recovery – will determine the number of victims, their location, their health status, and their needs

17. Although an infectious disease outbreak that produces large numbers of casualties, such as

pandemic influenza, could develop over weeks or months, typically a disaster that produces mass casualties develops rapidly, over hours or days. An effective patient tracking system as well as Standards must be usable during local, day to day incidents, as well as be deployed quickly to operate under all of these circumstances.

SUGGESTION 6: Based upon research performed, little difference might exist among systems, architecture, standards, or operational points of view between a ―patient tracking system‖ and a ―victim tracking system‖. If this suspicion is validated during initial scoping and analysis activities, consideration should be given to developing standards that perform both functions. This will broaden the scope beyond hospitals as the sole receiver to include processing points such as shelters, supply dispensaries, and morgues.

SUGGESTION 7: Strong consideration should be given to patient/victim identification. Many methods may be accommodated in the market and in localities as some communities use health record IDs, others use barcodes, RFIDs, smartcards or government issued ID‘s such as driver‘s license. In some cases, however, the only means of identification will be a photograph. Patient identification becomes a very critical issue when healthcare records are requested as the requestor needs to make absolutely sure that the patient in crisis is in fact the exact patient represented by the record.

For purposes of this standards effort, consideration should be given to capture and transport of standardized ways to provide various information to request patient identification, and to reply to requests providing patient ID information.

17

Wetterhall SF, Noji EK. Surveillance and epidemiology. In: Noji EK, (ed). The public health consequences of

disasters. Oxford University Press, New York, 1997, pp. 37-64

Re

se

ar

ch

Re

po

rt


Suggested Follow-up

Patient identification has been viewed as a major problem needing to be solved in the National Health Information Network implementations. While the Health Insurance Portability and Accountability Act (HIPAA) of 1996 mandated the development of a unique patient identifier (UPI) to enable physicians, hospitals, and other authorized users to share clinical and administrative records more efficiently, the development of a UPI, a key to linking records across the emerging network, has been completely sidetracked by privacy concerns. One advantage of a properly implemented UPI system is its freedom from errors. If patients have a single, unique identifier that follows them throughout their lives and is used only for health records, there is relatively little chance of a mismatch between individuals and their records. Because statistical matching attempts to substitute for a UPI by using other kinds of information, such as names, birth dates, addresses, zip codes, or employer information, this technique has a higher potential for error than the UPI option because the other kinds of information may not be unique to the individual, may change over time, and may also be entered in varying formats in different databases. Because statistical matching involves the probabilistic pairing of patient data with medical records, two types of errors may occur: false positives, linking to the wrong patient's records, and false negatives, missing the link between a patient and some part of his or her record. Published analyses have found false-negative error rates of about 8 percent in medical databases, trending higher in large databases with millions of records. These errors can pose significant risks for patient safety if providers act on incorrect or incomplete patient information.

Since it seems unlikely that a UPI will be implemented, it may be prudent to investigate the methods being by NHIN implementations so that all data elements required for statistical patient identification mapping will be accommodated by Emergency Patient Tracking Standards.

SUGGESTION 8: Since this standards effort may be dealing with information about individual citizens, additional steps must consider how a messaging or data standard must address concerns with regard to authorization for sharing of the information and the secondary use of the information once the information has been shared. In most cases, the information should be destroyed after the initial need is satisfied, but the boundaries and accountability of a messaging or data standard must be determined.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) began as a ―portability act‖ to help individuals keep their health insurance coverage as they moved from one job to another. HIPAA evolved to include much more than portability. It is a complex set of rules that cover patient privacy and the use of information technology to transfer your medical records. While HIPAA allows unauthorized access to a patient‘s medical information for emergency purposes, this information must also be carefully guarded to ensure that the information is only used to provide care.

Secondary use of health data applies personal health information for uses outside of direct care

delivery. While secondary use of health data can enhance health care experiences for individuals,

expand knowledge about disease and appropriate treatments, and strengthen understanding

about

effectiveness and efficiency of health care systems, complex ethical, political and social issues surround the secondary use of health data.

While not new, these issues play increasingly critical and

complex roles given current trend for improving access

to the data.

For more information on the privacy and reuse of patient health information, see http://www.patientprivacyrights.org/site/PageServer?pagename=Homepage .

SUGGESTION 9: Since patient and victim tracking systems represent the needs of a wide variety of stakeholder groups, the Emergency Patient Tracking effort should include representatives for all effected domains as defined by the scope of the effort.

http://www.patientprivacyrights.org/site/PageServer?pagename=Homepage

Re

se

ar

ch

Re

po

rt


Suggested Follow-up

In this regard subject matter experts involved in each of the researched initiatives have been included in each project‘s high level snapshot. These can be found in or request from the SharePoint repository.

SUGGESTION 10: Since the information from patient and victim tracking systems may be used for many different functions, including resource management and situational awareness, EDXL standards in these areas should be coordinated with the development of Emergency Patient Tracking standards.

The EDXL HAVE and Resource messaging standards could potentially be used in conjunction with patient victim tracking information for resource allocation, management and patient and victim distribution. The EDXL SitRep messaging standard currently provides aggregated patient and victim information for incidents such as the number of patients at the scene or the number of evacuees needing shelter.

Conclusion

Re

se

ar

ch

Re

po

rt


Conclusion

―All disasters are local,‖ is a common saying among those engaged in preparing and responding to emergencies. However, this does not mean that a locality, once overwhelmed, is on its own. Rather, there are many agreements, processes and procedures in place and emerging that attempt to ensure that an appropriate amount of resources, at appropriate levels, can be brought to bear in order to lessen the impact and consequences of a given disaster.

A key concern in preparing and responding to an emergency is making sure that steps are taken to minimize the number of casualties and minimize the adverse health consequences to those who are affected. This requires healthcare and emergency response systems that are resilient, flexible, interoperable and able to surge appropriately to meet the needs of those affected. The landscape is complex in the number and scope of functions as well as in the number and types of organizations involved, and any of the pieces, if not well-coordinated and integrated, could do something that might result in a negative impact despite the best intentions of all concerned.

In response to an emergency, responders often are presented with patients and victims that are little more than ―blank slates.‖ In cases such as a car crash, heart attack or diabetic emergency, responders and providers have little to no information about the patient and his/her medical history. Today data is collected by 9-1-1, collected at the scene by emergency medical services, and is available from sources such as personal health records and OnStar in the event of a car crash. However this data is not provided to, or exchanged among, all relevant parties. This lack of access to a patient‘s pertinent medical history limits the ability of emergency responders to provide the best treatment at the scene. It also hinders treatment by healthcare providers at the Emergency Department as they have limited knowledge of mechanism of injury and/or patient vitals and treatments administered prior to arrival, much less relevant personal medical history such as allergies and medications. New information sources and technologies have the capacity to inform and accelerate emergency response and patient care. Information collected and retained by a variety of external sources – such as Electronic Health Records, Personal Health Records, vehicular crash data, remote monitoring devices, and just-in-time training – can become valuable resources to responders and clinicians throughout the continuum of emergency medical care. These resources can provide responders with critical patient and incident data that they cannot access today. Patients and victims will not receive the best possible care until the emergency data that exists can be shared seamlessly with the stakeholders that need it.

Supporting External Resources


Supporting External Resources R

es

ea

rc

h R

ep

or

t

9/11 Commission. September 20, 2004. The 9/11 Commission Report. Chapter 9: Heroism and Horror. Pages 278-323. http://www.9-11commission.gov/report/911Report.pdf Committee on the Future of Emergency Care in the United States Health System. Institute of Medicine 2006. Emergency Medical Services At the Crossroads. Washington DC: National Academies Press. http://www.iom.edu/CMS/3809/16107/35010.aspx Committee on the Future of Emergency Care in the United States Health System. Institute of Medicine 2006. Hospital Based Emergency Care: At a Breaking Point. Washington DC: National Academies Press. http://www.iom.edu/CMS/3809/16107/35007.aspx Committee on Government Reform US House of Representatives. March 30, 2006. The Need to Know: Information Sharing Lessons for Disaster Response. Washington DC: US Government Printing Office. http://www.fas.org/sgp/congress/2006/infoshare.pdf Committee on Homeland Security and Governmental Affairs United States Senate. 2006. Hurricane Katrina: A Nation Still Unprepared. Washington DC: US Government Printing Office. http://hsgac.senate.gov/_files/Katrina/FullReport.pdf Cilluffo, Frank J., Kaniewski, Daniel J. Maniscalco, Paul M. May 2, 2005. Back to the Future: An Agenda for Federal Leadership of Emergency Medical Services. Washington DC: The George Washington University Homeland Security Policy Institute. http://emsresource.net/politics/HSPI_EMS_task_force_report_5-2-05.pdf National Research Council, Committee on Using Information Technology to Enhance Disaster Management. 2007. Improving Disaster Management: The Role of IT in Mitigation, Preparedness, Response, and Recovery. Washington DC: National Academy of Sciences Press. Public Statement by The Hon. Thomas HJ. Kean and the Hon. Lee H. Hamilton. July 22, 2004. Release of 9/11 Commission Report. http://www.9-11commission.gov/report/911Report_Statement.pdf US Department of Homeland Security. March 1, 2004. National Incident Management System. Washington DC: Department of Homeland Security. US Department of Homeland Security. September 2007. National Preparedness Guidelines. Washington DC: DHS. http://www.dhs.gov/xlibrary/assets/National_Preparedness_Guidelines.pdf

US Department of Homeland Security. September 10, 2007. National Response Framework. Washington DC: DHS. http://www.fema.gov/pdf/emergency/nrf/nrf-base.pdf US Department of Homeland Security. September 2007. Target Capabilities List. Washington DC: DHS. http://www.fema.gov/pdf/government/training/tcl.pdf

http://www.9-11commission.gov/report/911Report.pdf

http://www.iom.edu/CMS/3809/16107/35010.aspx

http://www.iom.edu/CMS/3809/16107/35007.aspx

http://www.fas.org/sgp/congress/2006/infoshare.pdf

http://hsgac.senate.gov/_files/Katrina/FullReport.pdf

http://emsresource.net/politics/HSPI_EMS_task_force_report_5-2-05.pdf

http://www.9-11commission.gov/report/911Report_Statement.pdf

http://www.9-11commission.gov/report/911Report_Statement.pdf

http://www.dhs.gov/xlibrary/assets/National_Preparedness_Guidelines.pdf

http://www.fema.gov/pdf/emergency/nrf/nrf-base.pdf

http://www.fema.gov/pdf/government/training/tcl.pdf

Appendices

Re

se

ar

ch

Re

po

rt


Appendices

Appendix A: Project Templates

Quick Reference Guide

Patient Information Tracking Messaging Standard

Prepared by: Author

<Title> Quick Reference Date:

<Title>

Project Category

Project Scope

Project Description

Sponsoring Organization

Participating Organizations

Primary Reference or Link

Re

se

ar

ch

Re

po

rt


Appendices

High Level Project Snapshot

Patient Information Tracking Messaging Standard

Prepared by: Author

<Title> High Level Project Snapshot Date:

<Title>

Purpose

Objectives

Outcomes

Dates/Status

Project Background

Project Scope

Project Description

Classification

Sponsoring Organization

Participating Organizations

References or Links

Source of Data Elements

Project Definitions

Attachment A: Participant Contact List

Attachment B: Process Flows

Attachment C: Additional Information

Re

se

ar

ch

Re

po

rt


Appendices

Appendix B: Sample Listing of Health Record Vendors

Electronic Health Records

Abraxas Medical Solutions http://www.abraxasmedical.com/

Allscripts Healthcare

Systems http://www.allscripts.com/

Blueware http://blueware.us/

Cerner Corporation http://www.cerner.com/public/

Chartcare http://www.chartcare.com/

CPSI http://www.cpsinet.com/default_IE.php

Digital MD http://www.digitalmd.com/

EClinicalWorks http://www.eclinicalworks.com/

Eclipsys Corporation http://www.eclipsys.com/

e-MDs http://www.e-mds.com/

Epic Systems Corporation http://www.epicsystems.com/

GE Healthcare Information Technologies

http://www.gehealthcare.com/worldwide.html

GEMMS http://www.gemmsnet.com/

GloStream http://www.glostream.com/

Greenway Medical Technologies

http://www.greenwaymedical.com/

Healthland http://www.healthland.com/

Healthcare Management Systems

http://www.hmstn.com/

iMedica http://www.imedica.com/

LSS Data Systems http://www.lssdata.com/

McKesson Provider Technologies

http://www.mckesson.com/

MedcomSoft http://www.medcomsoft.com/

MedHost http://www.medhost.com/Home.aspx

MedInformatix http://www.medinformatix.com/

NextGen Healthcare http://www.nextgen.com/

Pulse http://www.pulseinc.com/

http://www.abraxasmedical.com/

http://www.allscripts.com/

http://blueware.us/

http://www.cerner.com/public/

http://www.chartcare.com/

http://www.cpsinet.com/default_IE.php

http://www.digitalmd.com/

http://www.eclinicalworks.com/

http://www.eclipsys.com/

http://www.e-mds.com/

http://www.epicsystems.com/

http://www.gehealthcare.com/worldwide.html

http://www.gemmsnet.com/

http://www.glostream.com/

http://www.greenwaymedical.com/

http://www.healthland.com/

http://www.hmstn.com/

http://www.imedica.com/

http://www.lssdata.com/

http://www.mckesson.com/

http://www.medcomsoft.com/

http://www.medhost.com/Home.aspx

http://www.medinformatix.com/

http://www.nextgen.com/

http://www.pulseinc.com/

Re

se

ar

ch

Re

po

rt


Appendices

QuadraMed http://www.quadramed.com/

Sage Software http://www.sagehealth.com/wps/wcm/myconnect/sagehealth/www.sagehealth.com/

Siemens

http://www.medical.siemens.com/webapp/wcs/stores/servlet/StoreCatalogDisplay~q_catalogId~e_-1~a_langId~e_-1~a_storeId~e_10001.htm

SpringCharts http://www.springmedical.com/

Xpress Technologies http://www.xpte.com/

Personal Health Records

A Smart PHR Laxor AboutMyHealth LifeLedger AccessMyRecords LifeSensor ActivePHR LifeSpan AMESMyFile Lynxcare Bartlett Magnus Health Portal CapMed icePHR Mobile MedDataNet™ CapMedPHR Medefile Caregiver Alliance Web Services™ Medical ID Card CheckUp MedicAlert Compiling Your Family Health History MedicalSummary CrisisID MedicalSummary™ dLife MediCompass Dr. I-Net MediKeeper DrGlobe.com Med-InfoChipTM EMRy STICK MedKey EMRy STICK MedNotice ER Card Merck Source ER-Idcard Microsoft Health Vault Follow Me My Family Health Portrait Full Circle Registry My Health GlobalPatientRecord My HealtheVet Good Health Network My MedicalCD Google Health Records myHealthFolders Handymedical.com MyLifeSaver Health File MyMedicalRecords.com Health Minder MyMediList Health Profiler MyMeds Health Records Online MyMedSafe HealthButler myNDMA HealthCapture PHR MyNetRecord.com Healthcare Passport MyPHR.com HealtheTracks™ MyPRO™ Medical-Health Records Organizer HealthFolio NoMoreClipBoard.com HealthFrame NoMoreClipBoard.com Healthgram.com OnlineMedicalRegistry HealthNote Organized Solutions HealthString Patient Power

http://www.quadramed.com/

http://www.sagehealth.com/wps/wcm/myconnect/sagehealth/www.sagehealth.com/

http://www.sagehealth.com/wps/wcm/myconnect/sagehealth/www.sagehealth.com/




http://www.springmedical.com/

http://www.xpte.com/

http://www.thesmartphr.com/

http://www.laxor.com/

http://www.aboutmyhealth.org/

http://www.elderissues.com/

http://www.accessmyrecords.com/

http://www.us.lifesensor.com/lsn/content/index_usa.html

https://www.activehealthphr.net/dtc/

http://www.lifespancm.com/

http://www.amesmyfile.com/

http://www.lynxcare.net/

http://www.pehrtech.com/

http://www.magnushealth.com/

https://www.icephr.com/

http://www.meddatanet.com/

https://www.myphrinfo.com/

http://www.medefile.com/

http://www.caregiveralliance.com/

http://www.tnlink.com/medcard/

http://www.checkupsoftware.com/

http://www.medicalert.org/

http://store.channing-bete.com/onlinestore/storeitem.html?vid=20050104004&iid=173793&lang=0&pcode=

http://www.medicalsummary.com/

http://www.crisisid.com/

https://www.medicalsummary.com/

http://www.dlife.com/

http://www.medicompass.com/

http://www.drinet.com/

http://www.medikeeper.com/

http://www.drglobe.com/

http://www.medinfochip.com/

http://www.emrystick.com/download.htm

http://www.medkey.com/

http://www.emrystick.com/

http://www.mednotice.com/

http://www.er-card.com/

http://www.mercksource.com/pp/us/cns/cns_patient_resources_savard_form.jsp

https://secure.er-idcard.com/

http://www.healthvault.com/

http://www.followme.com/

http://www.hhs.gov/familyhistory/

http://www.fullcircleregistry.com/

http://www.myhealth123.com/

http://www.globalpatientrecord.com/

http://www.myhealth.va.gov/

http://www.ghnetwork.com/

http://www.mymedicalcd.com/

http://www.google.com/health

http://www.myhealthfolders.com/

http://www.handymedical.com/

http://www.doctorglobal.com/index2.asp

http://www.wakefieldsoft.com/healthfile

http://www.mymedicalrecords.com/

http://www.health-minder.com/

http://www.mymedilist.org/

http://www.healthprofiler.com/

http://www.my-meds.com/

http://www.healthrecordsonline.com/

http://www.websafe.com/

http://www.healthbutler.com/

https://www.myndma.com/myndma/home/InitHome.do

http://www.healthcapture.com/

http://www.mynetrecord.com/

http://www.healthcarepassport.com/

http://www.myphr.com/your_record/free_forms.asp

http://www.healthetracks.com/

http://www.organizedrecords.com/mypromedical_quicktour.asp

http://www.healthfolio.net/

http://www.nomoreclipboard.net/

http://www.healthframe.com/

http://www.nomoreclipboard.com/

http://www.healthgram.com/

http://www.myomr.com/

http://www.easymedicine.org/

http://www.organizedsolutionsllc.com/

http://www.healthstring.com/

http://gtipatientpower.com/

Re

se

ar

ch

Re

po

rt


Appendices

HealthTracer PatienTrak Healthy Circles People Chart I.C.E. Alert™ Personal MD ICER-2-Go Personal Medical Diary iHealthRecord PHR4me InstaHelpCard ProfileMD iPHER RelayHealth HealthNote Securemed HealthString So Tell Me…™ Medical Organizer HealthTracer Synchart Healthy Circles Telemedical.com

I.C.E. Alert™ The World Medical Card ICER-2-Go TouchNetworks iHealthRecord TravHealth InstaHelpCard VIA Interactive Patient™ VitalChart IQHealth VitalKey I-trax WebMD Health Manager iValley WorldMedcard Jakoter Health Organizer Your Health Record

Just In Case K.I.S. Medical Record Solutions

http://www.healthtracer.com/

http://www.patientrak.com/

https://www.healthycircles.com/

http://www.peoplechart.com/public/index.htm

http://www.directhealthaccess.com/ICE-Alert.html

http://www.personalmd.com/

http://www.icer-2-go.com/

http://www.personalphd.com/

http://www.ihealthrecord.org/

https://www.phr4me.com/

http://www.instahelpcard.com/

http://www.e-medtools.com/profilemd.html

http://www.myipher.com/

http://www.relayhealth.com/

http://www.easymedicine.org/

http://www.securamed.com/

http://www.healthstring.com/

http://www.sotellmeorganizer.com/

http://www.healthtracer.com/

http://www.synchart.com/

https://www.healthycircles.com/

http://www.telemedical.com/

http://www.directhealthaccess.com/ICE-Alert.html

http://www.world-medical-center.com/

http://www.icer-2-go.com/

http://www.touchnetworks.com/

http://www.ihealthrecord.org/

http://www.travhealth.fr/travhealth/src/g_service.asp?langue=UK&mscssid=UVKH32RB8WS92J5X00J859190448

http://www.instahelpcard.com/

http://www.mivia.org/

http://www.wimcare.com/

https://www.vitalchart.com/

http://www.cerner.com/iqhealth

http://www.vitalkey.com/

http://www.i-trax.com/oursolutions/oursolutions.asp

https://healthmanager.webmd.com/

https://www.siouxvalley.com/iValley/index.cfm

http://www.worldmedcard.com/

http://www.jakoter.com/

http://www.yourhealthrecord.com/

http://www.jic-software.com/

http://kismedicalrecords.com/

Re

se

ar

ch

Re

po

rt


Appendices

Appendix C: Project Definitions

All-hazards Approach:

Addresses all types of emergencies and disasters. This approach primarily denotes the use of a single set of management and response systems for response to emergencies regardless of their nature or cause.

Anonymized Data: Applying a common standard to patient information to protect patient identity from undesired disclosure when communicating care data to/from external parties. Also called pseudonymized data. Uses include aggregation for emergency management purposes, communication with public health agencies and research groups.

Chief Complaint: The patient‘s primary complaint. Important for statistical purposes and may not actually be the most serious medical issue.

Continuity of Care Document (CCD):

A harmonized standard that combines ASTM‘s Continuity of Care Record (CCR) standard with the HL7 standard. This harmonized standard will allow for the interoperable exchange of a patient‘s clinical care information between providers.

Continuum of Care: The provision of comprehensive care from the field to hospitals, clinics and physician offices to the home, which advocates the pooling together of medical, emergency, and social services within the community and the creation of linkages between community care initiatives at all levels of the health care and emergency response system. Also called Episode of care.

Electronic Health Record (EHR):

A longitudinal collection of all person-centric health information collaboratively created and maintained by both the person and their team of care providers. It is generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The record is both secure and universally accessible, promoting safe and efficient self-care and provider based care.

Health Information Technology

Standards Panel (HITSP):

A cooperative partnership between the public and private sectors formed for the purpose of harmonizing and integrating standards that will meet clinical and business needs for sharing information among organizations and systems.

Health Level 7 (HL7): Health Level Seven is an American National Standards Institute (ANSI) accredited Standards Developing Organization (SDO) operating in the healthcare arena. HL7‘s domain is standards for electronic interchange of clinical, financial, and administrative information among healthcare oriented computer systems.

HIPAA: The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was introduced to improve portability and continuity of health insurance coverage in the group and individual markets; to combat waste, fraud, and abuse in health insurance and health care delivery; to promote the use of medical savings accounts; to improve access to

http://www.ansi.org/

Re

se

ar

ch

Re

po

rt


Appendices

long-term care services and coverage; to simplify the administration of health insurance; and for other purposes.

Interoperability Specification:

A framework/template that represents a solution set for solving the known problems related to a defined Use Case. It is used by architects and system designers as a way to guide future implementation efforts based on health IT.

Locating: Identification of an individual‘s movement within the response system, and the present physical location of the individual.

LOINC (Logical

Observation Identifiers Names

and Codes):

A database of universal identifiers for laboratory and other clinical observations maintained by Regenstrief Institute which allows for the exchange and merging of clinical results.

Mass Casualty Incident:

Any event resulting in a number of victims large enough to disrupt the normal course of emergency and healthcare services. Generally, they are infrequent, occurring less often than day-to-day emergencies.

National Emergency Medical Services

Information System (NEMSIS):

The National EMS Information System (NEMSIS) serves to provide technical assistance for the implementation of the National Highway Traffic Safety Administration‘s Uniform Pre-Hospital EMS Dataset. The goal of NEMSIS is to establish an EMS data system at the local, state, and national levels.

Public Safety Answering Points (PSAPs) or 9-1-1:

The public‘s point of contact with the emergency medical response system. This includes both individual 9-1-1 callers, and public and private data sources initiating a response request (e.g., police communicating the need for emergency medical response and the identity of the victim; telematics automatic crash notification; heart monitor alarm; hazmat truck crash indication), or providing information about the request.

Patient Information:

Information about an individual that can be used to identify the individual and improve the quality of care given to him/her.

Patient: One who receives medical attention, care, or treatment. For the purposes of this project, the term ‗patient‘ can also include disaster victims, evacuees and the deceased.

Patient Identification: Ability to accurately identify and maintain a single patient record for each patient. It can contain demographic information including addresses, phone numbers, date of birth, sex and other information needed for the provision of care.

Patient Locator: A component of Integrated Patient Tracking, Patient Locator is for determining the location of a patient within the continuum of care.

Patient Tracking: The ability to know, at any given time, the location and status of a patient from the time s/he is first encountered by an emergency responder at an emergency event to arrival at a facility, whether the facility is a hospital, shelter or morgue.

Re

se

ar

ch

Re

po

rt


Appendices

Personal Health Record:

Secure, private, list of person-centric health information, entered, maintained, and managed by that person for themselves, or for others for whom they provide care. The PHR allows the person to view and manage their own health information independent of any provider team.

Provider: Individual assessing, triaging and treating the patient, or providing care for a victim.

Response Chain: The process of emergency response starting with first notification and continuing through the dispatch of emergency services, incident management, and post event analysis and reporting.

SNOMED (Systematized

Nomenclature of Medicine):

Systematized Nomenclature of Human and Veterinary Medicine. A standardized vocabulary system that creates a common clinical language for medical databases. Current modules contain more that 144,000 terms and are available in at least 12 languages.

Special Needs Population:

Individuals with physical, mental or medical care needs who may require assistance before, during or after an emergency after exhausting their usual resources and support. These can include: residents of group living facilities, people without vehicles, non-English speakers, medically fragile individuals, mentally and physically challenged, and visually, hearing, mobility challenged individuals.

Strategic National Stockpiles (SNS):

CDC program that reserves large quantities of medical supplies for use in the occurrence of a public health emergency which results in diminished local supplies. Plans to receive and distribute SNS resources are determined by state authorities.

Tracking: Documentation of an individual‘s movement between point 1 to point n, where n can be one to several locations.

Triage Tag: Tool used by first responders in a mass casualty incident allowing them to identify and track a patient‘s location, severity of injuries, treatment provided, and medications administered during an event.

URGENCY: Complex set of mathematical equations developed by a multidisciplinary team of physicians, trauma surgeons, engineers and crash injury statisticians to predict the probability of a serious, potentially life-threatening injury, resulting from a crash.

Victim:

Any person whose life has been affected by a criminal act, traumatic circumstance or disaster, regardless of severity.

Re

se

ar

ch

Re

po

rt


Appendices

Appendix D: IPTI Patient and Victim Information Elements

IPTI Information Elements Patient Identification Elements

Patient Unique Identification Number (barcode, RFID, etc.) Other identification numbers (Drivers license, Social security, Others according to local requirements) Gender

Age (broken down according to months, days, years, or selected by age range) Date of Birth Weight Hair Color Eye Color Name Aliases Address, City, State Phone Number(s) E-mail address Instant messenger name and service Incident name (e.g. Southwest Mall explosion) Incident ID/number Incident Location (i.e. when patient is entered away from scene, or when multiple incidents have occurred) supported by both GIS and manual location entry Latitude and longitude Street address Location of first encounter with system (i.e. when and where patient was entered into the system) supported by both GIS and manual location entry Latitude and longitude Street address Current Location Latitude and longitude Street address Photograph Race / Ethnicity Blood Type

Parent / Guardian / Next of Kin Contact Information (Phone number, Address) Personal belongings with the individual Relation to nearby victims (if any)

Identifying marks on the patient

Biometric data, which could include fingerprints, iris images, and/or facial images Occupation

Industry Assessment and Treatment Elements

Triage status (using either color-based or number-based system) Initial Updated Chief complaint and other complaints Symptoms by area of body, severity, category (compliant with NEMSIS

and SNOMED) Transportation Information Transporting agency/Unit

Re

se

ar

ch

Re

po

rt


Appendices

IPTI Information Elements Destination Time of Departure Time of Arrival Vital signs Time of assessment Pulses Blood Pressure Qualitative Perfusion Assessment (Capillary Refill, Skin color,

temperature, condition, etc.) Pupils Respiration rate and quality Level of consciousness (GCS) Trauma Score Cardiac rhythm interpretation Pulse oximetry Capnography Glucometry Lung Sounds Body temperature Medical History Medications Medical conditions/problems Allergies Treatment BVM ET Oxygen Bleeding Control Extremity Immobilization Spinal Immobilization IV started Hazardous materials decontamination/Decontamination status Medication Administered Cardiac Electrotherapy Care provider name, ID, credentials, specialization, and organization

Incident Management and Reporting Elements

Situational Awareness Number of patients/victims Numbers at each triage level Number by destination

Resource Management Shelters/capacity Number and types of transportations assets Bed availability

Re

se

ar

ch

Re

po

rt


Appendices

Appendix E: IEMRI Candidate Set of System Groups

Re

se

ar

ch

Re

po

rt


Appendices

Appendix F: AHRQ PTL Prototype Data Elements

Element Name Notes Datatype Length Permitted Values

eventName Name of the event. Corresponds to the incidentID element in EDXL 1.0.

xs:string max length 128

N/A

ptlEventId PTL internal event identifier. Unique within a single PTL instance. Could be specified only if previously retrieved from the same PTL instance.

xs:integer max length 30 Must be valid Event identifier within PTL internal database.

ptlPersonId PTL internal person identifier. Unique within a single PTL instance. Could be specified only if previously retrieved from the same PTL instance.

xs:integer max length 30 Must be valid Person identifier within PTL internal database.

ptlOrgId PTL internal organization identifier. Unique within a single PTL instance. Could be specified only if previously retrieved from the same PTL instance.

xs:integer max length 30 Must be valid Organization identifier within PTL internal database.

orgName Name of the organization (provider/authority) issuing the personId.


N/A

orgId Identifier for the provider/authority, as specified by that entity.

xs:string max length 30 N/A

personId Person identifier used by admitting facility.


N/A

lastName Person's last name. xs:string max length 40 N/A

Re

se

ar

ch

Re

po

rt


Appendices


firstName Person's first name. xs:string max length 40 N/A

emailAddress Person's email address.


N/A

gender Indicator of the sex of the patient: male, female, unknown. Uses DEEDS encoding (Sex).

xs:string max length 1 M = MaleF = FemaleU = Unknown or undetermined

ethnicity The patient's ethnicity as defined by the OMB. Use NEMSIS encoding (Ethnicity).

xs:integer max length 3 690 Hispanic or Latino 695 Not hispanic or Latino

birthDate Patient's date of birth which can be used to calculate the age of the patient. Format: YYYYMMDD

xs:date max length 8 N/A

approxBirthDateFlag Set to "true" if specified birth data is an approximation.

xs:boolean N/A true, false

race Race of the person. Unique code that identifies a Race value. Uses NEMSIS encoding (Race).

xs:integer max length 4 660 = American Indian or Alaska Native 665 = Asian 670 = Black or African American 675 = Native Hawaiian or Other Pacific Islander 680 = White 685 = Other Race

eyeColor Eye color of the person. Unique code that identifies an eye color value. Use NCIC 2000 standard (personal descriptors).

xs:string max length 3 BLK = BLACK BLU = BLUE BRO = BROWN GRN = GREEN GRY = GRAY HAZ = HAZEL MAR = MAROON MUL = MULTICOLORED PNK = PINK XXX = UNKNOWN

Re

se

ar

ch

Re

po

rt


Appendices


hairColor Hair color of the person. Unique code that identifies a hair color value. Use NCIC 2000 standard (personal descriptors).

xs:string max length 3 BLK = Black BLN = Blond or Strawberry BLU = Blue BRO = Brown GRN = Green GRY = Gray or Partially Gray ONG = Orange PLE = Purple PNK = Pink RED = Red or Auburn SDY = Sandy WHI = White XXX = UNKNOWN OR COMPLETELY BALD

specialNeeds Any special needs (such as hearing impaired). Use NEMSIS encoding (Barriers to Patient Care).

xs:integer max length 4 2600 = Developmentally impaired 1605 = Hearing impaired 2610 = Language 2615 = None 2620 = Physically impaired 2625 = Physically restrained 2630 = Speech impaired 2635 = Unattended or Unsupervised 2640 = Unconscious.

distinguishingMarks Text describing any distinguishing marks on the person. Free-form text.


N/A

personalBelongings Text describing any personal belongings. Might include pets, assistive devices (walker, canes), etc. Free-form text.


N/A

triageCategory The last known xs:string max length 6 red, yellow,

Re

se

ar

ch

Re

po

rt


Appendices


triage category. green, black, white

phoneType PTL phone type encodings to represent, for example: home, work, mobile

xs:string max length ???

phoneNbr The phone number. xs:string max length 20 N/A

addressType PTL encoding for address types to represent, for example: home, work

xs:string max length 4 home = Home address mail = Mailing address work = Work address

addressLine1 First line of the address. Free-form text.


N/A

addressLine2 Second line of the address. Free-form text.


N/A

city City for address. FIPS 5-digit place (city) codes (FIPS 55-3).

xs:integer max length 5 FIPS 55-3 codes

county County (or equivalent) for addresses. FIPS 3-digit county (or equivalent) codes (FIPS 6-4).


state State for address. FIPS two-letter state alpha codes (FIPS 5-2).

xs:string max length 2 FIPS 5-2 codes

postalCode Postal code, like US zip code.


contactLastName Last name of relative/guardian.


contactFirstName First name of relative/guardian.


Re

se

ar

ch

Re

po

rt


Appendices


contactAddressLine1 Address line 1 for relative/guardian.


N/A

contactAddressLine2 Address line 2 for relative/guardian.


N/A

contactCity City for address of relative/guardian. FIPS 5-digit place (city) codes (FIPS 55-3).


contactCounty County (or equivalent) for addresses. FIPS 3-digit county (or equivalent) codes (FIPS 6-4).


contactState State for address of relative/guardian. FIPS two-letter state alpha codes (FIPS 5-2).


contactPostalCode Postal code, like US zip code, for relative/guardian.


contactPhoneNbr The phone number for relative/guardian.


contactType The relationship of the patient's closest relative or guardian.

xs:integer max length 3 950 = Appointed Guardian 955 = Father 960 = Mother 965 = Other 970 = Son/daughter 975 = Spouse.

locationName Name of the location. Not required if the location is defined in the location table.


N/A

locationOrgName Name of the organization with which the location is associated.

xs:string N/A

locationOrgId External identifier used by the providing entity to identify an organization that is associated with the location.


N/A

Re

se

ar

ch

Re

po

rt


Appendices


locationAddressLine1 First line of the location address. Free-form text.


N/A

locationAddressLine2 Second line of the location address. Free-form text.


N/A

locationCity City for location address. FIPS 5-digit place (city) codes (FIPS 55-3).


locationCounty County (or equivalent) for location addresses. FIPS 3-digit county (or equivalent) codes (FIPS 6-4).


locationState State for location address. FIPS two-letter state alpha codes (FIPS 5-2).


locationPostalCode Postal code for location address, like US zip code.


locationStartDate Date when the person left the location. Format: YYYYMMDD


locationEndDate Date when the person left the location. Format: YYYYMMDD


dispositionType PTL code to represent the disposition of the person upon leaving the location (formerly discharge). Is there a standard

xs:integer max length 1 1 = released 2 = transferred 3 = deceased

Re

se

ar

ch

Re

po

rt


Appendices


encoding?

Re

se

ar

ch

Re

po

rt


Appendices

Appendix G: HITSP EREHR IS04 Recommended Standards

Construct Standard Reference C19 Entity identity Assertion

IHE Cross-Enterprise User Authentication (XUA) Supplement to the IHE-ITI-TF-2

http://wiki.ihe.net/index.php?title=Cross-Enterprise_User_Assertion_Profile

C28 Emergency Care Summary Document

IHE Emergency Department Encounter Summary

http://wiki.ihe.net/index.php?title=PCC_TF-1/EDES

C32 Summary Documents

HL7 CCD http://www.hl7.org/Library/General/HL7_CCD_final.zip

C39 Encounter Message

HL7 V2.5 ADT

www.hl7.org

C47 Resource Utilization Message

OASIS EDXL HAVE OASIS EDXL RM

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency

C48 Encounter Document

IHE PCC-Technical Framework (TF)

HL7 v3.0 CDA IHE Patient Care

Coordination (PCC) Cross Enterprise Sharing of Medical Summaries (XDS-MS)

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_4-0_Vol_1_2008-10-10.pdf http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_4-0_Vol_2_2008-10-10.pdf

C82 Emergency Common Alerting Protocol

OASIS CAP http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf

T23 Patient Demographics Query

IHE PDQ http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Patient_Demo_Query_2004_08-15.pdf

TP13 Manage Sharing of Documents

IHE XDS IHE XCA

www.ihe.net

T16 - Consistent Time

IETF Network Time Protocol (Version 3) Specification, Implementation and Analysis, "Request for Comment" (RFC) #1305

www.ietf.org

TP20 - Access Control

HL7 v3 Role Based Access Control (RBAC)

OASIS Security Assertion Markup Language (SAML) Core v2.0

OASIS WS-Trust Version 1.3

OASIS WS-Federation Web Services Federation Language (WS- Federation)

OASIS eXtensible Access Control Markup Language (XACML), ITU-T

www.oasis-open.org





http://www.hl7.org/Library/General/HL7_CCD_final.zip

http://www.hl7.org/Library/General/HL7_CCD_final.zip

http://www.hl7.org/




http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_4-0_Vol_1_2008-10-10.pdf






http://www.oasis-open.org/committees/download.php/15135/emergency-CAPv1.1-Corrected_DOM.pdf




http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Patient_Demo_Query_2004_08-15.pdf



http://www.ihe.net/

http://www.ietf.org/

http://www.oasis-open.org/

Re

se

ar

ch

Re

po

rt


Appendices

Construct Standard Reference Recommendation X.1142

TP22 Patient ID Cross Reference

IHE IT Infrastructure Technical Framework (ITI-TF) Patient Identifier Cross-Referencing (PIX)

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf

T40 - Patient Health Plan Eligibility Verification

Accredited Standards Committee (ASC) X12 270 and 271 transaction standards version 4010, using the Insurance Subcommittee (X12N) Implementation Guides

www.wpc-edi.com

T63 Emergency Message Distribution Element

OASIS EDXL DE http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf

T68 - Patient Health Plan Authorization

Accredited Standards Committee (ASC) X12 278 Transaction Version Standards Release 004010

www.wpc-edi.com

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4_0_Vol1_FT_2007_08_22.pdf



http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_4.0_Vol2_FT_2007-08-22.pdf



http://www.wpc-edi.com/

http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf



http://www.wpc-edi.com/

Re

se

ar

ch

Re

po

rt


Appendices

Appendix H: ASTM Continuity of Care Record (CCR) Document Object

Re

se

ar

ch

Re

po

rt


Appendices

Appendix I: VEDS Document Object Model

Pertinent Vehicular Emergency Data Set Structure

1.1 PostCrashOnSceneData

Information gathered by inquiries of the incident originator or agencies on the scene responding to the incident.

Number of Occupants

<NumOccupants> Number of Occupants

Occupant – Information about each occupant. 0 – infinity.

Begin Child Elements of Occupant

Occupant‘s Name

<Name> Name of the vehicle occupant.

Re

se

ar

ch

Re

po

rt


Appendices

Occupant‘s Age

<Age> Age of the vehicle occupant

Occupant‘s Gender

<Gender> Gender of the vehicle occupant. Indicates the gender of the person. Values:

M - Male F - Female U - Unknown

Conscious <Conscious> Indicates if occupant is conscious. Values:

Y – Yes N – No U - Unknown

Breathing <Breathing> Indicates if occupant is conscious. Values:


Speaking <Speaking> Indicates if occupant is conscious. Values:


Moving - Data about what limbs the occupant can move

Begin Child Elements of Moving

Arm <Arm> Indicates if occupant can move his arm. Values:


Leg <Leg> Indicates if occupant can move his leg. Values:


End Child Elements of Moving

External Bleeding

<ExternalBleeding> Indicates if occupant has external or visible bleeding. Values:


Entrapped <Entrapped> Indicates if occupant is entrapped in the vehicle. Values:


Ejected <Ejected> Indicates if occupant was ejected from the vehicle. Values:


Seat <SeatPosition> Indicates the seat that the occupant was occupying

Re

se

ar

ch

Re

po

rt


Appendices

Position in the vehicle. Values: Driver front Front row middle Passenger front second row left second row middle second row right third row left third row middle third row right

Child Seat - Data about the child seat used by this occupant.

Begin Child Elements of Child Seat

Restraint Type

<RestraintType> Description of the restraint type

Child Weight <ChildWeight> Weight of the child occupying the child seat.

Injury Patterns

<InjuryPatterns> Injury patterns the child sustained

Seat Type <SeatType> Indicates the type of seat Values: Built in Installed

Latch Used <LatchUsed> Description of the latch used on the child seat.

End Child Elements of Child Seat

End Child Elements of Occupant

Re

se

ar

ch

Re

po

rt


Appendices

1.2 Personal Medical Data

Medical information previously known and stored by the incident originator or a third party provider.

Subscriber

Information for each individual listed under personal medical data subscription with required attribute: id.

Begin Child Elements of Subscriber

Provider - Company providing personal medical data.

Begin Child Elements of Provider

Name <Name> Name of the Provider

Retrieval Method

<RetrievalMethod> Indicates method necessary to retrieve additional detailed medical records (e.g. EKG, MRI, etc). Values: Phone Fax Internet Email Other

Telephone Number

<TN>

Fax <Fax>

URL <URL>

End Child Elements of Provider

Record Update Date

<RecordUpdateDate> Last known update of personal medical data

Subscriber Information – Information about the Subsciber

Begin Child Elements of SubscriberInfo

Name <Name> Name of the Subscriber

Age <Age> Age of the Subscriber

Gender <Gender> Gender of the Subscriber

Language <Language> Language of the Subscriber

Hearing Impaired

<HearingImpaired> Indicates whether the person is hearing impaired. Values:


Mobility Impaired

<MobilityImpaired> Indicates whether the person is mobility impaired Values:


Speech Impaired

<SpeechImpaired> Indicates whether the person is speech impaired. Values:


Re

se

ar

ch

Re

po

rt


Appendices

Other Condition

<OtherCondition> Other condition information that may be of use to responders

Begin Child Elements of SubscriberInfo

Primary Care Physician - Subscriber's primary care physician information

Begin Child Elements of PrimaryCarePhy

Name <Name>

Telephone Number

<TN>

End Child Elements of PrimaryCarePhy

Emergency Contact - Subscriber's emergency contact information.

Begin Child Elements of EmergncyContact

Name <Name> Name of Emergency Contact

Telephone Number

<TN> Telephone Number of Emergency Contact.

Alternate TN <AltTN> Alternate Telephone Number of Emergency Contact.

End Child Elements of EmergncyContact

Medical History

<MedicalHistory> Current medical conditions pertinent to acute medical treatment of subscriber.

Allergies <Allergies> Subscriber's medication allergies.

Medications <Meds> Medications currently being taken by subscriber.

Blood Type < BloodType> Subscriber's blood type.

Pregnant < Pregnant> Indicates whether the subscriber is pregnant. Values:


Organ Donor

<OrganDonor> Indicates if subscriber is an organ donor. Answered as true or false.

Preferred Hospital

<PreferredHospital> Subscriber's preferred hospital for treatment

Living Will <LivingWill> Indicates if the subscriber has a living will or formal end of life document, such as "do not resuscitate" (DNR).

Driver’s License - Subscriber's drivers license information

Begin Child Elements of DriversLicense

Number <Number> Driver License Number.

StateProvince

<StateProvince> State and Province of the Driver.

End Child Elements of DriversLicense

Social Security Number

<SSN> Social Security Number of the Driver.

Insurance Provider - Subscriber's primary insurance provider information.

Begin Child Elements of Insurance Provider

Name <Name> Name of the Insurance Provider

Re

se

ar

ch

Re

po

rt


Appendices

Policy ID <PolicyID> Policy of the Insurance Provider

Telephone Number

<TN> Telephone Number of the Insurance Provider

End Child Elements of Insurance Provider

End Child Elements of Subscriber

Primary Driver - Information about the primary driver of the vehicle

Begin Child Elements of Primary Driver

Name <Name> Name of the Primary Driver

Age <Age> Age of the Primary Driver

Gender <Gender> Gender of the Primary Driver

Language <Language> Language of the Primary Driver

Hearing Impaired



Mobility Impaired



Speech Impaired



Other Condition


End Child Elements of Primary Driver

FrequentDriverOccupant - Information about frequent drivers and frequent occupants

of the vehicle

Begin Child Elements of Frequent Driver Occupant

Name <Name> Name of the Primary Driver

Age <Age> Age of the Primary Driver

Gender <Gender> Gender of the Primary Driver

Language <Language> Language of the Primary Driver

Hearing Impaired



Mobility Impaired



Speech Impaired



Re

se

ar

ch

Re

po

rt


Appendices

Other Condition


End Child Elements of Frequent Driver Occupant

End Child Elements if Personal Medical Data

Re

se

ar

ch

Re

po

rt


Appendices

Appendix I: Metro Boston Patient tracking System Data Elements

Demographics Patient Tracking ID # First Name Middle Name/Initial Last Name Street Address City State Zip Code Phone # Phone Type Email Address Housing Type Temporary Address Permanent Home Destroyed Age Date of Birth Height Feet/Inches Weight Gender Eye Color Hair Length Hair Color Facial Hair Skin Color Shirt Pant/Skirt Shoes Uniform Found with Objects Identifying Marks Alternate ID # Driver's License # Driver's License State DL/ID Raw Data (from Scan/swipe) Ethnic Background Language(s) Spoken Translation Required Insurance Image Image Description

Complaint/History Triage Category (Triage values are based on START triage definitions, although WHITE (uninjured) and GREY (almost dead) were added) Complaint Category Complaint Description Incident Involvement Allergies Medications Medical History Glasses Dentures Hearing Aid Contaminated

Re

se

ar

ch

Re

po

rt


Appendices

Contamination Description Decontaminated Decon Date Time

Vital Signs Blood Pressure

Pulse Respiration Temperature

Medications Med Time Medication Name Dose Amount Lot# Manufacturer Route Site Administered By Ordered by Reaction State Administered Comment

Procedures Procedure Time Procedure Name Procedure Results Administered by Ordered by Reaction State Administered Treatment Level Treatment Comment

Relatives Relative Type Relative Note Relative Link to Exist Patient Relative First Name Relative Middle Initial Relative Last Name Relative Street Address Relative City Relative State Relative Zip Relative Phone Relative Email

Property Prop. ID Prop. Description Prop Current Location Prop. Current Loc Comment Prop. Destination Prop. Destination Comment Prop. Destination Contact Prop. Returned to Owner

Re

se

ar

ch

Re

po

rt


Appendices

Provider Provider Name Provider Unit ID (if applicable) Actual Start Time End Time (either estimated or actual) Latitude (For GIS mapping) Longitude (For GIS mapping) Disposition Actual Patient Arrival Time Actual Patient Arrival Update User Actual Patient Discharge by Actual Patient Discharge Time

Re

se

ar

ch

Re

po

rt


Appendices

Appendix K: Sample Triage Tag

Re

se

ar

ch

Re

po

rt


Appendices

Appendix J: San Francisco Patient Tracking System Data Elements

Daily Patient Data Element Description

Name Definition Values Default Value

NEMSIS Element Required

ID# This is the identification # used by the organization to track the patient

Free Text From scanned tag in MCIs, randomly generated in daily

Blank Patient Care Report Number (E01_01)

Yes

Age The patient's age (either calculated from date of birth or best approximation)

Number between 0-120

Blank Age (E06_14) Yes, unless ―Unknown‖ is selected in Age Unit

Age Unit The units which the age is documented in (Hours, Days, Months, Years)

Years, Months, Days, Hours, Not Known

Years Age Unit (E06_15) Yes

Gender The patient's gender

Male, Female, Unknown, Other

Select One…

Gender (E06_11) Yes

Chief Complaint

This is the category for the patient‘s illness/injury

Not Available, Abdominal pain / problems, Airway obstruction, Allergic reaction, Altered level of consciousness, Behavioral / psychiatric disorder, Cardiac arrest, Cardiac rhythm disturbance, Chest pain / discomfort, Diabetic symptoms (hypoglycemia), Electrocution, Hyperthermia, Hypothermia, Hypovolemia / shock, Inhalation injury (toxic gas), Obvious death, Poisoning / drug ingestion, Pregnancy / OB delivery,

Select One…

Providers Primary Impression (E09_15)

Yes

Re

se

ar

ch

Re

po

rt


Appendices



Respiratory distress, Respiratory arrest, Seizure, Sexual assault / rape, Smoke inhalation, Stings / venomous bites, Stroke / CVA, Syncope / fainting, Traumatic injury, Vaginal hemorrhage

Backboard Is this patient currently immobilized on a backboard

Yes, No Select One…

Procedure (E19_03) NFIRS 5.0: Spinal Immobilization =22

This is required only for patients that have a chief complaint selected that is or may be traumatic in nature (see ** in chief compliant list). For other patients it is not displayed or required

Triage Category The START triage category assigned.

Red, Yellow, Green, Black

None. None Yes

Destination The next location where this patient will receive care

San Francisco Hospitals plus Highland and Marin General, Helicopter (specify service in text), Out of County (specify in text)

Select One…

Destination/Transferred to, Name (E20_01)

Yes

ETA (mins) Number of minutes before the estimated time of arrival of the patient at the destination.

5, 10, 15, 20, 25, 30, 45, 60, 90, 120, 150, 180

Select One…

Patient Arrived at Destination Date/Time (E05_10)

Yes

Re

se

ar

ch

Re

po

rt


Appendices



Provider The agency providing transportation to destination

San Francisco EMS Providers, MUNI, ME, POV

If user is mobile provider, default to provider name, if not then = Select One…

EMS Agency Name (D01_02)

Yes

Unit The identifying numbers and/or letters for the transport unit

Free Text Field Pick list specific to the provider + Other field

Blank EMS Unit Call Sign (D04_02)

Yes

Contaminated Is pt. contaminated

Radio buttons: Unknown, Yes, No

Unknown

Decontaminated Only if ‗yes‘ in previous field

Radio buttons: Unknown, Yes, No + text field

Unknown

Comments Free text comments

Memo field Blank

The fields required for creation of a new MCI triage patient record are:



ID# This is the identification # used by the organization to track the patient

Free Text Blank Patient Care Report Number (E01_01)

Yes

Triage Category The START triage category assigned.

Red, Yellow, Green, Black

None None Yes

Gender The patient's gender

Male, Female, Unknown, Other

Select One…

Gender (E06_11) Yes

Current Location

The patient‘s current position.

Scene – Transport ** Will also contain incident locations as they are created San Francisco Hospitals

If user is mobile provider, default to Select One… ,if hospital user— default to hospital name.

None Yes

Re

se

ar

ch

Re

po

rt


Appendices



Destination The next location where this patient will receive care

San Francisco Hospitals + Marin General and Highland, Out of county, helicopter providers, Casualty Collection Points # 1 – 5, DMAT, Other w/text

Select One…

Destination/Transferred to, Name (E20_01)

Yes

ETA (mins) Number of minutes before the estimated time of arrival of the patient at the destination.

5, 10, 15, 20, 25, 30, 45, 60, 90, 120, 150, 180

Select One…

Patient Arrived at Destination Date/Time (E05_10)

Yes


San Francisco EMS Providers, MUNI, ME, POV, Mutual Aid

If user is mobile provider, default to provider name, if not then = Select One…

EMS Agency Name (D01_02)

Yes

Unit The identifying numbers and/or letters for the transport unit

Free Text Field Blank

Contaminated Is pt. contaminated

Radio buttons: Unknown, Yes, No

Unknown


Decontaminated Only if ‗yes‘ in previous field

Radio buttons: Unknown, Yes, No + text field

Unknown

Yes

Re

se

ar

ch

Re

po

rt


Appendices



Comments Free text comments

Memo field Blank No