Version 2.x Messaging Conformance: Abdul-Malik Shakir HL7 Working Meeting January 2011 - Sydney, AU

Version 2.
x Messaging
Conformance
Abdul-Malik Shakir
Principal Consultant, Shakir Consulting
HL7 Working Meeting

January 2011 – Sydney, AU
© 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.
Abdul-Malik Shakir
Principal Consultant, Shakir Consulting, La Verne, CA
HL7 Member since 1991

 Principal Consultant with Shakir Consulting
 Chief Technical Architect with Cal2Cal Corporation
 Co-Chair of the HL7 Education Committee
 Member of the HL7 Architectural Review Board
 Member of the HL7 Public Health and Emergency Response Committee
 Member of the HL7 Regulated Clinical Research Information Management Committee
 Member of the HL7 Modeling and Methodology Committee
Session Outline
Part I Part II
 Background  Messaging Workbench
 HL7: What, and Why  What and Why
 Message Profile:  Features and Use
Why and When  Reports and Examples
 Message Profiles:  Contacts and Help
 What and How  Sample Projects
 Concepts and Constituents  CADHS ELR
 Levels and Examples  CA SIIS SIP
Health Level Seven
What and Why
An HL7 Messaging Scenario: Why
Program Order Entry
Order Entry Dataset
Module
User Interface
Application
Application
System
System Message Message
Creation Parsing
Transaction
Lab Result
Transaction
Lab Order
A to B B to A
Transformation Transformation
Message Message Laboratory

Laboratory Parsing Creation
Application
Application
System
System User Interface
Program
Dataset
Module
Reaching the Limits of Application Interfaces
Decision Electronic
Lab
Support Health Record
Radiology
Pharmacy
? ?
External Administrative
Order Entry ADT
Systems Systems
?
Enterprise
Systems
Health Level Seven: Why
• The number of interfaces between N systems is given by the formula

I = (N2-N)/2.
• Linking 432 systems only needs 1 interface, (4
(22 - 4)
(3 2) / 2 = 631 ;
3)
• 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
Health Level Seven: Why
Interfaces Required
120
100
80
Interfaces
60
40
20
0
2 3 4 5 6 7 8 9 10 11 12 13 14 15
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
System s
Tolerable Painful Intolerable

Divide and Conquer / Component Reuse
Patient Visit PV1

(PV1) Patient NK1
Demographics
(PID) PID
Next of Kin
IN1
(NK1)
Guarantor OBX
Insurance (GT1) GT1
(IN1) OBR
Patient
Demographics
(PID)
Patient Visit
(PV1) DATA
Next of KIN
(NK1)
Abstract Message Specification
Segment ID Segment Name

MSH Message Header
EVN Event Type
PID Patient Identification
[PD1] Additional Demographics
[ { NK1 } ] Next of Kin /Associated Parties
PV1 Patient Visit
[ PV2 ] Patient Visit - Additional Info.
…
[ { GT1 } ] Guarantor
[ ] optional
[
{ IN1 Insurance
[ IN2 ] Insurance Additional Info. { } may repeat
[ IN3 ] Insurance Add'l Info - Cert.
}
]
…
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
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 Elements
Relationships
Message
Specification
One to One One to Many Many to Many
Composite
Segment Group Data Type Code System
Data Type
Data Type
Message Segment Data Element Code System Term
Component
Segment Segment Field Code Table Code Table Item
Sample HL7 v2.x Message
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
Segments Delimiters
 MSH: Message Header | Field
 PID: Patient Identification ^ Component
 OBR: Observation Request
& Subcomponent
 OBX: Observation Result
~ Repetition
\ Escape Character
Message Profiles
Why and When
Reveal Assumptions
Do you Yes, I do
play play
football? football.
Revealing assumptions is an essential component of effective communication.
Reveal Assumptions
MSH
EVN MSH
PID Do you Yes, I EVN
[PD1] use use PID
[ { NK1 } ] [ NK1 ]
HL7? HL7. OBX
Message Profiles are an effective means of documenting our assumptions

about message structures
Reduce Ambiguity
MSH
EVN
PID
[PD1]
[ { NK1 } ]
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
MSH MSH
EVN EVN
PID PID
[PD1] [ NK1 ]
[ { NK1 } ] OBX
Sharing message profiles provides

an opportunity to identify and reconcile conflicts in our understanding
and to validate our assumptions about message structures.
Consolidate Viewpoints
Canonical Message Profile
MSH
EVN
{ PID }
[PD1]
[ { NK1 } ]
[ { GT1 } ]
[ OBX ]
MSH MSH MSH

EVN EVN EVN
PID PID { PID }
[PD1] [ NK1 ] [PD1]
[ { NK1 } ] OBX [ { GT1 } ]
Message Profile Message Profile Message Profile
Value of Message Profiling
 Reveal Assumptions
 Reduce Ambiguity
 Highlight Conflicts
 Consolidate Viewpoints
Message Profiles
What 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
Conceptual Overview
Message Profile = Static Profile + Dynamic Profile
Initiating Message
Response Message
Critical Care Unit
ADT System
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
HL7 Message Structure Message Profile
MSH MSH
EVN Segments/Segment Groups:
EVN •Usage (Optionality)
PID PID •Cardinality (min, max)
NK1 NK1 NK1 NK1 NK1 ... NK1 NK1 NK1 NK1 NK1
PV1 PV1
...
Fields/Components:
PV2 PV2
- Usage (Optionality)
...
OBX ...
OBX - Cardinality (min, max)
- Value Sets/Coding system
AL1 AL1 - 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
Receiver Responsibility
MSH-15,16
BED1 OFF BE
D 1 OF BED1 OFF
BED 1OFF BE
D 1 OF BE
D 1 OF
BED 1OFF ED1 OFF

B
BE
D 1 OF
BED 1OFF
BE
D 1OF
F
POTA
SS
I UM3. 5
-5.0
POTASS
IUM3.5-5.0
BED 1OFF
POT
ASS
I UM3.5- 5
.0
OTA
P SS
IUM 3
.5-5.0
BED1 OF BED 1 OFF

POT
ASS
I UM3.5- 5
.0
BED 1 OFF
BE
D 1OFF
BED1 OF
Accept + App ACK

Vectra
XU
5/90C
Critical Care Unit

HIS/CIS
No ACK
A/D/T System
BED1 OFF BE
D 1 OF BED1 OFF
BED 1OFF BE
D 1 OF BE
D 1 OF
Accept Ack
BED 1OFF ED1 OFF
B
BE
D 1 OF
BED 1OFF
BE
D 1OF
F
POTA
SS
I UM3. 5
-5.0
POTASS
IUM3.5-5.0
BED 1OFF
POT
ASS
I UM3.5- 5
.0
OTA
P SS
IUM 3
.5-5.0
BED1 OF BED 1 OFF

POT
ASS
I UM3.5- 5
.0
BED 1 OFF BE
D 1OFF
BED1 OF
Vectra
XU
5/90C
Clinical Data
Repository
Order Filling Application
How it all ties together
1 Use Case Model
Phys ician
1.1 Use Case: Admit/Visit Notification : ADT Sy stem : ADT Notifi cation
Recipient
authorizes Registrar
Pat ient is subject of triggers
2. Dynamic Interaction Model ADTÂ01
ACK Â01
sends notificat ion receives notific ation
A dmit/ Visit Notific ation
3 Dynamic Definition: ADT/ACK (Event A01)
ADT Sy stem ADT Notificat ion
Recipient 3.1 ADTÂ01 Interaction Model
Use Case Model 3.2 ACKÂ01
Segment ADT Message Usage Cardinality Chapter 4 Static Definition: - Message Level -
MSH
EVN
Message Header
Event Type
R
R
[1..1]
[1..1]
2
3 ADT/ACK (event A01)
PID Patient Identification R [1..1] 3
[ PD1 ] Additional Demographics X [0..0] 3
[{ ROL }]
[{ NK1 }]
Role
Next of Kin / Associated
X
RE
[0..0]
[0..3]
12
3 4.1 ADTÂ01
Parties
[
PV1
PV2 ]
Patient Visit
Patient Visit - Additional
R
RE
[1..1]
[0..1]
3
3
4.2 ACKÂ01
Info.
[{ ROL }] Role X [0..0] 12
[{
[{
DB1
OBX
}]
}]
Disability Information
Observation/Result
X
X
[0..0]
[0..0]
3
7
5 Static Defintiion - Segment Level
[{ AL1 }] Allergy Information RE [0..*] 3
[{ DG1 }] Diagnosis Information X [0..0] 6
[
[{
DRG ] Diagnosis Related Group X
X
[0..0]
[0..0]
6 5.1 MSH – Message Header Segment Definition
}]
PR1
[{ ROL
Procedures
Role
X
X
[0..0]
[0..0]
6
12 5.2 EVN - Event Type Segment Definition
}]
[{ GT1 }] Guarantor X [0..0] 6
5.3 PID (Y) - Patient Demographics Segment
[{
IN1
[ IN2 ]
Insurance
Insurance Additional Info.
X
X
X
[0..0]
[0..0]
[0..0]
6
6
Definition
5.4 PD1 – Patient Additional Demographic
Dynamic Definition
[{ IN3 Insurance Additional Info - X [0..0] 6
}] Cert.
[{ ROL Role X [0..0] 12
}]
}]
Segment Definition
[ ACC ]
[ UB1 ]
Accident Information
Universal Bill Information
X
X
[0..0]
[0..0]
6
6 5.5 NK1 - Next of kin Segment Definition
[ UB2 ] Universal Bill 92 Information X [0..0] 6
[ PDA ] Patient Death and Autopsy X [0..0] 3 5.6 PV1 (2) - Admit Visit Info Segment SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME
Definition 1
2
4
20
SI
CX
X
RE [1..1]
00104
00105
Set ID - PID
Patient ID
Static Definition – Message Level 5.7 AL1 - Allergy Segment Definition

3
4
5
20
20
48
CX
CX
XPN
R
X
R
[1..*]
[1..*]
00106
00107
00108
Patient Identifier List
Alternate Patient ID - PID
Patient Name
5.8 MSA - Message Acknowledgment Segment 6

7
48
26
XPN
TS
RE
RE
[1..*] 00109
00110
Mother’s Maiden Name
Date/Time of Birth
Definition 9
8
10
1
48
80
IS
XPN
CE
RE
X
X
0001
0005
00111
00112
00113
Sex
Patient Alias
Race
5.9 ERR - Error Segment Definition 11

12
106
4
XAD
IS
RE
X
[1..3]
0289
00114
00115
Patient Address
County Code
13 40 XTN RE [1..3] 00116 Phone Number - Home
14 40 XTN RE [1..3] 00117 Phone Number - Business
6 Static Definition - Field Level 15

16
60
80
CE
CE
X
X
0296
0002
00118
00119
Primary Language
Marital Status
17 80 CE X 0006 00120 Religion
18 20 CX X 00121 Patient Account Number
6.1 Table 0001 – Sex 19

20
16
25
ST
DLN
RE
X
00122
00123
SSN Number - Patient
Driver's License Number - Patient
6.2 Table 0002 – Marital Status 21

22
20
80
CX
CE
X
X 0189
00124
00125
Mother's Identifier
Ethnic Group
23 60 ST RE 00126 Birth Place
6.3 Table 0003 – Event Type Code 24
25
1
2
ID
NM
X
X
0136 00127
00128
Multiple Birth Indicator
Birth Order
6.4 Table 0004 – Patient Class 26

27
80
60
CE
CE
X
X
0171
0172
00129
00130
Citizenship
Veterans Military Status
28 80 CE X 0212 00739 Nationality
6.5 Table 0005 – Race 29 26 TS X 00740 Patient Death Date and Time
Static Definition – Field Level 6.6 Table 0006 – Religion

30 1 ID X 0136 00741 Patient Death Indicator
Vocabulary 6.7 Table 0007 – Admission Type Static Definition – Segment Level
6.8 Table 0008 – Acknowledgement Code
6.9 Table 0009 – Ambulatory Status
Message Profiles
Concepts and Constituents
Profiling Concepts
 Profile Types
 HL7 Standard
 Constrainable
 Implementable
 Generic term ‘message element’ used
 Segment groups
 Segments
Message
 Fields
Constituents
 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 Examples
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 ‘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 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 R, RE, O*, C, CE, X O is only permitted for

Compatibility 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 Profiles
Levels 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
[{ ROL }] Role X [0..0] 12
[{ NK1 }] Next of Kin / Associated RE [0..3] 3
Parties
PV1 Patient Visit R [1..1] 3
[ PV2 ] Patient Visit - Additional RE [0..1] 3
Info.
[{ ROL }] Role X [0..0] 12
[{ DB1 }] Disability Information X [0..0] 3
[{ OBX }] Observation/Result X [0..0] 7
[ DRG ] Diagnosis Related Group X [0..0] 6
[{ X [0..0]
PR1 Procedures X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]
[{ X [0..0]
IN1 Insurance X [0..0] 6
[ IN2 ] Insurance Additional Info. X [0..0] 6
[{ IN3 }] Insurance Additional Info - X [0..0] 6
Cert.
[{ ROL }] Role X [0..0] 12
}]
[ ACC ] Accident Information X [0..0] 6
[ UB1 ] Universal Bill Information X [0..0] 6
[ PDA ] Patient Death and Autopsy X [0..0] 3
Parties
[ PV2 ] Patient Visit - Additional RE [0..1] 3
Info.
[{ ROL }] Role X [0..0] 12
Parties
[ PV2 ] Patient Visit - Additional R [1..1] 3
Info.
[{ ROL }] Role X [0..0] 12
[{ DB1 }] Disability Information X [0..0] 3
[{ OBX }] Observation/Result X [0..0] 7
[ DRG ] Diagnosis Related Group X [0..0] 6
[{ X [0..0]
PR1 Procedures X [0..0] 6
[{ ROL }] Role X [0..0] 12
}]
[{ RE [0..3]
IN1 Insurance R [1..1] 6
[ IN2 ] Insurance Additional Info. RE [0..1] 6
[{ IN3 }] Insurance Additional Info - X [0..0] 6
Cert.
[{ ROL }] Role X [0..0] 12
}]
[ ACC ] Accident Information RE [0..1] 6
[ UB1 ] Universal Bill Information X [0..0] 6
[ PDA ] Patient Death and Autopsy X [0..0] 3
Parties
[ PV2 ] Patient Visit - Additional R [1..1] 3
Info.
[{ 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 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
SEQ LEN DT Usage Cardinality TBL# ITEM# ELEMENT NAME
6 250
1 XPN
4 SI OX Y 00104 Set ID 00109
- PID Mother’s Maiden Name
7 262 20
TS CX ORE [0..1] Y 00105 Patient00110
ID Date/Time of Birth
3 20 CX R [1..*] 00106 Patient Identifier List
8 1 IS O Y 0001 00111 Sex
4 20 CX X 00107 Alternate Patient ID - PID
9 250
5 XPN
48 XPN BR [1..*] 00108 Patient00112
Name Patient Alias
10 6
250 48
CE XPN ORE [0..*] 00109
0005Mother’s Maiden Name
00113 Race
7 26 TS RE [0..*] 00110 Date/Time of Birth
11 250 XAD O Y 00114 Patient Address
8 1 IS RE [0..*] 0001 00111 Sex
12 49 IS XPN
48 BX 0289
00112 Patient00115
Alias County Code
13 10
250 80
XTN CE OX Y 0005 00113 Race 00116 Phone Number - Home
11 106 XAD RE [0..3] 00114 Patient Address
14 250 XTN O Y 00117 Phone Number - Business
12 4 IS X 0289 00115 County Code
15 250
13 CE
40 XTN ORE [0..3] 0296
00116 Phone 00118 Primary Language
Number - Home
16 14
250 40
CE XTN ORE [0..3] 00117
0002Phone 00119
Number - Business
Marital Status
15 60 CE X 0296 00118 Primary Language
17 250 CE O 0006 00120 Religion
16 80 CE X 0002 00119 Marital Status
18 250
17 CX CE
80 OX 00121
0006 00120 Religion Patient Account Number
19 16
18 ST CX
20 BX 00121 Patient00122 SSN
Account Number Number - Patient
19 16 ST RE [0..1] 00122 SSN Number - Patient
20 25 DLN B 00123 Driver's License Number - Patient
20 25 DLN X 00123 Driver's License Number - Patient
21 250
21 CX CX
20 OX Y 00124
00124 Mother's Identifier Mother's Identifier
22 250
22 CE CE
80 OX Y 0189
0189 00125 Ethnic 00125
Group Ethnic Group
23 60 ST RE [0..1] 00126 Birth Place
23 250 ST O 00126 Birth Place
24 1 ID X 0136 00127 Multiple Birth Indicator
24 125 2ID NM OX 0136
00128 00127 Multiple Birth Indicator
Birth Order
25 226 NM
80 CE OX 00128
0171 00129 Citizenship Birth Order
27 60 CE X 0172 00130 Veterans Military Status
26 250 CE O Y 0171 00129 Citizenship
27 250
29 CE TS
26 OX 0172
00740 Patient00130
Death DateVeterans
and Time Military Status
28 250
30 CE
1 ID BX 0212
0136 00741 Patient00739 Nationality
Death Indicator
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
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
 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.
Compliance Conformance  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.
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 Workbench
What 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
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 Workbench
Features 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 Workbench
Reports 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 Workbench
Contacts 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
peter.rontey@med.va.gov
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
Inbound Inbound Canonical Outbound Outbound
Message Profile Message Mapping Message Profile Message Mapping Message Profile
Inbound Transform Canonical Transform Outbound

Lab Message Lab Message
Laboratory Laboratory Laboratory
Supplier Consumer
Message Translate Message Translate Message
Knowledge Knowledge
Object Graph
Management Management
Generation
Service Service
Laboratory
Canonical Laboratory Business
Message Object Additional Data
Message Profile Message Intelligence
Model Sources
Objects Application
Object Relational Object Extract, Business

Map Relational Transform, Intelligence
Mapping and Load Application
CA Public Health
HL7 RIM & ELR Database Laboratory Extract, Business
Logical Data Laboratory
CDC PHLDM Design Model Message Transform, Intelligence
Model Datamart
Respository and Load Application

Supplier Consumer
Inbound Message Processing Outbound Message Processing

Knowledge Knowledge
Object Graph
Generation
Service Service
Laboratory
Model Sources
Objects Application
Data Persistence
Business Intelligence
CA Public Health
Model Datamart
Respository and Load Application

Supplier Consumer
Knowledge Knowledge
Object Graph
Generation
Service Service
Laboratory
Model Sources
Objects Application

CA Public Health
Model Datamart
Repository and Load Application
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
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)
Project Scope
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.
Problem Statement
 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.
Current Processes
 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 Limitations
 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.
SIIS SIP SOLUTION
 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.
HL7 Message Profiling
ad Dynamic View
Health Level Seven CDC / AIRA SIIS SIP Project Team Regional Registry
HL7 v 2.5 Messaging

Prepare IZ Implementation
Standard Guide
IZ Messaging Preliminary Segment

Prepare Preliminary
Implemenation Guide Lev el Profile
Segment Lev el Profile
Prepare SIIS SIP Map Profile to Regional

Conceptual Data Model Systems
SIIS SIP Conceptual Regional System to

Prepare Final Segment
Data Model Lev el Profile Profile Mapping
Final Segment Lev el

Prepare SIIS SIP Logical
Data Model Profile
SIIS SIP Logical Data

Prepare SIIS SIP Phase I
Model Message Lev el Profiles
SIIS SIP Phase I

Prepare SIIS SIP
Vocabulary Specification Message Lev el Profiles
SIIS SIP Vocabulary

Specification
ad Dynamic View
 Prepare IZ messaging implementation guide

Health Level Seven
HL7 v 2.5 Messaging

CDC / AIRA SIIS SIP Project T eam Regional Registry
Prepare IZ Implementation
Standard Guide
 Prepare preliminary segment level profile

IZ Messaging Preliminary Segment
Prepare Preliminary
Implemenation Guide Lev el Profile
Segment Lev el Profile
 Prepare SIIS SIP conceptual data model

Prepare SIIS SIP Map Profile to Regional
 Map preliminary profile to regional IZ systems

Conceptual Data Model Systems
SIIS SIP Conceptual Regional System to

Prepare Final Segment
Prepare final segment level profile

Data Model Profile Mapping

Lev el Profile
 Prepare SIIS SIP logical data model Prepare SIIS SIP Logical
Data Model
Final Segment Lev el
Profile
 Prepare SIIS SIP phase I message level profiles

SIIS SIP Logical Data
Model
Prepare SIIS SIP Phase I
Message Lev el Profiles
 Prepare SIIS SIP vocabulary specification

SIIS SIP Phase I
Prepare SIIS SIP
Message Lev el Profiles
Vocabulary Specification
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; and
4. 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 Reference
PID 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
SIIS SIP Conceptual Data Model
cd Logical Model Patient Demographics
PersonPostalAddress
streetOrMailingAddress: char(120)
streetName: char(50) Person PersonTelecommunicationAddress
dwellingNumber: char(12) surname: char(50) telecommunicationUseCode: char(3)
city: char(50) givenName: char(30) areaCityCode: numeric(5)
stateOrProvince: char(50) secondAndFurtherGivenNamesOrInitialsThereof: char(30) phoneNumber: numeric(9)
0..* 1..* 1..* 0..*
zipOrPostalCode: char(12) suffix: char(20) extension: numeric(5)
addressType: char(3) anyText: char(199)
countyParishCode: char(20)
countryCode: char(3)
1 1 1 1
0..* 0..*
PersonIdentifier
PersonAlternateName
id: char(15)
typeCode: char(1)
idType: char(6)
surname: char(50)
namespaceId: char(20)
givenName: char(30)
secondAndFurtherGivenNamesOrInitialsThereof: char(30)
suffix: char(20)
0..1
Patient
dateTimeOfBirth: timestamp
birthState: char(60) Facility
0..* multipleBirthIndicator: char(1)
administrativeSex: char(1) identifier: char(20)
PatientRelationship
birthOrder: numeric(2) name: char(50)
identifier: char(20) deathDateTime: timestamp assigningAuthorityId: char(20)
text: char(199) deathIndicator: char(1) namespaceId: char(20)
contactRoleIdentifier: char(20) lastUpdateDateTime: timestamp streetAddress: char(120)
contactRoleText: char(199) 1..* 1 lastUpdateFacility: char(20) 0..* 1 city: char(50)
livingArrangement: char(2) PublicityCodeID: char(20) stateOrProvince: char(50)
publicityCodeEffectiveDate: datetime zipOrPostalCode: char(12)
publicityCodeText: char(199) country: char(3)
protectionIndicator: char(1) addressType: char(3)
protectionIndicatorEffectiveDate: datetime
immunizationRegistryStatus: char(1)
immunizationRegistryStatusEffectiveDate: datetime
1
1
1..*
0..*
PatientRace
PatientLanguageAbility
1..*
identifier: char(20)
identifier: char(20)
text: char(199) PatientEthnicGroup text: char(199)
identifier: char(20) preferenceIndicator: char(1)
text: char(199)
Regional System to Segment Profile Mapping
Allowable
Supported?
Source values
Mapping
Element Name Source Table Source Column(s) Data type (attach
Comments
and length reference if
necessary)
PID DO NOT MAP

SetID-PID Y
PatientIdentifierList DO NOT MAP
ID Y Patient pt_id int
assigningauthority DO NOT MAP
namespaceID Y
PatientName DO NOT MAP
familyname DO NOT MAP
surname 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'sMaidenName DO NOT MAP
surname Y Patient birth_mom_mname char(20)
Date/TimeOfBirth DO NOT MAP
Date/Time Y Patient dob datetime
AdministrativeSex Y Patient sex char(1)
PatientAlias DO NOT MAP
surname N
givenname N
secondandfurthergivennamesorinitialsthereof N
suffix(e.g.,JRorIII) N
Race DO NOT MAP
identifier Y Patient race char(2)
text Y
nameofcodingsystem Y
PatientAddress DO NOT MAP
streetaddress(SAD) DO NOT MAP
streetormailingaddress Y PatientAddress addr_1, addr_2 varchar(35)
streetname N
dwellingnumber 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)
Regional System to Segment Profile Mapping
Profile Usage
VAXTRACK
COMMENT
Imperial
BARR
CVIIS
INNC
RIDE
SDIR
LINK
CCIR
SFT
Path Element Name
PID PID
PID.1 SetID-PID Y Y N Y Y N Y Y Y N Y
PID.3 PatientIdentifierList
PID.3.1 ID Y Y N Y Y Y Y Y Y Y Y
PID.3.4 assigningauthority
PID.3.4.1 namespaceID Y Y N Y Y Y Y Y Y N Y
PID.5 PatientName
PID.5.1 familyname
PID.5.1.1 surname Y Y Y Y Y Y Y Y Y Y Y
PID.5.2 givenname Y Y Y Y Y Y Y Y Y Y Y
PID.5.3 secondandfurthergivennamesorinitialsthereof Y Y Y Y Y Y Y Y Y Y Y
PID.5.4 suffix(e.g.,JRorIII) Y Y Y Y Y Y Y Y Y N Y
PID.6 Mother'sMaidenName
PID.6.1 familyname
PID.6.1.1 surname Y Y Y Y Y Y Y Y Y Y Y
PID.7 Date/TimeOfBirth
PID.7.1 Date/Time Y Y Y Y Y Y Y Y Y Y Y
PID.8 AdministrativeSex Y Y Y Y Y Y Y Y Y Y Y
PID.9 PatientAlias
PID.9.1 familyname
PID.9.1.1 surname N N Y N Y Y Y/Y Y Y Y Y
PID.9.2 givenname N N Y N Y Y Y/Y Y Y Y Y
PID.9.3 secondandfurthergivennamesorinitialsthereof N N Y N Y N Y/Y Y Y Y Y
PID.9.4 suffix(e.g.,JRorIII) N N Y N Y N Y/Y N Y N Y
PID.10 Race
PID.10.1 identifier Y Y Y Y Y Y Y Y Y Y Y
PID.10.2 text Y N Y Y Y N Y Y Y Y Y
PID.10.3 nameofcodingsystem Y Y Y Y Y N Y Y Y N Y
PID.11 PatientAddress
PID.11.1 streetaddress(SAD)
PID.11.1.1 streetormailingaddress Y Y Y Y Y Y Y Y Y Y Y
PID.11.1.2 streetname N N N N N N N N N Y N
PID.11.1.3 dwellingnumber N N N N N N N N N Y N
PID.11.3 city Y Y Y Y Y Y Y Y Y Y Y
PID.11.4 stateorprovince Y Y Y Y Y Y Y Y Y Y Y
PID.11.5 ziporpostalcode Y Y Y Y Y Y Y Y Y Y Y
PID.11.7 addresstype Y Y Y Y Y N Y Y Y Y Y
PID.11.9 county/parishcode Y Y Y Y Y Y Y Y Y Y Y
Final Segment Level Profile
Message Tree Seq ETyp DTyp Usage Min Max Table

PID 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
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 *
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
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
SIIS SIP Logical Data Model
cd Logical Model Patient Demographics
PersonPostalAddress
*PK idNumber: int
*FK personIdNumber: int PersonTelecommunicationAddress
Person
addressLine1Text: char(120) *PK idNumber: int
addressLine2Text: char(120) *PK idNumber: int *FK personIdNumber: int
cityName: char(50) (personIdNumber = idNumber) surname: char(50) telecommunicationUseCode: char(3)
stateCode: char(50) givenName: char(30) (personIdNumber = idNumber) areaCode: numeric(5)
postalCode: char(12) 0..* 1 middleName: char(30) 1 0..* * phoneNumber: numeric(9)
addressTypeCode: char(3) nameSuffix: char(20) extensionNumber: numeric(5)
countyCode: char(20) 1 concatenatedTelecomNumber: char(199)
PK
1
FK + PK_Person(int) FK
+ FK_PersonPostalAddress_Person(int) (personIdNumber = idNumber) + FK_PersonTelecommunicationAddress_Person(int)
1
PK 1
+ PK_PersonPostalAddress(int)
(personIdNumber = idNumber)
PersonAlternateName
PersonIdentifier
*PK idNumber: int 0..*
*FK personIdNumber: int *PK idNumber: int
* typeCode: char(1) FK organizationIdNumber: int
* surname: char(50) * idCode: char(15)
(administeringProvideridNumber = idNumber)
givenName: char(30) *FK personIdNumber: int
middleName: char(30) idTypeCode: char(6)
nameSuffix: char(20) (patientIdNumber = idNumber) * idAssigningAuthority: char(20)
0..*
* statusCode: char(2)
FK
FK
+ FK_PersonAlternateName_Person(int)
+ FK_PersonIdentifier_Organization(int)
+ FK_PersonIdentifier_Person(int)
VaccineAdministration 0..*
0..*
FK administeringProvideridNumber: int
*FK patientIdNumber: int Patient
*PK idNumber: int
*PK idNumber: int
*FK FacilityIdNumber: int 0..*
FK facilityIdNumber: int
* doseSequenceNumber: numeric(4) PatientRelationship
* birthDate: datetime
* substanceIdCode: char(20)
birthStateCode: char(60) *PK idNumber: int
* startDateTime: datetime
multipleBirthIndicator: char(1) *FK patientIdNumber: int
* endDateTime: datetime
(patientIdNumber = * sexCode: char(1) * typeCode: char(20)
* substanceAdministeredAmount: numeric(20)
idNumber) deathIndicator: char(1) *FK patientIdNumber: int
* routeIdCode: char(20) (patientIdNumber =
* raceCode: char(20) *FK personIdNumber: int
* substanceUnitOfMeasureCode: char(20) 0..* 1 idNumber)
* ethnicityCode: char(20) * effectiveDate: datetime
* siteIdCode: char(20) 1 1..*
* allowableReminderTypeCode: char(20)
substanceLotNumber: char(20) FK
* primaryLanguageCode: char(20) (organizationIdNumber = idNumber)
* substanceDosageFormIdCode: char(20)
recordSharingConsentIndicator: char(1) + FK_PatientRelationship_Patient(int)
* substanceManufacturerIdCode: char(20)
immunizationRegistryStatusCode: char(1) + FK_PatientRelationship_Person(int)
* systemEntryDateTime: datetime
PK
FK + PK_PatientRelationship(int)
FK
+ FK_Patient_Facility(int)
+ FK_VaccineAdministration_Facility(int)
PK
+ FK_VaccineAdministration_Patient(int) 0..*
+ FK_VaccineAdministration_Person(int) + PK_Patient(int)
PK 0..*
+ PK_VaccineAdministration(int) (FacilityIdNumber = idNumber)
normally receives
1 care at
(vaccineAdministrationIdNumber = idNumber)
Facility
1
*PK idNumber: int 1
FK providerOrganizationIdNumber: int
Organization
addressLine1Text: char(120)
addressLine2Text: char(120) *PK idNumber: int
0..*
cityName: char(50) idCode: char(20)
TreatmentRefusal statePostalCode: char(50) (providerOrganizationIdNumber * assigningAuthorityIdCode: char(20)
postalCode: char(12) = idNumber) * name: char(50)
*PK reasonIdCode: char(20) countryCode: char(3) 0..* 0..1
*pfK vaccineAdministrationIdNumber: int addressTypeCode: char(3) PK
+ PK_ProvderOrganization(int)
FK FK
+ FK_TreatmentRefusal_VaccineAdministration(int) 0..1
+ FK_Facility_ProviderOrganization(int)
PK PK
+ PK_TreatmentRefusal(char, int) + PK_Facility(int)
1
(identifierAssigningAuthority = idNumber)
0..*
FacilityAlternateIdentifier
*PK facilityAlternateId: char(20)
*pfK FacilityIdNumber: int
FK identifierAssigningAuthority: int
identifierTypeCode: bigint
FK 0..*
+ FK_FacilityAlternateIdentifier_Facility(int)
+ FK_FacilityAlternateIdentifier_Organization(int)
PK
+ PK_FacilityAlternateIdentifier(char, int)
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 Model
The 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 Model
The 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 Requirements
The 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.
 Cardinality
Cardinality 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 Specification
Vocabulary 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
1.0 Immunization
3.0 Vaccine
Vaccine Record Update History Query
Record Update Prov ider Organization
Immunization History Request
Query Response
Update Confirmation
Local Registry User

Patient Information Update
Update Confirmation
2.0 Patient
Demographic
Update
SIIS Analysis Report SIIS Analysis Report
SIIS Registry
Administration
SIIS Analysis Report

4.0 Immunization
SIIS Analysis Report Statistical Analysis
Local Registry Trusted Third Parties

Administration
SIIS SIP Activity Model
ad InteractionActiv ityModel
Requesting Registry System SIIS SIP Immunization Information Exchange System Responding Registry System
1.1 Request Immunization

1 2.2 Validate Immunization
«message» «datastore»
Data Data Request Message
M.01 Immunization Data D.04 Immunization
Request (VXQ) Registry
3
[Valid Message]
2
[Invalid Message]
2.3 Route Immunization «message» 3.1 Retriv e Requested

2.4 Notify System «message» Data Request Message Immunization Data
M.03 Immunization
Administrator M.02 Request Error Message
Data Request (VXQ)
(ACK)
[Desired Record Selected]
5.1 Refine Demographic «message»

Data M.08 No Matching Record
Message (QCK) 3.2 Retrival
Result?
4
[Desired Record Not Present]
4.3 Route Response
5.2 Select Desired Record «message» Message [No Matching Record]
M.09 Multiple Matching «message»
Record Message (VXX) 3.2.1 Return "No Matching
M.04 No Matching Record" Response
Record Response (QCK)
«message» [Valid Message]

5.3 Merge Immunization
Data w ith existing data M.10 Requested Immunization
Data Message (VXR) «message» [Multiple Matching Records]
4.2 Validate Response 3.2.2 Return "Multiple
Message M.05 Multiple Matching Matching Records"
Records Response (VXX) Response
«datastore» 6
D.01 Immunization
Registry «message»
3.2.3 Return Requested [Single Matching Record]
M.06 Requested Immunization Data
Immunization Data (VXR)
5
«message»
4.4 Notify System
[Invalid Message] M.07 Response Message Administrator
Error (ACK)
SIIP SIP Interaction Model
sd Interactions
Requesting Registry SIIS SIP Immunization Responding Registry

System Information Exchange System
System
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 Requirements
Message Source Destination Acknowledgment
• 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
• General Acknowledgement (ACK) IIES Responder Never
• Query Acknowledgement (QCK) IIES Requester Never
• Vaccination Query Response (VXX) Responder IIES Only on error
• Vaccination Query Response (VXX) IIES Requester Never
• Vaccination Query Response (VXR) Responder IIES Only on error
• 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 Static
Definitions

SIP HL7 messages.
VXR, QCK, and ACK).
definition.
SIIS SIP Message
Profile Static
Definitions
SIP HL7 messages.
VXR, QCK, and ACK).
definition.
SIIS SIP Message Profile
 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.
SIIS SIP Message Profile
 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 Testing
sd Dynamic View
User Interface Query Initiating Registry Mess ages Query Responding Registry
VXQ: Immunization Query Request

1.0 Initiate Immunization 2.0 Formulate
Query Request VXQ: Vacci ne Query Immunization Query
Mess age Response
3.0 Handle No Matching

Record Response QCK: No Matc hing [No Matchi ng Record]
Record Response
VXR: Immunization Query Response

6.0 Handle Immunization [Single Matching Record]
Query Response VXR: Immunization Query
Response
VXX: Multiple Matches Response

4.0 Handle Multiple 5.0 Formulate Immunization
Matches Response VXQ: Vacci ne Query Query Response (know n
Message w /responder's patient)
patient identifier
VXX: Multiple Record Detail Display VXX: Multiple Matches [Multiple Matching Records]
Response
act 2.0 Immunization Query Response
Rec eiv e VXQ: Vacci ne Query

VXQ Mess age
ActivityInitial
(from Message Types)
2.1 Update Transmission 2.2 Determine Data

Log Retriv al Strategy
2.3 Retriv e Data from

«database» Regional Database «database»
D3: Tra nsmissi on Log D1: Regional S ystem
Data base Data base
(from Databases) (from Databases)
2.4 Filter Data Retriv al 2.6 Create QCK Message

Response QCK: No Matching Record
Response Send QCK
[No Re cords]
2.5 Determine Appropriate 2.7 Create VXR Message

Response Message Type VXR: Immuniz ation Query
Response
[Single Record]
[Multiple Records]
2.8 Create VXX Message

VXX: Multiple Matches «database»
Response D2: V ocabulary Send VXR
Translation Database
(from Message Types) (from Databases)
Send VXX
ActivityFinal
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, QCK
This 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, VXR
This 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 Content

This 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 element
This 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 element
This 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
SIIS SIP Vocabulary Specification
http://www.ca-siis.org/images/docs/SIIS_SIP_HL7_Message_Profile_Vocabulary_Specification_V1-0.pdf
SIIS SIP Logical Data Model
http://www.ca-siis.org/images/docs/SIIS_SIP_LogicalDataModel_v1-0.pdf
Questions
Thank You
Abdul-Malik Shakir Abdul-Malik Shakir

Principal Consultant Information Management Strategist
Shakir Consulting City of Hope

1407 Foothill Blvd., Suite 145 1500 East Duarte Road
La Verne, CA 91750 Duarte, CA 91010-3000
Office: (909) 596-6790 Mobile: (626) 644-4491 Office: (626) 256-4673 Mobile: (626) 644-4491
Email: AbdulMalik@ShakirConsulting.com Email: ashakir@coh.org

Version 2.x Messaging Conformance: Abdul-Malik Shakir HL7 Working Meeting January 2011 - Sydney, AU

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Version 2.x Messaging Conformance: Abdul-Malik Shakir HL7 Working Meeting January 2011 - Sydney, AU

Uploaded by

Copyright:

Available Formats

Version 2.

HL7 Working Meeting

HL7 Member since 1991

Message Message Laboratory

• The number of interfaces between N systems is given by the formula

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

Tolerable Painful Intolerable

Patient Visit PV1

Segment ID Segment Name

SEQ - position within segment

 An HL7 message specification is an ordered collection of one or more segment groups

Segment Segment Field Code Table Code Table Item

Revealing assumptions is an essential component of effective communication.

Message Profiles are an effective means of documenting our assumptions

Message Profiles provide a language that allows us to unambiguously express our

Sharing message profiles provides

MSH MSH MSH

Message Profile Message Profile Message Profile

Critical Care Unit

Clinical Data Repository

BED 1OFF ED1 OFF

BED1 OF BED 1 OFF

Accept + App ACK

Critical Care Unit

BED1 OF BED 1 OFF

2. Dynamic Interaction Model ADT^A01

Static Definition – Message Level 5.7 AL1 - Allergy Segment Definition

5.8 MSA - Message Acknowledgment Segment 6

5.9 ERR - Error Segment Definition 11

6 Static Definition - Field Level 15

6.1 Table 0001 – Sex 19

6.2 Table 0002 – Marital Status 21

6.4 Table 0004 – Patient Class 26

Static Definition – Field Level 6.6 Table 0006 – Religion

 Identifies minimum and maximum number of

[0..0] Element never present

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

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

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

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

B – Backward R, RE, O*, C, CE, X O is only permitted for

29 26 TS O 00740 Patient Death Date and Time

 Uniquely identifies static and dynamic profile

 Rapid prototyping of message profiles derived from

 Tools for storage and retrieval of profiles as well as

Inbound Transform Canonical Transform Outbound

Object Relational Object Extract, Business

Inbound Transform Canonical Transform Outbound

Inbound Message Processing Outbound Message Processing

Inbound Transform Canonical Transform Outbound

Object Relational Object Extract, Business

Inbound Inbound Canonical Outbound Outbound

Inbound Transform Canonical Transform Outbound

 Describe message structure and anticipated application behavior

System Interface Project

 SIIS consists of nine regional

 Immunization Network of Northern California (INNC)

The scope of the California Statewide Immunization

 A combination of manual and automated processes are employed to

 There are serious inefficiencies and limitations associated with the

 Some healthcare providers operate in multiple regional registry

 Today immunization information is not easily able to follow

HL7 v 2.5 Messaging

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