Version 3 - HL7’s “Swiss Army Knife”

1. Version 3 - HL7’s“Swiss Army Knife” What it is. What it does. G. W. Beeler, Jr. beeler@mayo.edu

2. Topics • Interoperability & HL7 standards • Version 3 - building on Version 2 • Semantics first • Infrastructure of standards for interoperability • Infomration Model (later in session) • Vocabulary • Clinical templates • Applications of the infrastructure • Components (CCOW) • PRA Document architecture • Medical logic representation (Arden Syntax)

3. What IS interoperability? Functionalinteroperability Semanticinteroperability • Intuitive answer is easy, but specific response is not • Institute of Electrical and Electronics Engineers (IEEE) dictionary: "The ability of two or more systems or components to exchange information and to use the information that has been exchanged.”[IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]

4. Any meaningful exchange of utterances depends upon the prior existence of an agreed upon set of semantic and syntactic rules ISO TR9007:1987 Information Processing Systems – Concepts and Technology for the Conceptual Schema and the Information Base Basis for Communication

5. 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. What must be specified? A channel to carry the communication Examples of channels include written documents, telephones, network connections, satellite links, etc. HL7 specifications Nouns Things or entities that are being communicated. Adjectives Descriptors and relationships of the nouns. Verbs Actions being requested or communicated. 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.

6. HL7 Version 3 - • HL7 “grew up” on the Version 2 series, culminating in 2.3.1 • But now, HL7 is into Version 3 • What is it? • How is it different? • Why is it important?

7. Versions 2.x • Widely used: • secondary and tertiary facilities • large practices • Broad functional coverage: • clinical: laboratory, pharmacy, radiology, dietary, most other diagnostic services, patient care, public health • “clinical administrative:” patient registration, admission; patient accounts; medical document life cycle; master file maintenance, HIPAA attachments • Designed in 1987 • Based on older messaging formats such as X12

8. Strengths broad functional coverage highly adaptable IS environments differ system capabilities variations vocabulary independent least common denominator technological base Difficulties broad functional coverage highly adaptable “Seen one? Seen one.” vendor capability mismatch vocabulary independent least common denominator technological base Versions 2.x

9. Version 3 Differences • Design based on consensusReference Information Model • Adaptable to current and future technology bases • Vocabulary-level interoperability • Explicit conformance model • Built on strongly accepted industry base technologies

10. What is Version 3? • A new form of standards • Messaging standards that are logically consistent with Versions 2.x, but with crucial semantic improvements • Document standards based on SGML/XML document architecture • Component standards • Knowledge representation AND • A new process for developing those standards • A wholly new approach to the way HL7 develops its standards Amounts to “re-engineering” the HL7 organization and process

11. Version 3 as a Standard • A new communication framework that • Separates message content definition from transmission formats • Includes a Patient record architecture (PRA) - to define sharable persistent documents • Facilitates use of external codes and terminologies • Clinical templates • Ability to define specific clinical content that can be exchanged with standard messages from Versions 2 and 3 • Components for • Clinical communications • Workstation integration • Medical logic representation - Arden syntax

12. Version 3 as Process • A wholly new approach to developing HL7 standards • Model and repository-based for increased control and standards that are internally consistent • Specific coupling of events, data elements, messages. documents, and more • Increased detail, clarity and precision of specification • Finer granularity in the ultimate messages • Explicit inclusion of standard vocabularies, terminologies and code sets.

13. 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. Semantics - the CORE issue A channel to carry the communication Examples of channels include written documents, telephones, network connections, satellite links, etc. Nouns Things or entities that are being communicated. Adjectives Descriptors and relationships of the nouns. Verbs Actions being requested or communicated. 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.

14. What does it mean when ... • I identify the “patient’s attending physician?” • a single individual? Or • all of the physicians’ involved in the case? • I send a “patient identifier?” • their Social Security Number? Or • the medical record number in my institution? Or • a shared MPI number? • I key my action to the end of the current “episode?” • the period of time the patient undergoes care on a given day? Or • the period of time the patient spends being an inpatient? Or • the period of time during which the patient is diagnosed with the same health condition (diabetes, hypertension, etc.)

15. HL7 sine qua non - Common semantic models 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

16. Model of Standards for Interoperability Functional Infrastructure Vocabulary Interactions Information Model

17. ORU: The usual result message Observation Loop Result/Element Loop

18. OBX: the flexible segment A code that identifies the datatype of OBX-5 OBX-5: Data Status A code that identifies the units of numerical data in OBX-5 Other data fields include: date of observation, identity of provider giving observation, normal ranges, abnormal flags OBX||NM|11289-6^^LN||38|C^^ISO+|||||F A code that identifies the data in OBX-5(Temp Reading)

19. OBX: with a coded value A code that identifies the datatype as a coded element The code is from LOINC The code is from SNOMED A code that identifies the data in OBX-5(Fetal Gender) OBX-5: Data A code for Female OBX||CE|11882-8^Fetal Gender^LN||T-D0AA0^Female^SMI|

20. HL7 Reference Information Model Class: Patient Description:A person who may receive, is receiving, or has received healthcare services. Associations is_a_role_of (1,1) :: Person is_source_for (0,n) :: Specimen_sample Attributes birth_order_number birth_dttm (from Person) gender_cd <domain 35674> (from Person) marital_status_cd (from Person)

21. Codes in the HL7 RIM • Class: Person • Attribute: gender_cd <domain 35674> • HL7 Domain Specification • Id “35674”, • Scheme “SMI”, version “3.4”, • Name “Sex, NOS”, • Include Set{{T-D0A90}} • SNOMED International • T-D0A90Sex, NOS • T-D0A96Indeterminate sex • T-D0AA0Female, NOS • T-D0AB0Male, NOS

22. Codes in an HL7 message OBX|1|CE|11882-8^Fetal Gender^LN||T-D0AA0^Female^SMI| LOINC 1.0K 11882-8 GENDER:FIND:PT:^FETUS:NOM: ULTRASOUND:OB.US SNOMED International • T-D0A90Sex, NOS • T-D0A96Indeterminate sex • T-D0AA0Female, NOS • T-D0AB0Male, NOS

23. Vocabulary and Information Model • There is a tight connection between clinical data models and vocabulary • Changes in structure cause changes to the vocabulary, and vice versa • Vocabulary and structure must be coordinated to achieve an integrated whole

24. HL7 Vocabulary TC Purpose: To identify, organize and maintain coded vocabulary terms used in HL7 messages.

25. The Approach • The HL7 Vocabulary TC is committed to using existing vocabularies (coding systems) as values for coded fields in HL7 messages, rather than creating a new terminology. • We need a solution that allows HL7 to reference and use proprietary vocabularies (SNOMED, Read, etc.) in a manner that is equitable to all vocabulary creation/maintenance organizations.

26. Model of Standards for Interoperability Interactions Information Model Vocabulary Functional Infrastructure Constraints (Templates)

27. ORU: The usual result message Element Loop Answer Part Loop

28. An instance of an ORU message MSH, EVN, PID, PV1, ORC, OBR||8974-9^BP Battery^LN| OBX|1|CE|8357-6^METHOD^LN|M^Manual| OBX|2|CE|8358-4^DEVICE^LN|1|AC^Adult Cuff| OBX|3|CE|8359-2^SITE^LN|1|RBA^Rt Brachial Artery| OBX|4|CE|8361-7^POSITION^LN|1|SIT^Sitting| OBX|5|NM|8479-8^SBP^LN|1|138|mmHg| OBX|6|NM|8462-4^DBP^LN|1|85|mmHg|

29. A BP Battery Template Battery Level Constraint BPBattery ::= SET { obr { universalServiceID (8974-9^BP Battery) } obxs { MethodObs, DeviceObs, SiteObs, PositionObs, SystolicBPObs, DiastolicBPObs }

30. Observation Template Observation level constraint PositionObs ::= SET{ observationId (8361^POSITION^LN), value (PositionDomain) } SystolicBPObs ::= SET{ observationId (8479-8^SBP^LN), value (Numeric, “DDD”) }, units (mmHg) }

31. The RIM and Clinical Templates Stakeholder Service Event Organization Person Order Assessment Rx Order Observation Service Order Goal Root 120+ 1,000+ Retics O2 Sat UA Eye

32. What are clinical templates? • “Constraint of an existing information model” • Reference Information Model (RIM) • Message Information Model (MIM) • Message Element Type (MET) • Hierarchical Message Definition (HMD) • Constraint of specific RIM classes: • clinical assessment • clinical observation • service event • service order • others • Can be applied to Version 2.X or version 3.0

33. Clinical Template Work Items • Define the formal notation for templates • Literary representation • Database representation • Graphical representation • Define a process for creating, approving, and maintaining templates • Define a mechanism for participating with professional societies or other clinical experts in the creation of template content • Create a repository for storing and allowing access to templates

34. Model of Standards for Interoperability Functional Infrastructure Interactions Information Model Constraints (Templates) Vocabulary Interoperable Systems OperationallyDependent OperationallyIndependent Applications (of the infrastructure)

35. Tightly Coupled navigation system and gyroscope model: function call operational dependence the default mode for software component services frequently associated with one-source data Loosely Coupled navigation system and map data model: message operational independence, or semi-dependence can be implemented with software component services data replication Operational Coupling

36. What is CCOW? A Standard to: Standard Standard • Couple • Coordinate • Synchronize Disparate applicationson the workstation at the point of care. (similar to HL7 but on the “front-end”) Manatee: a sea cow

37. “Visual” Integration Server “Data” Integration Visual Integration Server Server The Clinical Applications The Provider The Provider's Workstation

38. Context Manager Component The Clinical Applications C COM Automation The Provider's Workstation The Provider

39. It’s real and it works • Current Patient = Nancy Furlow as shown within: • Multum MediSource • Oacis EMPI • Medicalogic Logician • Hewlett Packard CareVue

40. Within Oacis EMPI, search for a new patient and select Michael O’Donnell.

41. The patient context is automatically switched to Michael O’Donnell within all systems at the point use.

42. Component Implementation Context Manager Implementation CM Application #1 Implementation CP CD Common Context Data Application #n Implementation CP Patient Mapper Implementation MA II

43. Current Work • Single sign-on: • users do not have to memorize many user names and passwords • authentication via password, badge swipe, biometrics • Web-based applications • share context with client/server apps • “pure” web-based: awaits an interested participant

44. Model of Standards for Interoperability Functional Infrastructure Interactions Information Model Constraints (Templates) Vocabulary Interoperable Systems OperationallyDependent OperationallyIndependent Applications (of the infrastructure) DocumentSharing

45. Document Patient Record Architecture • Proposal • Architecture that allows for varying levels of complexity in clinical documents • Interface that is a mediator between two applications or systems • Exchange mechanism from a document centered perspective with varying levels of requirements

46. <PRESCRIPTION> <MEDNAME MED="Amoxil"> Prescribed medication: Amoxil </MEDNAME> <PLAN CC.CLIENT.ETN="PRESCRIPTION"> <MENTION DOMAIN="Kona Example" NORMALIZED.CONTENT="Amoxil" CC.CLIENT.ETN="MEDNAME"> Prescribed medication: Amoxil </MENTION> A Transformation Architectural Forms specify how tags are changed: APPLICATION PRA Transform <PRESCRIPTION> to <PLAN>

47. The Patient Record Architecture • Multi-layered schema consisting of three layers • A basic, abstract layer to exchange narrative documents (ProseDoc) • A layer that provides simple classification (ClinicalContent) • A layer that requires greater clinical semantics

48. The Patient Record Architecture

49. Example: Document Repository Diabetes DTD 1 Op-Note DTD 2 Diabetes Note (1) Transform Op-Note (1) Op-Note (2) Transform Transform Diabetes Note (PRA Level one) Op-Note (PRA) Op-Note (PRA) Organization 1 Organization 2 Op-Note DTD 1 A computer can searchall the notes based on Level One admin. Data, anddo smart processing onOp-notes based on the PRA subset A person can readall the contents ofall the notes

50. Model of Standards for Interoperability Functional Infrastructure Interactions Information Model Constraints (Templates) Vocabulary Interoperable Systems OperationallyDependent OperationallyIndependent Applications (of the infrastructure) DocumentSharing PortableRules