1. Creation of a Common Data Profile for California Regional Immunization Registries
Chris K. Kim, MS
Information Systems Manager
Statewide Immunization Information Systems
Immunization Branch
California Department of Health Services
March 6, 2007

2. Agenda CA Statewide Immunization Information System (SIIS)
CA Regional Registries
NIP Implementation Guide
CA HL7 Messaging Profile
Conclusions
March 6, 2007
CA HL7 Profile

3. The California State Immunization Information System (SIIS)
A collaboration of immunization regional registries that ensures the secure, electronic exchange of immunization records to support the elimination of vaccine preventable diseases.
Goals
Increase Immunization Rates
Eliminate both missed opportunities to immunize and unnecessary duplicate immunizations
Share complete immunization records between registries in the system
March 6, 2007
CA HL7 Profile

4. California Immunization Registries
9 Regional registries
2 County registries
6 Web-enabled softwares
~ 3 Million kids under 6 years
~ 29% of kids in Registry (2005)
~ 1% of kids move between registries
March 6, 2007
CA HL7 Profile

5. California Immunization Registries’ Challenges
No centralized database for the statewide immunization registry
Different registry applications independently managed and operated
No data link among registries
Large scale of population and spectrum of key stakeholders across the state
March 6, 2007
CA HL7 Profile

6. Solution to Current Challenges
Electronic exchange of immunization related data.
System that supports the electronic request and response for immunization data from one registry to another.
Standard that facilitates the participation of all stakeholders, such as regional and county registries, healthcare providers, and multi-jurisdictional provider organizations
There is a need to create a common data profile based upon Health Level 7 messaging standards to exchange immunization data.
March 6, 2007
CA HL7 Profile

7. Health Level Seven (HL7)
One of American National Standards Institute (ANSI) accredited Standards Developing Organizations operating in the healthcare arena
Develops specifications for health data-interchange standard designed to facilitate the transfer of clinical and administrative data reside on different and disparate computer applications in health care settings.
March 6, 2007
CA HL7 Profile

8. HL7 Implementation Guide
Implementation Guide for Immunization Data Transactions using Version of the HL7 Standard Protocol
Center for Disease Control and Prevention (CDC), National Immunization Program (NIP)
American Immunization Registry Association (AIRA)
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.
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 of the Health Level Seven (HL7) Standard Protocol”.
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.
The purpose 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.
March 6, 2007
CA HL7 Profile

9. Differences Between CA Message Profile and the Implementation Guide
Message Profile: An unambiguous specification of one or more standard HL7 messages
Eliminates ambiguity by declaring static and semantic constraints
CA HL7 message profile is an extension to the NIP implementation Guide. (version 2.1, 2002)
Does not conflict with the guide
More constraints
Dynamic and static definition
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 CA 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.
March 6, 2007
CA HL7 Profile

10. CA HL7 Message Profile Why HL7 Version 2.5?
MSH 21 Message Profile Identifier
Replacement of Composite (CM) datatype with specific composite datatypes
Normative fields and component lengths
The use of QRF 10 – Search Confidence Threshold
1. This field contains identification of the message profile to which the message is intended to
conform. This will aid in message validation by identifying valid assigning authorities.
2. The composite data types are distinctly defined in version 2.5 which enables a field level
definition to be constructed
3. Field and component lengths are normative in version 2.5 which provides greater consistency, and
4. QRF 10 field contains a numeric value used to establish a minimum threshold match. It is used in
patient look-up transactions where the searching system employs a numeric algorithm for
determining potential matches to patient lookups. The value instructs the responding system to
return no records for patients whose “match weight” on the look-up was lower than this value.
March 6, 2007
CA HL7 Profile

11. HL7 2.5 Messaging Standard Message Specification Datatype
Segment Group
Segment
Segment field
Data element
Datatype
Simple: No components
Composite: An ordered collection of one or more datatype components
Coded Table: Collection of code table items
HL7 Defined, user defined, or 3rd party defined
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.
March 6, 2007
CA HL7 Profile

12. HL7 Message Dynamic Definition
Use Case Model
Describes the purpose for each message exchange
Defines the actors
Describes the situations when the exchange of a particular HL7 message profile is required
Interaction Model
Illustrates the sequence of trigger events and the resulting message flows
Acknowledgement Requirements
Defines the acknowledgments of required or allowed usage of the specified static 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.
March 6, 2007
CA HL7 Profile

13. CA Message Profile Use Case Diagram
March 6, 2007
CA HL7 Profile

14. CA Message Profile Interaction Model
March 6, 2007
CA HL7 Profile

15. HL7 Message Static Definition
Usage Rules
Codes to clearly identify the rules governing the presence of specific elements
Cardinality
The minimum and maximum number of repetitions for specific elements
Vocabulary Specification
An organized set of code systems and code system terms
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.
March 6, 2007
CA HL7 Profile

16. CA Message Profile Static Definitions
The usage and cardinality constraints for the constituent message elements
Definition for each message type
(VXQ, VXX, VXR, QCK, and ACK)
Message, segment, and field level definition
The static definition portion of the message profile declares the usage and cardinality constraints for the constituent message elements of the CA HL7 message Profile.
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.
March 6, 2007
CA HL7 Profile

17. CA SIIS HL7 V2.5 Message Profiling
IZ messaging implementation guide
HL7 v2.5 Messaging standard
Preliminary segment level profile
SIIS level conceptual data model
Map preliminary profile to regional IZ systems
Final segment level profile
SIIS level logical data model
CA SIIS HL7 message level profiles
CA SIIS HL7 vocabulary specification
March 6, 2007
CA HL7 Profile

18. Conclusions
CA HL7 Version 2.5 Message Profile Version 1.1 is registered with HL7 (Oct. 2006)
Vocabulary mapping is in progress among registries
Necessary but intricate process
March 6, 2007
CA HL7 Profile

19. www.ca-siis.org For More Information
Special thanks to Abdul-Malik Shakir, Principal Consultant, Shakir Consulting
March 6, 2007
CA HL7 Profile

20. Thank You Contact : Chris K. Kim, MS
Phone:
Certified HL7 2.5 Control Specialist
Information System Manager
Statewide Immunization Information System
Immunization Branch
California Department of Health Services
March 6, 2007
CA HL7 Profile