A tutorial I presented at the HL7 January 2011 working group meeting.
- 1. Version 2.x Messaging Conformance Abdul-Malik Shakir
Principal Consultant, Shakir Consulting HL7 Working Meeting January
2011 Sydney, AU
2.
- Principal Consultant, Shakir Consulting, La Verne, CA
- 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
3. Session Outline
-
- Message Profile:Why and When
-
- Concepts and Constituents
4.
5. An HL7 Messaging Scenario:Why User Interface Program Module
Dataset User Interface Program Module Dataset Message Creation
Message Parsing A to B Transformation Message Parsing Message
Creation B to A Transformation Order EntryApplication System
LaboratoryApplication System Lab OrderTransaction Order
EntryApplication System LaboratoryApplication System Lab
ResultTransaction 6. Reaching the Limits of Application Interfaces
Lab Order Entry ADT Pharmacy Radiology Decision Support Electronic
Health Record Administrative Systems ? Enterprise Systems ?
External Systems ? 7. Health Level Seven:Why
- The number of interfaces between N systems is given by the
formulaI = (N 2 -N)/2.
- Linkingsystems only needs 1 interface,;
- Linking 6 systems needs as many as 15 interfaces, (6 2 6) / 2
=15
- The benefits of using the HL7 standard increase rapidly with
the number of systems involved.I = N
3 (3 2- 3) / 2 = 32 (2 2- 2) / 2 = 14 (4 2- 4) / 2 = 6 8. Health
Level Seven:Why Tolerable Painful Intolerable 9. Divide and Conquer
/ Component Reuse DATA Visit Billing Results Reporting Next of Kin(
NK 1 ) Insurance( IN 1 ) Patient Visit( PV 1 ) PatientDemographics(
PID ) Guarantor ( GT 1 ) NK 1 IN 1 PV 1 PID GT 1 OBR OBX Next of
KIN ( NK 1 ) Patient Visit ( PV 1 ) PatientDemographics ( PID ) 10.
Abstract Message Specification
- PID Patient Identification
- [PD1] Additional Demographics
- [ { NK1 } ] Next of Kin /Associated Parties
- [ PV2 ] Patient Visit - Additional Info.
- [ IN2 ] Insurance Additional Info.
- [ IN3 ]Insurance Add'l Info - Cert.
Segment ID Segment Name [ ] optional { } may repeat 11. MSH
Segment Definition 12. 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 13. HL7
Message Elements
- An HL7message specificationis an ordered collection of one or
moresegment groupswhere 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.
- Asegmentis an ordered collection of fields.Eachsegment fieldis
an instance of a data element.Adata elementmay 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.
- Adatatypemay be simple or composite.Acomposite datatypeis an
ordered collection of one or more data type components; a simple
datatype has no components.Adata type componentis 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.Acode tableis a collection of code table items.Eachcode
table itemis acode system termfrom some code system.Acode systemmay
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.
14. HL7 v2 Message Elements 15. Sample HL7 v2.x Message
- PID: Patient Identification
Delimiters |Field^ Component & Subcomponent~RepetitionEscape
Character MSH |^~&| LABGL1 || DMCRES || 199812300100 || ORU ^
R01 | LABGL1199510221838581 | P | 2.3 ||| NE | NE PID ||| 6910828 ^
Y ^ C8 || Newman ^ Alfred ^ E || 19720812 | M || W | 25 Centscheap
Ave ^^ Whatmeworry ^ UT ^ 85201 ^^ P || (555)777-6666 |
(444)677-7777 || M || 773789090OBR || 110801 ^ LABGL | 387209373 ^
DMCRES | 18768-2 ^ CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE) ^ LN
||| 199812292128 || 35 ^ ML ||||||| IN2973 ^ Schadow ^ Gunther ^^^^
MD ^ UPIN ||||||||||^ Once |||||| CA20837 ^ Spinosa ^ John ^^^^ MD
^ UPIN OBX || NM | 4544-3 ^ HEMATOCRIT (AUTOMATED) ^ LN || 45 ||
39-49 |||| F ||| 199812292128 || CA20837 OBX || NM | 789-8 ^
ERYTHROCYTES COUNT (AUTOMATED) ^ LN || 4.94 | 10*12/mm3 | 4.30-5.90
|||| F ||| 199812292128 || CA20837 16.
17. Reveal Assumptions Revealing assumptions is an essential
component of effective communication. Yes, I do play football. Do
you play football? 18. Reveal Assumptions Message Profiles are an
effective means of documenting our assumptions about message
structures Do youuseHL7? MSH EVN PID [PD1] [ { NK1 } ] Yes, I
useHL7. MSH EVN PID [ NK1 ] OBX 19. 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 MSH EVN PID [PD1] [
{ NK1 } ] 20. Highlight Conflicts Sharing message profiles
providesan opportunity to identify and reconcile conflicts in our
understandingand to validate our assumptions about message
structures. MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX
21. Consolidate Viewpoints Message Profile Message Profile Message
Profile MSH EVN PID [PD1] [ { NK1 } ] MSH EVN PID [ NK1 ] OBX MSH
EVN { PID } [PD1] [ { GT1 } ] MSH EVN { PID } [PD1] [ { NK1 } ] [ {
GT1 } ] [ OBX ] Canonical Message Profile 22. Value of Message
Profiling
23.
24. 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
-
-
- What data will be passed in a message
-
-
- The format in which the data will be passed
-
-
- The acknowledgement responsibilities of the sender
andreceiver
25. Message Profile Defined (contd)
- Based on HL7, although may further constrain
-
-
- Static structure and content of each message
- Parts of a valid message profile
- Represented as an XML document
-
-
- Canbe registered with HL7
-
-
- May be reused by other HL7 users
-
-
- May be used for documentation
of15 26. Conceptual Overview Message Profile =Static Profile+
Dynamic Profile Critical Care Unit ADT System Clinical Data
Repository Response Message Initiating Message Initiating Message
27. Use Case Model
- Documents the scope and requirements for an HL7Message 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
- V3.0 Message Development Framework (MDF 99)
28. Static Definition
- A specification for a message structure intended to support the
use case
- Based on amessage defined in HL7 Std
- Defined at the message, segment, and field levels
-
- Follows the HL7 rules (chapter 2)
-
-
- Identifies only those specific elements used in the
exchange
-
-
- Removes all instances of optionality, defining explicitly
-
-
- Segments, segment groups, fields and components usage
rules
-
-
- Value sets and coding systems
29. Static Definition Example ... ... ... NK1 MSH EVN PID NK1
NK1 NK1 NK1 PV1 PV2 OBX AL1 Message Profile
Fields/Components: - Usage (Optionality) - Cardinality (min,
max) - Value Sets/Coding system - Descriptions ... NK1 MSH EVN PID
NK1 NK1 NK1 NK1 PV1 PV2 OBX AL1 HL7 Message Structure 30. Dynamic
Definition
- Defines interaction between the sender and receiver
-
- Acknowledgment mode supported
-
- Conditions under which an accept and/or application level
acknowledgment is expected
-
- 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
31. Dynamic Interaction Critical Care UnitHIS/CIS Clinical Data
Repository A/D/T System Order Filling Application Accept Ack Accept
+ App ACK Receiver Responsibility MSH-15,16 No ACK 32. How it all
ties together 33.
- Concepts and Constituents
34. Profiling Concepts
- Generic term message element used
Message Constituents 35. Profile Types
-
- represents a specific HL7 published standard
-
- creation and publication limited to HL7 use
-
- May have optionality - not implementable
-
- Narrower profiles may be defined based on this
-
- Realm Specific (National, Regional, SIGs, etc.)
-
- Organization / Application Specific
36. 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 *)
37. 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 38. 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
39. Usage (continued)
-
- 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
40. 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
41. Usage (continued)
-
- 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
42. Usage (continued)
-
- 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
43. 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
-
- 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
44. 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
constrainableprofiles 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 constrainableprofiles W
Withdrawn X 45. 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.
46. Usage-Cardinality Combinations 47. 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
48.
49. Message Level Profile
-
- 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
- Profile does not allow for empty segment
- HL7 abstract message syntax PLUS
50. Message Level Profile Example 51. Message Level Profile
Example 52. Message Level Profile Example 53. Message Level Profile
Example 54. 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
- Syntax (tabular HL7 segment definitions)
55. Segment Level Profile Example(PID) 56. Segment Level Profile
Example(PID) 57. Field Level Profile
-
- 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
-
-
- 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
58. 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
59. 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.
60. Compliance and Conformance
-
- Messages that adhere to the rules and conventions for
constructing of a specific version of a standard arecompliantto
that version of the standard.
-
- Messages that adhere to the constraints of a precise and
unambiguous specification called amessage profileare said to
beconformantto the profile.
Compliance Conformance 61. Conformance Benefits
- Lower Cost of Integration
-
- Conformance SIG is developing Implementation guide
-
- Required of third-party application vendors
-
- Simplifies introduction/acquisition of new applications
62.
63. The Messaging Workbench (MWB)
-
- 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
- It will continue to be supported within the VA for the
foreseeable future
64. 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
65. 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
66. HL7 67. Constrainable 68. Constrainable(continued) 69.
Implementation 70. Message Profile 71.
72. Capture/Analyze Message 73. Reverse Engineer from Message
74. New Profile Using Libraries 75. New Profile Using Libraries
(contd) 76. New Profile Using Libraries (contd) 77. New Profile
Using Libraries (contd) 78. New Profile Using Libraries (contd) 79.
New Profile using copy/paste 80. New Profile Copy/Paste (contd) 81.
New Profile Copy/Paste (contd) 82. Modifying a Profile HL7 83.
Modifying a Profile Constrainable 84. Modifying Profile Constr
(contd) 85. Modifying Profile Implementation 86. Modifying Profile
Impl (contd) 87. Diagram Drawing Tool 88.
89. Reports 90. Reports(continued) 91. Reports(continued) 92.
Reports(continued) 93. Reports(continued) 94. Reports(continued)
95. Producing Profile Reports 96. Producing Profile Reports (contd)
97. Producing Profile Reports (contd) 98. Producing Profile Reports
(contd) Browser View 99. Producing Profile Reports (contd) 100. HL7
Message Profile 101. Register Profile with HL7 102.
103. 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]
104. Where to Get More Information
105. Where to Get More Info (contd)
106. Where to Get More Info (cont)
107. Where to Get More Info (contd)
- Conformance Tools Forum at Yahoo Groups
108. California Department of Health Services Electronic
Laboratory Reporting Project 109. 110. Inbound Message Processing
Outbound Message Processing Data Persistence Business Intelligence
111. Inbound Laboratory Message Inbound Message Profile Transform
Translate Inbound Message Mapping Canonical Laboratory Message
Canonical Message Profile Transform Translate Outbound Message
Mapping Outbound Laboratory Message Outbound Lab Message Supplier
Lab Message Consumer Knowledge Management Service Knowledge
Management Service Object Graph Generation Laboratory Message
Objects Object Relational Mapping Laboratory Message Repository
Object Relational Map ELR Database Design Model CA Public Health
Logical Data Model HL7 RIM & CDC PHLDM Canonical Message
Profile Laboratory Message Object Model Extract, Transform, and
Load Laboratory Datamart Business Intelligence Application Business
Intelligence Application Business Intelligence Application Message
Profile Extract, Transform, and Load Additional Data Sources 112.
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
113. 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?
114. 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?
115. 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?
116. CaliforniaState Immunization Information System System
Interface Project 117.
- 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.
118. 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)
119.
- 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
individuals complete immunization history regardless of where that
history is maintained.
Project Scope 120.
- The premise behind the project is that, for many reasons, a
persons 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
persons primary residence, changes in a persons primary healthcare
provider, and ad hoc administration of immunizations such as during
vacation or emergencies.
- Once a persons 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 121.
- 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 persons 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 122.
- There are serious inefficiencies and limitations associated
with the current processes used to address the fragmentation of a
persons 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 123.
- 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 124. HL7 Message Profiling 125.
- 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
126. 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 isImplementation 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.
127. 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:
-
- a query from one system for a patients vaccination record that
is held in another system using the HL7 VXQ message;
-
- a response to a query containing multiple patient matches to
the query, but not returning vaccination records using the HL7 VXX
message;
-
- a response to a query containing the vaccination record using
the HL7 VXR message; and
-
- 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.
128. Preliminary Segment Level Profile 129. SIIS SIP Conceptual
Data Model 130. Regional System to Segment Profile Mapping 131.
Regional System to Segment Profile Mapping 132. Final Segment Level
Profile 133. SIIS SIP Logical Data Model 134. 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.
135. HL7 Message Profile Dynamic Definition
- The dynamic definition describes the supported use cases,
interactions, and acknowledgement requirements.
-
- 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
-
- 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.
136. HL7 Message Profile Static Definition
- The static definition describes usage rules, cardinalities, and
code systems.
-
- 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 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 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.
137. SIIS SIP Use Case Diagram 138. SIIS SIP Activity Model 1 2
3 4 6 5 139. SIIP SIP Interaction Model 140. 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
- General Acknowledgement (ACK)
IIES Responder Never
- Vaccination Query Response (VXX)
IIES Requester Never
- Vaccination Query Response (VXR)
Responder IIES Only on error
- General Acknowledgement (ACK)
IIES Responder Never
- Vaccination Query Response (VXR)
IIES Requester Never 141. 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.
142.
- 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 143. 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.
144. 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.
145. 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.
146. Application Testing 147. 148. Test Themes and Scenarios
- Valid message syntax, content, and flow
- Valid message syntax, content, and invalid flow
- Valid message syntax, invalid content
149. 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.
-
- 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.
-
- 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
150. 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.
151. 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
152. Questions 153. Thank You Abdul-Malik Shakir Principal
Consultant Shakir Consulting 1407 Foothill Blvd., Suite 145 La
Verne, CA 91750 Office: (909) 596-6790 Mobile: (626) 644-4491
Email:[email_address] Abdul-Malik ShakirInformation Management
Strategist City of Hope 1500 East Duarte Road Duarte, CA 91010-3000
Office: (626) 256-4673 Mobile: (626) 644-4491
Email:[email_address]