Version 3: Is it Real, or is it Memorex? Wes Rishel Vice-chair, Technical Steering Committee

9/14/981©1998 by HL7 & Wes Rishel Message Development Framework (MDF) Table of Contents 1. INTRODUCTION 2. USE CASE MODEL 3. INFORMATION MODEL 4. INTERACTION MODEL 5. CREATING MESSAGE SPECIFICATIONS 6. CONFORMANCE CLAIMS 7. FORMAL SPECIFICATION OF HL7 MDF COMPONENTS 8. GLOSSARY OF VERSION 3 TERMS AND ACRONYMS A. EXAMPLE_MODEL_FOR_MDF

9/14/982©1998 by HL7 & Wes Rishel Sending an HL7 Message

9/14/983©1998 by HL7 & Wes Rishel Describing an HL7 Message Format

9/14/984©1998 by HL7 & Wes Rishel Version 3 Message Definition Process

9/14/985©1998 by HL7 & Wes Rishel Use Case Model

9/14/986©1998 by HL7 & Wes Rishel Use Case Example Decomposition Leaf-level use case is likely event Used to identify candidate classes

9/14/987©1998 by HL7 & Wes Rishel Information Models

9/14/988©1998 by HL7 & Wes Rishel Information Model

9/14/989©1998 by HL7 & Wes Rishel Information Model

9/14/9810©1998 by HL7 & Wes Rishel Reference Information Model Major version 3 deliverable –Subject Areas –Classes –Associations Creates consistent semantics throughout all version 3 projects. Reconciliation is a substantial effort

9/14/9811©1998 by HL7 & Wes Rishel Subject Classes, Application Roles Certain classes are identified as subject classes State transitions are analyzed for subject class State transitions relate to trigger events Application roles are defined with a subject class name and role suffix –Encounter –Encounter <Archivist)

9/14/9812©1998 by HL7 & Wes Rishel Interaction Model

9/14/9813©1998 by HL7 & Wes Rishel Interaction Model

9/14/9814©1998 by HL7 & Wes Rishel Interaction Model Relates –trigger event –sending application role –receiving application role –message format (defined in HMD) Provides the responsibilities of an application role –send XXX interactions –receive XXX interactions

9/14/9815©1998 by HL7 & Wes Rishel Message Object Diagram

9/14/9816©1998 by HL7 & Wes Rishel Message Object Diagram Begin definition of message formats Identifies Objects, as distinct from Classes Example, Person objects in an admission Message –The Person who is the patient –The Person who is the next of kin –The Person who is the admitting physician –The Person who is the attending physician –The Person who is the primary care physician Establishes sequence of objects

9/14/9817©1998 by HL7 & Wes Rishel Message Object Diagram Patient_encounter none Inpatient_encounter Patient_admission Patient C is_preceded_by 1..1 involves 1..1 Individual_HC_practitioner [Prim care phys] is_a_role_of 1..1 has_a_primary_provider 0..1 is_a_role_of 1..1 Stakeholder_identifier [Pt] is_assigned 1..1 Stakeholder[Pt] Person[Pt] Stakeholder [Prim care phys] Person [Prim care phys]

9/14/9818©1998 by HL7 & Wes Rishel Message Information Model (MIM)

9/14/9819©1998 by HL7 & Wes Rishel MIM Walk

9/14/9820©1998 by HL7 & Wes Rishel Message Object Diagram (Close Up) Patient_encounter

9/14/9821©1998 by HL7 & Wes Rishel MIM Walk

9/14/9822©1998 by HL7 & Wes Rishel Message Object Diagram (Close Up) Patient_encounter none Inpatient_encounter C

9/14/9823©1998 by HL7 & Wes Rishel MIM Walk

9/14/9824©1998 by HL7 & Wes Rishel Message Object Diagram (Close Up) Patient_encounter none Inpatient_encounter C Patient_admission is_preceded_by 1..1

9/14/9825©1998 by HL7 & Wes Rishel MIM Walk

9/14/9826©1998 by HL7 & Wes Rishel Message Object Diagram (Close Up) Patient_encounter none Inpatient_encounter Patient_admission C is_preceded_by 1..1 Patient involves 1..1

9/14/9827©1998 by HL7 & Wes Rishel Message Object Diagram (Close Up) Patient_encounter none Inpatient_encounter Patient_admission Patient C is_preceded_by 1..1 involves 1..1 Individual_HC_practitioner [Prim care phys] is_a_role_of 1..1 has_a_primary_provider 0..1 is_a_role_of 1..1 Stakeholder_identifier [Pt] is_assigned 1..1 Stakeholder[Pt] Person[Pt] Stakeholder [Prim care phys] Person [Prim care phys]

9/14/9828©1998 by HL7 & Wes Rishel MIM Walk

9/14/9829©1998 by HL7 & Wes Rishel Message Object Diagram

9/14/9830©1998 by HL7 & Wes Rishel Hierarchical Message Description

9/14/9831©1998 by HL7 & Wes Rishel HMD Has Three Parts Information Model Mapping Message Elements Message Structures Message Format 1 Message Format 2 Person ObjectPSN SegmentYesNo Name attribName data fieldYes-- Object from Message Object Diagram

9/14/9832©1998 by HL7 & Wes Rishel Hierarchical Message Description

9/14/9833©1998 by HL7 & Wes Rishel Rows in HMD Match Fields in Message Not so fast ! What about XML?

9/14/9834©1998 by HL7 & Wes Rishel HMD Describes HL7 Message Contents

9/14/9835©1998 by HL7 & Wes Rishel Conformance Claim...Relied on by a User...Describes the sponsors Information System list of HL7- written statements......Leads to an agreement Offered by a Sponsor...

9/14/9836©1998 by HL7 & Wes Rishel Trigger Events, Interactions, App Roles

9/14/9837©1998 by HL7 & Wes Rishel Certification HL7 Seal of Approval Certification = Testing What do we certify? –That a system passed a test … –… that individually tested one or more conformance claims. In other words … there is no logo that says 100% HL7 Compliant

9/14/9838©1998 by HL7 & Wes Rishel The Change Paradox It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be.... Isaac Asimov (1920–92) Most of us are about as eager to be changed as we were to be born, and go through our changes in a similar state of shock. James Baldwin (1924–87) It is change, continuing change, inevitable change, that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be.... Isaac Asimov (1920–92) Most of us are about as eager to be changed as we were to be born, and go through our changes in a similar state of shock. James Baldwin (1924–87)

9/14/9839©1998 by HL7 & Wes Rishel The Gain (V3 Benefits) Interfaces installed much more quickly –reduce sight-specific negotiations –greatly reduce custom programming –asymptote is plug and play Conformance claims; support for conformance testing Functional adaptation to the changing healthcare system

9/14/9840©1998 by HL7 & Wes Rishel Other Benefits Improved clarity and correctness of specification Appropriate to newer communications paradigms

9/14/9841©1998 by HL7 & Wes Rishel The Pain? Changes to the interface software –subtle, but substantial –segment groups –subsubsubcomponents –recursive types Functional changes to systems –more precise specifications –requirement to use data that is received Retraining

9/14/9842©1998 by HL7 & Wes Rishel Is the Pain worth the Gain? Transition costs –retooling of character-stream based interface software –or, adaptation of object-based approaches, with corresponding benefits –Analyst time to interpret 2.3 transactions and configure interface engines for 3.0 The good news –You have a two-year+ head start

9/14/9843©1998 by HL7 & Wes Rishel Other Observations on Change Change is inevitable... … inevitably slower than anticipated Change for marginal benefit gets overrun by newer change Change begets change

9/14/9844©1998 by HL7 & Wes Rishel The Revolution, um, Evolution of XML eXtended Markup Language Fundamental economic driver is an evolutionary change to the World Wide Web –content-based searching and presentation –management of documents in pieces –indirect links –etc. Compatible upgrade to HTML

9/14/9845©1998 by HL7 & Wes Rishel XML Benefits Will Beget Other Changes Document markup: SGML changes its costume and gets discovered Self-documenting data files –almost self-parsing The begetting happens through –tools, –people, –and hoopla (i.e. the attention of the marketing department)

9/14/9846©1998 by HL7 & Wes Rishel XML and Version 3 The syntax handles recursion Parsers are free Self-documenting data files XML-related tools –viewing –testing –conversion Availability of trained personnel LOTS and LOTS of HOOPLA!

9/14/9847©1998 by HL7 & Wes Rishel Dr. Asimov Revisited No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be.... Design decisions require cautious optimism about change. Five years from now, if V3 does not use XML, people will, at best, be amused by our quaint eccentric ways.

9/14/9848©1998 by HL7 & Wes Rishel Describing an HL7 Message Format

9/14/9849©1998 by HL7 & Wes Rishel Technology Layering in V3 Messaging

9/14/9850©1998 by HL7 & Wes Rishel The Gotchas Not a patch to an existing parser Access to free parsers on legacy operating systems Message sizes substantially larger

9/14/9851©1998 by HL7 & Wes Rishel The Plan Prototype –demo at HIMSS in HL7 booth –multiple systems –mixed version 2 and v3/XML –interface engine Prototype goals: –evaluate methodology –evaluate parsing difficulty/message size –HOOPLA

9/14/9852©1998 by HL7 & Wes Rishel Is it Real? The V3 Effort has already profoundly improved HL7 RIM provides coordinating point for broad array of standards efforts Organizational awareness of enabling technologies Technology-independence seemingly proven by our current work

9/14/9853©1998 by HL7 & Wes Rishel HL7--Not Just Messaging Anymore

9/14/9854©1998 by HL7 & Wes Rishel Implementing Version 3 as Change End user benefits need to be proven Some will derive from RIM improvements currently underway Some will derive from being enabled by new enabling technologies We are now entering the fray!