Version 2.x Messaging Conformance

© 2010 Health Level Seven ® International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

Version 2.x Messaging

ConformanceAbdulMalik Shakir

Principal Consultant, Shakir Consulting

HL7 Working MeetingSeptember 2012, Baltimore, MD


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

HL7 Member since 1991

Principal Consultant with Shakir Consulting Director Research Informatics Architecture with City of Hope Co-Chair of the HL7 Modeling and Methodology Committee Member of the HL7 Education Committee Member of the HL7 Public Health and Emergency Response Committee Member of the HL7 Regulated Clinical Research Information Management Committee Member of the HL7 Clinical Interoperability Council


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

Sample Projects CADHS ELR CA SIIS SIP


Health Level SevenWhat and Why


An HL7 Messaging Scenario: Why

User InterfaceProgramModuleDataset

User Interface ProgramModule Dataset

Message Creation

Message Parsing

A to BTransformation

Message Parsing

Message Creation

B to ATransformation

Order Entry Application

System

Laboratory Application

System

Lab

Ord

er

Tran

s act

ion

Order Entry Application

System

Laboratory Application

System

Lab

Res

ult

Tran

sact

ion


Reaching the Limits of Application Interfaces

Lab

Order Entry ADT

Pharmacy Radiology

DecisionSupport

ElectronicHealth Record

AdministrativeSystems

?

EnterpriseSystems

?ExternalSystems

?


Health Level Seven: Why

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

• Linking systems only needs 1 interface, ;• 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. I = N

3 (32 - 3) / 2 = 3 2 (22 - 2) / 2 = 1 4 (42 - 4) / 2 = 6


Health Level Seven: WhyInterfaces Required

0

20

40

60

80

100

120

Systems

Inte

rfac

es

W/O HL7 1 3 6 10 15 21 28 36 45 55 66 78 91 105

With HL7 2 3 4 5 6 7 8 9 10 11 12 13 14 15

2 3 4 5 6 7 8 9 10 11 12 13 14 15

Tolerable Painful Intolerable


Divide and Conquer / Component Reuse

DATA

Next of Kin (NK1)

Insurance (IN1)

Patient Visit (PV1) Patient

Demographics (PID)

Guarantor(GT1)

NK1

IN1

PV1

PID

GT1OBR

OBX

Next of KIN(NK1)

Patient Visit(PV1)

Patient Demographics

(PID)


Abstract Message Specification

MSH Message HeaderEVN Event TypePID Patient Identification [PD1] Additional Demographics[ { NK1 } ] Next of Kin /Associated PartiesPV1 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 DefinitionSEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

1 1 ST R 00001 Field Separator2 4 ST R 00002 Encoding Characters3 180 HD O 00003 Sending Application4 180 HD O 00004 Sending Facility5 180 HD O 00005 Receiving Application6 180 HD O 00006 Receiving Facility7 26 TS O 00007 Date/Time Of Message8 40 ST O 00008 Security9 7 CM R 00009 Message Type10 20 ST R 00010 Message Control ID11 3 PT R 00011 Processing ID12 8 ID R 0104 00012 Version ID13 15 NM O 00013 Sequence Number14 180 ST O 00014 Continuation Pointer15 2 ID O 0155 00015 Accept Acknowledgment Type16 2 ID O 0155 00016 Application Ack. Type17 2 ID O 00017 Country Code18 6 ID O Y/3 0211 00692 Character Set19 60 CE O 00693 Principal Language Of Message


MSH Segment DefinitionSEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME

1 1 ST R 00001 Field Separator2 4 ST R 00002 Encoding Characters3 180 HD O 00003 Sending Application4 180 HD O 00004 Sending Facility5 180 HD O 00005 Receiving Application6 180 HD O 00006 Receiving Facility7 26 TS O 00007 Date/Time Of Message8 40 ST O 00008 Security9 7 CM R 00009 Message Type10 20 ST R 00010 Message Control ID11 3 PT R 00011 Processing ID12 8 ID R 0104 00012 Version ID13 15 NM O 00013 Sequence Number14 180 ST O 00014 Continuation Pointer15 2 ID O 0155 00015 Accept Acknowledgment Type16 2 ID O 0155 00016 Application Ack. Type17 2 ID O 00017 Country Code18 6 ID O Y/3 0211 00692 Character Set19 60 CE O 00693 Principal Language Of Message

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


HL7 Message Elements

An HL7 message specification is an ordered collection of one or more segment groups where each segment group is an ordered collection of one or more segments. A segment may be part of more than one segment group; it can also appear more than once within the same segment group.

A segment is an ordered collection of fields. Each segment field is an instance of a data element. A data element may appear as a field in more than one segment or as more than one field within the same segment. Each data element is assigned a data type.

A datatype may be simple or composite. A composite datatype is an ordered collection of one or more data type components; a simple datatype has no components. A data type component is an instance of a data element. A data element may appear as a component of more than one composite data type or as more than one component of the same composite data type.

Segment fields and datatype components may be associated with a code table. A code table is a collection of code table items. Each code table item is a code system term from some code system. A code system may be HL7 defined, user defined, or defined by a third party. A code system term may be used as a code table item in more than one code table but may appear only once within the same code table.


HL7 v2 Message ElementsMessage

Specification

Segment Group

Segment Segment Field

Data ElementMessage Segment

Data Type

Data TypeComponent

Code Table Code Table Item

CompositeData Type Code System

Code System Term

One to One One to Many Many to Many

Relationships


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


Reveal Assumptions

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

Do you use

HL7?

MSHEVNPID [PD1][ { NK1 } ]

Yes, Iuse HL7.

MSHEVNPID[ NK1 ]OBX


Reduce Ambiguity

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



Highlight Conflicts

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

and to validate our assumptions about message structures.


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


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 (cont’d) 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

25 of 15


Conceptual OverviewMessage Profile = Static Profile + Dynamic Profile

Critical Care Unit

ADT System

Response Message

Initiating 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


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

MSHEVNPID

NK1 NK1 NK1 NK1PV1

PV2OBXAL1

HL7 Message Structure

...

NK1

MSHEVNPID

NK1 NK1 NK1 NK1PV1

PV2OBXAL1

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

POTASSI UM 3.5- 5. 0

POTASSIUM 3.5-5.0

POTASSI UM 3.5- 5. 0

BED 1 OFF

POTASSIUM 3.5-5.0

BED 1 OFF BED 1 OFF

BED 1 OFFBED 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

POTASSI UM 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 OFFBED 1 OFFBED 1 OFF

Clinical Data Repository

A/D/T System

Order Filling Application

Accept Ack

Accept + App ACK

Receiver Responsibility MSH-15,16

No ACK


How it all ties together

Static Definition – Field LevelVocabulary

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 Multip le 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 Not ifi c ation Rec ip ient

ADTÂ 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 Re c ipien t

A D T S y s tem

A dm it / V is i t No t ific a t ion

is s u b jec t o f au tho riz e s

rec e ives no t if ic a tions e n ds no t i f ic a t ion

Re g is t ra rt rig ge rs

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

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

Cardinality Usage


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.) Organization / Application 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 ExamplesValue 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 ‘Implementation’ 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 codesHL7 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 ExampleADT^A01^ADT_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


Message Level Profile ExampleADT^A01^ADT_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


Message Level Profile Example ADT^A01^ADT_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..10] 3


Info. R [1..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 [{ RE [0..3] IN1 Insurance R [1..1] 6 [ IN2 ] Insurance Additional Info. RE [0..1] 6 [{ IN3 }] Insurance Additional Info -

Cert. X [0..0] 6

[{ ROL }] Role X [0..0] 12 }] [ ACC ] Accident Information RE [0..1] 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


Message Level Profile Example ADT^A01^ADT_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..10] 3


Info. R [1..1] 3

[{ AL1 }] Allergy Information RE [0..*] 3 [{ RE [0..3] IN1 Insurance R [1..1] 6 [ IN2 ] Insurance Additional Info. RE [0..1] 6 }] [ ACC ] Accident Information RE [0..1] 6


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)


Segment Level Profile Example (PID)

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


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


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


MSH-21 Message Profile Identifier Sites may use this field to assert adherence to, or reference, a message

profile. Message profiles contain detailed explanations of grammar, syntax, and usage for a particular message or set of messages.

Repetition of this field allows more flexibility in creating and naming message profiles. Using repetition, this field can identify a set of message profiles that the message conforms to.

the first repetition could reference a vendor's message profile The second could reference another compatible provider's profile or a later version

of the first vendor profile. As of v2.5, the HL7 message profile identifiers might be used for

conformance claims. Prior to v2.5, the field was called Conformance Statement ID. For backward

compatibility, the Conformance Statement ID can be used here.


Compliance and Conformance

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

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

Compliance Conformance


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


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)


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)


Producing Profile Reports


Producing Profile Reports (cont’d)



Browser View


HL7 Message Profile


Register Profile with HL7


Messaging WorkbenchContacts and Help


MWB Contacts The Implementation/Conformance

WorkGroup is interested in your feedback and suggestions for improvement of the tool

Implementation/Conformance WorkGroup 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 Services

Electronic Laboratory Reporting Project


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 Persistence Business Intelligence

Lab MessageSupplier



Transform

Translate




Transform

Translate



Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Respository




Model

HL7 RIM &CDC PHLDM



Model


LaboratoryDatamart










Transform

Translate




Transform

Translate



Outbound

Lab MessageSupplier

Lab MessageConsumer

KnowledgeManagement

Service

KnowledgeManagement

Service




LaboratoryMessage

Repository




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?


California State Immunization Information System

System Interface Project


The California State Immunization Information System (SIIS) is a collaboration of

regional immunization registries, local health departments, the California Department of Health

Services Immunization Branch, and a spectrum of key stakeholders

across the state of California. The goal of SIIS is to ensure that

health care providers have rapid access to complete and up-to-date immunization records.

The objective is to eliminate both missed opportunities to immunize and unnecessary duplicate immunizations.

SIIS consists of nine regional registries and two county registries.

SIIS is a system of systems each independently managed and operated.


Regional and County Registries

Immunization Network of Northern California (INNC) Shots For Tots KIDS Regional Immunization Registry (SFT) Bay Area Regional Immunization Registry (BARR) Imperial County (IMPL) ** Contra Costa County Automated Immunization Registry (CCAIR)** Regional Immunization Data Exchange (RIDE) Central Valley Immunization Information System (CVIIS) Central Coast Immunization Registry (CCIR) Los Angeles-Orange Immunization Network (LINK) VaxTrack Regional Immunization Registry (VaxTrack) San Diego Regional Immunization Registry (SDIR)


The scope of the California Statewide Immunization Information System (SIIS) Systems Interface Project (SIP) is to design, construct, and implement a centralized electronic messaging hub that facilitates the automated exchange of immunization related data within the state of California. The objective is to enable registry users to gain access to an individual’s complete immunization history regardless of where that history is maintained.

Project Scope


The premise behind the project is that, for many reasons, a person’s immunization history data becomes fragmented over time.

The data are stored and maintained in separate state registries and immunization provider information systems.

Typical scenarios that lead to this situation are changes in a person’s primary residence, changes in a person’s primary healthcare provider, and ad hoc administration of immunizations such as during vacation or emergencies.

Once a person’s immunization data becomes fragmented across multiple registry or provider information systems it can be difficult to ascertain their current immunization status.

This can result in over immunization or under immunization.

Problem Statement


A combination of manual and automated processes are employed to address this issue.

First and foremost, providers are encouraged to enroll in regional registries and to record administered immunizations in the registry. All providers within the jurisdiction of the regional registry will then have access to the same data.

Second, a CIR (yellow card) with the person’s immunization history is updated by administering providers and carried by the patient, parent, or guardian to all settings requiring an official immunization record.

Finally, immunization data may be requested from a former provider by phone, email, or fax and then entered into the immunization registry system.

Current Processes


There are serious inefficiencies and limitations associated with the current processes used to address the fragmentation of a person’s immunization history data.

The yellow card is often out of date, misplaced or otherwise unavailable.

Some healthcare providers operate in multiple regional registry jurisdictions and find the prospect of coordinating reporting to multiple registries to be too much of an administrative burden.

Some providers would prefer to have an automated means of exchanging data between the regional registry system and their electronic systems. These providers object to entering data into regional registries because it involves redundant data entry.

Current Limitations


Today immunization information is not easily able to follow the approximately 30,000 CA children moving throughout the state each year.

SIP will address this shortcoming by enabling the electronic exchange of immunization related data.

The SIIS SIP Immunization Information Exchange System will support the electronic request and response for immunization data from one registry to another.

Regional and county registries, healthcare providers, and multi-jurisdictional provider organizations will be able to participate in a SIIS SIP information network and use electronic messages based upon HL7 messaging standards to exchange immunization data.

SIIS SIP SOLUTION


HL7 Message Profiling

ad Dynamic View

Health Level Seven CDC / AIRA SIIS SIP Project Team Regional Registry

HL7 v 2.5 Messaging Standard

IZ Messaging Implemenation Guide Prepare Preliminary

Segment Lev el Profile

Preliminary Segment Level Profile

Prepare SIIS SIPConceptual Data Model

SIIS SIP Conceptual Data Model

Map Profile to RegionalSystems

Regional System to Profile Mapping

Prepare Final SegmentLevel Profile

Final Segment Lev el Profile

Prepare SIIS SIP LogicalData Model

SIIS SIP Logical Data Model

Prepare SIIS SIP Phase IMessage Level Profiles

SIIS SIP Phase I Message Level Profiles

Prepare SIIS SIPVocabulary Specification

SIIS SIP Vocabulary Specification

Prepare IZ ImplementationGuide


ad Dynamic View

Health Level Seven CDC / AIRA SIIS SIP Project Team Regional Registry

HL7 v 2.5 Messaging Standard

IZ Messaging Implemenation Guide Prepare Preliminary

Segment Lev el Profile

Preliminary Segment Lev el Profile

Prepare SIIS SIPConceptual Data Model


Map Profile to RegionalSystems

Regional System to Profile MappingPrepare Final Segment

Lev el Profile

Final Segment Lev el ProfilePrepare SIIS SIP Logical

Data Model

SIIS SIP Logical Data Model Prepare SIIS SIP Phase I

Message Lev el Profiles

SIIS SIP Phase I Message Lev el ProfilesPrepare SIIS SIP

Vocabulary Specification


Prepare IZ ImplementationGuide

Prepare IZ messaging implementation guide

Prepare preliminary segment level profile

Prepare SIIS SIP conceptual data model

Map preliminary profile to regional IZ systems

Prepare final segment level profile

Prepare SIIS SIP logical data model

Prepare SIIS SIP phase I message level profiles

Prepare SIIS SIP vocabulary specification


Immunization Messaging Implementation Guide The Centers for Disease Control and Prevention (CDC) National

Immunization Program (NIP) publishes an implementation guide for immunization data messaging.

The title of the guide is “Implementation Guide for Immunization Data Transactions using version 2.3.1 of the Health Level Seven (HL7) Standard Protocol”.

The intent of the guide is to help familiarize developers of immunization information systems with HL7 immunization message definitions and encoding rules and provide a nationally consistent implementation of those messages.

Changes to the guide are coordinated through the Data Exchange Steering Committee of the American Immunization Registry Association (AIRA) and its associated work groups.

The members of AIRA are committed to advancing the exchange of immunization data using a common protocol.


Immunization Messaging Implementation Guide The guide identifies the set of HL7 messages needed to enable information

systems that maintain immunization records to transmit patient-specific immunization histories electronically to other systems to allow healthcare providers to have access to these records at the time health care is given.

The use cases detailed in the guide indicate that data transmission will occur as the result of four activities:1. a query from one system for a patient’s vaccination record that is held in another

system using the HL7 VXQ message;2. a response to a query containing multiple patient “matches” to the query, but not

returning vaccination records using the HL7 VXX message;3. a response to a query containing the vaccination record using the HL7 VXR

message; and4. an unsolicited update to a vaccination record using the HL7 VXU message.

In addition to the messages used for the four primary activities the guide also includes specifications for transmission confirmation and exception notification messages; ACK and QCK.


Preliminary Segment Level Profile

Message Tree Seq ETyp DTyp Usage Min Max Table Len ReferencePID 011 Segment R 1 1 Set ID - PID 001 Field SI RE 0 1 4 3.4.2.1 Patient ID 002 Field CX RE 0 1 33 3.4.2.2 Patient Identifier List 003 Field CX R 1 0 250 3.4.2.3 Alternate Patient ID - PID 004 Field CX RE 0 1 33 3.4.2.4 Patient Name 005 Field XPN R 1 0 250 3.4.2.5 Mother's Maiden Name 006 Field XPN RE 0 1 250 6.5.7.40 Date/Time Of Birth 007 Field TS RE 0 1 26 15.4.6.6 Administrative Sex 008 Field IS RE 0 1 0001 1 15.4.6.5 Patient Alias 009 Field XPN RE 0 1 250 3.4.2.9 Race 010 Field CE RE 0 1 0005 250 15.4.6.27 Patient Address 011 Field XAD RE 0 1 250 3.4.2.11 County Code 012 Field IS RE 0 1 0289 4 3.4.2.12 Phone Number - Home 013 Field XTN RE 0 1 250 3.4.2.13 Phone Number - Business 014 Field XTN RE 0 1 250 3.4.2.14 Primary Language 015 Field CE RE 0 1 0296 250 6.5.7.34 Patient Account Number 018 Field CX RE 0 1 250 3.4.2.18 SSN Number - Patient 019 Field ST RE 0 1 16 3.4.2.19 Mother's Identifier 021 Field CX RE 0 1 250 3.4.2.21 Ethnic Group 022 Field CE RE 0 1 0189 250 15.4.6.28 Birth Place 023 Field ST RE 0 1 250 3.4.2.23 Multiple Birth Indicator 024 Field ID RE 0 1 0136 1 3.4.2.24 Birth Order 025 Field NM RE 0 1 2 3.4.2.25 Citizenship 026 Field CE RE 0 2 0171 250 6.5.7.33 Veterans Military Status 027 Field CE RE 0 1 0172 250 3.4.2.27 Patient Death Date and Time 029 Field TS RE 0 1 26 3.4.2.29 Patient Death Indicator 030 Field ID RE 0 1 0136 1 3.4.2.30 Last Update Date/Time 033 Field TS RE 0 1 26 3.4.2.33 Production Class Code 038 Field CE RE 0 1 0429 250 3.4.2.38



cd Logical Model Patient Demographics

Facility

identi fier: char(20) name: char(50) assigningAuthori tyId: char(20) namespaceId: char(20) streetAddress: char(120) city: char(50) stateOrProvince: char(50) zipOrPostalCode: char(12) country: char(3) addressType: char(3)

Patient

dateTimeOfBirth: timestamp birthState: char(60) multipleBirthIndicator: char(1) administrativeSex: char(1) birthOrder: numeric(2) deathDateTime: timestamp deathIndicator: char(1) lastUpdateDateTime: timestamp lastUpdateFacil ity: char(20) PublicityCodeID: char(20) publicityCodeEffectiveDate: datetime publicityCodeText: char(199) protectionIndicator: char(1) protectionIndicatorEffectiveDate: datetime immunizationRegistryStatus: char(1) immunizationRegistryStatusEffectiveDate: datetime

PersonPostalAddress

streetOrMailingAddress: char(120) streetName: char(50) dwellingNumber: char(12) city: char(50) stateOrProvince: char(50) zipOrPostalCode: char(12) addressType: char(3) countyParishCode: char(20) countryCode: char(3)

PatientLanguageAbility

identi fier: char(20) text: char(199) preferenceIndicator: char(1)

PersonTelecommunicationAddress

telecommunicationUseCode: char(3) areaCityCode: numeric(5) phoneNumber: numeric(9) extension: numeric(5) anyText: char(199)

Person

surname: char(50) givenName: char(30) secondAndFurtherGivenNamesOrIni tialsThereof: char(30) suffix: char(20)

PersonIdentifier

id: char(15) idType: char(6) namespaceId: char(20)

PersonAlternateName

typeCode: char(1) surname: char(50) givenName: char(30) secondAndFurtherGivenNamesOrIni tialsThereof: char(30) suffix: char(20)

PatientRelationship

identi fier: char(20) text: char(199) contactRoleIdenti fier: char(20) contactRoleText: char(199) livingArrangement: char(2)

PatientRace

identi fier: char(20) text: char(199) PatientEthnicGroup

identifier: char(20) text: char(199)

0..*

1

1..*

1

1..*

1

0..1

1

0..*

1

0..*

1

0..* 1..* 0..*1..*

0..*

1

0..* 11..* 1


Regional System to Segment Profile Mapping

Supp

orte

d?

Source Table Source Column(s)Source

Data type and length

Allowable values (attach

reference if necessary)

Mapping Comments

PIDSetID-PID YPatientIdentifierList

ID Y Patient pt_id intassigningauthority

namespaceID YPatientName

familynamesurname Y Patient pt_lname char(20)

givenname Y Patient pt_fname char(20)secondandfurthergivennamesorinitialsthereof Y Patient pt_mname char(20)suffix(e.g.,JRorIII) Y Patient pt_suffix char(10)

Mother'sMaidenNamefamilyname

surname Y Patient birth_mom_mname char(20)Date/TimeOfBirth

Date/Time Y Patient dob datetimeAdministrativeSex Y Patient sex char(1)PatientAlias

familynamesurname N

givenname Nsecondandfurthergivennamesorinitialsthereof Nsuffix(e.g.,JRorIII) N

Raceidentifier Y Patient race char(2)text Ynameofcodingsystem Y

PatientAddressstreetaddress(SAD)

streetormailingaddress Y PatientAddress addr_1, addr_2 varchar(35)streetname Ndwellingnumber N

city Y PatientAddress city varchar(20)stateorprovince Y PatientAddress state char(2)ziporpostalcode Y PatientAddress zipcode char(10)addresstype Y PatientAddress address_type char(1)county/parishcode Y PatientAddress county varchar(20)

Element Name

DO NOT MAP

DO NOT MAP DO NOT MAP

DO NOT MAP

DO NOT MAP

DO NOT MAP

DO NOT MAP DO NOT MAP

DO NOT MAP

DO NOT MAP

DO NOT MAP

DO NOT MAP

DO NOT MAP


Regional System to Segment Profile Mapping

Path

LIN

K

SDIR

VAXT

RA

CK

CC

IR

BA

RR

RID

E

INN

C

SFT

CVI

IS

Impe

rial

Prof

ile U

sage

CO

MM

ENT

PID PIDPID.1 SetID-PID Y Y N Y Y N Y Y Y N YPID.3 PatientIdentifierListPID.3.1 ID Y Y N Y Y Y Y Y Y Y YPID.3.4 assigningauthorityPID.3.4.1 namespaceID Y Y N Y Y Y Y Y Y N YPID.5 PatientNamePID.5.1 familynamePID.5.1.1 surname Y Y Y Y Y Y Y Y Y Y YPID.5.2 givenname Y Y Y Y Y Y Y Y Y Y YPID.5.3 secondandfurthergivennamesorinitialsthereof Y Y Y Y Y Y Y Y Y Y YPID.5.4 suffix(e.g.,JRorIII) Y Y Y Y Y Y Y Y Y N YPID.6 Mother'sMaidenNamePID.6.1 familynamePID.6.1.1 surname Y Y Y Y Y Y Y Y Y Y YPID.7 Date/TimeOfBirthPID.7.1 Date/Time Y Y Y Y Y Y Y Y Y Y YPID.8 AdministrativeSex Y Y Y Y Y Y Y Y Y Y YPID.9 PatientAliasPID.9.1 familynamePID.9.1.1 surname N N Y N Y Y Y/Y Y Y Y YPID.9.2 givenname N N Y N Y Y Y/Y Y Y Y YPID.9.3 secondandfurthergivennamesorinitialsthereof N N Y N Y N Y/Y Y Y Y YPID.9.4 suffix(e.g.,JRorIII) N N Y N Y N Y/Y N Y N YPID.10 RacePID.10.1 identifier Y Y Y Y Y Y Y Y Y Y YPID.10.2 text Y N Y Y Y N Y Y Y Y YPID.10.3 nameofcodingsystem Y Y Y Y Y N Y Y Y N YPID.11 PatientAddressPID.11.1 streetaddress(SAD)PID.11.1.1 streetormailingaddress Y Y Y Y Y Y Y Y Y Y YPID.11.1.2 streetname N N N N N N N N N Y NPID.11.1.3 dwellingnumber N N N N N N N N N Y NPID.11.3 city Y Y Y Y Y Y Y Y Y Y YPID.11.4 stateorprovince Y Y Y Y Y Y Y Y Y Y YPID.11.5 ziporpostalcode Y Y Y Y Y Y Y Y Y Y YPID.11.7 addresstype Y Y Y Y Y N Y Y Y Y YPID.11.9 county/parishcode Y Y Y Y Y Y Y Y Y Y Y

Element Name


Final Segment Level Profile

Message Tree Seq ETyp DTyp Usage Min Max TablePID 009 Segment R 1 1 0396 Set ID - PID 001 Field SI R 1 1 Patient Identifier List 003 Field CX R 1 * ID number 001 Component ST R 1 1 assigning authority 004 Component HD R 1 1 namespace ID 001 SubComponent IS R 1 1 0363 identifier type code 005 Component ID R 1 1 0203 Patient Name 005 Field XPN R 1 1 family name 001 Component FN R 1 1 surname 001 SubComponent ST R 1 1 given name 002 Component ST RE 0 1 second and further given names or initials thereof 003 Component ST RE 0 1 suffix (e.g., JR or III) 004 Component ST RE 0 1 name type code 007 Component ID R 1 1 0200 Mother_s Maiden Name 006 Field XPN RE 0 1 family name 001 Component FN R 1 1 surname 001 SubComponent ST R 1 1 name type code 007 Component ID R 1 1 0200 Date/Time of Birth 007 Field TS R 1 1 time 001 Component DTM R 1 1 Administrative Sex 008 Field IS R 1 1 0001 Patient Alias 009 Field XPN RE 0 * family name 001 Component FN R 1 1 surname 001 SubComponent ST R 1 1 given name 002 Component ST RE 0 1 second and further given names or initials thereof 003 Component ST RE 0 1 suffix (e.g., JR or III) 004 Component ST RE 0 1 name type code 007 Component ID R 1 1 0200 Race 010 Field CE RE 0 1 identifier 001 Component ST R 1 1 0005 text 002 Component ST RE 0 1 name of coding system 003 Component ID R 1 1 0396 alternate identifier 004 Component ST RE 0 1 alternate text 005 Component ST RE 0 1 name of alternate coding system 006 Component ID RE 0 1 0396



cd Logical Model Patient Demographics

Facility

*PK idNumber: int FK providerOrganizationIdNumber: int addressLine1Text: char(120) addressLine2Text: char(120) cityName: char(50) statePostalCode: char(50) postalCode: char(12) countryCode: char(3) addressTypeCode: char(3)

FK+ FK_Facility_ProviderOrganization(int)PK+ PK_Facility(int)

Patient

*PK idNumber: int FK facilityIdNumber: int* birthDate: datetime birthStateCode: char(60) multipleBirthIndicator: char(1)* sexCode: char(1) deathIndicator: char(1)* raceCode: char(20)* ethnicityCode: char(20)* allowableReminderTypeCode: char(20)* primaryLanguageCode: char(20) recordSharingConsentIndicator: char(1) immunizationRegistryStatusCode: char(1)

FK+ FK_Patient_Facility(int)PK+ PK_Patient(int)

PersonPostalAddress

*PK idNumber: int*FK personIdNumber: int addressLine1Text: char(120) addressLine2Text: char(120) cityName: char(50) stateCode: char(50) postalCode: char(12) addressTypeCode: char(3) countyCode: char(20)

FK+ FK_PersonPostalAddress_Person(int)PK+ PK_PersonPostalAddress(int)

PersonTelecommunicationAddress

*PK idNumber: int*FK personIdNumber: int telecommunicationUseCode: char(3) areaCode: numeric(5)* phoneNumber: numeric(9) extensionNumber: numeric(5) concatenatedTelecomNumber: char(199)

FK+ FK_PersonTelecommunicationAddress_Person(int)

Person

*PK idNumber: int surname: char(50) givenName: char(30) middleName: char(30) nameSuffix: char(20)

PK+ PK_Person(int)

PersonIdentifier

*PK idNumber: int FK organizationIdNumber: int* idCode: char(15)*FK personIdNumber: int idTypeCode: char(6)* idAssigningAuthority: char(20)* statusCode: char(2)

FK+ FK_PersonIdentifier_Organization(int)+ FK_PersonIdentifier_Person(int)

PersonAlternateName

*PK idNumber: int*FK personIdNumber: int* typeCode: char(1)* surname: char(50) givenName: char(30) middleName: char(30) nameSuffix: char(20)

FK+ FK_PersonAlternateName_Person(int)

PatientRelationship

*PK idNumber: int*FK patientIdNumber: int* typeCode: char(20)*FK patientIdNumber: int*FK personIdNumber: int* effectiveDate: datetime

FK+ FK_PatientRelationship_Patient(int)+ FK_PatientRelationship_Person(int)PK+ PK_PatientRelationship(int)

Organization

*PK idNumber: int idCode: char(20)* assigningAuthorityIdCode: char(20)* name: char(50)

PK+ PK_ProvderOrganization(int)

FacilityAlternateIdentifier

*PK facilityAlternateId: char(20)*pfK FacilityIdNumber: int FK identifierAssigningAuthority: int identifierTypeCode: bigint

FK+ FK_FacilityAlternateIdentifier_Facility(int)+ FK_FacilityAlternateIdentifier_Organization(int)PK+ PK_FacilityAlternateIdentifier(char, int)

TreatmentRefusal

*PK reasonIdCode: char(20)*pfK vaccineAdministrationIdNumber: int

FK+ FK_TreatmentRefusal_VaccineAdministration(int)PK+ PK_TreatmentRefusal(char, int)

VaccineAdministration

FK administeringProvideridNumber: int*FK patientIdNumber: int*PK idNumber: int*FK FacilityIdNumber: int* doseSequenceNumber: numeric(4)* substanceIdCode: char(20)* startDateTime: datetime* endDateTime: datetime* substanceAdministeredAmount: numeric(20)* routeIdCode: char(20)* substanceUnitOfMeasureCode: char(20)* siteIdCode: char(20) substanceLotNumber: char(20)* substanceDosageFormIdCode: char(20)* substanceManufacturerIdCode: char(20)* systemEntryDateTime: datetime

FK+ FK_VaccineAdministration_Facility(int)+ FK_VaccineAdministration_Patient(int)+ FK_VaccineAdministration_Person(int)PK+ PK_VaccineAdministration(int)

0..*

1

0..*

(identifierAssigningAuthority = idNumber)

0..1

0..*

(personIdNumber = idNumber)

1

0..*

(organizationIdNumber = idNumber)

1

0..*

(providerOrganizationIdNumber= idNumber)

0..1

1..*

(patientIdNumber =idNumber)

1

0..*

(patientIdNumber = idNumber)

1

0..*


1

0..*

(administeringProvideridNumber = idNumber)

1

0..*


1

0..*


1

0..*

(vaccineAdministrationIdNumber = idNumber)

1

0..*

normally receivescare at

1

0..*

(Facil ityIdNumber = idNumber)

1

0..*

(patientIdNumber =idNumber)

1


SIIS SIP Message Level Profiles

HL7 defines a message profile as “an unambiguous specification of one or more standard HL7 messages that have been analyzed for a particular use case”. It prescribes a set of precise constraints upon one or more standard HL7 messages.

A message profile eliminates ambiguity in a HL7 message specification by declaring static and semantic constraints for constituent elements of a message and the expected dynamic behavior of conformant application systems.

The SIIS SIP HL7 message profile is an extension to the NIP Implementation Guide. The profile is based upon version 2.1 of the guide published in September 2002.

The profile extends the specifications included in the guide. The profiles do not conflict with the guide; however, they are more constrained than the guide.

Messages that conform to the profile are conformant with the guide as well; although the converse may not be true.

A message profile has dynamic definition and a static definition.


HL7 Message Profile Dynamic Definition

The dynamic definition describes the supported use cases, interactions, and acknowledgement requirements.

Use Case ModelThe use case portion of the message profile dynamic definition documents the scope and requirements for an HL7 message profile or set of message profiles. The use case model documents the purpose for each message exchange; defines the actors, including the sending and receiving applications; and document the situations in which the exchange of a particular HL7 message profile is required

Interaction ModelThe Interaction Model illustrates the sequence of trigger events and resulting message flows between 2 or more systems. It may be in literal or graphical form. Graphical form should be a UML activity diagram.

Acknowledgement RequirementsThe specific HL7 acknowledgments required and/or allowed for use with the specified static definition of the HL7 message profile is defined. Specifically, the dynamic definition identifies whether accept and application level acknowledgments are allowed or required. For any one static definition there may be one or more dynamic definitions. The dynamic definition defines the conditions under which accept and application level acknowledgments are expected. Allowed conditions include: Always, Never, Only on success, and Only on error.


HL7 Message Profile Static Definition

The static definition describes usage rules, cardinalities, and code systems. Usage Rules

Usage refers to the circumstances under which an element appears in a message instance. Some elements must always be present, others may never be present, and others may only be present in certain circumstances. HL7 has defined a set of codes to clearly identify the rules governing the presence of a particular element. These usage codes expand/clarify the optionality codes defined in the HL7 standard.

CardinalityCardinality identifies the minimum and maximum number of repetitions for a particular element (Segment Group, Segment or Field). Cardinalities are expressed as a minimum-maximum pair of non-negative integers. A conformant application must always send at least the minimum number of repetitions, and may never send more than the maximum number of repetitions.

Vocabulary SpecificationVocabulary specifications declare an organized set of code systems and code system terms. Code system terms are coded concepts including concept codes, concept names, and concept relationships. Code system terms are collected into value sets declared as code tables associated with segment fields and data type components. The static definition declares the value sets for tables associated with coded message elements. Some of the value sets are HL7 defined, third party defined, or user defined.


SIIS SIP Use Case Diagram ud Use Case Model

Local Registry User

1.0 Immunization History Query

2.0 Patient Demographic

Update

3.0 Vaccine Record Update Prov ider Organization

SIIS Registry Administration

4.0 Immunization Statistical Analysis

Trusted Third PartiesLocal Registry Administration

SIIS Analysis Report

SIIS Analysis Report

SIIS Analysis Report SIIS Analysis Report

Update Confirmation

Update Confirmation

Query Response

Vaccine Record Update

Patient Information Update

Immunization History Request


SIIS SIP Activity Modelad InteractionActiv ityModel

Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System

1.1 Request ImmunizationData «message»

M.01 Immunization Data Request (VXQ)

2.2 Validate ImmunizationData Request Message

«message»M.02 Request Error Message

(ACK)

2.3 Route ImmunizationData Request Message2.4 Notify System

Administrator

«message»

M.03 Immunization Data Request (VXQ)

3.1 Retrive RequestedImmunization Data

«datastore»D.04 Immunization

Registry

3.2 RetrivalResult?

3.2.1 Return "No MatchingRecord" Response

3.2.2 Return "MultipleMatching Records"

Response

3.2.3 Return RequestedImmunization Data

«message»M.04 No Matching

Record Response (QCK)

«message»

M.05 Multiple Matching Records Response (VXX)

«message»

M.06 Requested Immunization Data (VXR)

4.2 Validate ResponseMessage

«message»

M.07 Response Message Error (ACK)

4.3 Route ResponseMessage

4.4 Notify SystemAdministrator

«message»

M.08 No Matching Record Message (QCK)

«message»

M.09 Multiple Matching Record Message (VXX)

«message»

M.10 Requested Immunization Data Message (VXR)

5.1 Refine DemographicData

5.2 Select Desired Record

5.3 Merge ImmunizationData with existing data

«datastore»

D.01 Immunization Registry

[Valid Message][Invalid Message]

[Valid Message]

[No Matching Record]

[Desired Record Not Present]

[Multiple Matching Records]

[Single Matching Record]

[Desired Record Selected]

[Invalid Message]

1

2 3

4

6

5


SIIP SIP Interaction Modelsd Interactions

Requesting RegistrySystem

SIIS SIP ImmunizationInformation Exchange

System

Responding RegistrySystem

Vaccination Record Query (VXQ)

[Invalid VXQ Message]: General Acknowledgement (ACK)

[Valid VXR Message]: Vaccination Record Query (VXQ)

[No Matching Record]: Query Acknowledgement (QCK)

[Invalid QCK Message]: General Acknowledgement (ACK)

[Valid QCK Message]: Query Acknowledgement (QCK)

[Multiple Matching Records]: Vaccination Query Response (VXX)

[Invalid VXX Message]: General Acknowledgement (ACK)

[Valid VXX Message]: Vaccination Query Response (VXX)

[Single Matching Record]: Vaccination Query Response (VXR)

[Invalid VXR Message]: General Acknowledgement (ACK)

[Valid VXR Message]: Vaccination Query Response (VXR)


SIIS SIP Acknowledgement RequirementsMessage Source Destinat

ionAcknowledg

ment• Vaccination Record Query

(VXQ)Requester IIES Only on error

• General Acknowledgement (ACK)

IIES Requester

Never

• Vaccination Record Query (VXQ)

IIES Responder

Never

• Query Acknowledgement (QCK) Responder IIES Only on error


IIES Responder

Never

• Query Acknowledgement (QCK) IIES Requester

Never

• Vaccination Query Response (VXX)

Responder IIES Only on error


IIES Responder

Never

• Vaccination Query Response (VXX)

IIES Requester

Never

• Vaccination Query Response (VXR)

Responder IIES Only on error


IIES Responder

Never

• Vaccination Query Response (VXR)

IIES Requester

Never


SIIS SIP Message Profile Static Definitions

The static definition portion of the message profile declares the usage and cardinality constraints for the constituent message elements of the SIIS SIP HL7 messages.

There is a static definition for each message type (VXQ, VXX, VXR, QCK, and ACK).

Each static definition includes a message level, segment level, and field level definition.

The static definition also includes a supported elements definition.

The supported elements definition is a field level definition containing supported message elements only.


SIIS SIP Message Profile Vocabulary Specification

The Health Level Seven (HL7) message profile vocabulary specification is a companion document to the California State Immunization Information System System Interface Project HL7 message profiles.

The specification contains the value sets for supported coded message elements identified in the profile.

The values presented in this specification are the primary code values to be used for coded message elements in the SIIS SIP message profile.

Fields with a data type of CE may include an equivalent code drawn from an alternate coding system. However, the values included in this specification must be used as the primary code.


Application Testingsd Dynamic View

User Interface Query Initiating Registry Mess ages Query Responding Registry

VXQ: Immunization Query Request1.0 Initiate Immunization

Query Request VXQ: Vaccine Query Mess age

2.0 FormulateImmunization Query

Response

VXX: Multiple Matches Response

QCK: No Matc hing Record Response

3.0 Handle No MatchingRecord Response

4.0 Handle MultipleMatches Response


VXR: Immunization Query Response

6.0 Handle ImmunizationQuery Response


VXQ: Vaccine Query Message w/responder's

patient identifier

5.0 Formulate ImmunizationQuery Response (known

patient)

VXX: Multiple Record Detail Display

[No Matchi ng Record]

[Single Matching Record]

[Multiple Matching Records]


act 2.0 Immunization Query Response

VXQ: Vaccine Query Mess age

(from Message Types)

Receive VXQ

2.2 Determine DataRetrival Strategy

2.3 Retrive Data fromRegional Database

2.4 Filter Data Retriv alResponse

2.5 Determine AppropriateResponse Message Type

2.6 Create QCK Message

2.7 Create VXR Message

2.8 Create VXX Message

«database»D3: Tra nsmission Log

Data base

(from Databases)

«database»D2: Vocabulary

Translation Database

(from Databases)

«database»D1: Regional System

Data base

(from Databases)

2.1 Update TransmissionLog

ActivityInitial

QCK: No Matching Record Response






Send QCK

Send VXR

Send VXX

ActivityFinal

[No Records]

[Single Record]

[Multiple Records]


Test Themes and Scenarios

Valid message syntax, content, and flow

Valid message syntax, content, and invalid flow

Valid message syntax, invalid content

Invalid message syntax

Data content scenarios

Technical problems


Test Scenarios Valid Message Syntax, Content, and Flow

This set of tests is intended to ensure that the systems produce the appropriate flow of messages, with the proper content, and in the proper syntax. These tests should not result in anything being written to the error log.

VXQ, QCKThis scenario is a query for a patient that is known to have no match in the remote system. The remote system is expected to respond with a QCK. The test data should include patients with varying ranges of matching confidence.

VXQ, VXRThis scenario is a query for a patient that is known to match a single patient in the remote system. The remote system is expected to respond with a VXR.The test data should include patients with varying ranges of matching confidence. A subset of patients should have locked records to test the “locked record” alerting process


Test Scenarios

Valid Message Syntax, Invalid ContentThis set of tests is intended to ensure that message construction and validation rules are properly implemented. These test are focused on content issues not syntax errors. The message profile and vocabulary specification are the source of validation rules.

Missing required message elementThis scenario involves the omission of required message elements (segments, fields, or components). The omitted items in this test scenario are those that are specified as optional in the standard but declared as required in the SIIS SIP Message Profile. Such an error should result in an ACK message being returned to the message originator and an entry in the error log.

Missing conditionally required message elementThis scenario involves the omission of conditionally required message elements (segments, fields, or components). The omitted items in this test scenario are those that are specified as optional in the standard but declared as conditionally required in the SIIS SIP Message Profile. Such an error should result in an ACK message being returned to the message originator and an entry in the error log.

The test data for this scenario must include a mixture of data values that meet the predicate conditions and others that do not meet the predicate conditions relevant for the conditional elements.


SIIS SIP HL7 Message Profile Links

SIIS SIP Message Profile Specification

http://www.ca-siis.org/images/docs/SIIS_SIP_HL7_MessageProfile_V1-1.pdf


http://www.ca-siis.org/images/docs/SIIS_SIP_HL7_Message_Profile_Vocabulary_Specification_V1-0.pdf


http://www.ca-siis.org/images/docs/SIIS_SIP_LogicalDataModel_v1-0.pdf



http://www.ca-siis.org/images/docs/SIIS_SIP_HL7_Message_Profile_Vocabulary_Specification_V1-0.pdf

http://www.ca-siis.org/images/docs/SIIS_SIP_LogicalDataModel_v1-0.pdf


Questions


Thank You

AbdulMalik ShakirPrincipal Consultant

Shakir Consulting1407 Foothill Blvd., Suite 145

La Verne, CA 91750

Office: (909) 596-6790 Mobile: (626) 644-4491Email: [email protected]

AbdulMalik Shakir Information Management Strategist

City of Hope1500 East Duarte RoadDuarte, CA 91010-3000

Office: (626) 256-4673 Mobile: (626) 644-4491Email: [email protected]

mailto:[email protected]

mailto:[email protected]

Version 2.x Messaging Conformance

Documents

Transcript of Version 2.x Messaging Conformance