Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 HL7 2.X Conformance Tutorial Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara January 2001.

Similar presentations

Presentation on theme: "1 HL7 2.X Conformance Tutorial Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara January 2001."— Presentation transcript:


2 1 HL7 2.X Conformance Tutorial Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara January 2001

3 2 Speakers Ioana Singureanu, CEO Eversolve Mary Ann Juurlink, Healthcare Product Architect, Killdara

4 3 Also thanks to Kathy Blyler, Bas van Poppel,

5 4 Part 1 : Conformance Concepts Overview of HL7 2.x Conformance Conformance Concepts Use case derived message profiles Ioana Singureanu Sample Conformance documentation Mary Ann Juurlink

6 5 Part 2: Hands-on tutorial Hands-on message profiling exercise Real-life scenarios See the specification and tool in action !

7 6 Part 1 : Conformance Concepts Overview of HL7 2.x Conformance Conformance Concepts Use case derived message profiles Ioana Singureanu

8 7 The problem... Interoperability standard for clinical application – uptake … The standard combines the collective experience of many vendors Multiple business requirement sets combined but not enough specificity for any given implementation: optionality. Optional message elements had encouraged standard uptake but created difficulties in establishing standard conformance Z-segments, Z-triggers, optional fields and segments are all allowed by the standard. LACK OF UNIFORM SEMANTICS

9 8 The solution... Add specificity to existing messages and identify the specific scenarios/use cases Identify, document, and bridge semantic differences Eliminate optionality (implementable) UML- Unified Methodology Language (just like V3) RIM Common Message Type Message Type Message Type Message Profile Collective Experience equivalent V3 V2.X MDF Requirements

10 9 Conformance SIG HL7 Conformance has two objectives: –Interoperability Implementable message profiles –Certification Conformance Statement Informative Documentation –Specification for Message Profile Content Tutorial - education You are invited…

11 10 Glossary… Message Profile Conformant Message Profile Message profile id Conformance Statement Compatibility Consistency Registration Certification Validation

12 11 Message Profile Message specification indicating a precise, unambiguous use of message constructs (segments, fields, data types) for exchanging information based on a messaging standard. A message specification where optional are disallowed and repeatable constructs will be bound by maximum cardinality specifications. developed by vendors to describe their applications interoperability developed by healthcare providers to describe their interoperability needs.

13 12 Message Profiles specify… Use Case Model (UML) and Vocabulary (field semantics, code sets, user- defined value sets) Static message profile –Message,segment, field, data type Dynamic interaction –Initiating message, response message

14 13 Message Profile = Static Profile + Dynamic Profile Critical Care Unit A/D/T System Initiating Message Response Message Initiating Message Clinical Data Repository Conceptual Overview

15 14 Static Message Profile... MSH EVN PID NK1 PV1 PV2 OBX AL1 ADT^A01... HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1) Fields/Components: - Field Usage (Optionality) (R, RE, C, CE, X) - Cardinality (max repeats) - Value Sets/Coding system - Descriptions... MSH EVN PID NK1 PV1 PV2 OBX AL1 Segments/Segment Groups: - Cardinality (min, max) Message Profile HL7 Message Structure

16 15 Message Profile Specification HL7(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)

17 16 Segment Profile Specification Specification of Field Usage and Cardinality

18 17 Field/Component Profile Specification Field Descriptions –In cases where HL7 2.x fields descriptions are unclear or ambiguous, supply a more precise semantic definition.

19 18 Field/Component Profile Specification Vendor defined tables: –HL7 2.2 definition of PID-26 refers to Table #0171 which is undefined –HL7 suggests using ISO-3166 –ISO 3166 has 3 different coding schemes - Alpha-2, Alpha-3, Numeric –A vendor/provider may choose ISO Alpha-3

20 19 Message Profile Hierarchy NULL (0) DEVICE(2) A01(1) v2_2(4) Version static-profile(1) ADT(3) O01(92)A02 (2) 1(1) NEW(1) 1(1) CANCEL(4)... DIAG(1) ORM(21) NULL (0) NEW(1) 1(1) CANCEL(4)... DIET(2)... ORU(23) R01(112) NULL (0) LAB(1) 1(1) Profile Type Message Type Trigger Event Structure Use Model Data Version Registration Authority HL7(1) Organization HL7(1)

21 20 Dynamic Interaction Critical Care Unit HIS/CIS Clinical Data Repository A/D/T System Order Filling Application Accept Ack Accept + App ACK Receiver Responsibility MSH-15,16 No ACK

22 21 Message Profile Summary Well-defined process for developing Message Profiles. A Message Profile is a pre-negotiated agreement: –Static (data contents) –Dynamic (application interaction) Registered by a unique identifier.

23 22 Message Profiles are used for… Describing the content of inbound and outbound interfaces –Conformance statement Certifying conformance Validating messages Simplifying interoperability –Not plug-and-play but… close

24 23 Patient Management Admission Transfer Discharge Sender Receivers Radiology System Oncology System HIS System { } { } { } Application Use Case Message Profile Sample Application Use Case

25 24 Message Profiles are HL7 Conformant A message profile which meets the HL7 standard requirements: all the required segments and fields are specified and all fields are using the appropriated HL7 data types as specified in the Chapter 2 of the HL7 standard Only conformant profiles will be registered

26 25 HL7 Message Profile Identification A unique identifier is assigned to a message profile submitted by a vendor or a healthcare provider Assigned when the profile is registered with HL7 (Registration tool) ASN.1 Generated by the message profile registration tool (HL7 provided to members) Unique – OID – ASN.1 (American Symbolic Notation) Object Identifier Conformance SIG

27 26 OID… OID root for Registered Conformance Profiles is: ISO HL7 9 Profile Samples: …

28 27 Purpose of OID Unique identifier Registration –For cataloging message profiles registered by HL7 Used to specify the conformance statement of an application –References to OIDs

29 28 Conformance Statement A document describing the HL7 interoperability characteristics as a use case model (UML) of an application and the message profiles implemented by that application. Describes overall interoperability requirements along with the message profiles. Basis for compliance certification

30 29 { } Oncology System Conformance Statement Use Case Model Radiology System Conformance Statement Use Case Model { } Message Profile Registry { } { } { } { } { } { } ASN.1 identifiers Reference to… Application Conformance Statement

31 30 Compatibility Relationship between an outbound and an inbound message profile such that, despite differences, they can interoperate Outbound message profile will be richer in content than an inbound profile.

32 31 Hospital Registration System (producer) Radiology system (receiver) Nursing System (receiver) Oncology system (receiver) ADT Message Profile Compatibility Example

33 32 Consistency Characteristic of all message profile specifications registered with HL7. –XML documents following a pre-defined DTD Consistent documentation of message profiles will ensure that vendors and providers will be able to easily integrate applications. Encourages reuse, comparison, differences –Simplifies interoperability

34 33 Application Role The set of messages (message types) an application can send or received as part of its operation. Applications with similar interoperability needs are expected to use the same application profile. – Part of HL7 Version 3

35 34 Registration A conformant message profile document will be registered with HL7 and be granted a unique message profile identifier.

36 35 Certification The process by which an applications conformance claim in verified against the actual application implementation. Certification is a very important part of conformance Conducted by providers, national or regional health organizations –Not conducted by HL7

37 36 Verification The process by which a message instance (one message) is verified against the message profile on which it is based.

38 37 Considerations XML Message –It represents an XML document and it contains data and meta-data (tags) as described by its schema/DTD. XML DTD/Schema –Contains the rules (structure, content, data types, cardinality) for constructing and validating an XML document. Message = document Version 2.XML specification from XML Sig (informative -> normative)

39 38 Conformance Benefits Consistent documentation Reuse of specification –Convergence on use cases Lower cost of integration –Tool for comparing specifications Similar to Version 3 –Conformance SIG is developing Implementation guide Chaos -> order

40 39 Conformance Support in the HL7 Standard Version 2.4, 2.5 –MSH:21 –Profile identifier –OID data type for ASN.1 identifiers –Conformance Chapter –Implementation Guide Version 3 –At the core of the Message Development Process –Chapter 8 of MDF –Implementation Guide

41 40 Overview of HL7 2.x Conformance Conformance Concepts Use case derived message profiles Sample Conformance documentation

42 41 Use Case Analysis UML –Language for describing requirements Use Case Analysis Use Case Models Conceptual Interoperability Model –Expressed in the users terms Information Model

43 42 Use Case derived Message Profiles Specification for Message Profile Content –See the HL7 web site Use cases, static profile, dynamic specification, profile identifiers Allows clinical site and application vendors to specify their standard conformance XML DTD/schemas for describing profiles –Profiling tool

44 43 Vendor Message Profiles Conformance Statements Contract between vendor and customers –It will enable clinical sites to make better purchasing decisions and clearly evaluate the capabilities of various software products. Unambiguous, registered, backed by design and analysis

45 44 Site Message Profiles Supports specific needs Required of third-party application vendors RFP Simplifies introduction/acquisition of new applications

46 45 HL7 Registry of Profiles Search/browse Unique profile identifiers Consistent Profile Documentation DTD/Schema representation of the profile Indicates who is using a profile Version 3 application roles

47 46 Domain Use Case Profiled App Role1 Sends Receives Role1 Sends Receives Role1 Sends Receives Role1 Sends Receives Sends Receives Application Profile Leaf-level Use Cases Analogous to V2.x Profiling Static Message Structures Interaction Model Use Case Model Version 3 Deliverables (for a given domain) HMD Version 3 Conformance (for a given application) Actors

48 47 Overview of HL7 2.x Conformance Conformance Concepts Use case derived message profiles Ioana Singureanu Sample Conformance documentation Mary Ann Juurlink

49 48 The Goal To enable healthcare organizations to better communicate with their partners by sharing data electronically To facilitate Healthcare integration efficiently and cost effectively To use and promote open systems and standards

50 49 Hospital Registration System Clinical information system support messaging (VPN) no support for secure communication (Internet) Remote Lab system Remote Physicians Office cannot send/receive messages easily Existing Infrastructure

51 50 How do we achieve the goal? By developing profiles for applications By encouraging vendors to create their own profiles and register them with HL7 By creating a transition path (V2.x -> V3.0) based on conformance profile development

52 51 Message Profiling Specification Use case model Vocabulary –Coding –Value sets –Field semantics Static Definition of an HL7 v2.x message –Message Level Profile –Segment Level Profile –Field Level Profile Dynamic Definition of HL7 v2.x message –Interaction Model

53 52 Message Description A registration event (ADT^A04) signals that a patient has arrived or checked in but is not assigned a bed. Scenario 40 year old female Diabetes Community hospital Arrives by ambulance Register a Patient ADT^A04

54 53 Hospital registration System Is responsible for notifying all appropriate systems Remote Lab System Receives the messages and sends results Remote Physicians Office Receives the message Use Case Actors

55 54 Use Case Model Care Data Systems Killdara Intrinsiq Patient Registration ADT^A04 +sends message +receives message FiveSight +routes message

56 55 Preconditions The patient is ready for clinical attention and demographic information is supplied Flow of events The patient is registered and the appropriate system is notified Post Conditions The appropriate system has been notified Use Case Description

57 56 Dynamic Interaction 1.Sequence Diagram 2.Receiver responsibility AcceptNever, Application Never

58 57 Static Definition ADT^A04 Cardinality Message Description MSH [1,1] Message Header EVN [1,1] Event Type PID[1,1] Patient Demographics [{ NK1 }] [0,+] Next of Kin PV1 [1,1] Admit Visit Info PV2 [1,1] More Admit Visit Info [{ AL1 }] [0,+] Allergy Info 2.Segment Level Profile PID (1) – Patient Demographics SEQ DT R/O RP/# ITEM# TBL# ELEMENT NAME 1 SI RE SetID – Patient ID 2 CK RE Patient External ID 3 CM R Y00106 Patient Internal ID 4 ST RE Y Alternate Patient ID 5 PN R Patient Name 6 ST RE00109 Mothers Maiden.. 7 TS RE00110 Date Of Birth 8 ID RE Sex 9 PN RE Y Alias 10 ID RE Race 11 AD RE Y/ Address Patient Internal ID (00106) Components: ^ ^ ^ ^ Patient Name (00108) Components: ^ ^ ^ ^ ^ Name is standard format described in Chapter 2, HL7 Standard. 1.Message Level Profile 3.Field Level Profile

59 58 ADT^A04 XML Conformance Profile produced using the Message Work Bench report XML Spec

60 59 HL7 Conformance Profile DTD V2.X This is the result of associating the dtd with the ADT^A04 Conformance Profile All profiles registering with HL7 must be validated against this dtd One dtd per version

61 60 ADTA01_AdmitPatient ADTA02_TransferPatient ADTA03_DischargePatient ADTA04_RegisterPatient ADTA05_PreadmitPatient ADTA08_UpdatePatientInfo ADTA11_CancelAdmit The Most Common ADT HL7 Message Profiles

62 61 ORMO01_NewDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderAccepted ORRO02_UnableToAcceptDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelled ORMO01_CancelDiagnosticStudyOrder ORRO02_DiagnosticStudyOrderCancelledAsRequested ORRO02_UnableToCancelDiagnosticStudyOrder The Most Common Order/Result HL7 Message Profiles

63 62 Reference Model Repository RequirementsAnalysis Use Case Model(UCM)RequirementsAnalysis Model(UCM)DomainAnalysis Information Model & Vocabulary (RIM)DomainAnalysis (RIM) AnalysisAnalysisDesignDesign InteractionDesignInteractionModel(IM)InteractionDesignInteractionModel(IM)MessageDesign Hierarchical Message Descriptions (HMD)MessageDesign (HMD) ApplicationApplication 2-nd Order 1 choice of 1 choice of 0-n Drug 0-n Drug 0-1 Nursing 0-1 Nursing 2-nd Order 1 choice of 1 choice of 0-n Drug 0-n Drug 0-1 Nursing 0-1 Nursing Medical logic Variable definition for Arden syntax (AVD) Medical logic Variable definition for Arden syntax (AVD) data: location_of_action := READ LAST MPSLOC ; {patient location} {patient location} data: location_of_action := READ LAST MPSLOC ; {patient location} {patient location} Documents Document Types for HL7 PRA (DTD)Documents (DTD) Messaging Message Types for use with XML, ER7, etc (MET)Messaging Message Types for use with XML, ER7, etc (MET) TYPE MPSLOC CONTAINS { id[id].TYPE IID nm[name].TYPE ST ad[addr].TYPE XAD ph[phon].TYPE XTN _address [emlAdr].TYPE XTN } TYPE MPSLOC CONTAINS { id[id].TYPE IID nm[name].TYPE ST ad[addr].TYPE XAD ph[phon].TYPE XTN _address [emlAdr].TYPE XTN } C Code c Code a art b blue c color HL7 V3 Message Development Lifecycle

64 63 Deliverables Some form of the Technical Committee Documentation Template Domain interaction model Leaf level interaction model Common message types (HMD) So now what do we do with all of this? How to we apply our specific user requirement?

65 64 Starting point for Conformance Profiling

66 65 Hierarchical Message Definition Information Model Mapping Classes and attributes of the R-MIM, describes a walk through. Message Element Describes elements and types, set up as a hierarchy General constraints Describes specific constraints for the message element defined in the row

67 66 Constraints based on application requirements

68 67 Message Profiling Specification for Version 3 Use case model Vocabulary –Coding –Value sets –Field semantics Static Definition of an HL7 V3 message –Message Level Profile –Segment Level Profile –Field Level Profile Dynamic Definition of HL7 3 message –Interaction Model – application role

69 68 Version 3 vs. Version 2.X Analysis, Design i.e RIM Interaction model Message Profile Collective Experience V3 V2.X disambiguate Common Specific HMD Profile

70 69 Benefits of Message Profiling Conformance statement Describes a standard implementation by coupling events, data elements and messages Improves clarity and precision Profiles may be registered with HL7 Approaches plug and play Conformance testing Messages can be validated against the message profile

71 70 ROI Benefits of Hl7 Conformance Reduces the overhead of integrating applications EFFICIENCY Able to meet the needs of the clinicians for access to information, when and where they need it QUALITY OF COMMUNICATION Clinical sites can evolve yet maintain their infrastructure SAVINGS

72 71 Conformance Tool Available! The Messaging Workbench tool is available free of charge It is open source It is supported within the VA for the foreseeable future

73 72 Contacts We in the Conformance sig are interested in your feedback and suggestions for improvement of the tool The Conformance sig list server is a good source for general information For conformance tool information:

74 73 Q&A

Download ppt "1 HL7 2.X Conformance Tutorial Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara January 2001."

Similar presentations

Ads by Google