110360447-hl7-ehr-2012-ambassador-presentation-20121011

Transcript

HL7 EHR System Functional Model and Standard Presented by: Pat Van Dyke The ODS Companies Delta Dental Plans Association CoChair, EHR Work Group Technical Steering Committee Ambassador Webinar October 2012 The Drivers  Concerns about cost, quality and efficiency  By all stakeholders     Employers Healthcare providers Consumers Government The Need  Complete patient health information  At the point of care  With clinical decision support Successful Projects  Reduced costs through chronic care management programs  Improved healthcare through clinical decision making  Improved patient participation and compliance through computer based reminders  Improving safety, quality and efficiency of healthcare © HL7 2012 Agenda  Current Status  Overview of EHR System (EHR-S) Functional Model  Walk through of EHR-S FM  Conformance Clause and Profiles  Distinction between Standards and Product Certification  Development of Release 2  Next Steps © HL7 2012 EHR vs. EHR-S  EHR  The underlying single, logical patient record  The data elements comprising the record  Needs to serve as the record of care for legal, business, and disclosure purposes  EHR-S  Software that provides functionality to:  Manage and maintain the record  Accomplish the various clinical, research, and business purposes of the record  Monolithic system or a system of systems © HL7 2012 How It Started - Request from US Govt  April, 2003: CMS asked  Institutes of Medicine (IOM) for guidance on care delivery functions  IOM & HL7 to coordinate development of a functional model for an EHR system, not a transaction  Need: pay for performance  April, 2003: HL7 EHR WG began work on EHR-S FM  July 31, 2003: IOM Committee on Data Standards for Pt. Safety releases Letter Report © HL7 2012 From DSTU to ANSI/ISO/CEN Accreditation  July, 2004: Approved as a draft standard for trial use (DSTU)  February, 2007: Release 1.0 approved as a fully American National Standards Institute (ANSI) accredited standard  November, 2009: Release 1.1 approved as a International Organization for Standardization (ISO) standard  Release 2.0 balloted as a normative model in April 2012. Five international standards organizations involved. © HL7 2012 EHR-S FM’s position within HL7  Health Level Seven (HL7) is an international Standards Development Organization (SDO)  The term “HL7” is often used synonymously for the HL7 organization and the HL7 messaging standard  HL7 standards are divided into multiple camps: 1. Healthcare-related data/information/routing Standards: – Messaging Standards (V2.x and V3) – Document Standards (CDA) 2. Healthcare-related Functional Standards (EHR-S FM) 3. Other Standards (CCOW, Vocabulary, Security, Healthcare Devices, etc.) © HL7 2012 Sample of an “HL7 message”  Sample v2 message (is difficult to read): MSH|^~\&|ADT1|MCM|LABADT|MCM|199912311100|SECURITY|ADT^A01|MSG00001|P|2.3| EVN|A01|199912311058|| PID|||PATID4321^5^M11||DOE^JOHN^A^II||19500227|M||C|123 MAIN STREET^^ANYTOWN^NY^12345-1234|GL|(123)555-1212|(123)555-2121 ||S||PATID4321001^2^M10|123456789|123456^NY| NK1|SMITH^SALLY^J|WIFE||||||NK^NEXT OF KIN PV1|1|I|1000^215^01||||001234^SMITH^CHRIS^M.|||SUR||||ADM|A0|  Translation: Patient John A. Doe, II was admitted on December 31, 1999 at 10:58 a.m. by doctor Chris M. Smith (#001234) for surgery (SUR). He has been assigned to nursing unit 1000, room 215, bed 01. © HL7 2012 Background and Context (con’t)  Sample v3 (CDA) document (raw): -- - - - 23 Main Street Anytown NY 12345 USA © HL7 2012 Background and Context (con’t)  Sample v3 (CDA) document (raw): -- - - - 23 Main Street Anytown NY 12345 USA © HL7 2012 Background and Context (con’t)  Sample v3 (CDA) document (is easy to read when rendered): Patient ID: 54321 Home address: 23 Main St., Anytown, NY. 12345 © HL7 2012 The EHR-S Functional Model Is Not…  A messaging specification  An EHR specification  An implementation specification (not the “how”)  Does not prescribe technology  Does not dictate how functions must be implemented (e.g., via the user interface, database design) Is…  A system specification  An EHR system specification  A reference list of functions that may be present in an EHR-S (the “what”)  Enables consistent expression of functionality  Provides flexibility for innovation and product differentiation  Gold standard, sensitive to what can practically be done by a system, future system development © HL7 2012 EHR-S Functional Model at a Glance Functions describe the behavior of a system in useroriented language so as to be recognizable to the key stakeholders of an EHR System This represents the R.1.1 Structure © HL7 2012 EHR-S Functional Model & Standard  Function names & statements provide a reference list of functions that:  May be present in an EHR-S  Understandable from a user’s perspective  Enables consistent expression of functionality  Conformance criteria  Required criteria: Mandatory  Optional criteria: Two levels © HL7 2012 The Structure of the Functional Model ID# DC.1.1.1 Ty pe F Name Identify and Maintain a Patient Record Statement/Description Statement: Identify and maintain a single patient record for each patient. Description: A single record is needed for legal purposes, as well as to organize it unambiguously for the provider. Health information is captured and linked to the patient record. Static data elements as well as data elements that will change over time are maintained. The patient is uniquely identified, after which the record is tied to that patient. Combining information on the same patient, or separating information where it was inadvertently captured for the wrong patient, helps maintain health information for a single patient. In the process of creating a patient record, it is at times advantageous to replicate identical information across multiple records, so that such data does not have to be reentered. For example, when a parent registers children as new patients, the address, guarantor, and insurance data may be propagated in the children’s records without having to re-enter them. See Also S.1.4.1 S.2.2.1 S.3.1.2 S.3.1.5 IN.2.1 IN.2.3 1. 2. 3. 4. The system SHALL create a single logical record for each patient. The system SHALL provide the ability to create a record for a patient when the identity of the patient is unknown. The system SHALL provide the ability to store more than one identifier for each patient record. The system SHALL associate key identifier information (e.g., system ID, medical record number) with each patient record. The system SHALL provide the ability to uniquely identify a patient and tie the record to a single patient. The system SHALL provide the ability, through a controlled method, to merge or link dispersed information for an individual patient upon recognizing the identity of the patient. IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to mark the information as erroneous in the record of the patient in which it was mistakenly associated and represent that information as erroneous in all outputs containing that information. IF health information has been mistakenly associated with a patient, THEN the system SHALL provide the ability to associate it with the correct patient. The system SHALL provide the ability to retrieve parts of a patient record using a primary identifier, secondary identifiers, or other information which are not identifiers, but could be used to help identify the patient. 5. 6. 7. 8. 9. © HL7 2012 Existing Profiles The EHR-S FM R.1.1 contains approx. 160 functions and 1,000 conformance criteria across 3 sections Functional Profiles (Care Setting) HL7 EHR-System Functional Model (EHR-S FM) Release 1.1 Ancillary Profiles (Specific Purpose) Records Management & Evidentiary Support Vital Records Clinical Research Emergency Long Term and Post Acute Care Behavioral Health Functional and ancillary profiles are subsets derived from the FM. EHR systems conform to profiles. Child Health © HL7 2012 Conformance to the Functional Model EHR System Functional Model (EHR-S FM) DC 1.1, CC 3 …. SHALL … DC 1.1, CC 4 … SHOULD … Making every attempt to develop a robust, yet flexible FM Country1 DC 1.1, CC3: SHALL DC 1.1, CC4: SHOULD Child Health FP Derived FP1 Child Health Conforms to RM&ES RM&ES AP Remainder Not Incorporated into EHR-S FM Derived FP2 LTPAC Conforms to RM&ES LTPAC FP DC 1.1, CC 3: SHALL DC 1.1, CC 4: SHOULD LTPAC FP DC 1.1, CC 3: SHALL DC 1.1, CC 4: SHALL Child Health FP Country2 DC 1.1, CC 3: SHALL DC 1.1, CC 4: SHALL C2 LTPAC FP DC 1.1, CC 3: SHALL DC 1.1, CC 4: SHALL Derived FP1 © HL7 2012 Other Functional Profiles Available     Dietetics/Food & Nutrition Public Health E-Prescribing (jointly with NCPDP) Pharmacist/Pharmacy (jointly with NCPDP) © HL7 2012 Standards vs Certification  Gold standard vs. specific purpose incentives  Wide spread EHR adoption  Pay for performance  Standards development organization (SDO) vs. public/private collaborative  Avoid perceived conflict of interest (where a single organization both develops the standard and certifies against it)  Product certification references standards © HL7 2012 Functional Model & Certification HL7 EHR-S Standard Conformance Criteria Function ID 1.0 1.1 ABC 1 2 3 4 5 6 …SHALL…….. …SHOULD….. …SHALL…….. …MAY……….. …SHOULD…….. …SHALL…….. …SHALL…….. …SHALL…….. …SHALL…….. ...(Did not adopt) …SHALL…….. …SHALL…….. X X X X X Function No. Clause Certification Criteria 2008 2009 2010 Product Certification Certification Year  Granularity: Individual conformance criterion may be certified in a year different from other criteria in the same function  Dependent on essential now vs. future, market availability, & priority for improving quality of care © HL7 2012 Inputs to Release 2.0 (R2) …. Vital Rptg. RM & ES Beh. Health LTC Alignment Lifecycle …. Provider Based Interop Model PHR-S FM & Profiles SOA SAIF R1.1 Adjustments, Enhancements EHR-S Profiles EHR-S FM Release 2.0 International Stds Data Use Health Info Exchange • Fraud Mgt • Quality • Rev Cycle (ISO TC215, ISO 20514, ISO DIS CEN 18308, 13606) Other Industry Initiatives Privacy, Security, Confidentiality Certification (CCHIT, Q-Rec) Others? © HL7 2012 Extension of Function List  The number of conformance criteria increased from 972 in R1.0, 983 in R1.1 and 2,310 in R2.0 HL7 EHR-S Functional Model, Release 2 Summary Breakdown of Functions and Conformance Criteria Release 1 Conformance Criteria Release 1.1 Conformance Criteria Chapter OV CP CPS POP AS RI TI Overarching Criteria Care Provision Care Provision Support Population Health Support Administration Support Records Infrastructure Trust Infrastructure TOTALS: Functions 2 41 76 18 55 37 93 322 Conformance Criteria 33 494 559 108 249 186 681 2,310 972 983 © HL7 2012 Chapter Reorganization Direct Care (DC) Supportive (S) Information Infrastructure (IN) Overarching (O) Care Provision (CP) Care Provision Support (CP) Population Health Support (POP) Record Infrastructure (RI) Trust Infrastructure (TI) © HL7 2012 Administrative Support (AS) Overarching Criteria Chapter  Criteria that apply to all EHR Systems and consequently must be included in all EHR-S FM compliant profiles  Examples: OV.1 The system SHALL conform to function TI.1.1 (Entity Authentication). The system SHALL conform to function TI.1.2 (Entity Authorization). The system SHALL conform to function TI.1.3 (Entity Access Control). Overarching IF the system receives or transmits data for which jurisdictionally established interchange standards exist, THEN the system SHALL conform to function IN.5.1 (Interchange Standards) to support interoperability. The system SHOULD conform to function IN.6 (Business Rules Management). The system SHOULD conform to function IN.7 (Workflow Management). OV.2 Manage User Help © HL7 2012 Care Provision  Focus on functions required to provide care to a specific patient and enable hands-on delivery of healthcare  Organized in general order of an encounter Example child functions: Manage Clinical History Render Externally-sourced InformationCP.1 Manage Clinical History CP.1.1 Manage Patient History Manage Clinical Documentation Manage Allergy, Intolerance and Adverse Reaction Manage Orders CP.1.2 List CP.1.3 Manage Medication List Manage Results CP.1.4 Manage Problem List Manage Treatment Administration CP.1.5 Manage Strengths List Manage Future Care CP.1.6 Manage Immunization List Manage Patient Education & Communication Manage Medical Equipment, Prosthetic/Orthotic, CP.1.7 Device List Manage Care Coordination & Reporting CP.1.8 Manage Patient and Family Preferences © HL7 2012 CP.1 CP.2 Care Provision CP.3 CP.4 CP.5 CP.6 CP.7 CP.8 CP.9 Care Provision Support  Focus on functions required to support the provision of care to a specific patient to enable hands-on delivery of healthcare  Organized in alignment with Care Provision chapter Example child functions: Record Management CPS.4 Support Orders Support Externally-sourced Information CPS.4.1 Manage Order Set Templates Support Clinical Documentation CPS.4.2 Support Medication & Immunization Orders Support Orders CPS.4.2.1 Support for Medication Interaction & Allergy Checking Support Results CPS.4.2.2 Support for Patient Specific Dosing and Warnings Support Treatment Administration CPS.4.2.3 Support for Medication Ordering Efficiencies Support Future Care CPS.4.2.4 Support for Medication Recommendations Support Patient Education & Communication for Non-Medication Ordering CPS.4.3 Support Support Care Coordination CPS.4.4 & Reporting Support Orders for Diagnostic Tests CPS.4.5 © HL7 2012 CPS.1 CPS.2 CPS.3 CPS.4 CPS.5 CPS.6 CPS.7 CPS.8 CPS.9 Care Provision Support Support Orders for Blood Products and Other Biologics Population Health Support POP.1 Support input to systems that perform medical research,  Focus onfor Health Maintenance, Preventive Care and Wellness POP.2 Support for Epidemiological Investigations of Clinical Health Within Population promote public health, & improve the qualityaof care at a POP.3 Support for Notification multi-patient level and Response POP.4 POP.5 POP.6 POP.7 POP.8 POP.9 POP.10 Support for Monitoring Response Notifications Regarding a Specific Patient’s Health Donor Management Support Measurement, Analysis, Research and Reports Public Health Related Updates De-Identified Data Request Management Support Consistent Healthcare Management of Patient Groups or Populations Manage Population Health Study-Related Identifiers Population Health Support Example child functions: POP.6 POP.6.1 POP.6.2 POP.6.3 POP.6.4 Measurement, Analysis, Research and Reports Outcome Measures and Analysis Performance and Accountability Measures Support for Process Improvement Support for Care System Performance Indicators (Dashboards) © HL7 2012 Administration Support  Focus on functions to Assist with the administrative and AS.1 Manage Provider Information financial requirements Manage Patient Demographics, Location and Synchronization AS.2 AS.3 AS.4 AS.5 AS.6 Manage Personal Health Record Interaction Manage Communication Manage Clinical Workflow Tasking Manage Resource Availability Manage Encounter/Episode of Care Management Manage Information Access for Supplemental Use Manage Provider Information AS.1 Manage Administrative Transaction Processing Manage Provider Registry or Directory AS.1.1 Manage Provider's Location Within Facility AS.1.2 AS.1.3 AS.1.4 AS.1.5 AS.1.6 AS.1.7 © HL7 2012 Provider's On Call Location Manage Provider's Location(s) or Office(s) Team/Group of Providers Registry or Directory Provider Caseload/Panel Manage Practitioner/Patient Relationships Administration support AS.7 AS.8 AS.9 Example child functions: Record Infrastructure  Focus on records, record entries and record management, including R1.1 functions/criteria and key provisions of the RM-ES Functional Profile, EHR Interoperability and Lifecycle Model DSTUs.  Consists of Release1.1’s :  IN.2 (Record Management, except Audit),  IN.8 (Record Archive/Restore) and  IN.10 (Record Lifecycle -previously EHR Lifecycle Model DSTU). Record Infrastructure RI. 1 RI. 2 RI. 3 Record Lifecycle and Lifespan Record Synchronization Record Archive and Restore RI.1.1 RI.1.1.1 RI.1.1.2 RI.1.1.3 RI.1.1.4 RI.1.1.5 RI.1.1.6 RI.1.1.7 RI.1.1.8 RI.1.1.9 RI.1.1.10 RI.1.1.11 Record Lifecycle Originate and Retain Record Entry Amend Record Entry Content Translate Record Entry Content Attest Record Entry Content View/Access Record Entry Content Transmit and/or Disclose Record Entries Receive and Retain Record Entries De-identify Record Entries Pseudomynize Record Entries Re-identify Record Entries Extract Record Entry Content Example child functions: © HL7 2012 Trust Infrastructure  Contains the remaining Release 1.1 Infrastructure functions, including Audit. Trust Infrastructure TI.1 TI.2 TI.3 TI.4 TI.5 TI.6 TI.7 TI.8 TI.9 Security Audit Registry and Directory Services Standard Terminology and Terminology Services Standards-Based Interoperability TI.1 Security TI.1.1 Entity Authentication Business Rules Management TI.1.2 Entity Authorization Workflow Management Database Backup and Recovery TI.1.3 Entity Access Control TI.1.4 Patient Access Management System Management Operations and Performance TI.1.5 Non-Repudiation TI.1.6 Secure Data Exchange TI.1.7 Secure Data Routing TI.1.8 Information Attestation Example child functions TI.1.9 Patient Privacy and Confidentiality © HL7 2012 Layout of EHR-S FM R2  Function Name  Function Statement  Function Description  Examples  Conformance Criteria  See Also © HL7 2012 Next Steps  Redevelopment of current profiles based on R2  Realm (country)-based profiles  Map Functional Model to HL7 messages, documents, data  Development of a corresponding Information Model © HL7 2012 Want to Know More?  Join HL7  Review the HL7 web site  Subscribe to HL7 EHR WG list serve  Join our Tuesday Work Group calls  3:00- 4:30 PM Eastern www.hl7.org/ehr © HL7 2012 HL7 EHR System Functional Model and Standard Q&A