Presentation is loading. Please wait.

Presentation is loading. Please wait.

HL7 2.X Conformance Tutorial

Similar presentations

Presentation on theme: "HL7 2.X Conformance Tutorial"— Presentation transcript:

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

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

3 Kathy Blyler, Kathryn.Blyler@SMED.COM
Also thanks to Kathy Blyler, Bas van Poppel,

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

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

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

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

8 The solution... V3 V2.X RIM 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) Collective Experience MDF Common Message Type Message Type equivalent Requirements Requirements Message Type Message Profile

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…

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

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.

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

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

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

15 Message Profile Specification

16 Segment Profile Specification
Specification of Field Usage and Cardinality

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. User defined tables For each HL7 user defined table used, define set of valid values By agreement between AWG members, HL7 user defined tables evolve into AWG pre-defined tables Coding Systems For each coded entry (CE) type field used, identify the specific coding system used. Repeat cardinality For repeating fields, define the maximum number of repeats Field Descriptions In cases where HL7 2.2 fields descriptions are unclear or ambiguous, supply a more precise semantic definition.

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

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

20 Clinical Data Repository
Dynamic Interaction Receiver Responsibility MSH-15,16 Critical Care Unit HIS/CIS A/D/T System Accept + App ACK 1. this is not a replacement for the process 2. we will be looking into new tools as they become available! No ACK Clinical Data Repository Accept Ack Order Filling Application

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.

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

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

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

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

26 OID… OID root for Registered Conformance Profiles is: ISO 16 840 HL7 Profile Samples:

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

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

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

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.

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

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

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

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

35 Certification The process by which an application’s 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

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

37 <XML>Considerations </XML>
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)

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

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

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

41 Use Case Analysis UML Use Case Analysis Use Case Models
Language for describing requirements Use Case Analysis Use Case Models Conceptual Interoperability Model Expressed in the user’s terms Information Model

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

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

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

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

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

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

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 Lets start by stating the obvious, looking at the goal from a birds eye view, 3000 feet in the air. The goals The technology is in place the HL7 standard is to discussing Conformance as conformance is becoming a hot topic in most working groups or at least a concern. We just aren’t quite sure what conformance is what it means to be conformant and just how to go about it. Well we hope to change this in this tutorial and in general by encouraging all vendors to profile their messages and register them so that they can be reused. Generally speaking the use of open systems and standards should be encouraged as an accepted norm – not being the value added to a product but the utility of a product is the value added.

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

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 How do we achieve our goals To better communicate To integrate efficiently and cost effectively To use and promote open systems and standards considering the existing infrastructure Documenting messaging which are already in use As we have seen in Ioana’s slide 8 “The Solution” a v3 message = v2.x profile Define XML- XML (eXtensible Markup Language). XML is a new technology that uses Document Type Definition (DTD). The DTD portion of an XML document tells the recipient what kind of information is found in the document. PKI - PKI has been recognized by HIPAA and has been broadly adopted by national healthcare organizations. (encrypted, signed digitally (X.509), using PKI Entrust™ ) HL7 imitates the process of developing v3 messages from HMD At this point we will be talking about HL7 and how it fits into our goals V2.x -> messages + profiles (disambiguates messages) V3.0 -> RIM -> HMD -> messages (initial high level analysis) V2.x as it is now has no formal design process and is not scalable. V2.x implies, indicates, and suggests…..but is not formally documented

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 V2.x as it is now has no formal design process and is not scalable. implies, indicates, and suggests…..but is not formally documented This is the outline of the Specification Tool developed by the Conformance SIG. It has been balloted in the Spring of 2000 and updated / posted to the Conformance section of the HL7 web site. This is considered an informative document. Initially thinking about the data to be exchanged Interactions? User requirements? Challenge comes in with semantics (vocabulary) Profiles encourage the definition of fields Requirements are the basis or starting point for profiles., starting point? what kind of information do I have to send / receive? Send a lot, authority in area i.e. registration (export demographics) Receiving end, what is partner expecting? How do we express requirements? V2.x use cases V3 storyboards By defining use cases we let others know operability therefore we increase the possibility of interoperability

52 Register a Patient ADT^A04
Scenario 40 year old female Diabetes Community hospital Arrives by ambulance Message Description A registration event (ADT^A04) signals that a patient has arrived or checked in but is not assigned a bed. Let’s apply this Specification Tool to the ADT^A04 message. Scenario, natural language. This is one scenario of many, could arrive with a heart condition and the registration system would do the same thing. Person with preexisting condition presents a number of complaints, diagnosis of diabetes and arrives in emerg. There is a protocol which is followed. We don’t yet know if the patient is to be admitted yet we need a minimum amount of information, and tracking of what is to be done with the patient for this visit. Questions: What do other applications need to know? Patient demographics (patient ID, patient name) Next of Kin Admit Vist Info (patient class – in this case its an emergency class) Allergy Info (ID transaction, or Allergy code – referencing some external coding system Who needs to be included in the broadcast? Interested parties could be lab, primary physician, billing. Essentially the trigger event states what happened and this is the information you want to exchange.

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

54 Use Case Model +routes message FiveSight +sends message
+receives message Patient Registration Care Data Intrinsiq A Use Case model represents the functionality of the systems from beginning to end. Here we see how all these actors come together to play their role when registering a patient. Using the XML 2000 demo again we see CDS sending the registration, Five Sight routing the messages, and Intrinsiq and Killdara receiving the messages. Peter what is the difference between system and actor? ADT^A04 Systems +receives message Killdara

55 Use Case Description 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 This may seem very over simplified however this simplicity and clarity distinguishes the beginning and end of a functionality messages So the wording and sequencing is important.

56 Dynamic Interaction AcceptNever, Application Never Sequence Diagram
CDS sending v2.x XML Where necessary translation to ASCII ER7 encoding (pipes and hats), i.e. remote site AccNe AppNe not necessary if there is a reliable/robust transport mechanism, which guarantees message delivery AccAL – i.e. unsolicited acknowledgement message. Signifies that the receiver got the message only. Redundant if using AppAL. AppAL – ORR^O02 order response message, application level Receiver responsibility AcceptNever, Application Never

57 Static Definition Message Level Profile
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 Segment Level Profile PID (1) – Patient Demographics SEQ DT R/O RP/# ITEM# TBL# ELEMENT NAME SI RE SetID – Patient ID CK RE Patient External ID CM R Y Patient Internal ID ST RE Y Alternate Patient ID PN R Patient Name ST RE Mother’s Maiden .. TS RE Date Of Birth ID RE Sex PN RE Y Alias ID RE Race AD RE Y/ Address Field Level Profile Patient Internal ID (00106) Components: <patient ID (NM)> ^ <check digit (NM)> ^ <check digit scheme (ID)> ^ <assigning facility ID (ST)> ^ <type (ID)> Patient Name (00108) Components: <family name> ^ <given name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^ <degree (e.g., MD)> Name is standard format described in Chapter 2, HL7 Standard. Blank * (1 or many) ? (0 or 1) + (0 or many)

58 ADT^A04 XML Conformance Profile produced using the Message Work Bench report XML Spec
<Field Name="Patient ID (Internal ID) " Description="" Optionality="R" Repeatable="Y" Sequence="3" Primitive="T" Datatype="CM" Length="20" QuantLo="1" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field> <Field Name="Alternate Patient ID " Description="" Optionality="NS" Repeatable="N" Sequence="4" Primitive="T" Datatype="ST" Length="12" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Field> <Field Name="Patient Name" Description="" Optionality="R" Repeatable="N" Sequence="5" Primitive="F" Datatype="PN" Length="48" QuantLo="1" QuantHi="0"><Component Name="family name" Description="" Optionality="O" Repeatable="N" Sequence="1" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component> <Component Name="given name" Description="" Optionality="O" Repeatable="N" Sequence="2" Primitive="T" Datatype="ST" Length="0" QuantLo="0" QuantHi="0"> <DataValues ExValue="" ConstantValue="" DBName="" DataSet="" FieldName="" ValueSourceType="ODBC"/> </Component>

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 <!-- PID - Patient Identification section --> <!ELEMENT PID (PID.3+, PID.5, PID.27* )> <!ELEMENT PID.3 (#PCDATA)> <!ELEMENT PID.5 (PID.5.1?, PID.5.2?, PID.5.3?, PID.5.4?, PID.5.5?, PID.5.6? )> <!ELEMENT PID.5.1 (#PCDATA)> <!ELEMENT PID.5.2 (#PCDATA)> <!ELEMENT PID.5.3 (#PCDATA)> <!ELEMENT PID.5.4 (#PCDATA)> <!ELEMENT PID.5.5 (#PCDATA)> <!ELEMENT PID.5.6 (#PCDATA)> <!ELEMENT PID.27 (#PCDATA)> 1 dtd / version Rules and regulations The Conformance Profile will be validated against the Conformance dtd for Registration purposes. This is an excerpt.

60 The Most Common ADT HL7 Message Profiles
ADTA01_AdmitPatient ADTA02_TransferPatient ADTA03_DischargePatient ADTA04_RegisterPatient ADTA05_PreadmitPatient ADTA08_UpdatePatientInfo ADTA11_CancelAdmit See list for ADT fields, common segments, and datatypes.

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

62 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 Model (IM) Message Design Hierarchical Message Descriptions (HMD) Documents Document Types for HL7 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 _address [emlAdr].TYPE XTN } 2-nd Order 1 choice of 0-n Drug 0-1 Nursing <!ENTITY %DT_MPSLOC “,, MPSLOC.addr?, MPSLOC.phon?, MPSLOC.emlAdr?"> data: location_of_action := READ LAST MPSLOC ; ‘ {patient location} This diagram shows the four essential development steps for Version 3 standards, and the application of the resulting models to specific standards. C Code c Code a art b blue c color Reference Model Repository

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?

64 Starting point for Conformance Profiling
Once you have the user requirements, of course! 

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

66 Constraints based on application requirements

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 Profiling process same for V2 or V3 We need the implementation of the standard to meet application requirements not the reverse! Think Ask Research Functional analysis refinement Document Vendors to document profiles Register with HL7 Promote reuse

68 Version 3 vs. Version 2.X V3 V2.X Analysis, Design Collective
i.e RIM Interaction model Collective Experience HMD Message Common Specific overview Common message type in HMD equates to V2 V3 message type more specific, more refined Union message??? disambiguate Profile Profile

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 As we have heard from Ioana’s presentation a conformance statement is: A document describing HL7 overall interoperability charateristecs (overall use case) Message profiles Sooo part of a conformance statement is a message profile Conformance testing – validating of cardinality, min, max, repeating profiles may be reused by vendors with similar needs

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 Efficiency Provides basis for consistent mapping to HL7 messages Provides basis for future mappings Supports linkage to open healthcare standards Disambiguates the message Quality Savings Maintains the integrity of existing systems. We consider the Specification Tool as a Transitional Tool from v2.x – v3

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

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:

73 Q&A

Download ppt "HL7 2.X Conformance Tutorial"

Similar presentations

Ads by Google