''This is a draft of the Immunization Registry Content Profile (IRC) supplement to the PCC Technical Framework. This draft is a work in progress, not the official supplement or profile.''
__TOC__
==Profile Abstract==
The Immunization Content Profile (IC)
The Immunization Content Profile defines standard immunization data content for Immunization Information Systems (IISs), other public health systems, electronic medical records (EMR) systems, Health Information Exchanges, and others wishing to exchange immunization data electronically in a standard format.
==Glossary==
<!--; Term : Definition-->
; Immunization Information System (IIS) : ''Preferred term of the American Immunization Registry Association for "Immunization Registry"''
==Issue Log==
===Open Issues===
# In preparation for the development of this profile, the compatibility of HL7 Version 3 POIZ and CareRecord were analyzed. The standards were found to be highly compatible. A few differences were identified and referred back to the HL7 Public Health and Emergency Response (PHER) Work Group for resolution through comments on both Draft Standards for Trial Use (DSTU). The approach taken in the Immunization Content (IC) Profile is to update the current Immunization Summary template provided in QED to contain all the fields in POIZ and to use POIZ tags (in order to best reflect terminology created by immunization and public health domain experts). The updated template is the equivalent of a POIZ template on CareRecord.
# Care Management (CM) provides the notification-based integration profile for HL7 V2 immunization messages (VXQ/VXX/VXR). Query for Existing Data (QED) provides a query-based integration profile for the HL7 V3 portions of this profile, but doesn't include an option for HL7 V2. Thus, we still don't have a query option for V2. We are asking for public comment on this point.
# This IC profile contains three options for each actor. This has been thought to be problematic because two systems implementing different options may not be able to communicate. Another approach would be to break this profile into two, one for HL7 Version 2, and one for HL7 Version 3 (combining the Immunization Summary and Care Record options into one). Public comment on this issue is sought.
# We see this as a two-part exercise: (1) update of the existing IHE Immunization Summary template to reflect missing POIZ fields; and (2) creation of a new profile that includes Allergies, Problems, etc. - something that looks more like a discharge summary or a transfer of care summary, etc.
===Notes to Author/Editor (do not include in final drafts)===
# V2.3.1 messages blend identity resolution with transmission of clinical data. Profiles such as QED and CM do not handle identity management; this is the purview of PIX and PDQ. How then is this aspect of HL7 Version 2.3.1 to be handled?
# Note that HL7 "V2" below refers to "V2.3.1". Note that an implementation guide for HL7 V2.5 is also under development in the U.S. Centers for Disease Control (CDC).
# Address how to handle updates to referenced V2 Guides.
# Template for Advanced Directives needs to be fixed to include Immunization Refusal Reasons.
# Template for Immunizations needs to be fixed to include Lot #, Manufacturer, and Expiration Date.
# POIZ DSTU includes a "subject" tag that is redundant with the "patient" tag in Care Record, and is stated to be "required." We want to omit or ignore it, since it is redundant in the Care Record context.
# POIZ DSTU appears to use different tagnames for "author" and "informant" than PCC defines them in section 6.4.4.1. PCC-2 samples (e.g.:6.4.4.20) and specs (6.4.4.1) show:
<author typeCode='AUT'>
<assignedEntity classCode='ASSIGNED'><!--sb 'classCode=' instead of 'typeCode-'-->
<id root='' extension=''/>
<addr></addr>
<telecom use='' value=''/>
<assignedPerson classCode='PSN'>
<!--<determinerCode='INSTANCE'/>probably typo in 6.4.4.20-->
<name>…</name>
</assignedPerson>
<representedOrganization>
<name>...</name>
</representedOrganization>
</assignedEntity>
</author>
versus POIZ, which appears to me to show in POIZ_HD030050UV and COCT_MT090107UV:
Although the structures are the same (with the addition of a Role code in POIZ), the tagnames are different than those used for author in Care Record. Also, some of the PCC-2 samples show other tagnames for author (e.g.: 6.4.4.6). Is this an issue?
===Closed Issues===
# Important elements are currently missing from the PCC QED immunization template, for example, the person who gave the shot. CareRecord can include person who administered vaccine in Performer role. This will be resolved by updating the current immunization template.
=Volume I=
<pre>Add the following bullet to the list of profiles</pre>
* Immunization Content - The Immunization Content Profile defines standard immunization data content for Immunization Information Systems, other public health systems, EMR systems, Health Information Exchanges, and others wishing to exchange immunization data electronically in a standard format.
===Dependencies===
<pre>Add the following row(s) to the list of dependencies</pre>
The Immunization Content Profile (IC) provides a standard message, document and web service formats for exchanging immunization data. It is intended to facilitate the exchange of immunization data among multiple systems belonging to a single or to multiple organizations. Data exchange with and among the installed base of U.S. Immunization Information System (IIS) base was a critical consideration in formulating this profile. However, its intention is to go beyond data exchange among IISs, and facilitate immunization data exchange on a healthcare information network that includes electronic medical record (EMR) systems, Health Information Exchanges, other public health systems, Personal Health Record (PHR) systems, and other stakeholder systems. Thus, the profile specifies common data formats for exchanging immunization data only, or for exchanging immunization data along with medical summary data needed for the overall care of a patient related to immunizations.
To accomplish this, IC draws from two HL7 Version 3 message standards: Immunizations and Care Provision. Immunizations contains a message information model which handles detailed immunization information only. It includes history of administered vaccines with such details as lot number, who administered the shot, and so forth. Care Provision contains a message information model which handles immunization as well as other information related to the patient's care. For example, it includes medical history, medications, allergies, vital signs, and so forth. To provide for compatibility with the U.S. installed base of Immunization Information Systems (IISs), an HL7 Version 2.3.1 content option is also included.
The format of data is treated here as a separate topic from whether the data communicated in message, service, or document format, or whether an enclosing message is query-based or notification-based. By isolating content description from transaction description, the same content can be exchanged both in query and notification (unsolicited update) transaction styles, or in a service. IC is intended to be used in conjunction with integration profiles such as Query for Existing Data (QED) and Care Management (CM) to create architectures for immunization information exchange. It is also hoped that in the future, IC can be used in document-oriented profiles such as XDS. Finally, the IC Profile is also intended to pave the way for content to be passed to immunization-related decision support services. Decision support, however, is out of scope for the 2007-2009 IHE cycle and is on the IHE roadmap for the future.
===Use Cases===
The following progression of use cases is illustrated in the drawing below.
{{Fixme|insert Drawing for Public Comment here}}
====Use Case 1: Immunization Information System Participation====
Various provider organizations - airport flu shot clinics, storefront vaccine clinics, and hospital vaccine clinics - wish to submit immunization histories for patients to a regional Immunization Information System (IIS) with appropriate patient consent. The provider IT departments configure HL7 Verion 2.3.1 connections with the IIS. Each time immunizations are recorded, records of the administered vaccines are automatically sent to the IIS using an HL7 version 2.3.1 standard format.
This is representative of the present-state use case in the U.S.
====Use Case 2: Immunization Yellow Card====
A pediatrician's office produces official immunization records (sometimes called "Yellow Card") for patients. The provider electronic medical record (EMR) system retrieves demographic information and records of immunization its immunization repository. To supplement its records with immunizations that the patient may have received from other providers, it queries the regional Immunization Information System (IIS). It passes the immunization content to a software module or service that prints the information in the official Yellow Card format.
====Use Case 3: Personal Health Record====
The provider wishes to make the assembled immunization information available in the patient's Personal Health Record (PHR). The pediatrician's office EMR system includes the retrieved immunization information in its complete care provision information about the patient. The standard Care Provision information contains current conditions, allergies and past adverse events, medications, vital signs, past medical history such as disease history, and so forth, in addition to immunizations. Knowing that the patient also has visited providers in a neighboring state, the EMR system queries the neighboring state's Health Information Exchange (HIE) to retrieve additional care provision information in a standard format. Since the neighboring state IIS is also part of the HIE, the retrieved information also includes immunizations. The pediatrician's office EMR system combines the retrieved and local information and sends it to the provider's PHR system in a standard format.
====Use Case 4: Vaccine Forecast====
The pediatrician's office wishes to run an automated Vaccine Forecast Decision Support Service to calculate which vaccines due on the next visit, and to assist with reminder/recall. The service may be integrated within the EMR or may be accessed externally using a web service interface. The service accepts a standard XML-based payload in Immunization Content format. The pediatrician's EMR system submits the patients Care Provision data that it has previously assembled to the Vaccine Forecast Decision Support Service and receives a vaccine forecast care plan in return. It records the care plan and uses it in reminder/recall.
===Actors/Transaction===
There are two actors in this profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. <!--A [[Document Source]] or a [[Portable Media Creator]] may embody the [[Content Creator]] Actor. A [[Document Consumer]], a [[Document Recipient]] or a [[Portable Media Importer]] may embody the [[Content Consumer]] Actor.
The sharing or transmission of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described by section 3.7 Content Bindings with XDS, XDM and XDR found in the [[Frameworks#IHE_Patient_Care_Coordination_Technical_Framework|Patient Care Coordination Technical Framework]]-->
[[image:cccc.png|frame|center|Immunization Registry Content Actor Diagram]]
Note <sup ID=note1>1</sup>: The Actor shall support at least one of these options.
<!--
=== Grouping ===
==== Content Bindings with XDS, XDM and XDR====
It is expected that the transfers of care will occur in an environment where the physician offices and hospitals have a coordinated infrastructure that serves the information sharing needs of this community of care. Several mechanisms are supported by IHE profiles:
* A registry/repository-based infrastructure is defined by the IHE [[Cross Enterprise Document Sharing]] (XDS) and other IHE Integration Profiles such as patient identification (PIX & PDQ), and notification of availability of documents (NAV).
* A media-based infrastructure is defined by the IHE [[Cross Enterprise Document Media Interchange]] (XDM) profile.
* A reliable messaging-based infrastructure is defined by the IHE [[Cross Enterprise Document Reliable Interchange]] (XDR) profile.
* All of these infrastructures support Security and privacy through the use of the [[Consistent Time]] (CT) and [[Audit Trail and Node Authentication]] (ATNA) profiles.
For more details on these profiles, see the [[Frameworks#IHE_IT Infrastructure_Technical_Framework|IHE IT Infrastructure Technical Framework]].
Content profiles may impose additional requirements on the transactions used when grouped with actors from other IHE Profiles.
==== Cross Enterprise Document Sharing, Media Interchange and Reliable Messages ====
Actors from the ITI XDS, XDM and XDR profiles embody the [[Content Creator]] and [[Content Consumer]] sharing function of this profile. A [[Content Creator]] or [[Content Consumer]] must be grouped with appropriate actors from the XDS, XDM or XDR profiles, and the metadata sent in the document sharing or interchange messages has specific relationships to the content of the clinical document described in the content profile.
==== [[Notification of Document Availability]] (NAV) ====
A Document Source should provide the capability to issue a [[Send Notification]] Transaction per the ITI [[Notification of Document Availability]] (NAV) Integration Profile in order to notify one or
more [[Document Consumer]](s) of the availability of one or more documents for retrieval. One of the Acknowledgement Request options may be used to request from a Document Consumer that
an acknowledgement should be returned when it has received and processed the notification.
A Document Consumer should provide the capability to receive a [[Receive Notification]] Transaction per the NAV Integration Profile in order to be notified by Document Sources of the availability of one or more documents for retrieval. The [[Send Acknowledgement]] option may be used to issue a Send Acknowledgement to a [[Document Source]] that the notification was received and processed.
==== [[Document Digital Signature]] (DSG)====
When a [[Content Creator]] Actor needs to digitally sign a document in a submission set, it may support the Digital Signature (DSG) Content Profile as a [[Document Source]].
When a [[Content Consumer]] Actor needs to verify a Digital Signature, it may retrieve the digital signature document and may perform the verification against the signed document content.
; [http://www.hl7.org/documentcenter/public/standards/informative/crs.zip CRS] : Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm), 2006, HL7.
; [http://www.hl7.org/Library/Committees/structure/CCD%2E01Dec2006%2EDRAFT%2Ezip CCD] : ASTM/HL7 Continuity of Care Document (Draft)-->
; [http://www.cdc.gov/vaccines/programs/iis/stds/downloads/hl7guide.pdf Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol] : Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol.
; [http://hssp-rlus.wikispaces.com/September2006BallotedSFM HSSP Retrieve, Locate and Update Service] : Implementation Service Functional Model (SFM), balloted HL7 Draft Standard for Trial Use (DSTU) HL7.
; [http://www.omg.org/cgi-bin/doc?health/2007-09-01 HSSP Retrieve, Locate and Update Service] : Initial submission to OMG includes a profile that demonstrates immunization data retrieval and update in conformance to SFM
; [http://www.hl7.org/v3ballot/html/welcome/environment/index.htm HL7 V3 Immunizations (Click on Universal Domains, Immunizations) ] : HL7 Version 3 Standard: Immunization, Release 1 DSTU Ballot 3 - May 2008
; [http://www.hl7.org/v3ballot/html/welcome/environment/index.htm HL7 V3 Care Provision (Click on Universal Domains, Care Provision)] : HL7 Version 3 Standard: Care Provision, Release 1 Last Ballot: DSTU Ballot 3 - September 2007
==== Data Element Index ====
==== Data Element Index ====
{{Fixme|We want to add definitions to all of the element names. Some may be self-explanatory}}
{{Fixme|We want to add definitions to all of the element names. Some may be self-explanatory}}
{| cellspacing=0 border=1 align='center'
{| cellspacing=0 border=1 align='center'
!style='background-color:#cfcfcf' |Data Elements
!style='background-color:#cfcfcf' |Data Elements
!style='background-color:#cfcfcf' |Element from Care Record Root
!style='background-color:#cfcfcf' |Element from POIZ Root
|Dose Quantity || ||immunization.doseQuantity.value - units
|-
|-
|Description ||text ||text ||
|Route || ||immunization.routeCode
|-
|-
|Immunization Date ||effectiveTime ||effectiveTime ||
|Approach Site || ||immunization.approachSiteCode
|-
|-
|Confidentiality Code || ||confidentialityCode || not defined in Care Record
|Vaccine Code || CDC CVX code in US ||administerableMaterial.code
|-
|-
|Uncertainty Code ||||uncertaintyCode || not defined in Care Record
|Vaccine Name || ||administerableMaterial.name
|-
|-
|Dose Quantity ||doseQuantity.value - units||doseQuantity.value - units ||
|Vaccine Lot # || ||administerableMaterial.lotNumberText
|-
|-
|Route ||routeCode ||routeCode ||
|Vaccine Expiration Date || ||administerableMaterial.expirationTime
|-
|-
|Approach Site ||approachSiteCode ||approachSiteCode ||
|Manufacturer ID || CDC MVX code in US ||asMedicineManufacturer.manufacturer.id
|-
|-
|Vaccine Code ||consumable. administerableMaterial. administerableMaterial. code||consumable. administerableMedication. administerableMedicine. code || CDC CVX code in US
|Manufacturer name || ||asMedicineManufacturer.manufacturer.name
|-
|-
|Vaccine Name ||consumable. administerableMaterial. administerableMaterial. name ||consumable. administerableMedication. administerableMedicine. name||
|Performer Name || ||performer.assignedPerson.assignedPrincipalChoice List.person.name
|-
|-
|Manufacturer ID ||consumable. administerableMaterial. administerableMaterial. asMedicineManufacturer. manufacturer.id ||consumable. administerableMedication. administerableMedicine. asMedicineManufacturer. manufacturer.id || CDC MVX code in US
|Performer Organization ID || ||performer.assignedPerson.representedOrganization.id
|-
|-
|Manufacturer name ||consumable. administerableMaterial. administerableMaterial. asMedicineManufacturer. manufacturer. name ||consumable. administerableMedication. administerableMedicine. asMedicineManufacturer. manufacturer. name ||
|Performer Organization Name || ||performer.assignedPerson.representedOrganization.name
|-
|-
|Vaccine Lot # Recalled Effective Date ||consumable. administerableMaterial. administerableMaterial. asMedicineManufacturer. entryRelationship. observation. effectiveTime||consumable. administerableMedication. administerableMedicine. asMedicineManufacturer. entryRelationship. observation. effectiveTime || Date Recall was effective
|colspan=2|This section shall contain a full description of the immunizations administered to the patient in the past. It shall include entries for medication administration as described in the Entry Content Module. It shall also contain all known medical information which is relevant to past and future immunization decisions for the patient.
|- style='background-color:#cfcfcf;'
!LOINC Code
!Opt
!Description
|-
|11369-6
|align='center'|R
|HISTORY OF IMMUNIZATIONS
|- style='background-color:#cfcfcf;'
!Entries
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.?.?
|align='center'|R
|Immunization Content
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.?.?
|align='center'|R
|History of Immunizations (POIZ) <br> (if no immunizations have been given, that fact must be stated with negationInd = true, and NoImmunizationReason supplied)
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.5
|align='center'|R2
|Problems and Conditions
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|11.3.6.1.4.1.19376.1.5.3.1.4.6
|align='center'|R
|Allergies and Intolerances <br> (allergy to eggs must be specified, whether positive, negative, or unknown) <br> (any known reactions to vaccine events must be specified, and linked to the particular immunization event, if known)
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.7
|align='center'|R2
|Medications
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.13.1
|align='center'|R2
|Vital Signs Organizer
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.13.2
|align='center'|R2
|Vital Signs Observation
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.13.5
|align='center'|C
|Pregnancy Observation
|- style='background-color:#cfcfcf;'
!Sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.13.7
|align='center'|R2
|Advance Directives and Consent Observation
|- style='background-color:#cfcfcf;'
!Sub-sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.1
|align='center'|R2
|Severity <br> (used in Problems and Allergies)
|- style='background-color:#cfcfcf;'
!Sub-sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.1.1
|align='center'|R2
|Clinical Status <br> (used in Problems and Allergies)
|- style='background-color:#cfcfcf;'
!Sub-sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.1.2
|align='center'|R2
|Health Status <br> (used in Problems)
|- style='background-color:#cfcfcf;'
!Sub-sub-sections
!Opt
!Description
|-
|1.3.6.1.4.1.19376.1.5.3.1.4.2
|align='center'|R2
|Comments <br> (used in POIZ, Problems, Allergies and Advance Directives)
|}
==Parent Template==
{{Fixme|do we need this?}}
<pre>
<entry>An XML Example</entry>
</pre>
=== entry ===
The parent of this template is CCD 3.11.
==SampleMessages==
===Sample V3 Message===
{{Fixme|insert ImmunizationRegistryContent 052808.xml from discussion page}}
===Sample V2 Message===
See ''Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol'', referenced in Standards above.
Revision as of 18:29, 29 May 2008
Introduction
This is a draft of the Immunization Registry Content Profile (IRC) supplement to the PCC Technical Framework. This draft is a work in progress, not the official supplement or profile.
The Immunization Content Profile defines standard immunization data content for Immunization Information Systems (IISs), other public health systems, electronic medical records (EMR) systems, Health Information Exchanges, and others wishing to exchange immunization data electronically in a standard format.
Glossary
Immunization Information System (IIS)
Preferred term of the American Immunization Registry Association for "Immunization Registry"
Issue Log
Open Issues
In preparation for the development of this profile, the compatibility of HL7 Version 3 POIZ and CareRecord were analyzed. The standards were found to be highly compatible. A few differences were identified and referred back to the HL7 Public Health and Emergency Response (PHER) Work Group for resolution through comments on both Draft Standards for Trial Use (DSTU). The approach taken in the Immunization Content (IC) Profile is to update the current Immunization Summary template provided in QED to contain all the fields in POIZ and to use POIZ tags (in order to best reflect terminology created by immunization and public health domain experts). The updated template is the equivalent of a POIZ template on CareRecord.
Care Management (CM) provides the notification-based integration profile for HL7 V2 immunization messages (VXQ/VXX/VXR). Query for Existing Data (QED) provides a query-based integration profile for the HL7 V3 portions of this profile, but doesn't include an option for HL7 V2. Thus, we still don't have a query option for V2. We are asking for public comment on this point.
This IC profile contains three options for each actor. This has been thought to be problematic because two systems implementing different options may not be able to communicate. Another approach would be to break this profile into two, one for HL7 Version 2, and one for HL7 Version 3 (combining the Immunization Summary and Care Record options into one). Public comment on this issue is sought.
We see this as a two-part exercise: (1) update of the existing IHE Immunization Summary template to reflect missing POIZ fields; and (2) creation of a new profile that includes Allergies, Problems, etc. - something that looks more like a discharge summary or a transfer of care summary, etc.
Notes to Author/Editor (do not include in final drafts)
V2.3.1 messages blend identity resolution with transmission of clinical data. Profiles such as QED and CM do not handle identity management; this is the purview of PIX and PDQ. How then is this aspect of HL7 Version 2.3.1 to be handled?
Note that HL7 "V2" below refers to "V2.3.1". Note that an implementation guide for HL7 V2.5 is also under development in the U.S. Centers for Disease Control (CDC).
Address how to handle updates to referenced V2 Guides.
Template for Advanced Directives needs to be fixed to include Immunization Refusal Reasons.
Template for Immunizations needs to be fixed to include Lot #, Manufacturer, and Expiration Date.
POIZ DSTU includes a "subject" tag that is redundant with the "patient" tag in Care Record, and is stated to be "required." We want to omit or ignore it, since it is redundant in the Care Record context.
POIZ DSTU appears to use different tagnames for "author" and "informant" than PCC defines them in section 6.4.4.1. PCC-2 samples (e.g.:6.4.4.20) and specs (6.4.4.1) show:
Although the structures are the same (with the addition of a Role code in POIZ), the tagnames are different than those used for author in Care Record. Also, some of the PCC-2 samples show other tagnames for author (e.g.: 6.4.4.6). Is this an issue?
Closed Issues
Important elements are currently missing from the PCC QED immunization template, for example, the person who gave the shot. CareRecord can include person who administered vaccine in Performer role. This will be resolved by updating the current immunization template.
Volume I
Add the following bullet to the list of profiles
Immunization Content - The Immunization Content Profile defines standard immunization data content for Immunization Information Systems, other public health systems, EMR systems, Health Information Exchanges, and others wishing to exchange immunization data electronically in a standard format.
Dependencies
Add the following row(s) to the list of dependencies
Integration Profile
Dependency
Dependency Type
Purpose
Immunization Content Content
ATNA
CT
The Immunization Content Profile (IC)
The Immunization Content Profile (IC) provides a standard message, document and web service formats for exchanging immunization data. It is intended to facilitate the exchange of immunization data among multiple systems belonging to a single or to multiple organizations. Data exchange with and among the installed base of U.S. Immunization Information System (IIS) base was a critical consideration in formulating this profile. However, its intention is to go beyond data exchange among IISs, and facilitate immunization data exchange on a healthcare information network that includes electronic medical record (EMR) systems, Health Information Exchanges, other public health systems, Personal Health Record (PHR) systems, and other stakeholder systems. Thus, the profile specifies common data formats for exchanging immunization data only, or for exchanging immunization data along with medical summary data needed for the overall care of a patient related to immunizations.
To accomplish this, IC draws from two HL7 Version 3 message standards: Immunizations and Care Provision. Immunizations contains a message information model which handles detailed immunization information only. It includes history of administered vaccines with such details as lot number, who administered the shot, and so forth. Care Provision contains a message information model which handles immunization as well as other information related to the patient's care. For example, it includes medical history, medications, allergies, vital signs, and so forth. To provide for compatibility with the U.S. installed base of Immunization Information Systems (IISs), an HL7 Version 2.3.1 content option is also included.
The format of data is treated here as a separate topic from whether the data communicated in message, service, or document format, or whether an enclosing message is query-based or notification-based. By isolating content description from transaction description, the same content can be exchanged both in query and notification (unsolicited update) transaction styles, or in a service. IC is intended to be used in conjunction with integration profiles such as Query for Existing Data (QED) and Care Management (CM) to create architectures for immunization information exchange. It is also hoped that in the future, IC can be used in document-oriented profiles such as XDS. Finally, the IC Profile is also intended to pave the way for content to be passed to immunization-related decision support services. Decision support, however, is out of scope for the 2007-2009 IHE cycle and is on the IHE roadmap for the future.
Use Cases
The following progression of use cases is illustrated in the drawing below.
-->>insert Drawing for Public Comment here<<--
Use Case 1: Immunization Information System Participation
Various provider organizations - airport flu shot clinics, storefront vaccine clinics, and hospital vaccine clinics - wish to submit immunization histories for patients to a regional Immunization Information System (IIS) with appropriate patient consent. The provider IT departments configure HL7 Verion 2.3.1 connections with the IIS. Each time immunizations are recorded, records of the administered vaccines are automatically sent to the IIS using an HL7 version 2.3.1 standard format.
This is representative of the present-state use case in the U.S.
Use Case 2: Immunization Yellow Card
A pediatrician's office produces official immunization records (sometimes called "Yellow Card") for patients. The provider electronic medical record (EMR) system retrieves demographic information and records of immunization its immunization repository. To supplement its records with immunizations that the patient may have received from other providers, it queries the regional Immunization Information System (IIS). It passes the immunization content to a software module or service that prints the information in the official Yellow Card format.
Use Case 3: Personal Health Record
The provider wishes to make the assembled immunization information available in the patient's Personal Health Record (PHR). The pediatrician's office EMR system includes the retrieved immunization information in its complete care provision information about the patient. The standard Care Provision information contains current conditions, allergies and past adverse events, medications, vital signs, past medical history such as disease history, and so forth, in addition to immunizations. Knowing that the patient also has visited providers in a neighboring state, the EMR system queries the neighboring state's Health Information Exchange (HIE) to retrieve additional care provision information in a standard format. Since the neighboring state IIS is also part of the HIE, the retrieved information also includes immunizations. The pediatrician's office EMR system combines the retrieved and local information and sends it to the provider's PHR system in a standard format.
Use Case 4: Vaccine Forecast
The pediatrician's office wishes to run an automated Vaccine Forecast Decision Support Service to calculate which vaccines due on the next visit, and to assist with reminder/recall. The service may be integrated within the EMR or may be accessed externally using a web service interface. The service accepts a standard XML-based payload in Immunization Content format. The pediatrician's EMR system submits the patients Care Provision data that it has previously assembled to the Vaccine Forecast Decision Support Service and receives a vaccine forecast care plan in return. It records the care plan and uses it in reminder/recall.
Actors/Transaction
There are two actors in this profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile.
<additions to list of SNOMED code(s) to include IZ Refusal Reasons>
advanceDirectives.code
Scope Permitted?
advanceDirectives.value
Description
advanceDirectives.text
Effective From Date
advanceDirectives.effectiveTime.low
Effective Thru Date
advanceDirectives.effectiveTime.high
Comments
advanceDirectives.comments
Data Elements
Other Reference
Care Record Element
Update Entry
Type Code
replace or append
reference.typeCode
Referenced Act ID
ii
reference.externalAct.id
Document Specification
Data Element
Opt
PCC Section
Template ID
Immunization Content Constraints
Original Care Record
R
Patient ID
C
Not Required for Vaccine Forecast Decision Support
DOB
C
Only Required for Vaccine Forecast Decision Support
Gender
C
Only Required for Vaccine Forecast Decision Support
History of Immunizations (POIZ)
R
1.3.6.1.4.1.19376.1.5.3.1.4.??
Immunization Record ID
R
Negation Indicator
R
Description
R
Immunization Date
R
Confidentiality Code
R2
Uncertainty Code
R2
Dose Quantity
R2
Route
R2
Approach Site
R2
Vaccine Code
R
CDC CVX
2.16.840.1.113883.6.59
Vaccine Name
R2
Vaccine Lot #
R2
Vaccine Expiration Date
R2
Manufacturer ID
R2
Performer Person ID
R2
Performer Person Name
O
Performer Organization ID
R2
Performer Organization Name
O
Author
R2
6.4.4.1
Informant
R2
6.4.4.1
Vaccine Information Statement Given
R2
VIS Version
R2
Reason Not Administered
R2
Comments about Shot
R2
6.4.4.6
1.3.6.1.4.1.19376.1.5.3.1.4.2
Authors and Informants
R2
6.4.4.1
ID
R
Address
R
Telecom
R
Role Code
R2
Name
O
Informant Mode
R2
Informant Source
R2
Problem Entry
R2
6.4.4.14
1.3.6.1.4.1.19376.1.5.3.1.4.5
ID
R
Problem began
R2
Problem ended
R2
Problem Type
R2
Confidentiality Code
R2
Uncertainty Code
R2
Problem Code
R
Severity
R2
6.4.4.3
1.3.6.1.4.1.19376.1.5.3.1.4.1
Clinical Status
O
6.4.4.4
1.3.6.1.4.1.19376.1.5.3.1.4.1.1
Health Status
O
6.4.4.5
1.3.6.1.4.1.19376.1.5.3.1.4.1.2
Comments
O
6.4.4.6
1.3.6.1.4.1.19376.1.5.3.1.4.2
Allergies and Intolerances
R2
6.4.4.15
1.3.6.1.4.1.19376.1.5.3.1.4.6
ID
R
Intolerance Type
R
Allergy Code
R
Allergen Substance
R2
Allergic Reaction History
R2
Severity
R2
6.4.4.3
1.3.6.1.4.1.19376.1.5.3.1.4.1
Clinical Status
O
6.4.4.4
1.3.6.1.4.1.19376.1.5.3.1.4.1.1
Comments
O
6.4.4.6
1.3.6.1.4.1.19376.1.5.3.1.4.2
Medications
R2
6.4.4.16
1.3.6.1.4.1.19376.1.5.3.1.4.7
ID
R
Description
R2
Date Range
R
Drug Code
R2
Drug Name
R2
Lab Results
R2
6.4.4.16
1.3.6.1.4.1.19376.1.5.3.1.4.13
ID
R
Lab Code
R
Description
R2
Date
R
Result
R2
Result Interpretation
R2
Test Method
R2
Author
R2
6.4.4.1
Vital Signs Organizer
R2
6.4.4.21
1.3.6.1.4.1.19376.1.5.3.1.4.13.1
Observation Date
R
Observation by
R2
Vital Signs Observation
R2
6.4.4.22
1.3.6.1.4.1.19376.1.5.3.1.4.13.2
ID
R
Observation Code
R
LOINC: 8310-5 body temp
vitalSigns.code
Observation Value - Units
R
Pregnancy Observation
R2
6.4.4.26
1.3.6.1.4.1.19376.1.5.3.1.4.13.5
ID
R
Observation Date
R
Pregnancy Info Type
R2
Pregnancy Status
R2
Pregnancy Info Type
R2
Estimated Due Date
R2
Advance Directive Observation
R2
6.4.4.28
1.3.6.1.4.1.19376.1.5.3.1.4.13.7
ID
R
Refusal Reason Code
R
6.4.4.28.4
<need to expand SNOMED list to include vaccines, refusal reasons, etc.>
Reason Code Permits Immunization?
R2
Effective From Date
R2
Effective Thru Date
R2
Comments
O
6.4.4.6
1.3.6.1.4.1.19376.1.5.3.1.4.2
Update Entry
C
6.4.4.31
1.3.6.1.4.1.19376.1.5.3.1.4.16
Type Code
R
6.4.4.31.3
RPLC or APND
Referenced Act ID
R
6.4.4.31.5
id of section being replaced or appended to
Immunization Content Section
TemplateID
1.3.6.1.4.1.19376.1.5.3.1.?.?
Parent Template
CCD 3.11(2.16.840.1.113883.10.20.1.6)
General Description
This section shall contain a full description of the immunizations administered to the patient in the past. It shall include entries for medication administration as described in the Entry Content Module. It shall also contain all known medical information which is relevant to past and future immunization decisions for the patient.
LOINC Code
Opt
Description
11369-6
R
HISTORY OF IMMUNIZATIONS
Entries
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.?.?
R
Immunization Content
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.?.?
R
History of Immunizations (POIZ) (if no immunizations have been given, that fact must be stated with negationInd = true, and NoImmunizationReason supplied)
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.5
R2
Problems and Conditions
Sub-sections
Opt
Description
11.3.6.1.4.1.19376.1.5.3.1.4.6
R
Allergies and Intolerances (allergy to eggs must be specified, whether positive, negative, or unknown) (any known reactions to vaccine events must be specified, and linked to the particular immunization event, if known)
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.7
R2
Medications
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.13.1
R2
Vital Signs Organizer
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.13.2
R2
Vital Signs Observation
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.13.5
C
Pregnancy Observation
Sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.13.7
R2
Advance Directives and Consent Observation
Sub-sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.1
R2
Severity (used in Problems and Allergies)
Sub-sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.1.1
R2
Clinical Status (used in Problems and Allergies)
Sub-sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.1.2
R2
Health Status (used in Problems)
Sub-sub-sections
Opt
Description
1.3.6.1.4.1.19376.1.5.3.1.4.2
R2
Comments (used in POIZ, Problems, Allergies and Advance Directives)
Parent Template
-->>do we need this?<<--
<entry>An XML Example</entry>
entry
The parent of this template is CCD 3.11.
SampleMessages
Sample V3 Message
-->>insert ImmunizationRegistryContent 052808.xml from discussion page<<--
Sample V2 Message
See Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol, referenced in Standards above.