HL 7 Introduction to HL 7 Version 3

Скачать презентацию HL 7 Introduction to HL 7 Version 3

eb075f7980be76f4488eafa9f60fe440.ppt

Количество слайдов: 117

Goals of this Tutorial • Overview of Version 3 – What is it? How are the work products built? • Motivation for this new methodology – Why HL 7 needs a new standard and approach • To prepare you for Version 3 activities – Describe the models in Version 3 – Show they are used to develop the HL 7 message specifications that make up the standard? • Introductory information to prepare you for the more detailed tutorials to follow January 24, 2000 © 1999, 2000 Health Level 7 2

Topics Outside of this Tutorial Scope • Does not go into the details of each step (Intermediate and Advanced Tutorials) • Does not teach how to design models • Does not review current models (e. g. , RIM) • Does not cover details of project issues (e. g. , tools, coordination, balloting, etc. ) • Does not explain how to design a software architecture January 24, 2000 © 1999, 2000 Health Level 7 3

Tutorial Outline • Part I - Introduction – HL 7, business problem, and how HL 7 solves it – What is Version 3? – Why HL 7 is making the move to Version 3 • Part II - Technical Concepts – Background information • Part III - Methodology – Modeling process January 24, 2000 © 1999, 2000 Health Level 7 4

What Is HL 7? • The HL 7 organization was founded in 1987 • In June 1994 HL 7 was designated as an ANSI accredited standards development organization (SDO) January 24, 2000 © 1999, 2000 Health Level 7 6

HL 7 Mission Statement • 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. • . . . the complete ‘life cycle’ of a standards specification -- development, adoption, market recognition, utilization and adherence. January 24, 2000 © 1999, 2000 Health Level 7 7

Standard Development Participants M&M Executive Committee Business Strategy & W Motivation hy w? Ho y? Methodology, Measurement, Coordination V 3. 0 n? he W Technical Steering Committee Planning & Enforcement January 24, 2000 © 1999, 2000 Health Level 7 W ha t? Technical Committees Modeling & Voting 8

HL 7 Standard Versions • • 2. 0 (1988) 2. 1 (1990) 2. 2 (1994) 2. 3 (1997) 2. 3. 1 (1999) 2. 4 (2000) 3. 0 January 24, 2000 Prototype First standard Widely Adopted In operation Current ANSI standard In ballot Balloting of Prototype in 2000, balloting of formal specifications in 2001 © 1999, 2000 Health Level 7 9

What does “HL 7” stand for? A domain-specific, common protocol for the exchange of health care information. Function Communication 7 6 5 4 3 2 1 Application Presentation Session Transport Network Data Link Physical ISO-OSI Communication Architecture Model January 24, 2000 © 1999, 2000 Health Level 7 10

Increasing Pace of Business Change Migration Towards a Wellness Model Managing Visit Managing Care Socializ Managing Health ed Medic ine Clinton’s Reform Market R e form Initial Transitional Anticipated Fee-for-service, on-demand Capitated, case -based Preventive, episodal January 24, 2000 Present time © 1999, 2000 Health Level 7 11

Increased IS Complexity Client/Server, Internet, Multimedia Centralized Computing (Batch) Network Computing (RPC, ORBs, etc) IBM Digital Dell Micron HP Enterprise Computing (Client/Server) January 24, 2000 © 1999, 2000 Health Level 7 12

Current Implementation Problems with Version 2. x Complex integration: at least 2 -4 months to install HL 7 interfaces Problem • Honest misunderstanding of specifications Cause • Different implicit information models • Misleading conformance claims • No vocabulary to describe conformance concepts January 24, 2000 © 1999, 2000 Health Level 7 14

Lack of a rigorous documented ies Methodology leadsulto: 7 t c ffi Outcome. . . • Unmeasurable progress e di e HL es of th • Unpredictable results ix th ” o f ering ocess • Metastasizing optionality r ts t ine p p g em -en and att “re on Past V 2 Process n 3 res izati sio qui. ADT/ an er re V t org Finance Patient u Care b Mn. M Orders January 24, 2000 Control/ Query Home Health © 1999, 2000 Health Level 7 15

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 January 24, 2000 © 1999, 2000 Health Level 7 16

Benefits of V 3 to HL 7 • Reduces optionality: results in more specific messages • Uncovers hidden assumptions about application boundaries • Facilitates defining clear, fine-grained, conformance claims HL 7 V 3. 0 Certified January 24, 2000 © 1999, 2000 Health Level 7 17

Benefits of V 3 to Providers Deals with complexity of the HC environment: u Facilitates integration of heterogeneous systems u Increases choices of innovative best-of-breed solutions u Provides support for legacy systems IBM u Allows reliable verification of vendors’ conformance claims January 24, 2000 © 1999, 2000 Health Level 7 18

Benefits of V 3 to Vendors u Provides improved protocol for interconnecting heterogeneous systems u Reduces installation effort – reduces site-specific negotiations – simplifies interface programming u Promotes vendor specialization by allowing segmentation of product lines into niche market spaces January 24, 2000 © 1999, 2000 Health Level 7 19

Version 3 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” January 24, 2000 © 1999, 2000 Health Level 7 20

Approved Statement of Principles • • Explicit Scope, Target Users Support for Legacy Systems Loosely Coupled Systems Internationalization Compatibility with Versions 2. X (limited) Management - ANSI and by-laws Uniform Trigger Event Model Information System Role January 24, 2000 © 1999, 2000 Health Level 7 21

Version 3 Principles (continued) • • • Conformance Claims The Version 3 Development Process Project Scope Version 3 Methodology - MDF Quality Assurance Processes Process Support Confidentiality of Patient Information Authenticated Authorization for Services Security, Privacy, and Integrity January 24, 2000 © 1999, 2000 Health Level 7 22

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 January 24, 2000 © 1999, 2000 Health Level 7 23

Contents of Existing HL 7 V 2. 3 • Trigger events – Actions or occurrences • Messages – Information content • Segments – Repeating structures • Data elements – Data representation January 24, 2000 © 1999, 2000 Health Level 7 25

An HL 7 Version 3. X Spec HL 7 Reference Model Common Specs Chapter. Specific Specs *Future Consideration Use Case Model Information Model January 24, 2000 Interaction Model Message Model 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing © 1999, 2000 Health Level 7 Implementable Message Implementable Specification Implementable Message Specification XML/ER 7/… Specification OLE/CORBA EDIFACT* 26

Version 3 is a change to the HL 7 Architecture • The HL 7 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 to improve the internal consistency of HL 7 provide sound semantic definitions enable future architectures produce an evolution not a revolution Done by applying MODELING to the HL 7 process January 24, 2000 © 1999, 2000 Health Level 7 27

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

HL 7 V 3 Deliverables • Message design model • Use case model – Hierarchy of tasks and actors • Interaction model – Trigger events, abstract messages & application profiles • Information model – Classes, relationships, states, and lifecycles January 24, 2000 – Refined Message Information Model -MIM) – Abstract message definitions (HMDs) (R • Vocabulary – Domain definitions – Representations and mappings • Implementation – Implementation Technology Specification (ITS) © 1999, 2000 Health Level 7 29

Software Engineering Concepts Process: Activities leading to the orderly construction of the models Operation rat n Op e tio Object: Domain specific concept Op ion rat era Abstract representation of a subject n Op e tio era Op Attribute s (Data) An approach to problem solving Model: ion Method: Operation January 24, 2000 © 1999, 2000 Health Level 7 31

Modeling is a Technique for Managing Complexity • Decomposition – Divide-and-conquer • Abstraction – Chunking the information • Hierarchy – Increasing semantic content of individual chunks of information through reuse January 24, 2000 © 1999, 2000 Health Level 7 33

Modeling leads to solutions • Applying analysis techniques leads to solutions to integrate components • Modeling provides the framework for the analysis steps and products • Object Oriented Analysis and Modeling form the basis of the standard techniques adopted for Version 3 January 24, 2000 © 1999, 2000 Health Level 7 34

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 merged • The HL 7 standard message specification will be derived from the models • Models are expressed in UML January 24, 2000 © 1999, 2000 Health Level 7 35

Part III Methodology v Process Overview Ø Model Deliverables and Phases Ø Generation of Messages v Process in Detail Ø Methodology Activities Ø Coordination of Parallel Committee Projects (Harmonization) January 24, 2000 © 1999, 2000 Health Level 7 36

HL 7 and engineering tasks • Analysis – Requirements Analysis – Domain Analysis Use Case Model (UCM) Information Model (RIM & DIM) Vocabulary Domain Specification • Design Interaction Model (IM) – Component and Object Message Information Model (MIM) Interaction Design Hierarchical Message Description – Message Design (HMD) • Voting and Publishing • Implementation Guide – Technology January 24, 2000 Implementation Technology Specification (ITS) © 1999, 2000 Health Level 7 38

V 3 process is documented in the Message Development Framework (MDF) Use Case Model • Captures healthcare requirements • Defines scope for TSC approval • Specifies data and its semantics Information Model • Specifies major state transitions • Specifies vocabulary for domains Interaction Model • Defines information flows • Defines communication roles • Forms basis for conformance claims 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing Message Specification • Defines message contents • Apply constraints to the information model and vocabulary January 24, 2000 © 1999, 2000 Health Level 7 39

Message Development Framework (MDF) • Is a Methodology for building HL 7 models • Is a description for defining HL 7 standard messages • Full instruction book for HL 7 participants • Basis for member training • Five years in development • Continues to evolve as we gain experience January 24, 2000 © 1999, 2000 Health Level 7 40

MDF Model Relationships Analysis Requirements Analysis Domain Analysis Voting Design Interaction Design Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing Use Case Model (UCM) RIM January 24, 2000 Domain Information Model (DIM) Interaction Model (IM) Hierarchical Message Descriptions (HMD) Reference 2000 Health Level 7 © 1999, Model Repository Approval D C C Ballots 41

Models developed in Phases Develop Scope Create Use Cases Identify Actors & Events Information Model Use Case Model Spec UCM Spec DIM Spec Class Diagram State Diagram Use Case Diagram Define Interactions Create Conformance Claims January 24, 2000 Interaction Model Spec Interaction Diagram Model new concepts Harmonize with RIM Define Trigger Events Define Application Roles Draw initial contents from RIM Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing h//mt: 50”d” … … … Develop Message Information Model Develop Message Object Diagram Specify HMD © 1999, 2000 Health Level 7 42

Models are used to build the HMD Reference Information Model Domain Information Model Use Case Model Interaction Model Message Information Model Domain Specification Database Common Message Element Types Hierarchical Message Description January 24, 2000 © 1999, 2000 Health Level 7 43

Requirements Analysis Activities by Phase Define. Scope Define Scope Create Use Cases Identify Actors& Actors & Events Information Model Use Case Model Spec UCM Spec DIM Spec Class Diagram State Diagram Use Case Diagram Define Interactions Create Conformance Claims January 24, 2000 Interaction Model Spec Interaction Diagram Model new concepts Harmonize with RIM Define Trigger Events Define Application Roles Draw initial contents from RIM Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing h//mt: 50”d” … … … Develop Message Information Model Develop Refined MIM Specify HMD © 1999, 2000 Health Level 7 46

Use Case Model: Definitions • Scope statement – A high level use case for the entire project • Use case – Describes specific situations in which communication between healthcare entities is needed • Actor – An entity which initiates or participates in the use case. Discovered in the process of developing use cases • Use Case Diagram – Provides a graphical form to develop the use case model from the business process analysis - UML notation – Makes it easy to show the relationship between use cases • Use cases can be decomposed • Use cases can be shared January 24, 2000 © 1999, 2000 Health Level 7 47

Use Case Definitions (cont’d) • Use Case Path – Single ‘thread’ or ‘storyboard’ or ‘scenario’ – Longitudinal temporal description of a Use Case instance • Support for OO Concepts – Generalizes • adds additional behavior – Includes • uses another use case – Extends • allows branch flow logic in use case execution January 24, 2000 © 1999, 2000 Health Level 7 48

Sample Use Case Model Health Care Enterprise Manage Health Plans Provide Services Manage Health Plans Perform Triage Manage Network Manage Membership Order Service Treat Patient Schedule Service Treat Patient Order Service Administer Procedure Manage Membership Enroll Member Create Order Evaluate Outcomes Discharge Member Sign Order Status Order Record Results Approve Services Manage Network Evaluate Provider Create Appointment Market Services January 24, 2000 Schedule Service Monitor Appointment © 1999, 2000 Health Level 7 49

Use Case Diagram Fragment The individual responsible for managing The inpatient encounter becomes encounter information. active when a patient is admitted. If the encounter has not been previously scheduled, it can be created at the time of admission. January 24, 2000 © 1999, 2000 Health Level 7 50

Domain Analysis Develop Scope Create Use Cases Identify Actors & Events Information Model Use Case Model Spec UCM Spec DIM Spec Class Diagram State Diagram Use Case Diagram Define Interactions Create Conformance Claims January 24, 2000 Interaction Model Spec Interaction Diagram Model new concepts Harmonize with RIM Define Trigger Events Define Application Roles Draw initial contents from RIM Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing h//mt: 50”d” … … … Develop Message Information Model Develop Refined MIM Specify HMD © 1999, 2000 Health Level 7 51

The Information Model • A detailed and precise definition for the information from which all data content of HL 7 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 HL 7 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 all HL 7 messages. January 24, 2000 © 1999, 2000 Health Level 7 52

Parts of the Information Model • Classes, Attributes, and Relationships – Documented in the Reference Information Model, the Domain Information Model, and the Message Information Model – Consistency ensured by a Style Guide • State Transition Models – For certain selected classes (Subject Classes) • Data Types and Constraints – Vocabulary definitions, Domains January 24, 2000 © 1999, 2000 Health Level 7 53

The Reference Information Model (RIM) • Expresses the information content for the collective work of the HL 7 Working Group in UML notation. • A coherent, shared information model that is the source for the data content of all HL 7 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 January 24, 2000 © 1999, 2000 Health Level 7 54

RIM Content • Classes – Have Committees as Stewards – Some identified as Subject Classes • Attributes – Have types constraining their domains • Relationships – Express cardinality for their use in messages • Subject Areas – Define broad areas of interest (eg Stakeholders, Patient_encounters, Master_tables) January 24, 2000 © 1999, 2000 Health Level 7 55

Domain Information Models • Committees and SIGs generally work with a small subset of the RIM • Each subset is focussed on a particular area of group interest; this area is referred to as a DOMAIN (subject domain) • A subset of the RIM expressed using the same tools is known as a Domain Information Model or DIM • The DIMs are completely under committee control - these are committee models January 24, 2000 © 1999, 2000 Health Level 7 56

Committee Vs. HL 7 RIM • What is the RIM? – A HL 7 -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 January 24, 2000 • How will we coordinate these efforts? – Iterative reviews – Harmonization meetings • Who controls the RIM? – The M&M committee • Format, syntax, style • Revision histories – The Technical Steering Committee © 1999, 2000 Health Level 7 • Dispute resolution • Overseer 57

Current 094 RIM Statistics • • • 114 Classes 536 Attributes 159 Association Relationships 27 Inheritance Relationships 2 Aggregation Relationships 37 Subject Areas – 18 Domain, 8 Work-in-Progress, 11 Administrative • Maintained in an Access 97 database, expressed in UML, and annotated with literary and HTML expressions. January 24, 2000 © 1999, 2000 Health Level 7 59

RIM Domain Subject Areas • Stakeholders • Patient_encounters – – Patient Person Stakeholder Healthcare_service_ provider – Organization • Healthcare finances – Patient_billing_account – Healthcare_benefit_plan – Guarantor_contract January 24, 2000 – – – – Pharmacy_service_event Scheduling Patient_service_location Patient_service_order Patient_encounter Patient_service_event Patient_clinical_pathway • Master_tables – Clinical_pathway_master – Service_catalog_item – Observation_service_ catalog_item © 1999, 2000 Health Level 7 60

Model Harmonization Reference Information Model E G (1, 1) (0, M) (0, 1) B (1, 1) (0, M) C A (0, M) (1, 1) B A X (0, M) (1, 1) D B Domain Information Model January 24, 2000 (0, M) (0, 1) B (0, M) C A C (1, 1) (0, M) D Domain Information Model © 1999, 2000 Health Level 7 62

RIM Harmonization Process Change Proposal Preparation Review RIM Change Proposal w/ Stewards Prepare RIM Change Proposal Document Rationale for not supporting RIM change proposal Revise or Withdraw RIM Proposal Notify HL 7 Members of RIM Change Proposal Posting Provide Comment on RIM Change Proposals Post RIM Change Proposals Submit RIM Change Proposal Post RIM Change Proposal Harmonization Meeting Discuss the RIM Change Proposal Revise, withdraw, or Table RIM Change Proposal Vote on RIM Change Proposal Apply Approved Changes to RIM Hold TSC and/or Board Appeals Apply Technical Coorections Finalize Revised RIM Post Harmonization Meeting Review Present RIM Harmonization Report to TSC January 24, 2000 © 1999, 2000 Health Level 7 63

Sources of Models for Harmonization Others Information Model HL 7 Technical Committees Use Case Model Spec DIM Spec Class Diagram State Diagram UCM Spec Use Case Diagram Interaction Model Spec Interaction Diagram 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing HL 7 Member Organizations Other Standard Development Organizations January 24, 2000 © 1999, 2000 Health Level 7 64

Information Model Facilitators • A team of model facilitators was recruited from within the HL 7 working group. • The model facilitators are provided focussed training in the HL 7 modeling methods and tools. • The model facilitators provide modeling assistance to the technical committees and special interest groups. • The facilitators meet as a team at each working group meeting to update each other on progress and to identify modeling or process issues. • The facilitators prepare change proposals for the RIM and attend RIM harmonization meetings. January 24, 2000 © 1999, 2000 Health Level 7 65

Domain Specialists and Data Stewards • The members of the message producing technical committees and message content special interest groups are the domain specialists for the HL 7 RIM. • The technical committees are assigned stewardship responsibility for classes within the information model, based upon their domain expertise. • The technical committee designates a domain specialist from among its members to represent their stewardship interest at RIM harmonization meetings. • Data steward representatives and model facilitators collaborate with each other to prepare RIM change proposals. • Data steward representatives attend RIM harmonization meetings. January 24, 2000 © 1999, 2000 Health Level 7 66

RIM Subject Classes • The Subject Classes are those classes in the RIM that express the concepts that are central to managing healthcare, e. g. Patient, Order. • Subject Classes are the focus for trigger events, use cases & application roles. • State transition modeling of Subject Classes discovers potential trigger events. • Subject Classes capture the domain behaviors that the HL 7 committee feels are most important January 24, 2000 © 1999, 2000 Health Level 7 68

State Transition Modeling • Identify States – From Use Cases • Document States – – Which attributes must be valued/unvalued? What are the constraints on the values? What associations must be established? What associations must not exist? • Capture State Model – UML State Transition Model January 24, 2000 © 1999, 2000 Health Level 7 69

State Transition Diagrams Figure State diagram for Patient class. State diagram for Patient_encounter class Transitions include reference to the trigger event. January 24, 2000 © 1999, 2000 Health Level 7 70

Vocabulary and Domains • Attributes in the RIM must be associated with a Domain to have meaning • Domains are associated with Vocabularies – Held in the Domain Specification Database • The vocabulary and domain define the values that may be taken on by an attribute in a defined message – Set of coded values or defined words/phrases – Statements in a constraint language January 24, 2000 © 1999, 2000 Health Level 7 71

Interaction Design Develop Scope Create Use Cases Identify Actors & Events Information Model Use Case Model Spec UCM Spec DIM Spec Class Diagram State Diagram Use Case Diagram Define Interactions Create Conformance Claims January 24, 2000 Interaction Model Spec Interaction Diagram Model new concepts Harmonize with RIM Define Trigger Events Define Application Roles Draw initial contents from RIM Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing h//mt: 50”d” … … … Develop Message Information Model Develop Refined MIM Specify HMD © 1999, 2000 Health Level 7 72

Modeling Interactions • Derived from the leaf-level Use Cases • Specifies all Trigger Events and Message Flows • Does not define standard system or application functions, only messaging roles • Fine-grained abstraction; every system will claim several roles • Basis for contractual agreement: describes roles to which systems may claim conformance • Potential basis for conformance testing • Captured in an Interaction Diagram and an Application Role Diagram January 24, 2000 © 1999, 2000 Health Level 7 73

Interaction Model Contents • Each Interaction consists of: – Trigger event • Event dependency usually expressed as the state of one or more classes – Message ID • Each interaction sends one particular message – Sender role • When trigger event detected, message is sent – Receiver role • Receiver responsibility - a specific functional responsibility for the receiver to initiate another (consequential) interaction January 24, 2000 © 1999, 2000 Health Level 7 74

Interaction Model Diagram Figure Interactions for Patient subject class. b Interaction Trigger Event causes a Message to be sent by a Sending role to a Receiving role for which there may be a Receiver responsibility January 24, 2000 © 1999, 2000 Health Level 7 Application Role identifies an information management responsibility for one of the subject classes. Responsibilities typically are: Creator, Manager, Tracker and Archivist. Healthcare applications are assumed to take on one or more application roles. 75

Application Roles • All Application Roles that participate in the interactions for a trigger event must be identified • All trigger events that a particular application role participates in must be identified • All Classes that participate in the interactions must be identified • Captured in an Application Role Diagram January 24, 2000 © 1999, 2000 Health Level 7 76

Application Roles and Conformance Claims • A conformance claim is a commitment to fulfill one or more interactions relating to an Application Role • For each Role, the application must send and receive all of the interactions (messages) specified for that Role: – At specified trigger events, obeying specifications about conditionality, required presence, etc. – Upon receipt of certain messages, perform the receiver responsibilities • Provides a consistent, unambiguous vocabulary for pre-contract understanding of vendor capabilities • Grouped into a Conformance Claim Set January 24, 2000 © 1999, 2000 Health Level 7 78

Conformance Claim Structure • Formally defined declarations – Information_system_sponsor, Information_system_user, Healthcare_information_system, Function_point – Trigger_event, Application_role, Interaction, Technical_conformance_claim, Conformance_message_element • Detailed and Explicit – For each Message Element, a conforming application: • Can provide or accept it, requires it for full function, multimedia enabled free text level, message element interaction support, message type definition • Details still being worked out January 24, 2000 © 1999, 2000 Health Level 7 79

Message Design Develop Scope Create Use Cases Identify Actors & Events Information Model Use Case Model Spec UCM Spec DIM Spec Class Diagram State Diagram Use Case Diagram Define Interactions Create Conformance Claims January 24, 2000 Interaction Model Spec Interaction Diagram Model new concepts Harmonize with RIM Define Trigger Events Define Application Roles Draw initial contents from RIM Message Design 2 -nd Order 1 choice of 0 -n Drug 0 -1 Nursing h//mt: 50”d” … … … Develop Message Information Model Develop Refined MIM Specify HMD © 1999, 2000 Health Level 7 80

Message Specification Domain Information Model Reference Information Model Use Case Model Hierarchical Message Description Interaction Model Message Information Model January 24, 2000 © 1999, 2000 Health Level 7 81

Message Specification • The RIM must first be refined by subsetting and constraining it – Create a MIM with RIM classes needed – Develop an R-MIM from these classes • Define the structure for the message – Tree walk the R-MIM (Define a Path) – Identify Message Element Types (MET, CMET) • Document the Message Specification – Create the Heirarchical Message Definition (HMD) • HL 7 Tooling to assist with these steps January 24, 2000 © 1999, 2000 Health Level 7 82

Subset the RIM MIM • Select the portion of the RIM that contains the classes of interest in the message – Classes that participate in the Use Cases as documented in the Use Case Model – Classes that participate in interactions and application roles as documented in the Interaction Model – Attributes of interest in these interactions • Collection of classes with some constraints • Collection of attributes and associations to support the R-MIM • No need for high precision at this point, can be corrected later – this is the first draft stage January 24, 2000 © 1999, 2000 Health Level 7 83

Convert the MIM R-MIM • Constrain cardinality on Associations – May be limited in the interactions for which messages are being designed • Constraints on Attributes – Some may be left out – Sub-components may be individually constrained • Classes are duplicated for different uses • May modify the Inheritance structure – Some specializations may subsume the generalization – Always inherit downwards to specializations • One block for each class structure • Defines patterns of constraints for each class January 24, 2000 © 1999, 2000 Health Level 7 84

Refine and Document R-MIM • Document the R-MIM in tabular form – Identify information not in graphical form • Domains, Update Semantics, Conditionality, etc. • Contains all information needed for the HMD – But the classes are shown in arbitrary order – Usually multiple class instances shown for some RIM classes • Tooling simplifies entire process January 24, 2000 © 1999, 2000 Health Level 7 85

Construct the HMD (defines the METs) • The HMD combines the structure and semantics of the message contents • Produced by performing a tree walk – Select nodes to start each tree based on the Interactions and Use Cases – Follow the appropriate connections in the R-MIM – Re-orders and structures the information in the R-MIM to follow a Path through the Information Model • Note each class instance block in the R-MIM is a MET; the entire table is the full message MET, which is the HMD January 24, 2000 © 1999, 2000 Health Level 7 89

How in the world… • • • How is all of this done? It is not as complicated as it sounds Significant tooling support Rose. Tree permits aided walkthrough of the RIM to generate the MIM and the R-MIM Rose. Tree generates output for set of Excel macros to generate the R-MIM and HMD easily Generates both Graphical and Tabular forms Set of usage guidelines to make Path definition easy Rose. Tree. II Version 20215. exe is most current PC/Windows ONLY January 24, 2000 © 1999, 2000 Health Level 7 90

MET and CMET • Some Message Element Types are unique – Used only for a specific message • e. g. structure for an EKG waveform result • Some Message Element Types may be reused in many messages – – Analogous to v 2. x segments like PID, PV 1, etc. May have finer granularity than v 2. x Have certain constraints loosened for re-use CMETs (Common Message Element Types) January 24, 2000 © 1999, 2000 Health Level 7 91

Build the HMD • All of the information of the MET and CMET is documented in the Hierarchical Message Description – HMD • Tabular • Stored in the repository • Final specification of a particular message • Contains conformance parameters January 24, 2000 © 1999, 2000 Health Level 7 92

The MET Incorporates all previous work and is documented in the HMD Reference Information Model Domain Information Model Use Case Model Interaction Model Message Information Model Domain Specification Database Common Message Element Types Hierarchical Message Description January 24, 2000 © 1999, 2000 Health Level 7 93

V 2. 3 Message Profiles For a specific implementation, the profile specifies: • Which of the optional segments to use • When segments may repeat • Which optional data elements to use for each segment • Which data elements repeat • Which tables (codes) to use January 24, 2000 © 1999, 2000 Health Level 7 94

V 2. 3 Abstract Message - ADT MSH Message Header EVN Event Type PID Patient Identification [PD 1] Additional Demographics [ { NK 1 } ] Next of Kin /Associated Parties PV 1 Patient Visit [ PV 2 ] Patient Visit - Additional Info. … [ { GT 1 } ] Guarantor [ { IN 1 Insurance [ IN 2 ] Insurance Additional Info. [ IN 3 ] Insurance Add'l Info - Cert. } ] … January 24, 2000 © 1999, 2000 Health Level 7 [ ] optional { } may repeat 95

HL 7 2. 3 Segment Definition SEQ - position within segment LEN - length of field DT - data type for field OPT - optionality for field RP/# - repeatability TBL# - table number for codes ITEM# - HL 7 field number ELEMENT NAME - name January 24, 2000 © 1999, 2000 Health Level 7 96

Version 2. 3 - 3. 0 Equivalence • The Version 3 Hierarchical Message Description (HMD) is a structure that combines the Version 2. x – Abstract Message Definition – Segment tables – Message profiles Abstract Message + Segment + Message HMD = tables profiles Definition January 24, 2000 © 1999, 2000 Health Level 7 97

Hierarchical Message Description Information Model Mapping Ties every element of a message directly to a class, attribute or association in the Reference Information Model January 24, 2000 Message Elements Equivalent to populating a V 2. x Abstract Message Definition with each of the relevant Segment tables AND then adding the message profile specification for which segments to use and/or repeat, and which code domains to use. © 1999, 2000 Health Level 7 Message Structure Provides the message profile specifications for the data elements in the message 98

Build the Message Element Section • Built directly from the Tabular R-MIM – Defines a particular PATH through the model • Specify the type of object – Composite, primitive, etc. – Previously defined MET (CMET) • Which type (MET) the element is IN • Which type (MET or datatype) the element is OF January 24, 2000 © 1999, 2000 Health Level 7 100

Finish With Message Structure • Specify the constraints on each element – Cardinality for this message – Domain from which the data field will be drawn • Vocabulary reference, constraint predicate, etc. • Coding strength – – – Mandatory Requirement Default Values Update parameters Conformance Flag Notes and comments January 24, 2000 © 1999, 2000 Health Level 7 102

Implementation Technology Specification • Implementation technology is – A method of encoding and sending HL 7 messages. Version 3 implementation technologies will initially be XML, and will eventually include ER 7, other objectinterfaces, and, perhaps, EDIFACT • Implementation Technology Specification – Describes how HL 7 messages are sent using a specific implementation technology. It includes specifications of the method of encoding the messages, rules for the establishment of connections and transmission timing, procedures for dealing with errors, and it may include a specified application programming interface January 24, 2000 © 1999, 2000 Health Level 7 105

Implementation Technology Specification – The HMD definition of a message/method is technology neutral: it doesn’t specify the form (encoding) of the message, nor the technology used to transport the message – A V 3 goal is to support at least 3 different ITS layers • Character based interfaces – XML Will be the initial technology for v 3. 0 – ER 7, ASN. 1 • Object Broker Technology – CORBA – Active-X/DCOM • Others – EDIFACT is a possibility January 24, 2000 © 1999, 2000 Health Level 7 106

Putting the pieces together Implementation Technology Specification "Send as ASCII string in XML format" Hierarchical Message Definition "Discontinue pharmacy order" ITS for XML Data HL 7 Message Creation Message Instance HL 7 -Conformant Application January 24, 2000 © 1999, 2000 Health Level 7 HL 7 Message Parsing Data HL 7 -Conformant Application 107

An HL 7 V 2. 3 Message MSH|^~&|LABGL 1||DMCRES||199812300100||ORU^R 01|LABGL 1199510221838581|P|2. 3 |||NE|NE PID|||6910828^Y^C 8||Newman^Alfred^E||19720812|M||W|25 Centscheap Ave^^ Whatmeworry^UT^85201^^P||(555)777 -6666|(444)677 -7777||M||773789090 OBR||110801^LABGL|387209373^DMCRES|18768 -2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN 2973^Schadow^Gunther^^^^MD^UPIN |||||^Once||||||CA 20837^Spinosa^John^^^^MD^UPIN OBX||NM|4544 -3^HEMATOCRIT (AUTOMATED)^LN||45||39 -49 ||||F|||199812292128||CA 20837 OBX||NM|789 -8^ERYTHROCYTES COUNT (AUTOMATED)^LN||4. 94|10*12/mm 3 |4. 30 -5. 90||||F|||199812292128||CA 20837 A sample results message January 24, 2000 © 1999, 2000 Health Level 7 108

V 3 XML Prototype - same data Sample George H LABGL 110801 DMCRES 387209373 18768 -2 CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE) 4544 -3 HEMATOCRIT (AUTOMATED) 45 39 -49 199812292128 199812292315 January 24, 2000 © 1999, 2000 Health Level 7 109

So how is all this done? • UML and the Rational Rose toolset is used to capture many models • HL 7 has developed a number of our own tools and templates to assist in the process - ROSETREE • Detailed tools training tutorials are held during WG meetings and harmonization meetings • Mn. M is the overseer of the tools and the process URL to download Tooling: http: //www. hl 7. org/library/data-model/Rose_tooling/rose_index. htm (this includes a text file to describe what each downloadable file is) Or directly: http: //www. hl 7. org/library/data-model/Rose_tooling/Rose. Tree_II. zip January 24, 2000 © 1999, 2000 Health Level 7 110

Tools that are used • Rational Rose 98 (commercial product) – Version 4. 5 or later • Rose. Tree_II* – Current Version 20215 • HL 7 Tools. mdb* – not versioned – useful for working with the repositories • Microsoft Access and Excel (commercial product) – Office ‘ 97 Versions * have help files January 24, 2000 © 1999, 2000 Health Level 7 111

Summary of V 3 Features • Internal consistency - enforced in models • Sound definitions - captured in a repository • Enables variety of implementation technologies – ranging from ASCII to ORBs and EDIFACT to XML • Eliminates rampant optionality in the messages – reduces implementation effort • Application roles are a basis for component functional specifications • Provides verifiable conformance claims January 24, 2000 © 1999, 2000 Health Level 7 112

Credits This innovative approach was developed through significant contributions by the following people (listed alphabetically): • • • Woody Beeler, Mayo Foundation Norman Daoust, Partners Healthcare Gary Dickenson Yakov Golder, Consultant Jack Harrington, Hewlett Packard Stan Huff, IHC Clem Mc. Donald, Regenstreif Institute Ted Klein, c. More Medical Solutions Charlie Mead, Care. Centric Solutions January 24, 2000 • • • Linda Quade, Eli Lilly and Company Larry Reis, Wizdom Systems Wes Rishel, Wes Rishel Consulting Mark Shafarman Oacis Healthcare Systems Gunther Schadow, Regenstreif Institute Rob Seliger, Sentillion Abdul-Malik Shakir, The Huntington Group Mark Tucker, Regenstreif Institute Karen Van Hentenryck, HL 7 Mead Walker, The Huntington Group © 1999, 2000 Health Level 7 113

Bibliography (classics) • Jacobson, I. Et Al, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison. Wesley, Reading, MA, 1994. • Rumbaugh, J. Et Al, Object-Oriented Modeling and Design, Prentice Hall International, Englewood Cliffs, NJ, 1991. • Booch, G. , Object-Oriented Analysis and Design with Applications, 2 nd ed. , The Benjamin/Cummings Publishing Company, Inc. , Redwood City, CA, 1994. January 24, 2000 © 1999, 2000 Health Level 7 114

Bibliography (additional) • White, I. , Using the Booch Method. A Rational Approach, The Benjamin/Cummings Publishing Company, Inc. Redwood City, CA, 1994. • M. Fowler, UML Distilled. Applying the Standard Object Modeling Language, Addison-Wesley, Reading, MA, 1997. • Vaskevitch, D. , Client/Server Strategies, IDG Books, San Mateo, CA, 1993. • Taylor, D. A. , Object-Oriented Technology: A Manager’s Guide, Addison-Wesley, Reading, MA, 1990. • Taylor, D. A. , Business Engineering with Object Technology, John Wiley & Sons, Inc. . New York, NY, 1995. January 24, 2000 © 1999, 2000 Health Level 7 115