Introduction to HL7 Version 3

1. Introduction to HL7 Version 3 Jane Curry Sierra Systems HL7 Canada – Halifax October 18th, 2001

2. Today’s Objectives • Discuss the rationale for Version 3. • Introduce the Version 3 methodology • Describe the RIM its core components and relate to Vocabulary Domains and Data Types. • Briefly discuss the use of XML (eXtensible Markup Language) in Version 3. • Version 3 and the EHR – new opportunities

3. Acknowledgements • Abdul-Malik Shakir • Woody Beeler • Stan Huff • Ted Klien • Lloyd McKenzie • Dan Russler • Gunther Schadow • Helen Stevens • Mead Walker • And others too numerous to mention (The named individuals are those I directly swiped slides from)

4. Outline of this Session • Version 3 and the drive for Interoperability • A new paradigm for HL7 Messages - methodology introduction • Introduction to the HL7 Reference Information Model (RIM) & to HL7 vocabularies • Key Ballot Components • Message Basics • XML: HL7’s chosen message transport mechanism • Discussion on HL7 V3 and the EHR

5. Note: Our Focus is on Standards Development • The Version 3 methodology provides: • processes for building HL7 message • discussion of the models that support that process • tools to aid in message creation • Standards implementers should understand the basis for the messages they implement. • Standards implementers do not need to master the mechanics of using the methodology simply to implement V3 interfaces.

6. Semanticinteroperability Functionalinteroperability Interoperability & Innovation • Main Entry: in·ter·op·er·a·bil·i·tyFunction: nounDate: 1977: ability of a system (as a weapons system) to use the parts or equipment of another systemSource: Merriam-Webster web site • interoperability: ability of two or more systems or components to exchange information and to use the information that has been exchanged. Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]

7. Interoperability & Innovation • Main Entry: in·no·va·tionFunction: nounDate: 15th century1: the introduction of something new2: a new idea, method, or device : noveltySource: Merriam-Webster web site

8. Interoperability & Innovation HL7’s mission is clinical interoperability “To provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services.” Source: HL7 Mission statement (1997) HL7’s strategy is innovation – both by ourselves and by our users

9. Another Perspective on New Requirements • Drawn from The eHealth Landscape - a paper prepared for the Robert Wood Johnson Foundation to discuss emerging information and communication technologies (available online at www.rwjf.org.) “Many observers believe that a vision of convergent— or at least interoperable— clinical, laboratory, and public health information systems appropriately linked to personal health information, will provide unprecedented opportunities for improving individual and population health services and knowledge.” “Outside of the approximately 3 billion health care claims processed annually, an estimated additional 25 to 30 billion clinical, financial, and administrative health care transactions take place, with only a small fraction of these transactions transmitted electronically.” “Extensible Markup Language (XML) is enabling the development of innovative eHealth tools that are considerably more powerful and user friendly than what we currently have.”

10. The semantics of the communication The semantics convey the actual "meaning" of the message. The semantics is conveyed via a set of symbols contained within the communication. An external "dictionary", thesaurus, or terminology explains the meaning of the symbols as they occur. A channel to carry the communication Examples of channels include written documents, telephones, network connections, satellite links, etc. What must be specified for communication? HL7 specifications Nouns . Adjectives Verbs A syntax for communication The syntax defines the structure and layout of the communication. Common syntax representations include ASN.1, XML, X.12, HL7, IDL, etc. Services to accomplish the communication Examples include the post office, a telephone switchboard, SMTP, FTP, Telnet, RPC, ORB services, etc.

11. HL7 Version 3.0 • HL7 version 3.0 will be the most definitive HL7 standard to date, incorporating more trigger events and message formats with very little optionality. • Version 3.0 uses an object-oriented development methodology and a Reference Information Model (RIM) to create message specifications. • The RIM is an essential part of the HL7 Version 3.0 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages. • As part of version 3.0, the HL7 Vocabulary Technical Committee is developing methods that will allow HL7 messages to draw upon codes and vocabularies from a variety of sources. • The V3.0 vocabulary work will assure that the systems sending and receiving V3.0 HL7 messages have an unambiguous understanding of the code sources and code value domains they are using. • HL7’s primary goal for version 3.0 is to offer a standard that is definite and testable, and to provide certification of vendor’s conformance.

12. Limitations of Version 2.x • Implicit information model, not explicit. • Events not tightly coupled to profiles. • Need for controlled vocabularies. • Limited to a single encoding syntax. • No explicit support for object technologies. • No explicit support for security functions. • Optionality is ubiquitous and troublesome.

13. HL7 Version 3 Characteristics • Design based on consensus Reference Information Model - ties message elements to explicit semantic definitions • Adaptable to current and future technology bases - requires abstract expression of standard data structure • Vocabulary-level interoperability - requires robust data type(s) for coded data • Explicit conformance model - means that optional elements in the specification must be eliminated where ever possible

14. Version 3 is a change to the HL7 Architecture • The HL7 2.x specifications have: • Segments that imply information entities • Events that indicate implied behaviors • Descriptive content that suggests use cases but never formally documents these • Version 3 seeks to formalize this by applying object analytic methods and style • to improve the internal consistency of HL7 • to provide sound semantic definitions • to enable future architectures • to produce an evolution not a revolution Done by applying MODELING to the HL7 process

15. V3 has a Focus on Quality • We often criticize the quality of standard interfaces: • each implementation is different, • install time is no less then a custom interface, • little support for specialized needs. • Version 3 provides a platform for quality improvement: • the methodology defines the process for creating the standard - this is subject to incremental improvement, • models such as the RIM explicitly declare the functional assumptions of the standards developers. • The drive to create more rigorous specification of interface leads to greater effort in standards development.

16. Outline of a Method for building Messages:a “Methodology”

17. Version 3 Messaging Goals • Provide a framework for coupling events, data elements and messages. • Improve clarity and precision of specification. • Improve adaptability of standards to change. • Begin to approach “plug and play”.

18. 1996 Introduce modeling to TC Chairs First V3 Tutorial to general membership Vocabulary SIG established 1997 Roll-out of first RIM, version 0.80 First Message Development Framework First RIM Harmonization meetings 1998 Adopted Rational Rose for modeling Work begins on V3 XML ITS First RoseTree tools appear 1999 V3 Data type proposal reviewed Notion of R-MIM added to MDF Vocabulary enters the V3 MDF 2000 V3 data types out to ballot First vocabulary harmonization V3 Acceleration Project started 2001 RIM and Vocabulary stabilized Version 3 Publication Strategy Publish initial message ballot Datatype ballots expected complete XML ITS ballot completed Still in progress History of HL7 V3 Messaging Activities

19. Dispense Medications Manage Care Perform Lab Tests Review Utilization By demanding analysis of the requirements and information content, Version 3 assures consistency in and enhances the value of the resulting products. Encounter Account Provider Patient Order HAL HL7 message HL7 message Finance ADT Pharmacy HL7 Modeling Abstractions: Version 2.x focused its energies at the communication level and covered the other abstractions only loosely in the specifications. Activities(Use Case Model) Objects (Information Model) Communication (Interaction and Message Models)

20. Messaging Methodology Mission • To bring modern software engineering practices, such as Object Oriented Analysis and Design and formal modeling, to the standards development process. • To bring the highest level of quality, understandability, and flexibility to a messaging standard. • Incorporate concept abstractions and behavior modeling using roles in a rigorous set of work products. • Express the standard in widely accepted UML notation.

21. In fact, Version 3 Is Mostly Modeling • The deliverables are expressed as models. • Each model leads to greater understanding of areas that influence content, structure, and behavior of messages. • Messages are defined when the models are integrated. • The HL7 standard message specification will be derived from the models.

22. Use Case Model Information Model Interaction Model 2-nd Order 1 choice of 0-n Drug 0-1 Nursing Message Specification HL7 Version 3 Models and Specifications • Captures healthcare requirements • Defines scope for TSC approval • Specifies data and its semantics • Specifies major state transitions • Specifies vocabulary for domains • Defines information flows • Defines communication roles • Forms basis for conformance claims • Defines message contents • Apply constraints to the information model and vocabulary

23. Use case model Hierarchy of tasks and actors Interaction model Trigger events, abstract messages & application profiles Information model Classes, relationships, states, and lifecycles Message design model Refined Message Information Model (R-MIM) Abstract message definitions (HMDs) Vocabulary Domain definitions Representations and mappings Implementation Specification Implementation Technology Specification (ITS) HL7 V3 Messaging Deliverables

24. C Code c Codea artb bluec color HL7 V3 Message Development Lifecycle Analysis Design Application Messaging Message Types for use with XML, ER7, etc (MET) Requirements Analysis Use Case Model (UCM) Domain Analysis Information Model &Vocabulary (RIM) Interaction Design Interaction Model (IM) Message Design HierarchicalMessageDescriptions (HMD) Documents Document Types forHL7 PRA (DTD) Medical logic Variable definition for Arden syntax (AVD) TYPE MPSLOC CONTAINS { id[id].TYPE IID nm[name].TYPE ST ad[addr].TYPE XAD ph[phon].TYPE XTN email_address [emlAdr].TYPE XTN } 2-nd Order 1 choice of 0-n Drug 0-1 Nursing <!ENTITY %DT_MPSLOC“MPSLOC.id, MPSLOC.name?, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.emlAdr?"> data:location_of_action := READ LAST MPSLOC ; ‘ {patient location} Reference Model Repository

25. Information Model Use Case Model Spec Spec DIM Spec Class Diagram State Diagram UCM Spec Use Case Diagram Interaction Model Message Design Spec 2-nd Order 1 choice of 0-n Drug 0-1 Nursing h//mt:50”d” … … … Inter Spec Interaction Diagram Message Development Phases

26. Chapter-Specific Specs Chapter-Specific Specs Chapter-Specific Specs Chapters 2 and 8 Chapters 3, 4, 6, ... Segments and Fields Trigger Event and Messages An HL7 Version 2.x Message Spec Common Specs

27. An HL7 Version 3.x Message Spec Chapter-Specific Specs Message Model Information Model Use Case Model Interaction Model 2-nd Order 1 choice of 0-n Drug 0-1 Nursing HL7 Reference Model Common Specs *Future Consideration Implementable Message Specification XML/ER7/… Implementable Message Specification OLE/CORBA Implementable Message Specification EDIFACT*

28. HL7 Version 3 Methodology in words 1. Define a consensus reference information model (RIM) that defines the data of interest in the healthcare domain. 2. Assemble the terminologies and data types necessary to express the attributes of the RIM. 3. Apply the model, vocabulary and types to: messages, patient record DTDs, medical logic modules, component specifications, etc. 4. For any particular application, draw from the RIM to construct an abstract message structure - the Hierarchical Message Description (HMD). 5. For any particular implementation technology, HL7 will define an implementation technology specification (ITS) for mapping the HMD to that technology. 6. When the message (or equivalent) is sent, the HMD is used to marshal the data, and the ITS is used to format the data for communication.

29. Defining Conformance within V3 • Reducing the cost, and increasing the predictability of a new interface is a key driver for Version 3. • At the same time, the standards organization cannot, and should not, determine how application functions should be organized and bundled together. • For example: • Should an application that manages patient encounters also manage patient accounts? • Does a system that captures (outpatient) visits also have to record inpatients? • Does a system that receives lab orders also have to receive pharmacy orders. • The solution is conformance claims based on application roles.

30. V3 Conformance Claims • HL7 defines, within the Interaction Model, application roles that are played by message senders and receivers. • A vendor or system creator issues conformance claims that declare which application role or roles their system can support. • This implies the system can send and/or receive all the messages defined for that application role. • Conformance claims also indicate how a vendor or system creator supports V3 messages. • They declare the message encoding to be used. • They indicate, of the attributes in a message that are neither mandatory nor forbidden, which are supported.

31. "Discontinue "Send as ASCII Implementation Hierarchical pharmacy order" string in XML Technology Message format" Specification Definition ITSforXML HL7 HL7 Message Message Message Data Instance Data Creation Parsing HL7-Conformant HL7-Conformant Application Application How do you get an encoded message?

32. Building an HL7 Reference Information Model

33. Domain expertise Vocabulary developers, professional societies, government agencies, HL7 committees Domain expertise HL7 committees, affiliates, members & collaborators Messaging, Document structures, Clinical templates, Arden syntax, Component specification, ….. Applications HL7 core requirement - Common semantic models

34. The Information Model • A detailed and precise definition for the information from which the data content of HL7 messages are drawn. • Follows object-oriented modeling and diagramming techniques, and is centered on a depiction of the classes that form the basis for the objects in HL7 messages. • Provides a means for expressing and reconciling differences in data definition independent of message structure. • Forms a shared view of the information domain used across HL7

35. The Reference Information Model (RIM) • Used to express the information content for the collective work of the HL7 Working Group. • A coherent, shared information model that is the source for the data content of all HL7 messages. • Maintained by a collaborative, consensus building process involving all Technical Committees and Special Interest Groups. • RIM change proposals are debated, enhanced, and reconciled by technical committee representatives and applied to the RIM during the model harmonization process

36. The Reference Information Model • is a consensus view on our universe • nothing exists outside, isolated from the RIM • provides flexible structures • rather than isolated detail data elements • melts the vertical silos into a coherent whole • is work in progress • wants you to get involved • wants you to wrestle with it, • wants you to understand it, • wants you to help improving it • wants to work for you!

37. What is the RIM? A HL7-wide common reference model that integrates all Technical Committees’ domain views Why do we need a common model? To ensure consistency of concepts To ensure consistent vocabulary How will we coordinate these efforts? Iterative reviews Harmonization meetings Who controls RIM? The M&M committee Format, syntax, style Revision histories The Technical Steering Committee Dispute resolution Overseer Committee Models Vs. HL7 Model

38. Change Proposal Preparation Harmonization Meeting Post Harmonization Meeting Review Post RIM Change Proposals Document Rationale for not supporting RIM change proposal Revise or Withdraw RIM Proposal Submit RIM Change Proposal Post RIM Change Proposal Notify HL7 Members of RIM Change Proposal Posting Provide Comment on RIM Change Proposals Discuss the RIM Change Proposal Revise, withdraw, or Table RIM Change Proposal Vote on RIM Change Proposal Apply Approved Changes to RIM Apply Technical Corrections Present RIM Harmonization Report to TSC Hold TSC and/or Board Appeals Finalize Revised RIM HL7 RIM Harmonization Process Review RIM Change Proposal w/ Stewards Prepare RIM Change Proposal

39. Reference Information Model

40. Relationship Link Act Relationship 0..* 0..* 0..* 0..1 0..1 0..* 0..* 0..* 1 0..* 1 0..* 1 1 1 1 RIM Core Classes Entity Role Participation Act Encounter Referral Supply Procedure Observation Substance Administration Financial act Patient Employee Certified Practitioner Assigned PractitionerSpecimen Healthcare Facility Organization Living Subject Material Place

41. Definitions Act - an intentional action in the business domain of HL7. Healthcare (and any profession or business) is constituted of intentional actions. An instance is a record of an act. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. Entity - physical thing or organization and grouping of physical things. A physical thing is anything that has extent in space, mass. Excludes information structures, electronic medical records, messages, data structures, etc. Role –For people, role is usually positions, jobs, or ‘hats’ and for places and things are what these places or things are normally used for. Each role is “played by” one Entity and is usually “scoped” by another. Thus the role of Patient is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, an Employee role is scoped by the employer.

42. Definitions (continued) Participation -- exists only within the scope of one act.Acts have multiple participants, each of which is an entity in a role. Role signifies competence while participation signifies performance. Relationship Link – Is similar to an Act relationship in that it binds together two roles. Thus Dr. Smith of the OB section (an Assigned Practitioner) has primary responsibility for Mrs. Smith (a Patient of Mercy Hospital).

43. 0..1 0..1 0..1 0..1 0..* 0..* 0..* 0..* 1 1 0..* 0..* RIM Core Attributes Relationship Link Act Relationship type_cd : CS effective_time : IVL<TS> type_cd : CS Entity Role Participation Act class_cd : CC cd: CE determiner_cd : CS status_cd : CS id : II class_cd : CS cd: CE effective_time : IVL<TS> status_cd : CS id : II type_cd : CS time : IVL<TS> status_cd : CS class_cd : CC cd: CD mood_cd : CS status_cd : CS effective_time : GTS id : II 1 plays 0..* 1 scopes 0..* Six attributes: Class_cd+cd/type_cd, time, mood, determiner, status, id

44. Observation • Procedure • Supply • Substance • Admin • Financial • ... • Living Subject • Person • Organization • Material • Place • ... • Patient • Provider • Employee • Specimen • Certified • Practitioner • ... • Performer • Author • Witness • Subject • Destination • ... Act Class Code Role Class Code Entity Class Code Participation Type Code 1 1 0..* 0..* • Definition • Intent • Order • Event • Criterion • ... • Kind • Instance • (QuantifiedGroup) Entity Determiner Code Act Mood Code RIM Core Attribute Value Sets Entity Role Participation Act class_cd : CC determiner_cd : CS status_cd : CS cd: CE 1 class_cd : CS effective_time : IVL<TS> cd: CE type_cd : CS time : IVL<TS> status_cd : CS class_cd : CC mood_cd : CS status_cd : CS Cd: CD effective_time : GTS plays 0..* 1 scopes 0..*

45. Act State Model

46. Master Act(definition) Care plan for a patient Define plans and guidelines Act Ordering(order) Business Cycle Scheduling Performing Reviewing Documenting & reporting(event)

47. Why Does the RIM look the way it does? • Highly generic class structure promotes stability and extensibility. • Provides a simple construct that can easily be grasped. • The richness and complexity of the real world is captured in individual domain and message information models. • Note, for some, the RIM is too abstract. HL7 is working on a way to link together the subset models to address this issue.

48. A RIM is not enough – what about Vocabularies. and Data Types?

49. Constraining Coded Attributes • Coded attributes in the RIM must be associated with one and only one Vocabulary Domain prior to being used in a message specification. • A vocabulary domain is “The set of all concepts that can be taken as valid values in an instance of a coded field or attribute.” • Each concept in the vocabulary domain is represented using a code from a specific vocabulary. Coded attributes Over 40% of RIM attributes are coded!

50. RIM Domain Attribute Person.gender_cd Gender Specialization Sub-domain R-MIM Patient Gender A subset of Gender Patient.gender_cd Value Set Specialization HMD (PAFM) Realm (USA) Code System (HL7) Administrative Gender Patient.gender_cd Attributes, domains, and value sets