Version 2 Messaging Conformance Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois Abdul-Malik Shakir Principal Consultant, Shakir.

Version 2 Messaging ConformanceVersion 2 Messaging ConformanceHL7 Educational Summit

Chicago, Illinois

Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting

July 2005

March 2005 V2 Messaging Conformance 2 of 122

My HL7 Background

Abdul-Malik ShakirPrincipal Consultant, Shakir Consulting, La Verne, CA

HL7 Member since 1991

• Three-term Member of the HL7 Board of Directors

• Co-Chair of the Board Education and Implementation Committees

• Member of the Board Architectural Review Board

• Member of the Board Process Improvement Committee

• Co-Chair of the Modeling & Methodology Technical Committee


Session Outline

Part I

• Background

HL7: What, and Why

Message Profile: Why and When

• Message Profiles:

What and How

Concepts and Constituents

Levels and Examples

Part II

• Messaging Workbench

What and Why

Features and Use

Reports and Examples

Contacts and Help

• CADHS ELR Project

Project Scope

Message Profiles


Health Level SevenWhat and Why


An HL7 Messaging Scenario: Why

User InterfaceUser InterfaceProgram

Module

ProgramModuleDataset

Dataset

User InterfaceUser Interface Program

Module

ProgramModule Dataset

Dataset

Message Creation

Message Creation

Message Parsing

Message Parsing

A to BTransformation

A to BTransformation

Message Parsing

Message Parsing

Message Creation

Message Creation

B to ATransformation

B to ATransformation

Order Entry Application

System

Laboratory Application

System

Lab

Ord

er

Tr a

ns a

ctio

nOrder Entry Application

System

Laboratory Application

System

Lab

Res

ult

T

ran

sact

ion


Reaching the Limits of Application Interfaces

LabLab

Order EntryOrder Entry ADTADT

PharmacyPharmacy RadiologyRadiology

DecisionSupport

DecisionSupport

ElectronicHealth Record

ElectronicHealth Record

AdministrativeSystems

AdministrativeSystems

?

EnterpriseSystems

EnterpriseSystems

?ExternalSystems

ExternalSystems

?


Health Level Seven: Why

• The number of interfaces between N systems is given by the formula (N2-N)/2.

• Linking 2 systems only needs 1 interface, (22 – 2) / 2 = 1;

• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15

• The benefits of using the HL7 standard increase rapidly with the number of systems involved.


Abstract Message Specification

MSH Message Header

EVN Event Type

PIDPatient Identification

[PD1] Additional Demographics

[ { NK1 } ] Next of Kin /Associated Parties

PV1 Patient Visit

[ PV2 ] Patient Visit - Additional Info.

…

[ { GT1 } ] Guarantor

[

{ IN1 Insurance

[ IN2 ] Insurance Additional Info.

[ IN3 ] Insurance Add'l Info - Cert.

}

]

…

[ ] optional

{ } may repeat

Segment ID Segment Name


MSH Segment Definition


MSH 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# - HL7 element number

ELEMENT NAME - name


Sample HL7 v2.x Message

Segments

• MSH: Message Header

• PID: Patient Identification

• OBR: Observation Request

• OBX: Observation Result

MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3|||NE|NE

PID|||6910828^Y^C8||NewmanÂlfredÊ||19720812|M||W|25 Centscheap Ave^^WhatmeworryÛT^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|||||||IN2973^Schadow^Gunther^^^^MDÛPIN||||||||||Ônce||||||CA20837^Spinosa^John^^^^MDÛPIN

OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49||||F|||199812292128||CA20837

OBX||NM|789-8ÊRYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3|4.30-5.90||||F|||199812292128||CA20837

Delimiters

| Field

^ Component

& Subcomponent

~ Repetition

\ Escape Character


Message ProfilesWhy and When


Revealing assumptions is an essential component of effective communication.

Yes, I doplay

football.

Do youplay

football?

Reveal Assumptions


Message Profiles are an effective means of documenting our assumptionsabout message structures

Yes, Iuse HL7.

Do you use

HL7?

Reveal Assumptions

MSHEVNPID [PD1][ { NK1 } ]

MSHEVNPID[ NK1 ]OBX


Message Profiles provide a language that allows us to unambiguously express our understanding and assumptions about the information in a

message structure used in a particular scenario

Reduce Ambiguity



Sharing message profiles provides an opportunity to identify and reconcile conflicts in our understanding

and to validate our assumptions about message structures.

Highlight Conflicts


MSHEVNPID[ NK1 ]OBX


Consolidate Viewpoints

Message Profile Message Profile Message Profile


MSHEVNPID[ NK1 ]OBX

MSHEVN{ PID } [PD1][ { GT1 } ]

MSHEVN{ PID } [PD1][ { NK1 } ][ { GT1 } ][ OBX ]

Canonical Message Profile


Value of Message Profiling

• Reveal Assumptions

• Reduce Ambiguity

• Highlight Conflicts

• Consolidate Viewpoints


Compliance and Conformance

• Compliance

Messages that adhere to the rules and conventions for constructing of a specific version of a standard are compliant to that version of the standard.

• Conformance

Messages that adhere to the constraints of a precise and unambiguous specification called a message profile are said to be conformant to the profile.

ComplianceCompliance ConformanceConformance


Conformance Project Background

• Began in 1997 by the HL7 Conformance SIG

• The SIG, in conjunction with the Andover Working Group (AWG), prepared this specification to:

Define the HL7 Message Profile

Recommend a specification for defining specific message profiles of HL7 messages

Facilitate HL7 interpretation by users familiar with the HL7 standard, reducing interface analysis time and dissatisfaction with the HL7 standard


Conformance SIG

• HL7 Conformance has two objectives: Interoperability

• Implementable message profiles

Certification• Conformance Statement

• Normative Documentation Chapter 2

Message Profile Schema/DTD

• Tutorial - education

• You are invited to participate! Bi-weekly calls

List server


Message ProfilesWhat and How


Message Profile Defined

• Unambiguous specification of a standard HL7 message for use within a particular set of requirements

Prescribes a set of precise constraints upon one or more standard messages

Supported by use case analysis and interaction modeling

• Measurable

What data will be passed in a message

The format in which the data will be passed

The acknowledgement responsibilities of the sender and receiver


Message Profile Defined (continued)

• Based on HL7, although may further constrain Static structure and content of each message

The dynamic interactions

• Parts of a valid message profile Use Case Model

Static Definition

Dynamic Definition

• Represented as an XML document Can be registered with HL7

May be reused by other HL7 users

May be used for documentation


Conceptual Overview

Message Profile = Static Profile + Dynamic Profile

Critical Care Unit

ADT System

Initiating MessageResponse Message

Initiating Message

Clinical Data Repository


Use Case Model

• Documents the scope and requirements for an HL7 Message Profile or set of Message Profiles

May include a use case diagram or detailed text

Provides a name that clearly and concisely defines the exchange

Defines the actors, including the sending and receiving applications

Defines the responsibilities of these actors

Documents the situations in which the exchange of a particular HL7 Message Profile is required

Documents the purpose

• V3.0 Message Development Framework (MDF 99)


Static Definition

• A specification for a message structure intended to support the use case

• Based on a message defined in HL7 Std

• Defined at the message, segment, and field levels

Follows the HL7 rules (chapter 2)

May further constrain

• Identifies only those specific elements used in the exchange

• Removes all instances of optionality, defining explicitly

• Segments, segment groups, fields and components usage rules

• Cardinalities

• Value sets and coding systems

• Implementation notes


Static Definition Example

...

...

...

NK1

MSH

EVN

PID

NK1 NK1 NK1 NK1

PV1

PV2

OBX

AL1

HL7 Message Structure

...

NK1

MSH

EVN

PID

NK1 NK1 NK1 NK1

PV1

PV2

OBX

AL1

Message Profile

Segments/Segment Groups:•Usage (Optionality) •Cardinality (min, max)

Fields/Components: - Usage (Optionality) - Cardinality (min, max) - Value Sets/Coding system - Descriptions


Dynamic Definition

• Defines interaction between the sender and receiver Acknowledgment mode supported

Conditions under which an accept and/or application level acknowledgment is expected

• Always

• Never

• Only on success

• Only on error

• Interaction Model Defines specific interactions between the applications that support message

profile communication requirements

Includes interaction diagrams that illustrate the sequence of trigger event and resulting message flows between the sending and receiving applications

• Dynamic can refer one to many static definitions


Dynamic Interaction

Vectra

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

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

XU

5/90C

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF

POTASSIUM 3.5-5.0

POTASSIUM 3.5-5.0

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


How it all ties together

Static Definition – Field Level

Vocabulary

SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME

1 4 SI X 00104 Set ID - PID

2 20 CX RE [1..1] 00105 Patient ID

3 20 CX R [1..*] 00106 Patient Identifier List

4 20 CX X 00107 Alternate Patient ID - PID

5 48 XPN R [1..*] 00108 Patient Name

6 48 XPN RE [1..*] 00109 Mother’s Maiden Name

7 26 TS RE 00110 Date/Time of Birth

8 1 IS RE 0001 00111 Sex

9 48 XPN X 00112 Patient Alias

10 80 CE X 0005 00113 Race

11 106 XAD RE [1..3] 00114 Patient Address

12 4 IS X 0289 00115 County Code

13 40 XTN RE [1..3] 00116 Phone Number - Home

14 40 XTN RE [1..3] 00117 Phone Number - Business

15 60 CE X 0296 00118 Primary Language

16 80 CE X 0002 00119 Marital Status

17 80 CE X 0006 00120 Religion

18 20 CX X 00121 Patient Account Number

19 16 ST RE 00122 SSN Number - Patient

20 25 DLN X 00123 Driver's License Number - Patient

21 20 CX X 00124 Mother's Identifier

22 80 CE X 0189 00125 Ethnic Group

23 60 ST RE 00126 Birth Place

24 1 ID X 0136 00127 Multiple Birth Indicator

25 2 NM X 00128 Birth Order

26 80 CE X 0171 00129 Citizenship

27 60 CE X 0172 00130 Veterans Military Status

28 80 CE X 0212 00739 Nationality

29 26 TS X 00740 Patient Death Date and Time

30 1 ID X 0136 00741 Patient Death Indicator

: A DT S y s tem : A DT Notifi c ation Rec ip ient

A DTÂ 01

A CK Â 01

Interaction Model

Segment ADT Message Usage Cardinality Chapter

MSH Message Header R [1..1] 2

EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [{ ROL }] Role X [0..0] 12 [{ NK1 }] Next of Kin / Associated

Parties RE [0..3] 3

PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit - Additional

Info. RE [0..1] 3

[{ ROL }] Role X [0..0] 12 [{ DB1 }] Disability Information X [0..0] 3 [{ OBX }] Observation/Result X [0..0] 7 [{ AL1 }] Allergy Information RE [0..*] 3 [{ DG1 }] Diagnosis Information X [0..0] 6 [ DRG ] Diagnosis Related Group X [0..0] 6 [{ X [0..0] PR1 Procedures X [0..0] 6 [{ ROL }]

Role X [0..0] 12

}] [{ GT1 }] Guarantor X [0..0] 6 [{ X [0..0] IN1 Insurance X [0..0] 6 [ IN2 ] Insurance Additional Info. X [0..0] 6 [{ IN3 }]

Insurance Additional Info - Cert.

X [0..0] 6

[{ ROL }]

Role X [0..0] 12

}] [ ACC ] Accident Information X [0..0] 6 [ UB1 ] Universal Bill Information X [0..0] 6 [ UB2 ] Universal Bill 92 Information X [0..0] 6 [ PDA ] Patient Death and Autopsy X [0..0] 3

Dynamic Definition

Static Definition – Segment Level

P at ie n t

P hy s ic ian

A D T N o t ific a t ion R e c ip ien t

A D T S y s tem

A dm it / V is it N ot ific a t ion

is s u b jec t o fau tho riz es

rec e ives no t if ic a t ions en ds no t if ic a t ion

R eg is t ra rt rig gers

Use Case Model

Static Definition – Message Level

1 Use Case Model

1.1 Use Case: Admit/Visit Notification

2. Dynamic Interaction Model

3 Dynamic Definition: ADT/ACK (Event A01)

3.1 ADTÂ013.2 ACKÂ01

4 Static Definition: - Message Level -ADT/ACK (event A01)

4.1 ADTÂ014.2 ACKÂ01

5 Static Defintiion - Segment Level

5.1 MSH – Message Header Segment Definition5.2 EVN - Event Type Segment Definition5.3 PID (Y) - Patient Demographics Segment Definition5.4 PD1 – Patient Additional Demographic Segment Definition5.5 NK1 - Next of kin Segment Definition5.6 PV1 (2) - Admit Visit Info Segment Definition5.7 AL1 - Allergy Segment Definition5.8 MSA - Message Acknowledgment Segment Definition5.9 ERR - Error Segment Definition

6 Static Definition - Field Level

6.1 Table 0001 – Sex6.2 Table 0002 – Marital Status6.3 Table 0003 – Event Type Code6.4 Table 0004 – Patient Class6.5 Table 0005 – Race6.6 Table 0006 – Religion6.7 Table 0007 – Admission Type6.8 Table 0008 – Acknowledgement Code6.9 Table 0009 – Ambulatory Status


Message ProfilesConcepts and Constituents


Profiling Concepts• Profile Types

HL7 Standard Constrainable Implementable Future type to allow for expected receiver behavior

• Generic term ‘element’ used Segment groups Segments Fields Components Sub-components

• Cardinality• Usage

Message Constituents


Profile Types

• HL7 Standard Profile

represents a specific HL7 published standard

creation and publication limited to HL7 use

• Constrainable

May have optionality - not implementable

Narrower profiles may be defined based on this

Realm Specific (National, Regional, SIGs, etc.)

Supplier / Consumer Specific

• Implementation

Further constrained

No optionality


Cardinality

• Identifies minimum and maximum number of repetitions

• Special values for cardinality

Minimum number of repetitions is 0, the element may be omitted from a message

The maximum value may have no practical limit (In this case, it may be identified as ‘*’)


Cardinality Examples

Examples of common cardinality combinations are:Element Cardinality

Value Description

[0..0] Element never present

[0..1] Element may be omitted and it can have at most one Occurrence

[1..1] Element must have exactly one Occurrence

[0..n] Element may be omitted or may repeat up to n times

[1..n] Element must appear at least once, and may repeat up to n times

[0..*] Element may be omitted or repeat for an unlimited number of times

[1..*] Element must appear at least once, and may repeat unlimited number of times

[m..n] Element must appear at least “m” and at most” n” times


Usage

• The circumstances under which an element appears in a message

Some elements must always be present

others may never be present

others may only be present in certain circumstances

• Rules governing the expected behavior of the sending and limited restrictions on the receiving application with respect to the element


Usage (continued)

• R - Required

A conforming sending application

• populate all “R” elements with a non-empty value

A conforming receiving application

• process (save/print/archive/etc.) or ignore the information conveyed by required elements

• must not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element

For complete compatibility with HL7, any element designated as required in a standard HL7 message definition shall also be required in all HL7 Message Profiles of that standard message


Usage (continued)

• RE - Required but may be empty May be missing from the message, but must be sent by the

sending application if there is relevant data

A conforming sending application

• must be capable of providing all “RE” element

• if it knows the required values for the element, then it must send that element

• if the conforming sending application does not know the required values, then element will be omitted

A conforming receiving applications

• will be expected to process (save/print/archive/etc.) or ignore data contained in the element

• must be able to successfully process the message if the element is omitted (I.e. no error message should be generated because the element is missing


Usage (continued)

• Optional

This code indicates that the Usage for this element has not yet been defined

May NOT be used in ‘Implemention’ profiles (no-optionality profiles)

Conformance cannot be tested on an Optional field


Usage (continued)

• C - Conditional Predicate associated with this element that identifies the

conditions under which the element must be present• must be testable and based on other values within the message

• may be expressed as a mathematical expression or in text and may utilize operators such as equivalence, logical AND, logical OR and NOT

• The conforming sending and receiving applications shall both evaluate the predicate

If the predicate is satisfied:• See rules for R (Required)

If the predicate is NOT satisfied:• A conformant sending application must NOT send the element

• A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it MAY raise an error if the element IS present


Usage (continued)

• CE - Conditional but may be empty This usage also has an associated condition predicate similar to

Conditional (C)

If the predicate is satisfied:

• See rules for RE (Required but may be empty)

If the predicate is not satisfied:

• The conformant sending application must NOT send the element

• The conformant receiving application MAY raise an application error if the element IS present

• X - Not supported Conformant sending applications will NOT send the element

Conformant receiving applications MAY ignore the element if it IS present, or may raise an application error


Optionality / Usage Relationship

• Conformance Usage codes are more specific than HL7 Optionality codes

HL7 Optionality Allowed Conformance Usage Comment

R - Required R

O - Optional R, RE, O*, C, CE, X O is only permitted for constrainable profiles

C - Conditional C, CE, R**, RE** ** If satisfied by use case

X – Not Supported X

B – Backward Compatibility

R, RE, O*, C, CE, X O is only permitted for constrainable profiles

W – Withdrawn X


Usage / Cardinality Relationship

• Both Usage and Cardinality govern the appearance of a field in a message

• Cardinality constrained by the usage code

If Required (R), the minimum and maximum cardinality for the element shall always be >= 1

If the usage of an element is not Required (R) (i.e. any code other than ‘R’), the minimum cardinality shall be 0 except in the following condition:

• where an element will not always be present but, when present, must have a minimum number of repetitions greater than one, this may be indicated by specifying

– the non-required Usage code

– the minimum cardinality representing the minimum number of repetitions when the element is present.


Usage-Cardinality Combinations

Cardinality Usage Interpretation

[1..1] R There will always be exactly 1 repetition present

[1..5] R There will be between 1 and 5 repetitions present

[0..1] R Illegal: Minimum and maximum cardinality must always be at least 1 for ‘Required’ elements

[0..1] RE The element must be supported, but may not always be present

[0..5] C If the condition predicate is true, there will be between 1 and 5 repetitions. If the predicate is false, there will be 0 repetitions

[3..5] RE If any values for the element are sent, there must be at least 3 and no more than 5 repetitions. However, the element may be absent (0 repetitions)

[0..1] CE Under certain circumstances, the element must be supported, but may not always be present

[0..0] X Not supported


Usage Within Hierarchical Elements

• Messages are constructed using a hierarchy of elements

• At least one lower level element must be present for the higher level element to be considered to be present

• Adds an implicit conditional constraint on elements that enforce the presence of an element

• Places constraints on what combinations of usage codes may be used within a hierarchy


Message ProfilesLevels and Examples


Message Level Profile

• Segment Definitions

The set of segments and segment groups included within the message of an HL7 Message Profile shall be defined

Any segments or segment groups that are required by HL7 shall be included

• Segment Usage

• Segment Cardinality

• Profile does not allow for “empty” segment

• HL7 abstract message syntax PLUS

Usage

Cardinality


Message Level Profile Example

ADTÂ01ÂDT_A01 ADT Message Usage Cardinality Chapter

MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [{ ROL }] Role X [0..0] 12 [{ NK1 }] Next of Kin / Associated

Parties RE [0..3] 3


Info. RE [0..1] 3

[{ ROL }] Role X [0..0] 12 [{ DB1 }] Disability Information X [0..0] 3 [{ OBX }] Observation/Result X [0..0] 7 [{ AL1 }] Allergy Information RE [0..*] 3 [{ DG1 }] Diagnosis Information X [0..0] 6 [ DRG ] Diagnosis Related Group X [0..0] 6 [{ X [0..0] PR1 Procedures X [0..0] 6 [{ ROL }] Role X [0..0] 12 }] [{ GT1 }] Guarantor X [0..0] 6 [{ X [0..0] IN1 Insurance X [0..0] 6 [ IN2 ] Insurance Additional Info. X [0..0] 6 [{ IN3 }] Insurance Additional Info -

Cert. X [0..0] 6

[{ ROL }] Role X [0..0] 12 }] [ ACC ] Accident Information X [0..0] 6 [ UB1 ] Universal Bill Information X [0..0] 6 [ UB2 ] Universal Bill 92 Information X [0..0] 6 [ PDA ] Patient Death and Autopsy X [0..0] 3

ADTÂ01ÂDT_A01 ADT Message Usage Cardinality Chapter

MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [{ NK1 }] Next of Kin / Associated

Parties RE [0..3] 3


Info. RE [0..1] 3

[{ AL1 }] Allergy Information RE [0..*] 3


Segment Level Profile

• The set of fields of each instance of a segment within the Message Profile

• If a segment occurs multiple times, it may be represented by different segment profiles

• Field Usage

• Field Cardinality

• Null

• Syntax (tabular HL7 segment definitions)

Length (updated)

Usage (new column)

Cardinality (new column)


SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME

1 4 SI X 00104 Set ID - PID

2 20 CX RE [0..1] 00105 Patient ID

3 20 CX R [1..*] 00106 Patient Identifier List

4 20 CX X 00107 Alternate Patient ID - PID

5 48 XPN R [1..*] 00108 Patient Name

6 48 XPN RE [0..*] 00109 Mother’s Maiden Name

7 26 TS RE [0..*] 00110 Date/Time of Birth

8 1 IS RE [0..*] 0001 00111 Sex

9 48 XPN X 00112 Patient Alias

10 80 CE X 0005 00113 Race

11 106 XAD RE [0..3] 00114 Patient Address

12 4 IS X 0289 00115 County Code

13 40 XTN RE [0..3] 00116 Phone Number - Home

14 40 XTN RE [0..3] 00117 Phone Number - Business

15 60 CE X 0296 00118 Primary Language

16 80 CE X 0002 00119 Marital Status

17 80 CE X 0006 00120 Religion

18 20 CX X 00121 Patient Account Number

19 16 ST RE [0..1] 00122 SSN Number - Patient

20 25 DLN X 00123 Driver's License Number - Patient

21 20 CX X 00124 Mother's Identifier

22 80 CE X 0189 00125 Ethnic Group

23 60 ST RE [0..1] 00126 Birth Place

24 1 ID X 0136 00127 Multiple Birth Indicator

25 2 NM X 00128 Birth Order

26 80 CE X 0171 00129 Citizenship

27 60 CE X 0172 00130 Veterans Military Status

28 80 CE X 0212 00739 Nationality

29 26 TS X 00740 Patient Death Date and Time

30 1 ID X 0136 00741 Patient Death Indicator

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

1 4 SI O 00104 Set ID - PID

2 20 CX B 00105 Patient ID

3 250 CX R Y 00106 Patient Identifier List

4 20 CX B Y 00107 Alternate Patient ID - PID

5 250 XPN R Y 00108 Patient Name

6 250 XPN O Y 00109 Mother’s Maiden Name

7 26 TS O Y 00110 Date/Time of Birth

8 1 IS O Y 0001 00111 Sex

9 250 XPN B 00112 Patient Alias

10 250 CE O 0005 00113 Race

11 250 XAD O Y 00114 Patient Address

12 4 IS B 0289 00115 County Code

13 250 XTN O Y 00116 Phone Number - Home

14 250 XTN O Y 00117 Phone Number - Business

15 250 CE O 0296 00118 Primary Language

16 250 CE O 0002 00119 Marital Status

17 250 CE O 0006 00120 Religion

18 250 CX O 00121 Patient Account Number

19 16 ST B 00122 SSN Number - Patient

20 25 DLN B 00123 Driver's License Number - Patient

21 250 CX O Y 00124 Mother's Identifier

22 250 CE O Y 0189 00125 Ethnic Group

23 250 ST O 00126 Birth Place

24 1 ID O 0136 00127 Multiple Birth Indicator

25 2 NM O 00128 Birth Order

26 250 CE O Y 0171 00129 Citizenship

27 250 CE O 0172 00130 Veterans Military Status

28 250 CE B 0212 00739 Nationality

29 26 TS O 00740 Patient Death Date and Time

30 1 ID O 0136 00741 Patient Death Indicator

Segment Level Profile Example (PID)


Field Level Profile

• Field definitions Each individual field is completely defined to eliminate any

possible ambiguity

If HL7 2.x field descriptions are not sufficient, a precise semantic definition shall be specified

• Exact allowed value set shall be specified Coded Values (ID and IS)

• HL7 tables (ID) may be extended

• User defined (IS) may be redefined and/or extended

Coded Entry (CE, CF, CWE, and CNE)

• Composite Data (CM) types • Appendix for 2.3.1 and 2.4 for XML encoding

• Deprecated and all CM fields are using new data types as of 2.5


Profile Registration Tool

• Message Profile registration utility on the HL7 Members’ Page of the HL7 WWW (www.hl7.org/memonly/conformance)

• Valid Conformance Documents (XML)

• Message Profile Identifier generated

• Repository of Message Profile

• Catalogue of Message Profile Users (future) application name and version

contact person

application role (whether the application sends or receives messages described by the profile)

• Search Capabilities

http://www.hl7.org/memonly/conformance


Message Profile Identifier

• Uniquely identifies static and dynamic profile

• The static profile identifier is a means to uniquely identify a message profile, expressed as an ASN.1 Object Identifier (OID)

The sending application uses the profile identifiers to determine the specific HL7 Message Profile to send

Branch from ISO to HL7 and Message Profile

• 2.16.840.1.113883.9


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

• The process by which message instance(s) are verified against the message profile on which it is based

• Verification is a very important part of conformance

• Conducted by providers, national or regional health organizations

Not conducted by HL7


Australian Healthcare Messaging Laboratory(http://www.ahml.com.au)

http://www.ahml.com.au/

http://www.ahml.com.au/


<XML>Considerations </XML>

• Message profile is independent of message instance encoding - ER7/XML

• XML Message Instance• 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

• Version 2.xml specification from XML SIG (informative -> normative)


Conformance Benefits

• Consistent Documentation

• Reuse of Specification

• Lower Cost of Integration

• Similar to Version 3 Conformance SIG is developing Implementation guide

• Chaos -> order

• Site Specific Profiles Supports specific needs

Required of third-party application vendors

RFP

Simplifies introduction/acquisition of new applications


Conformance Support in the HL7 Standard

• Version 2.4, 2.5, 2.6

MSH:21

Profile identifier

OID data type for ASN.1 identifiers

Conformance Section

Implementation Guide

• Version 3

At the core of the Message Development Process

Chapter 7 of HDF

Implementation Guide


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

V3 Conformance


Break


Messaging WorkbenchWhat and Why


The Messaging Workbench (MWB)

• For those who: Design HL7 2.x messages

Manage specification repositories

Collaborate on varied messaging projects within and outside of their organizations

• Free of charge from HL7 Web site (www.hl7.org) HL7 -> SIG -> Conformance -> Documents

• Encouraged by the Conformance SIG

• Open Source Project Call for participation

• It will continue to be supported within the VA for the foreseeable future

http://www.hl7.org/


Design Features - 1

• Rapid prototyping of message profiles derived from standard libraries, from profile inheritance or from scratch

• Quick and easy alteration of existing profiles to meet new requirements

• Design time comparison of profiles on an element by element basis

• Linkage of data elements or constants to message elements for a more complete specification


Design Features - 2

• Tools for storage and retrieval of profiles as well as updating and customizing message element libraries

• The ability to capture and analyze ER7 messages

• Capability to reverse engineer specifications from captured messages.

• A suite of reports that document specifications and produce example messages in text, xml and html formats

• Additional style sheets available for PDF


HL7


Constrainable


Constrainable (continued)


Implementation


Message Profile


Messaging WorkbenchFeatures and Use


Capture/Analyze Message


Reverse Engineer from Message


New Profile Using Libraries


New Profile Using Libraries (cont’d)








New Profile using copy/paste


New Profile Copy/Paste (cont’d)


New Profile Copy/Paste (cont’d)


Modifying a Profile – HL7


Modifying a Profile – Constrainable


Modifying Profile – Constr (cont’d)


Modifying Profile – Implementation


Modifying Profile – Impl (cont’d)


Diagram Drawing Tool


Messaging WorkbenchReports and Examples


Reports


Reports (continued)


Reports (continued)


Reports (continued)


Reports (continued)


Reports (continued)


Producing Profile Reports


Producing Profile Reports (cont’d)





Browser View




HL7 Message Profile


Register Profile with HL7


Messaging WorkbenchContacts and Help


MWB Contacts

• The Conformance SIG is interested in your feedback and suggestions for improvement of the tool

• Conformance SIG list server is a good source for general information about the tool and for making improvement suggestions

• For specific questions you may also contact Pete Rontey via Email at [email protected]


Where to Get More Information

• MWB On-line help


Where to Get More Info (cont’d)

• MWB On-line help (cont’d)


Where to Get More Info (cont’)

• MWB Updates/Downloads


Where to Get More Info (cont’d)

• Conformance Tools Forum at Yahoo Groups

California Department of Health ServicesElectronic Laboratory Reporting Project


California Electronic Laboratory Reporting System

Lab MessageSupplier

InboundLaboratoryMessage

InboundMessage Profile

Transform

Translate

InboundMessage Mapping

CanonicalLaboratoryMessage

CanonicalMessage Profile

Transform

Translate

OutboundMessage Mapping

OutboundLaboratoryMessage

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service

Object GraphGeneration

LaboratoryMessageObjects

ObjectRelationalMapping

LaboratoryMessage

Respository

Object RelationalMap

ELR DatabaseDesign Model

CA Public HealthLogical Data

Model

HL7 RIM &CDC PHLDM


LaboratoryMessage Object

Model

Extract,Transform,and Load

LaboratoryDatamart

BusinessIntelligenceApplication



OutboundMessage Profile


Additional DataSources


Inbound Message Processing Outbound Message Processing

Data PersistenceBusiness Intelligence

Functional Areas of the CA-ELR System

Lab MessageSupplier



Transform

Translate




Transform

Translate



Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Respository




Model

HL7 RIM &CDC PHLDM



Model


LaboratoryDatamart








California Electronic Laboratory Reporting System



Transform

Translate




Transform

Translate



Outbound

Lab MessageSupplier

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Respository




Model

HL7 RIM &CDC PHLDM



Model


LaboratoryDatamart




Message Profile




Message Profiles

• Describe message structure and anticipated application behavior

• Identify required, optional, and conditional message elements

• Identify coding systems or value-sets for coded elements

• Enable message validation, transformation, and persistence

• Are essential for achieving system-to-system interoperability



Transform

Translate




Transform

Translate





Message-Level Profile

• Which Segments are Supported?

• Which Segments are Required?

• How are Segments Grouped?

• What is the order of Segments and Segment groups

• Which Segments/Segment Groups are repeatable?

• What is the cardinality of repeating segments/segment Groups?


Segment-Level Profile

• Which Fields are Supported?

• Which Fields are Required?

• What is the order of fields within the segment?

• What is the datatype of each field?

• Which fields are repeatable?

• What is the cardinality of repeating fields?

• What maximum field length is supported?

• What value tables are associated with the field?


Field-Level Profile

• Which Field components are supported?

• Which Field components are Required?

• What is the order of components within a field?

• What is the datatype of each field component?

• Which fields components are repeatable?

• What is the cardinality of repeating fields components?

• What maximum length is supported for field components?

• What value tables are associated with the field components?


Questions / Discussion / Feedback


Thank You

Abdul-Malik ShakirPrincipal Consultant

Shakir Consulting1911 Foothill Blvd., Suite 148

La Verne, CA 91750

Office: (909) 596-6790 Mobile: (626) 644-4491

Email: [email protected]

Version 2 Messaging Conformance Version 2 Messaging Conformance HL7 Educational Summit Chicago, Illinois Abdul-Malik Shakir Principal Consultant, Shakir.

Documents

2005v2 messaging conformance10

2005v2 messaging conformance17

2005v2 messaging conformance9

2005v2 messaging conformance8

2005v2 messaging conformance11

2005v2 messaging conformance2

2005v2 messaging conformance16

2005v2 messaging conformance12