1. Introduction to HL7 Version 3 W. Ed Hammond February 25, 2008

2. 25 February 2008Hammond2 HL7 v3 messaging standard HL7 v3 is based on an object information model called the Reference Information Model, (RIM). This model is “abstract,” that is, it is defined without regard to how it is represented in a message “on the wire” or in a “service architecture” method or in a “clinical document.” In fact, each of these representations can contain the same “instance” of information. This object-oriented design paradigm means that v3 can be extended incrementally when new clinical information domains need to be added, in a way that doesn’t require changing what has already been created.

3. 25 February 2008Hammond3 HL7 Development Framework The HL7 Development Framework is a formal methodology for mapping any “local”, domain-specific system, such as a “laboratory system” in the v3 Reference model. The basic concept is that any system can be mapped into a “neutral” and formal UML-based Domain Analysis (DAM) model with the help of domain experts. The DAM can then be mapped into the equivalent v3-RIM model. This mapping is bi-directional, and highlights any changes needed by either the local system or the RIM to create a semantically complete mapping. The RIM Harmonization process supports a standard way to add new domain requirements to the RIM in a way that doesn’t invalidate the previously created models. This again is a feature of object-oriented paradigms.

4. 25 February 2008Hammond4 Model-based Development HL7 Framework HL7 Specification RIM Datatypes Data elements Vocabulary Templates Clinical Statements Core Structured Content V3 Messaging CDA Specifications System Oriented Architecture

5. 25 February 2008Hammond5 What’s different about v3? Conceptual foundation – a single, common reference information model to be used across HL7 Semantic foundation – in explicitly defined concept domains drawn from the best terminologies Abstract design methodology that is technology-neutral – able to be used with whatever is the technology de jour (e.g. XML, UML, etc.) Maintain a repository (database) of the semantic content to assure a single source, and enable development of support tooling

6. 25 February 2008Hammond6 How is Version 3 “better”? Tools for documentation of constraints for both message definition and conformance specifications Tools to auto-generate XML schemas for messages once the semantic content is final (via ballot and conformance constraints) –The same auto-generation process is being used for Java API’s for the v3 messaging models

7. 25 February 2008Hammond7 Some V3 tools details HL7 Model Repository – database holding the core of HL7 semantic specifications –RIM- Storyboards –Vocabulary domains- Interaction models –Message designs- Message constraints Tool sets designed against the repository to –Permit management of repository content –Review and browsing of semantic specifications –Design of abstract information structures based on the RIM for use in messages, templates, documents, etc. –Publish HL7 specifications and standards –Support implementation of HL7 standards

8. 25 February 2008Hammond8 Drivers for v3 adoption Needed to support for large scale integration V3 has “built-in” support for Complex Datatypes supporting “universally unique” instance identifiers for persons, places, organizations, practitioners, URL’s, orders, observations, etc. Name datatype (persons and organizations) Time and date-related datatype forms Codes (binding standard vocabularies to RIM attributes) V3’s methodology of deriving its models from the RIM also supports semantic interoperability

9. 25 February 2008Hammond9 Drivers for v3 adoption For implementations requiring large scale integration (city, region, province, nationwide, international), v3 has ‘built-in’ support “Structural ontology”: a coherent set of (structures) models guaranteeing semantic interoperability and re- use: based on the RIM and datatypes, with integrated vocabulary support Identifier strategy supporting wide integration Model and Tools based design and implementation The need for decision support, and rules-based processing requires the v3 model-based semantic interoperability which is available across the many healthcare information domains. The same information is represented the same way everywhere using the RIM with the binding to structural and standard vocabularies

10. 25 February 2008Hammond10 HL7 Version 3.0 Use-case Model Reference Information Model Domain Information Model Message Information Model Message Object Diagram Hierarchical Message Description Common Message Element Definition

11. 25 February 2008Hammond11 HL7 Version 3 Domain Level Elements

12. 25 February 2008Hammond12 Common Domains Common Message Element Types (CMETS): template structures for complex administrative objects such as address or telephone number Shared Messages Clinical Statement

13. 25 February 2008Hammond13 Administrative Management Accounting and billing Claims & reimbursement Patient Administration Personnel Management Scheduling

14. 25 February 2008Hammond14 Infrastructure / Messaging Transmission Message Control Query Master File / Registry

15. 25 February 2008Hammond15 Health and Clinical Management Blood, Tissue and Organ Care Provision Clinical Decision Support Clinical Document Architecture Clinical Genomics Immunization Laboratory Materials Management Medical Records Medication Observations Orders Pharmacy Public Health Reporting Regulated Products Regulated Studies Specimen Therapeutic Devices Items in yellow are Draft Standards for Trial Use

16. 25 February 2008Hammond16 Version 3 Methodology Storyboard Storyboard Example Application Role Interaction Trigger Event RIM D - MIM R - MIM HMD Message Type Example References SenderReceiver Triggers Content Derive Restrict Serialize Restrict Information Modeling Interaction Modeling Message Design Use Case Modeling

17. 25 February 2008Hammond17 v-3 Methodology defining abstract message Use Case Model Interaction Model Hierarchical Message Description Domain Information Model Message Information Model Refined Message Information Model Common Message Element Definition Reference Information Model

18. 25 February 2008Hammond18 Message instance Source: W. Beeler

19. 25 February 2008Hammond19 v3 Messaging Concerns Difficult to implement Overhead too much –1% of message is payload compared to v2 (delimiters) is about 90-95% No one understands what implementation of v3 messaging means Question value of HDF Need stability, clarity, definition of v3 messaging

20. 25 February 2008Hammond20 What about v3 messages? Some implementers create their own messaging using the HDF process. This is tough and probably not necessary. HL7 has begun to build a library of v3 messages, developed by HL7 experts in different areas and clinical domains. How many v3 messages are required to support robust EHR, RHIO, NHIN? Could we meet needs with one message and constraints?

21. Introduction to Clinical Data Architecture

22. 25 February 2008Hammond22 Document standards Clinical Document Architecture (CDA) –Radiology reports –Patient summary –Discharge summary –Referrals –Claims attachments –Infectious Disease Reports Continuity of Care Record (CCR) Continuity of Care Document (CCD) Common Document Types

23. 25 February 2008Hammond23 What is the CDA? The CDA is a document markup standard for the structure and semantics of exchanged "clinical documents". A CDA document is a defined and complete information object that can exist outside of a message and can include text, images, sounds, and other multimedia content.

24. 25 February 2008Hammond24 Key aspects of CDA CDA documents are encoded in Extensible Markup Language (XML). CDA documents derive their meaning from the HL7 Reference Information Model (RIM). CDA is derived from HL7's central Reference Information Model, thereby enabling data reusability - with lab or pharmacy messages, with claims attachments, clinical trials, etc. The CDA specification is richly expressive and flexible. Templates, conformance profiles, and implementation guides can be used to constrain the generic CDA specification.

25. 25 February 2008Hammond25 CDA Release 1 Allergies and Adverse Reactions Penicillin - Hives Aspirin - Wheezing Codeine – Itching and nausea <coded_entry.value ORIGTXT=“A1” V="DF-10074" S=“SNOMED“ DN=“Allergy to Penicillin”/> Allergies and Adverse Reactions · Penicillin - Hives · Aspirin - Wheezing · Codeine – Itching and nausea ANSI/HL7 CDA R1.0-2000

26. 25 February 2008Hammond26 <code code="101155-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> Allergies and Adverse Reactions Penicillin - Hives Aspirin - Wheezing Codeine - Itching and nausea <code code="247472004" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="HIves"> <code code="91936005" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Allergy to penicillin"/> CDA Release 2

27. 25 February 2008Hammond27 Continuity of Care Document (CCD) CCD as a catalyst: The approach taken in the development of CCD is to reflect the CCR requirements in a CDA R2 framework, and to do so in such a way that CDA is constrained in accordance with models being developed by other HL7 committees. This has helped accelerate convergence within HL7 around a common “clinical statement” model, leading to closer collaboration with several domain committees, such as: Results: Lab committee Family History: Genomics committee Allergies, Problems: Patient Care committee Medications: Pharmacy committee

28. 25 February 2008Hammond28 Continuity of Care Document (CCD) CCD maps the CCR elements into a CDA representation. 2.16.840.1.113883.19.1 Assessment Time 200004071430 Hematology CBC WO DIFFERENTIAL 43789009 SNOMED CT Final Results <code code="30954-2“ codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> Laboratory results CBC (04/07/2000): HGB 13.2; WBC 6.7; PLT 123* <code code="43789009" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="CBC WO DIFFERENTIAL"/>