1 / 52

Emergency Responder Electronic Health Record

Emergency Responder Electronic Health Record. September 4, 2008 | 2:00 – 3:30 pm (Eastern) Presenter: HITSP Provider Perspective Technical Committee Stephen Hufnagel PhD, Co-chair Allen Hobbs PhD, Co-chair Michael Glickman, Facilitator. Learning Objectives.

oksana
Télécharger la présentation

Emergency Responder Electronic Health Record

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Emergency Responder Electronic Health Record September 4, 2008 | 2:00 – 3:30 pm (Eastern) Presenter: HITSP Provider Perspective Technical Committee Stephen Hufnagel PhD, Co-chair Allen Hobbs PhD, Co-chair Michael Glickman, Facilitator

  2. Learning Objectives a webinar series on U.S. healthcare interoperability • During this 90-minute webinar, participants will be introduced to the emergency responder community stakeholder groups and gain a basic understanding of their unique needs, including: • the Emergency Communication System (ECS) and the Emergency Contact Registry (ECON) • Patient identification and information, including tracking data for various types of vocabulary / terminology, messaging and document sharing • Common approaches to delivering incident information and incident types • Remote monitoring of ambulance or field-based devices • Situational Awareness Reporting • HITSP constructs to support EMS cross-domain messaging

  3. Agenda a webinar series on U.S. healthcare interoperability • Introduction to HITSP and HITSP Interoperability Specification 04 (IS 04), Emergency Responder Electronic Health Record (ER-EHR) • Methodology and Technology used to transform an AHIC Use Case to a HITSP Interoperability Specification • Emergency Responders’ Continuum of Care • AHIC Use-Case Stakeholders and Information Exchange Requirements • HITSP Interoperability Specification’s Business and Technical Actors • Emergency Responder’s HITSP Constructs • Emergency Responder Gap and Harmonization Projects • Questions and Answers / Open Dialogue

  4. Introduction: Steve’s Story . . . part eight Patient is a 26-year-old male coping with the long-term effects of a brain tumor that was removed during his childhood During a routine check-up at his local hospital in Las Vegas, Steve sees a large number of emergency patients rushed in for CT scans to check for smoke inhalation injury Steve is troubled by the lack of accessible medical records, especially for people visiting from out of town who may have pre-existing conditions Doctors and emergency responders need to know the whole story to provide the best treatment

  5. Introduction: Steve’s Story . . . part eight In an interoperable world . . . On-site emergency care professionals, medical examiner/fatality managers and public health practitioners would have the access they need to information regarding care, treatment, or investigation of emergency incident victims HITSP IS 04 covers the use of an ER-EHR from multiple perspectives: First responders (911 operators) Dispatch care (Emergency Communications Systems or Systems) On-site emergency care providers (EMS, Law Enforcement, Fire etc.) and emergency care clinicians

  6. HITSP is a volunteer-driven, consensus-based organization that is funded through a contract from the Department of Health and Human Services. The HITSP Panel brings together public and private-sector experts from across the healthcare community to harmonize and recommend the technical standards that are necessary to assure the interoperability of electronic health records. Overview

  7. The HITSP Standards Harmonization Framework Identify a pool of standards for an AHIC (American Health Information Community) Use Case Identify gaps and overlaps in the standards for this specific Use Case Make recommendations for resolution of gaps and overlaps Select standards using HITSP-approved Readiness Criteria Develop Interoperability Specifications (IS) that use the selected standard(s) for the specific context Test the IS Deliverables and Mode of Operation

  8. Deliverables and Mode of Operation • Each HITSP Interoperability Specification defines a set of “constructs” that: • specify how to integrate and constrain selected standards to meet the business needs of a Use Case; and • define a Roadmap to use emerging standards and to harmonize overlapping standards when resolved. • In essence, a HITSP IS represents a suite of documents that integrate and constrain existing standards to satisfy a Use Case.

  9. Deliverables and Mode of Operation • HITSP construct types, in decreasing breadth of scope, include: • Interoperability SpecificationsIntegration of all constructs used to meet the business needs of a Use Case • Transaction PackagesLogical grouping of transactions • TransactionsLogical grouping of actions that use components and/or composite standards to realize the actions • ComponentsLogical grouping of base standards that work together, such as messaging and terminology

  10. Current Interoperability Specifications (IS)

  11. IS 04Emergency Responder Electronic Health Record (ER-EHR) • This Interoperability Specification defines specific standards required to track and provide on-site emergency care professionals, medical examiner/fatality managers and public health practitioners with needed information regarding care, treatment or investigation of emergency incident victims. • Version: 1.0 Accepted (Secretary of HHS has accepted for a period of testing) • Version:1.1.1 Panel Review

  12. Emergency Responder Use Case Transforming an AHIC Use Case to a HITSP Interoperability Specification • METHODOLOGY • Identify new stakeholders and their Information Exchange Requirements (IERs) • HITSP ISs constrain IERs to their clinical care setting context and map IERs to HITSP constructs • HITSP constructs map IERs to standards-based System Data Exchange (SDE) • Emphasize re-use of existing HITSP IS and constructs • IERs, which do not have existing HITSP IS mappings require new or repurposedISs and/or constructs • TECHNOLOGY • HITSP uses Sparx Enterprise Architect tool for Business Processing Modeling Notation (BPMN) and UML modeling

  13. Emergency Responders’ Continuum of Care

  14. Emergency Responder Use Case • On-site Care • Emergency Care • Definitive Care • Small Scale (e.g., car accident) • Local Response • Medium Scale (e.g., chemical spill) • Regional Response • Large Scale (e.g., pandemic) • National Response

  15. An Emergency Communications System (ECS) supports emergency responder stakeholders by managing the exchange of voice and data based on the incident type, size and needs.

  16. AgencyLocator IdentityManagement/AccessControl Digital RightsManagement PatientLocator Integrated Emergency Medical ResponseEmergency Responders’ Clinical-Care Information-Technology Settings

  17. AHIC Use-Case Stakeholders and Information Exchange Requirements

  18. Proposed Model State Emergency IT HITSP specifies interoperability standards; not implementation architectures.

  19. Internetwork Core Services HITSP specifies interoperability standards; not implementation architectures.

  20. Technology Infrastructure • Agency Locator Service • Identity Management/Access Control • Message Brokers • Systems Integration Services • Wireless and Wired Transport • Interoperability & Data Transformation Public Patient Data Decision Support • Monitoring Devices • Cell Phones • Telematics • Special Needs & Evacuation Registries • Electronic Health Records • Personal Health Records • Emergency ContactRegistries • Insurance Information • Just-in-Time Training • Dynamic Protocols • Predictive Algorithms DATA PROVIDERS 9-1-1 Emergency Responder ED/Hospital • Computer Aided Dispatch • Emergency MedicalDispatch • Patient Care Recording • Electronic MonitoringDevices • Input Devices • Tracking Devices • ED Systems • Bed Availability Systems • Definitive Care Systems • Lab Systems • Pharmacy Systems ENTRY REPRESENTATITVES DoD/VA Emergency Management Public Health • Patient Tracking • Health Records • Crisis InformationManagement Software • Resource Management • Biosurveillance • Biosensors • Health Alert Network • Public Health InformationNetwork

  21. Use Case Stakeholders

  22. Stakeholder Data Requirements Overview class Data Requirements (DRs) DR01: Emergency Contact Data DR06: Patient Location Data Legend Data Requirement Standards gap or overlap Name: Data Requirements (DRs)Author: HITSP Provider TCVersion: 1.0 DR11: Resource Utilization DR12: Situation Awareness Report Data DR13: Present Episode of Care – on-site DR14: Present Episode of Care - ED DR16: PresentEpisode of Care -Definitive Care DR16: VehicularTelematicsIncidentInformation DR07: Triage Category DR19: DecisionSupport Request and Reply Data DR17: PublicHealth Protocol New DRs Proposed for IS 4 V2 DR22: Identification/Demographics for Insurance Eligibility/ Authorization Request DR18: MedicalDevice Data DR20: CCDClinical Summary DR21: AmbulanceRun Report DR02: Demographic Data DR03: Allergy Data ISO 4 V1.1 DRs subsumed by adding DR20 DR04: Medication History Data DR09: PreviousImmunizations Data DR06: Problem List Data DR08: Advance Directives Status DR 10: Treatment History

  23. Stakeholder Data Requirements Comprehensive class Data Requirements (DRs) • DR01: Emergency Contact Data • emergency contact name • emergency contact phone numbers • DR06: Patient Location Data • present location • incident location • receiving facility location • date/time of arrival Legend Data Requirement Standards gap or overlap Name: Data Requirements (DRs)Author: HITSP Provider TCVersion: 1.0 DR11: Resource Utilization • DR12: Situation Awareness • Report Data • on-site care situation • emergency care situation • definitive care situation • DR13: Present Episode of Care – on-site • 01 Demographic Data • 02 Emergency Contact Data • 03 Allergy Data • 04 Medication History Data • 05 Problem List Data • 06 Patient Location Data • 07 Triage Category • 09 Previous Immunization Data • complaint(s) • vital signs, which includes pain status • visual/clinical assessments • medications administered • procedures performed • DR14: Present Episode of Care - ED • 02 Demographic Data • 03 Allergy Data • 04 Medication History Data • 05 Problem List Data • 06 Patient Location Data • 07 Triage Category Data • 08 Advance Directives Data • 09 Previous Immunizations Data • 10 Treatment History DR16: PresentEpisode of Care -Definitive Care DR16: VehicularTelematicsIncidentInformation • DR07: Triage Category • Severity Index (ED) • NATO Colors (pre-hospital) DR17: PublicHealth Protocol DR19: DecisionSupport Request and Reply Data New DRs Proposed for IS 4 V2 • DR22: Identification/Demographics for Insurance Eligibility/ Authorization Request • Authorization/certification number for billing submission • Health Plan eligibility, co-pay, deductibles, limits, and exclusions DR18: MedicalDevice Data DR20: CCDClinical Summary DR21: AmbulanceRun Report • DR02: Demographic Data • name • age • gender • primary language spoken • DR03: Allergy Data • Allergies to medications • Significant food allergies • Latex ISO 4 V1.1 DRs subsumed by adding DR20 • DR04: Medication History Data • Long term medication histories • Other prescribed medications • Over-the-counter medications taken within the last 5-7 days • Administration of blood/blood products • DR09: PreviousImmunizations Data • Tetanus • Anthrax series • DR06: Problem List Data • Current problems • Other ongoing problems • DR08: Advance Directives Status • living will • do not resuscitate orders • medical power of attorney • organ donation • DR 10: Treatment History • Last two episodes of care for the chief complaint • Last five episodes of care

  24. Stakeholders Information Exchange Requirements

  25. Scenario 1On-Site Care

  26. Scenario 1: Onsite Care Business and Technical Actors

  27. Scenario 1: On-Site Care HITSP Constructs Underlying Infrastructure Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models 27

  28. Scenario 2 Emergency Care

  29. Scenario 2: Emergency Care Business and Technical Actors

  30. Scenario 2: Emergency Care HITSP Constructs Underlying Infrastructure Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

  31. Scenario 3 Definitive Care

  32. Scenario 3: Definitive Care Business and Technical Actors 32

  33. Scenario 3: Definitive Care HITSP Constructs Underlying Infrastructure Constructs are NOT shown (e.g., T15, T16, T17, C19, TP20, TP30) AHIC Use Cases as BPMN Behavior-Models and UML Component Structure-Models

  34. ER-EHR Gap Harmonization Projects

  35. REDindicates new or repurposed construct (2008)

  36. ER-EHR Gaps and Overlaps Projects • In October 2007, the HITSP Care Delivery Technical Committee (CDTC) formed an Emergency Medical Awareness and Response (EMAR) tiger team workgroup to address its IS04 ER-EHR identified standards gaps and overlaps • The work was planned to be completed in 2008, resulting in an updated version of IS 04 • National Emergency Medical Services Information System (NEMSIS) assumed the leadership of the EMAR tiger team, which is addressing or monitoring the ER-EHR related projects described on the following pages

  37. Gap and Harmonization Project #1 Incident and Victim Identifiers Develop a standard practice for the initial first responder organization (normally government) to become aware of an incident assigns unique identifiers to an incident, any victims, and the other actors adopts those identifiers for all information exchanged about the person or incident associates person’s actual identity, when established, with the unique identifiers (UIDs) noted above links a person’s historical health information and new information developed about the victim, patient, and or incident to the UIDs The UID for both victims and incidents is a temporary ID and is used for the duration of the event by all involved

  38. Gap and Harmonization Project #2Common Approaches to Delivering Incident Information Exploring whether delivery of telematics data to the ECS and other emergency responders can be generalized to other third party incident information. This effort will consider, at a minimum: OASIS EDXL Distribution Element as the routing “header” for the pre-hospital messaging, along with different payloads (VEDS, IEEE 1512) The use of core services to route data and provide security, including a managed list of incident types internet accessible electronic maps to share information before interfaces to legacy systems are established decision support tools in 9-1-1 and medical control to manage the use of the new data

  39. Gap and Harmonization Project #3Standardized List of Incident Types Develop a consensus among leaders of the key emergency response domains on incidents, names and types NOTE: Though this is not a standards development process, it does support the OASIS EDXL Distribution Element calls for a Managed List of Incident types

  40. Gap and Harmonization Project #4Situational Awareness Reporting Utilize the OASIS EDXL DE and OASIS Resource Messages for Situational Awareness Reporting Other Situational Awareness Reporting messages are in early stages of development by a Department of Homeland Security (DHS)-sponsored process The DHS-Disaster Management PWG is developing potential standards

  41. Gap and Harmonization Project #5Emergency Contact Registry (ECON) IHE is developing a standardized query for law enforcement on-site access and exchange of patient-specific emergency contact information from a nationwide database, “ECON”, based upon a unique identified, such as a Vehicle Identification Number (VIN#) On 12/3/07 the IHE ITI Technical Committee approved the ECON Query Profile Proposal The IHE PCC Technical Committee is reviewing a Pre-Hospital Patient Care Report (PCR) Profile Proposal which will develop a standard for on-site care provider electronic download and automated entry patient-specific Emergency Contact Registry, Personal Health Record (PHR), and/or EHR data into an on-site Pre-Hospital Patient Care Report (PCR) system

  42. Gap and Harmonization Project #6Patient Information and Tracking Data Vocabulary / Terminology Harmonization The project will identify current data and exchange standards (e.g., DEEDS and NEMSIS harmonization) that are being used within EMAR enterprise and harmonize them

  43. Gap and Harmonization Project #7Patient Information and Tracking Messaging and Document Sharing Standard methods to support system to system exchange and notification of appropriate entities regarding all the information related to emergency medical response The resulting standards will be based upon HL7, HITSP constructs, the NEMSIS standards or the harmonized data standards that are established from Project #6

  44. Gap and Harmonization Project #8Nursing Terminology Overlap An overlap in standards has been identified by the ER-EHR Work Group in the Use Case scenario for Present Episode of Care Many of the individual data elements may be captured by nursing and dependent on nursing terminology A work group of nurses with expertise in nursing terminologies and emergency nursing is being convened to address this overlap. CONCLUSION This IS will use SNOMED CT as a reference terminology with the HITSP IS pre-condition that the sending and using systems must use formal coded nursing terminologies, such as the Clinical Care Classification (CCC) System or the Omaha System

  45. Gap and Harmonization Project #9Development of a new HITSP Construct to support EMS cross-domain messaging This project will compare and contrast the prevalent OASIS pre-hospital and HL7 hospital transport protocols in order to create a HITSP transport construct that is consistent with DOT, DHS, HHS and other relevant non-healthcare On-Site ER-EHR Use Case Perspective domains

  46. Gap and Harmonization Project #10Remote Monitoring of Ambulance or Field-based Devices The goal is to have data from these electronic devices automatically update the Episode of Care Record, saving time and avoiding errors by responders The 2008 Remote Monitoring (RMON) Use Case is being addressed by the Consumer Perspective TC. Its focus is home health care and does not include first responders’ life support remote monitoring devices

  47. Conclusion

  48. How YOU can become involved • Use or specify HITSP Interoperability Specifications in your HIT efforts and in your Requests for Proposals (RFPs) • Ask for CCHIT certification • Leverage Health Information Exchanges to promote HITSP specifications to make connections easier in the future • Ask . . . Is there a HITSP standard we could be using? • Get involved in HITSP . . . Help shape the standards

  49. How YOU can become involved Learn more about specific HITSP activities during these upcoming webinars:       

  50. Join HITSP in developing a safe and secure health information network for the United States. Visit www.hitsp.orgor contact . . . Michelle Deane, ANSI mmaasdeane@ansi.org Re: HITSP, its Board and Coordinating Committees Jessica Kant, HIMSS Theresa Wisdom, HIMSS jkant@himss.orgtwisdom@himss.org Re: HITSP Technical Committees

More Related