HL7 Electronic Data Exchange in Health Care

1. HL7 Electronic Data Exchange in Health Care W. Ed Hammond, Ph.D. President, AMIA Vice-chair, Technical Steering Committee, HL7 Co-chair, Vocabulary Technical Committee, HL7 Co-chair, EHR SIG, HL7 Convenor, ISO TC 215, WG2 Professor, Community & Family Medicine, Duke University

2. Why standards in health care? • There is an assumed and inherent need to share data in the health care setting. The data are of many types and form and will be used for multiple purposes. • We must share both data and knowledge for both improved health care and for economic reasons. • Sharing becomes economically possible only if interoperability exists. • Interoperability occurs only if a full set of standards in health care exist.

3. Inpatient setting • Inpatient systems consist of many heterogeneous systems that must be integrated for efficient and effective care. • Service requirements that are essential parts of hospital information systems require communication between the requestor of a service and the supplier of the service. • Automated capture of data is most economical, most accurate, and most complete. • Patient safety and improved quality of care require the integration of data without the loss of information among many systems.

4. Steps to making a standard • Awareness of need for standard • Critical mass of technical expertise to create standard • Must insure fairness and not competitive advantage to a single vendor • Expertise must be both technical and domain • MUST involve vendors, providers, consultants, government • Global acceptance of standard • Requires education, balanced voting • Vendor implementation of standard usually driven by consumer pressure to implement • Visible reduction in cost and effort of interfaces as a result of standard

5. Company Dos Windows Consortium Unix Linux Industry DICOM Government NIST CMS (UB92) HIPAA Voluntary consensus ASTM HL7 NCPDP Different Kinds of Standards

6. Consensus Standards • Volunteer-driven • Not full-time commitment • Uneven levels of participation • Uneven levels of understanding • Required resolution of negatives • Prone to compromise, often leading to ambiguity • Specialized balloting process (ANSI: requires 90% approval at membership level)

7. Multiple talents required for success • Administrative structure that supports the process but does not get in its way. • Political process that removes barriers to acceptance and implementation • Technical process that produces technically sound standard • Open process that does not slow or hinder production of standard • Funding process to create a standard in shortest, reasonable time • Commitment to life cycle of maintenance and update

8. A bit of history … • HL7 began in 1987 to permit the creation of an affordable Hospital Information System from a “best of breed” approach. • Standard was based on an implicit model based purely on the experience of the developers. • Limitations in technology defined the characteristics of the standard: character-based, character delimiters, position-defined. • First efforts addressed most important and frequent requirements. • Speed was important. • Acceptance took time.

9. Health Level Seven - Standards • Messaging Standard V2.4 • Messaging Standard V2.4, XML Syntax • Messaging Standard V 3.0 • Reference Information Model • Data Types • Clinical Document Architecture • Common Clinical Objects Working Group • Arden Syntax • Vocabulary • Clinical Guidelines • Decision Support • Clinical templates • Electronic Health record

10. Functional and Semantic Interoperability • Defined process for creating data interchange • Reference Information Model • Common Data Types • Common Terminologies • Common content specification at complex levels – a.k.a. clinical templates • Clinical document architectures • Conformance requirements • Document standards • Trigger Events

11. MDF Model Relationships Analysis Design Requirements Analysis Use Case Model (UCM) Domain Analysis Domain Information Model (DIM) Interaction Design Interaction Model (IM) Message Design HierarchicalMessageDescriptions (HMD) 2-nd Order 1 choice of 0-n Drug 0-1 Nursing Reference Model Repository RIM

12. Interoperability Standards • Reference Information Model • Object Model that provides framework for the exchange and sharing of health data. EHR model must be based on this model. • HL7 has created such a model, accepted internationally, that is now becoming stable • HL7 model is high level requiring subsequent refined models for communications and storage of data.

13. HL7 RIM 1.15

14. RelationshipLink Act Relationship 0..* 0..* 0..* 0..* 0..* 1 0..* 1 1 0..* 1 1 1 1 HL 7 RIM Core Classes Entity Role Participation Act Referral Transportation Supply Procedure Condition Node Consent Observation Medication Act complex Financial act Patient Employee Practitioner Assigned PractitionerSpecimen Organization Living Subject Material Place Health Chart

15. V3 Coded Data Types

16. Clinical Document Architecture • XML-based definition of clinical documents such as discharge summaries, op notes, progress notes, radiology reports, etc. • HL7 has ANSI approved standards. Work is based on 3 levels: (1) header; (2) header plus body structure and section headings; (3) element content specification and identification

17. Interoperability Standards (Concepts) • Clinical Data Model • Defines detail clinical object structures • Examples • CEN GPICS • HL7: 3M Clinical Data Models • HL7: Common Message Element Types • HL7: Clinical Templates • GEHR: Archetypes • ISO TC 215 WG2 has work item to harmonize these common conceptual elements (CHICS) • Require registry

18. Implementation/Conformance • Most frequently, ambiguity and options remain in standards at all levels. Total interoperability requires a precise definition of what will be sent to whom under what circumstances. • One example of this approach is DEEDS. • NEDSS will also provide this level of specification.

19. Methods • Work can be performed by a knowledgeable few; then get buy-in from group • Require use of standards by law • Sell value of standards; create a market • Demonstrations to prove standards work and to get publicity • Give publicity to vendors that use standards • Convince users to demand standards • Buy from vendors who use standards • Reduce confusion in market place caused by multiple, competing standards.

20. Final advice • Total adherence to standard is most economical approach • Mapping of “your standard” to the standard is inefficient, expensive, out of date, and wrong. • A business case must be made for switching to the standard. Then the switch must be made in a timely fashion. • Governments must support standards. • If you know what must be done, do it now!