Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
    • Environment:

      EDXL-HAVE

    • Proposal:
      Hide

      1 Introduction
      [All text is normative unless otherwise labeled]
      1.1 Terminology
      The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
      Error! Reference source not found..
      1.2 Normative References
      [CAP-1.2] Common Alerting Protocol Version 1.2. 01 July 2010. OASIS Standard. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html.
      [XMLSCHEMA-2] XML Schema Part 2: Datatypes Second Edition , P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . Latest version available at http://www.w3.org/TR/xmlschema-2/ .
      [EDXL-CT] Joerg, W. Committee Specification Draft Emergency Data Exchange Language Common Types. November 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd01/
      [EDXL-DE] EDXL Distribution Element (DE) Standard v1.0. March 2006. OASIS. http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc
      [EDXL-GSF] Joerg, W. Committee Specification Draft Emergency Data Exchange Language GML Simple Features. September 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/csd01/
      [NAMESPACES] Namespaces in XML 1.0 (Third Edition) , T. Bray, D. Hollander, A. Layman, R. Tobin, H. S. Thompson, Editors, W3C Recommendation, 8 December 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/ . Latest version available at http://www.w3.org/TR/xml-names .
      [OASIS CIQ] Customer Information Quality (CIQ) Specifications Version 3.0, Name (xNL), Address (xAL), and Party (xPIL). June 15, 2007. OASIS. http://docs.oasis-open.org/ciq/v3.0/specs/
      [OGC 07-36r1] Geography Markup Language (GML) Implementation Specification Version 3.2.1. 2007. Open Geospatial Consortium. http://portal.opengeospatial.org/files/?artifact_id=20509
      [OGC Schemas] GML 3.2.1 schemas. 2007. Open Geospatial Consortium. http://schemas.opengis.net/gml/3.2.1/
      [OGC 10-100r3] Geography Markup Language (GML) simple features profile (with Corrigendum) (2.0). 2010. http://portal.opengeospatial.org/files/?artifact_id=42729
      [OGC CRS] Topic 2 - Spatial Referencing by Coordinates (Topic 2) (CRS Abstract Specification), Version 3. 2004. Open Geospatial Consortium,. https://portal.opengeospatial.org/files/?artifact_id=6716
      [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
      [RFC5646]] Phillips, A., Ed., and M. Davis, Ed., Tags for Identifying Languages, BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, http://www.rfc-editor.org/info/rfc5646.[WGS 84] Department of Defense World Geodetic System. 1984. National Geospatial Intelligence Agency. http://earth-info.nga.mil/GandG/wgs84/index.html
      [XML 1.0] Extensible Markup Language (XML) 1.0 (Fifth Edition) , T. Bray, J. Paoli, M. , E. Maler, F. Yergeau, Editors, W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/ . Latest version available at http://www.w3.org/TR/xml .Non-Normative References
      [AHIC-BIODATA] BioSurvellience Data Elements. American Health Information Community (AHIC), BioSurvellience Data Working Group. http://www.hhs.gov/healthit/ahic/bio_main.html
      [EDXL-EXT] EDXL Extension, OASIS. https://tools.oasis-open.org/version-control/browse/wsvn/emergency/HAVE/rim/edxl-ext-v1.0.xsd
      [GJXDM] Global Justice XML Data Model (GJXDM) Data Dictionary. Global, Office of Justice Programs. http://it.ojp.gov/topic.jsp?topic_id=43
      [GML-BESTPRAC] Best Practices: A GML Profile for use in OASIS EM Standards - EDXL-RM, EDXL-DE, HAVE, and CAP DRAFT. Open Geospatial Consortium. http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20785/Best%20Practices%20-%20a%20GML%20Profile.doc
      [HAVBED-DATA] Hospital Bed Availability (HAvBED) Project – Definitions and Data Elements: AHRQ Releases Standardized Hospital Bed Definitions. Agency for Healthcare Research and Quality (AHRQ): http://www.ahrq.gov/research/havbed/definitions.htm
      [HAVBED2-REP] HAvBED2 Hospital Available Beds for Emergencies and Disasters. A Sustainable Bed Availability Reporting System. Final report. AHRQ Publication No. 09-0058-EF. April 2009. AHRQ. http://archive.ahrq.gov/prep/havbed2/havbed2.pdf
      [HAVE-REQSUP] EDXL HAVE Requirements Supplement. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16400/
      [HAVE-SRS] EDXL HAVE Standard Requirements Specification. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16399/
      [HL7] Health Level Seven International. - http://www.hl7.org/.
      [RM-DATAREQ] EDXL Resource Messaging (RM) Draft Requirements Specification. OASIS. http://www.oasis-open.org/committees/download.php/14310/
      [VHHA-TERM] Statewide Hospital Status Information System Terminology and Data Collection Elements. Virginia Hospital & Healthcare Association (VHHA). http://www.oasis-open.org/committees/download.php/18019

      1.3 Purpose
      The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national, international and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved.
      The current roster of published EDXL Standards includes:
      • The Common Alerting Protocol v1.2 specification (EDXL-CAP), with various dedicated profiles
      • The Distribution Element specification v2.0 (EDXL-DE)
      • The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE)
      • The Tracking of Emergency Patients specification v1.1 (EDXL-TEP)
      • The Resource Messaging specification v1.0 (EDXL-RM)
      • The Situation Reporting specification v1.0 (EDXL-SitRep)
      • The Tracking of Emergency Client v1.0 (EDXL-TEC)
      The primary purpose of EDXL-HAVE is to provide an XML-based reporting format that allows information to be shared about a set of health facilities including the communication of the status of a health facility, its services, and its resources. These include bed capacity and availability, emergency department status, staffing levels, available service coverage, and the status of a health facilities operations and resources.
      The primary audience for EDXL-HAVE is the broad community that interacts with health facilities and it is intended to be used as a tool to automate information flow in and out of the health network. It is not intended to be a tool used for internal administration of health facilities as other standards organizations (e.g. Health System Level Seven International – www.hl7.org) already handle this domain.

      1.4 History
      In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions such as where to route victims and automatically determining which hospitals have the ability to provide the needed service. Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as Emergency Operations Centers (EOCs), 9-1-1 centers, and Emergency Medical Systems (EMS) responders via a Web-based tool.
      The Hospital Availability Exchange standard was created to make sharing information about the state of hospitals for day-to-day and crisis use. Initially it was focused purely on hospitals but it has been extended to handle sharing information about the broader health network, including long-term care facilities, urgent care clinics, and temporary aid centers.
      HAVE 1.0 was released on 22DEC2009. Since the release of HAVE 1.0 there have been multiple operational uses of HAVE, including after the 2010 Haiti Earthquake. In many of the operational uses there were modified schema used to add services that were not in HAVE 1.0 and to convey other aspects of the data and to handle the sharing of information about non-hospital facilities (e.g. clinics, temporary locations). The use of the HAVE 1.0 standard was encouraging but the shortfalls needed to be addressed. To that end, in 2010 the OASIS EM-TC voted to re-open the HAVE standard with the goal of creating a HAVE 2.0 standard.
      The HAVE data exchange standard goes hand in hand with the EDXL Tracking of Emergency Patients (TEP). A TEP-based data exchange collects data on patients from incident EMS first encounter and field hospital triage to EMS transport and patient registration at a definitive care facility such as a hospital emergency room. It can also be used for the routine transport of patients and for the evacuation of hospitals involving EMS transport and care. In all scenarios, it relieves the heavy administrative burden levied on staff to re-key patient information, often after the fact, enabling automatic and pro-active hospital preparedness. In September of 2016, a bidirectional transformation specification between TEP and HL7 messaging was completed. This enables the transformation of the TEP data taken by emergency response to automatically populate in hospital data systems.
      HAVE supports the TEP standard by providing the data needed about available hospital resources to enable the informed routing decisions needed by EMS. In this way, the patients can be routed to the hospital with the facilities needed to support their needs. Given the TEP, the emergency room will be able to see the data about the incoming patient in order to best prepare for their optimal care. Both of these initiatives began with the Department of Homeland Security Science and Technology (DHS S&T) effort to identify the next most important data standards needed for emergency response. Practitioners in both the medical and emergency management domains were included in developing draft specifications after many facilitated sessions to include scenario working groups.

      The National Association of Emergency Medical Services Officials (NASEMSO) is one organization that participated in the DHS S&T effort. In October 2015, NASEMSO issued a resolution to encourage the completion and implementation of the TEP and HAVE standards.
      The DHS S&T effort concluded with two live exercises utilizing both TEP and HAVE (see next section).

      The HAVE 2.0 will be coordinated with HL7 through the work of the Patient Administration Work Group. OASIS and HL7 intend to release a joint specification for the HAVE Standard under the Statement of Understanding between the organizations. The effective exchange and common data interoperability will enable both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiently and speed.

      The TEP and HAVE Standards Have Been Proven Successful in Live Exercises
      The draft TEP standard was successfully implemented by four independent systems: Tennessee’s state EMS system and a local EMS system in Memphis, the state of Maryland EMS system, and the federal JPATS system. The Integrated Public Alerts and Warnings System (IPAWS) was plugged in as the message broker (the “post office” that routes data traffic where users need). State, local and federal agencies proved that these standards-based data exchanged work by plugging into existing major live-actor patient movement exercises at disaster sites, aircraft bases and hospitals.
      • During a 2010 National Disaster Medical System (NDMS) patient movement exercise in Tennessee, data following patient movement from Maryland to Tennessee was exchanged in real time between the Maryland EMS system to JPATS then to the Tennessee State and Memphis EMS systems. All systems displayed the current data as if updates were completed directly in their system. EM Systems was used to compile and aggregate HAVE data from 3 different hospitals, which was used by emergency managers to route patients to the most appropriate destinations with the availability, capabilities and staff to provide care.
      • Simultaneously with the FEMA National Level Exercise (NLE) in 2011, five states cooperated to track patient movement across them employing five different patient tracking systems. All systems, some commercially available and some home-grown, were able to track the data updates in their own systems.
      At the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit, presenters from the DHS S&T Practitioner Steering Group moved volunteer patients through the room to different “states” and were able to display data updates across four independent systems including JPATS.
      In these exercises and the 2012 demonstration, as each existing system automatically scanned, entered or updated patient data, that data was automatically shared in near real-time behind the scenes with no manual intervention, allowing users to view and report data in their own systems as if all data updates were made there. Using an aggregation of multiple hospital HAVE reports, emergency managers were able to route patients to appropriate destinations.

      Show
      1 Introduction [All text is normative unless otherwise labeled] 1.1 Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] . Error! Reference source not found.. 1.2 Normative References [CAP-1.2] Common Alerting Protocol Version 1.2. 01 July 2010. OASIS Standard. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html . [XMLSCHEMA-2] XML Schema Part 2: Datatypes Second Edition , P. V. Biron, A. Malhotra, Editors, W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . Latest version available at http://www.w3.org/TR/xmlschema-2/ . [EDXL-CT] Joerg, W. Committee Specification Draft Emergency Data Exchange Language Common Types. November 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-ct/v1.0/csd01/ [EDXL-DE] EDXL Distribution Element (DE) Standard v1.0. March 2006. OASIS. http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.doc [EDXL-GSF] Joerg, W. Committee Specification Draft Emergency Data Exchange Language GML Simple Features. September 2011. OASIS. http://docs.oasis-open.org/emergency/edxl-gsf/v1.0/csd01/ [NAMESPACES] Namespaces in XML 1.0 (Third Edition) , T. Bray, D. Hollander, A. Layman, R. Tobin, H. S. Thompson, Editors, W3C Recommendation, 8 December 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/ . Latest version available at http://www.w3.org/TR/xml-names . [OASIS CIQ] Customer Information Quality (CIQ) Specifications Version 3.0, Name (xNL), Address (xAL), and Party (xPIL). June 15, 2007. OASIS. http://docs.oasis-open.org/ciq/v3.0/specs/ [OGC 07-36r1] Geography Markup Language (GML) Implementation Specification Version 3.2.1. 2007. Open Geospatial Consortium. http://portal.opengeospatial.org/files/?artifact_id=20509 [OGC Schemas] GML 3.2.1 schemas. 2007. Open Geospatial Consortium. http://schemas.opengis.net/gml/3.2.1/ [OGC 10-100r3] Geography Markup Language (GML) simple features profile (with Corrigendum) (2.0). 2010. http://portal.opengeospatial.org/files/?artifact_id=42729 [OGC CRS] Topic 2 - Spatial Referencing by Coordinates (Topic 2) (CRS Abstract Specification), Version 3. 2004. Open Geospatial Consortium,. https://portal.opengeospatial.org/files/?artifact_id=6716 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119 . [RFC5646] ] Phillips, A., Ed., and M. Davis, Ed., Tags for Identifying Languages, BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, http://www.rfc-editor.org/info/rfc5646.[WGS 84] Department of Defense World Geodetic System. 1984. National Geospatial Intelligence Agency. http://earth-info.nga.mil/GandG/wgs84/index.html [XML 1.0] Extensible Markup Language (XML) 1.0 (Fifth Edition) , T. Bray, J. Paoli, M. , E. Maler, F. Yergeau, Editors, W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/ . Latest version available at http://www.w3.org/TR/xml .Non-Normative References [AHIC-BIODATA] BioSurvellience Data Elements. American Health Information Community (AHIC), BioSurvellience Data Working Group. http://www.hhs.gov/healthit/ahic/bio_main.html [EDXL-EXT] EDXL Extension, OASIS. https://tools.oasis-open.org/version-control/browse/wsvn/emergency/HAVE/rim/edxl-ext-v1.0.xsd [GJXDM] Global Justice XML Data Model (GJXDM) Data Dictionary. Global, Office of Justice Programs. http://it.ojp.gov/topic.jsp?topic_id=43 [GML-BESTPRAC] Best Practices: A GML Profile for use in OASIS EM Standards - EDXL-RM, EDXL-DE, HAVE, and CAP DRAFT. Open Geospatial Consortium. http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/20785/Best%20Practices%20-%20a%20GML%20Profile.doc [HAVBED-DATA] Hospital Bed Availability (HAvBED) Project – Definitions and Data Elements: AHRQ Releases Standardized Hospital Bed Definitions. Agency for Healthcare Research and Quality (AHRQ): http://www.ahrq.gov/research/havbed/definitions.htm [HAVBED2-REP] HAvBED2 Hospital Available Beds for Emergencies and Disasters. A Sustainable Bed Availability Reporting System. Final report. AHRQ Publication No. 09-0058-EF. April 2009. AHRQ. http://archive.ahrq.gov/prep/havbed2/havbed2.pdf [HAVE-REQSUP] EDXL HAVE Requirements Supplement. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16400/ [HAVE-SRS] EDXL HAVE Standard Requirements Specification. January 2006. OASIS. http://www.oasis-open.org/committees/download.php/16399/ [HL7] Health Level Seven International. - http://www.hl7.org/ . [RM-DATAREQ] EDXL Resource Messaging (RM) Draft Requirements Specification. OASIS. http://www.oasis-open.org/committees/download.php/14310/ [VHHA-TERM] Statewide Hospital Status Information System Terminology and Data Collection Elements. Virginia Hospital & Healthcare Association (VHHA). http://www.oasis-open.org/committees/download.php/18019 1.3 Purpose The ongoing goal of the Emergency Data eXchange Language (EDXL) project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national, international and non-governmental organizations of different professions that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession or governmental jurisdiction is involved. The current roster of published EDXL Standards includes: • The Common Alerting Protocol v1.2 specification (EDXL-CAP), with various dedicated profiles • The Distribution Element specification v2.0 (EDXL-DE) • The Hospital AVailability Exchange specification v1.0 (EDXL-HAVE) • The Tracking of Emergency Patients specification v1.1 (EDXL-TEP) • The Resource Messaging specification v1.0 (EDXL-RM) • The Situation Reporting specification v1.0 (EDXL-SitRep) • The Tracking of Emergency Client v1.0 (EDXL-TEC) The primary purpose of EDXL-HAVE is to provide an XML-based reporting format that allows information to be shared about a set of health facilities including the communication of the status of a health facility, its services, and its resources. These include bed capacity and availability, emergency department status, staffing levels, available service coverage, and the status of a health facilities operations and resources. The primary audience for EDXL-HAVE is the broad community that interacts with health facilities and it is intended to be used as a tool to automate information flow in and out of the health network. It is not intended to be a tool used for internal administration of health facilities as other standards organizations (e.g. Health System Level Seven International – www.hl7.org) already handle this domain. 1.4 History In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals’ bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions such as where to route victims and automatically determining which hospitals have the ability to provide the needed service. Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as Emergency Operations Centers (EOCs), 9-1-1 centers, and Emergency Medical Systems (EMS) responders via a Web-based tool. The Hospital Availability Exchange standard was created to make sharing information about the state of hospitals for day-to-day and crisis use. Initially it was focused purely on hospitals but it has been extended to handle sharing information about the broader health network, including long-term care facilities, urgent care clinics, and temporary aid centers. HAVE 1.0 was released on 22DEC2009. Since the release of HAVE 1.0 there have been multiple operational uses of HAVE, including after the 2010 Haiti Earthquake. In many of the operational uses there were modified schema used to add services that were not in HAVE 1.0 and to convey other aspects of the data and to handle the sharing of information about non-hospital facilities (e.g. clinics, temporary locations). The use of the HAVE 1.0 standard was encouraging but the shortfalls needed to be addressed. To that end, in 2010 the OASIS EM-TC voted to re-open the HAVE standard with the goal of creating a HAVE 2.0 standard. The HAVE data exchange standard goes hand in hand with the EDXL Tracking of Emergency Patients (TEP). A TEP-based data exchange collects data on patients from incident EMS first encounter and field hospital triage to EMS transport and patient registration at a definitive care facility such as a hospital emergency room. It can also be used for the routine transport of patients and for the evacuation of hospitals involving EMS transport and care. In all scenarios, it relieves the heavy administrative burden levied on staff to re-key patient information, often after the fact, enabling automatic and pro-active hospital preparedness. In September of 2016, a bidirectional transformation specification between TEP and HL7 messaging was completed. This enables the transformation of the TEP data taken by emergency response to automatically populate in hospital data systems. HAVE supports the TEP standard by providing the data needed about available hospital resources to enable the informed routing decisions needed by EMS. In this way, the patients can be routed to the hospital with the facilities needed to support their needs. Given the TEP, the emergency room will be able to see the data about the incoming patient in order to best prepare for their optimal care. Both of these initiatives began with the Department of Homeland Security Science and Technology (DHS S&T) effort to identify the next most important data standards needed for emergency response. Practitioners in both the medical and emergency management domains were included in developing draft specifications after many facilitated sessions to include scenario working groups. The National Association of Emergency Medical Services Officials (NASEMSO) is one organization that participated in the DHS S&T effort. In October 2015, NASEMSO issued a resolution to encourage the completion and implementation of the TEP and HAVE standards. The DHS S&T effort concluded with two live exercises utilizing both TEP and HAVE (see next section). The HAVE 2.0 will be coordinated with HL7 through the work of the Patient Administration Work Group. OASIS and HL7 intend to release a joint specification for the HAVE Standard under the Statement of Understanding between the organizations. The effective exchange and common data interoperability will enable both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiently and speed. The TEP and HAVE Standards Have Been Proven Successful in Live Exercises The draft TEP standard was successfully implemented by four independent systems: Tennessee’s state EMS system and a local EMS system in Memphis, the state of Maryland EMS system, and the federal JPATS system. The Integrated Public Alerts and Warnings System (IPAWS) was plugged in as the message broker (the “post office” that routes data traffic where users need). State, local and federal agencies proved that these standards-based data exchanged work by plugging into existing major live-actor patient movement exercises at disaster sites, aircraft bases and hospitals. • During a 2010 National Disaster Medical System (NDMS) patient movement exercise in Tennessee, data following patient movement from Maryland to Tennessee was exchanged in real time between the Maryland EMS system to JPATS then to the Tennessee State and Memphis EMS systems. All systems displayed the current data as if updates were completed directly in their system. EM Systems was used to compile and aggregate HAVE data from 3 different hospitals, which was used by emergency managers to route patients to the most appropriate destinations with the availability, capabilities and staff to provide care. • Simultaneously with the FEMA National Level Exercise (NLE) in 2011, five states cooperated to track patient movement across them employing five different patient tracking systems. All systems, some commercially available and some home-grown, were able to track the data updates in their own systems. At the 2012 Integrated Medical, Public Health, Preparedness and Response Training Summit, presenters from the DHS S&T Practitioner Steering Group moved volunteer patients through the room to different “states” and were able to display data updates across four independent systems including JPATS. In these exercises and the 2012 demonstration, as each existing system automatically scanned, entered or updated patient data, that data was automatically shared in near real-time behind the scenes with no manual intervention, allowing users to view and report data in their own systems as if all data updates were made there. Using an aggregation of multiple hospital HAVE reports, emergency managers were able to route patients to appropriate destinations.
    • Resolution:
      Hide

      This should have been an issue in Emergency rather than Emergency-Adopt, so closed here.

      Show
      This should have been an issue in Emergency rather than Emergency-Adopt, so closed here.

      Description

      Replace the current 1.0 Introduction with updated text.

        Attachments

          Activity

            People

            • Assignee:
              ejones Elysa Jones (Inactive)
              Reporter:
              ejones Elysa Jones (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: