1 hl7 2.x conformance tutorial ioana singureanu, eversolve mary ann juurlink, killdara january 2001

HL7 2.X Conformance Tutorial

Ioana Singureanu, Eversolve Mary Ann Juurlink, Killdara

January 2001

Speakers Ioana Singureanu, CEO Eversolveioana@eversolve.com

Mary Ann Juurlink, Healthcare Product Architect, Killdara

juurlink@killdara.com

Also thanks to

Kathy Blyler, Kathryn.Blyler@SMED.COM

Bas van Poppel, bvpoppel@HISCOM.NL

Part 1 : Conformance Concepts

Overview of HL7 2.x Conformance• Conformance Concepts

• Use case derived message profilesIoana Singureanu

Sample Conformance documentationMary Ann Juurlink

Part 2: Hands-on tutorial

• Hands-on message profiling exercise• Real-life scenarios• See the specification and tool in

action !

Part 1 : Conformance Concepts

Overview of HL7 2.x Conformance• Conformance Concepts• Use case derived message

profiles

Ioana Singureanu

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

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)

CommonMessage

MessageType

MessageProfile

Collective Experience

equivalent

V3 V2.X

Requirements Requirements

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…

Glossary…

• Message Profile• Conformant Message Profile • Message profile id • Conformance Statement • Compatibility • Consistency • Registration• Certification• Validation

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.

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

Message Profile = Static Profile + Dynamic Profile

Critical Care Unit

A/D/T System

Initiating MessageResponse Message

Initiating Message

Clinical Data Repository

Conceptual Overview

Static Message Profile

NK1 NK1 NK1 NK1 NK1

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

NK1 NK1 NK1 NK1 NK1

Segments/Segment Groups: - Cardinality (min, max)

Message ProfileHL7 Message Structure

Specification of Min, Max Cardinality

ADT^A01 ADT Message Chapter

MSH 1..1 Message Header 2EVN 1..1 Event Type 3PID 1..1 Patient Identification 3[ { NK1 } ]1..3 Next of Kin 3PV1 1..1 Visit Info 3PV2 1..1 Visit - additional info 3[ { OBX } ]0..0 Observation/Result 7[ { AL1 } ]1..* Allergy Information 3[ { DG1 } ]0..0 Diagnosis Information 6[ { PR1 } ]0..0 Procedures 6[ { GT1 } ]0..0 Guarantor Information 6[ 0..0 { IN1 0..0 Insurance Information 6 [ IN2 ] 0..0 Insurance Information - Addit. Info. 6 [ IN3 ] 0..0 Insurance Information - Cert. 6 }][ ACC ] 0..0 Accident Information 6[ UB1 ] 0..0 Universal Bill Information 6[ UB2 ] 0..0 Universal Bill 92 Information 6

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

Segment Profile Specification

SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME

1 4 SI X 00104 Set ID - Patient ID

2 16 CK RE 00105 Patient External ID

3 20 CM R Y 00106 Patient Internal ID

4 12 ST X Y 00107 Alternate Patient ID

5 48 PN R 00108 Patient Name

6 30 ST RE 00109 Mother's Maiden Name

7 26 TS RE 00110 Date of Birth

8 1 ID RE 0001 00111 Sex

9 48 PN X Y 00112 Alias

10 1 ID X 0005 00113 Race

11 106 AD RE Y/3 00114 Address

12 4 ID X 00115 County Code

13 40 TN X Y/3 00116 Home Phone Number

14 40 TN X Y/3 00117 Business Phone Number

15 25 ST X 00118 Primary Language

16 1 ID X 0002 00119 Marital Status

17 3 ID X 0006 00120 Religion

18 20 CK X 00121 Patient Account Number

19 16 ST RE 00122 SSN Number - Patient

20 25 CM X 00123 Driver's Lic Num - Patient

21 20 CK X 00124 Mother's Identifier

22 1 ID X 0189 00125 Ethnic Group

23 25 ST RE 00126 Birth Place

Specification of Field Usage and Cardinality

1.1.1 OBX-8 Abnormal flags (ID) 00576Definition: This field is used to indicate the normalcy status of the result.

This field will be specified with a repeat count of three (3). The first repetition willspecify the abnormal flag. The second repetition will specify the delta flag. The thirdrepetition will specify the microbial susceptibilities.

Values from HL7 table #0078:

- abnormal flags alpha {N,A,AA,CNM} numeric {L,H,LL,HH,CNM,<,>}

- delta flags alpha {B,W} numeric {U,D}

- microbial susceptibility flags {S,R,I,MS,VS}

Only the most extreme flag for each repetition of the field should be specified.

Note that the value “CNM” (Could Not Measure) has been added to HL7 table #0078.

Field/Component Profile Specification

• Field Descriptions– In cases where HL7 2.x

fields descriptions are unclear or ambiguous, supply a more precise semantic definition.

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-3166 - Alpha-3

PID-26 Citizenship (ID) 00129Definition: indicates the patient's country of citizenship. Refer to user-defined table 0171 -country code for suggested values or to ISO 3166.

This vendor profile specification uses ISO 3166 Alpha-3 codes.

Message Profile Hierarchy

NULL (0)

NULL (0) DEVICE(2)

A01(1)

v2_2(4)Version

static-profile(1)

ADT(3)

O01(92)A02 (2)

1(1) 1(1)

NEW(1)

1(1) 1(1)

CANCEL(4)...

DIAG(1)

ORM(21)

NULL (0)

NULL (0) NEW(1)

1(1) 1(1)

CANCEL(4) ...

DIET(2) ...

ORU(23)

R01(112)

NULL (0)

LAB(1)

1(1) 1(1)

Profile Type

Message Type

Trigger Event

Structure

Use Model

Data Version

Registration Authority HL7(1)

Organization HL7(1)

Dynamic Interaction

Vectra

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Critical Care Unit HIS/CIS

Vectra

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFF

BED 1 OFFBED 1 OFF

Clinical Data Repository

A/D/T System

Order Filling Application

Accept AckAccept Ack

Accept + App ACKAccept + App ACK

Receiver ResponsibilityMSH-15,16

No ACKNo ACK

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.

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

Patient Management

Admission Transfer Discharge

Sender

Receivers

RadiologySystem

OncologySystem

HISSystem

{1 1 3 .. 3 1} {1 1 3 .. 5 1} {1 1 3 .. 7 1}

Application Use Case

Message Profile

Sample Application Use Case

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

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

OID…

OID root for Registered Conformance Profiles is: OID root for Registered Conformance Profiles is: 2.16.840.1.113883.9. 2.16.840.1.113883.9.

• 2 ISO• 16• 840• 113883 HL7• 9 Profile • Samples:

2.16.840.1.113883.9.12.16.840.1.113883.9.22.16.840.1.113883.9.32.16.840.1.113883.9.4 …

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

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

{1 1 3 .. 3 0}

Oncology System

Use Case Model

Radiology System

Use Case Model

{1 1 3 .. 3 1}

Message Profile Registry

{1 1 3 .. 7 2}

{1 1 3 .. 4 1}

{1 1 3 .. 5 1}

{1 1 3 .. 6 1}

{1 1 3 .. 7 1}

{1 1 3 .. 8 1}

ASN.1 identifiers

Reference to…

Application Conformance Statement

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.

Hospital Registration System (producer)

Radiology system (receiver)

Nursing System(receiver)

Oncology system (receiver)

ADT Message Profile Compatibility Example

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

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

Registration

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

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

Verification

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

<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)

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

• Chaos -> order

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

• Version 3– At the core of the

Message Development Process

– Chapter 8 of MDF– Implementation

Overview of HL7 2.x Conformance

• Conformance Concepts

• Use case derived message profiles

• Sample Conformance documentation

Use Case Analysis

• UML– Language for describing requirements

• Use Case Analysis• Use Case Models• Conceptual Interoperability Model

– Expressed in the user’s terms

• Information Model

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

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

Site Message Profiles

• Supports specific needs • Required of third-party application

vendors • RFP• Simplifies introduction/acquisition

of new applications

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

Domain Use Case

Profiled App

Sends------------------------