Difference between revisions of "Immunization Registry Content"

From IHE Wiki
Jump to navigation Jump to search
m
 
(161 intermediate revisions by 3 users not shown)
Line 5: Line 5:
  
 
==Profile Abstract==
 
==Profile Abstract==
The Immunization Registry Content Profile (IRC)  
+
===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==
 
==Glossary==
 
<!--; Term : Definition-->
 
<!--; Term : Definition-->
  
; Immunization Information System (IIS) : ''Definition''
+
; Immunization Information System (IIS) : ''Preferred term of the American Immunization Registry Association for "Immunization Registry"''
  
 
==Issue Log==
 
==Issue Log==
 
===Open Issues===
 
===Open Issues===
 +
Public comment is solicited on all of the following 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 PCC-2 Immunization Summary template to contain all the fields in POIZ that are also supported in CareRecord.  Template for Immunizations needs to be fixed to include Lot #, Manufacturer, and Expiration Date, and a few other items.  The updated template is the equivalent of a POIZ template on CareRecord.  This update needs to be completed by the appropriate means.
 +
# Template for Advanced Directives needs to be fixed to include Immunization Refusal Reasons.
 +
# It is expected that ballot comments on the CareRecord DSTU within HL7 will include requests to add elements available in POIZ but not accommodated in CareRecord.  Assuming those elements are eventually added, this IC profile will have to be updated to also include them.
 +
# Not enough is said about precisely how the HL7 Version 2 messages are to be used.  HL7 Version 2 couples content more tightly with message syntax than Verion 3.  Care Management (CM) provides the notification-based integration profile, and Query for Existing Data (QED) provides a query-based integration profile for the HL7 V3 portions of this profile.  However, it is unclear how CM and QED will handle V2.  V2.3.1 messages blend identity resolution, which is outside the scope of this profile, with transmission of clinical data; how will this be handled?  Also, if a Version 2 Implementation Guide is referenced, how will updates to that document be handled?
 +
# 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 or even three profiles, i.e. , one for HL7 Version 2, and one or two for HL7 Version 3 (depending upon whether the Immunization Summary and Care Record options are combined).
 +
# Implementation of this profile within PCC Volumes I and II will involve a two-part exercises:  (1) update of the existing PCC-2 Immunization Summary template to reflect missing POIZ fields; and (2) creation of a new profile for the Care Record Option that includes Allergies, Problems, etc. - something that looks more like a discharge summary or a transfer of care summary, etc.
 +
# We assume we can use the Simple Observation template of Care Record to record Vaccine Information Statement Given (VIS Given) and VIS Version fields.  Is this the best approach?
 +
  
# If we include POIZ in the Immunization Summary, there are two approaches:  (1) make sure all the POIZ elements have counterparts in CareRecord; (2) propose changes to CareRecord that incorporate the syntax of POIZ in CareRecord.  Is the latter out of scope to this exercise?
 
# Can we rename the profile to not include the word "registry" - i.e. Immunization Content or Immunization Information System Content?  Immunization registries are trying to get away from that phrase and instead call themselves Immunization Information Systems.  Also, the word "registry" implies a Central Data Repository model; this content profile can be used for applications reaching beyond that model.
 
# How will V2 content be handled here?  If not here, where then will it be included?
 
{{Fixme|register IZ Implementation Guide with HL7 Message Profile Registry}}
 
# V2.3.1 messages blend identity resolution with transmission of clinical data.  How to handle this?
 
# Note that "V2" below refers to "V2.3.1".  Note V2.5 is also under development.
 
# How to handle updates to referenced V2 Guides.
 
# Had a discussion about queries (using QED) vs. notifications (updates) (using Care Management), also using templates to describe content, and how this would work in V3 vs. V2.  Also whether web services could provide a uniform transport layer interface for passing the different types of content.
 
{{Fixme|Care mgt defining WSDL, we supply template}}
 
# We want to use one WSDL for all v3 use cases, and a second WSDL for the same use cases in v2.
 
{{Fixme|V2 uses MLLP/MLLP under TLS might belong in Care Management batch vs. realtime belongs here?}}
 
# There are essentially 3 different payloads to pass: Submitted History Update; Query for History; and Submitted History for DSS.  We hope to use the same WSDL for all of them, and the same message structure for the Immunization History and Care Record details in all of them.
 
# 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:
 
        <author typeCode='AUT' contextControlCode='OP'>
 
            <assignedPerson classCode='ASSIGNED'>
 
                <id root='' extension=''/>
 
                <code/> 
 
                <addr></addr>
 
                <telecom use='' value=''/>
 
                <person classCode='PSN' determinerCode='INSTANCE'>
 
                    <name>...</name>
 
                </person>
 
                <representedOrganization classCode='ORG'
 
                                    determinerCode='INSTANCE'>
 
                    <name>...</name>
 
                </representedOrganization>
 
            </assignedPerson>
 
        </author>
 
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?
 
<br>
 
<br>
 
Responses:
 
<br>
 
# The overarching issue which can be discussed in Phoenix at HL7 is the harmonization of messages and documents.  The developer does not want to have to translate one to the other, even if all the elements in the one match the elements in another.  A precedent was set for this by CCD.  However this may be out of scope to our current exercise.
 
  
===Closed Issues===
+
===Closed Issues===  
# What PCC templates should be used?
+
# Where CareRecord and POIZ have different tags for the same elements, we have chosen to use the CareRecord tags in the templates and sample messagesThe other possibility is to use the POIZ tags, which may be more meaningful to immunization domain expertsHowever, we felt that the POIZ tag names and definitions within the HL7 POIZ HMD were not significantly more descriptive to warrant "breaking" software that currently parses Care Record messages and may expect Care Record tags.
# In what order should the specified templates appear?
 
# How will codesets be specified?
 
# What happens if two consecutive messages have conflicting content?
 
# Can we include the HL7 V3 Immunization message (POIZ) in the Immunization Summary so as to harmonize with POIZ? 
 
# If we don't include POIZ in the Immunization Summary, how do we get the important elements that are currently missing from the immunization template included, for example, the person who gave the shot?
 
<br>
 
Resolution
 
<br>
 
# Immunizations, Allergies & Intolerances, Vitals, Medications, Past Medical History, Problems
 
# Order does not matterThis is the precedent from other content profiles.
 
# IHE may leave codesets to implementation, following HITSP recommendations, etcKeith: IHE profile should leave it somewhat open, but U.S. realm would use CVX codesets for immunizatons, and ICD9 or SNOMED for problems or allergies.  But for realms outside U.S. codesets could and would be different.
 
# This will be handled in the integration profile.
 
# It appears that all the POIZ elements are currently included in CareRecord, but this needs to be checked in detail.  This has been done by Keith and will be looked at further in Phoenix by authors of POIZ.  So far no major show-stoppers have surfaced.  Most differences include items that are introduced in POIZ but not necessarily in use in installed bases.  Base IZ class includes activity time and uncertainly code, not reflected in CR.  POIZ includes more support in the protocol area (which is related to decision support), also a new area.  It was noted on the recent HL7 PHER call that POIZ is after all DSTU and if harmonization of labels were agreed upon, the changes could be released in a future ballot.
 
# CareRecord can include person who administered vaccine in Performer role.  That would amount to an update to the current immunization template.
 
  
 
=Volume I=
 
=Volume I=
 
<pre>Add the following bullet to the list of profiles</pre>
 
<pre>Add the following bullet to the list of profiles</pre>
* Immunization Registry Content - The Immunization Registry Content profile identifies the data to be sent to Immunization Registries
+
* 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===
 
===Dependencies===
 
<pre>Add the following row(s) to the list of dependencies</pre>
 
<pre>Add the following row(s) to the list of dependencies</pre>
{|style='background-color:#7f7f7f;' align='center' border='1' cellspacing='0'
+
{{T|Integration Profile|Dependency|Dependency Type|Purpose|Rows=
!Integration Profile
+
{{R|Immunization Content (IC)|Care Management (CM)|The Content Creator actor of the IC profile must be grouped with the Clinical Data Source Actor of the CM profile|The IC profile defines the content sent in the PCC-11 transaction specified in the CM profile}}
!Dependency
+
{{R|Immunization Content (IC)|Care Management (CM)|The Content Consumer actor of the IC profile must be grouped with the Care Manager Actor of the CM profile|The IC profile defines the content recieved in the PCC-11 transaction specified in the CM profile}}
!Dependency Type
+
{{R|Immunization Content (IC)|ATNA|Actors the IC profile shall implement the Secure Node Actor of the ATNA profile|Ensures that transmissions and changes to patient health information are logged in an audit repository, and that communication is secured between nodes.}}
!Purpose
+
{{R|Immunization Content (IC)|ATNA|Actors the IC profile shall implement the Time Client Actor of the CT profile|Ensures that concistent time is used in all messages.}}
|- style='background-color:#ffffff;' align='center'
+
}}
|Immunization Registry Content
 
|
 
|
 
|
 
|-
 
|}
 
==Profile Name==
 
The Immunization Content Profile (IISC)  
 
  
The Immunization Content Profile (IISC) provides a template for exchanging immunization data.  
+
==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.
  
Immunization data includes two types of content:
+
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.
  
# information about administration of vaccines
+
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.
# care provision information required in making decisions about administration of vaccines
 
  
Thus, IISC draws from two HL7 Version 3 message paradigms:  Care Provision and Immunizations.  ''(Something about how CareRecord and POIZ harmonization is resolved.)''
 
  
''It seems there are two cases:  one where just the immunization summary is passed and the other where the entire CareRecord is passed.''
+
===Use Cases===
 +
The following progression of use cases is illustrated in the drawing below.
  
''Should we includeTo provide for compatibility with the U.S. installed base of Immunization Information Systems (IISs), or Immunization Registries, HL7 Version 2 content is also included.''
+
====Use Case 1Immunization 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.
  
The IC Profile is also intended to pave the way for content to be passed to immunization-related decision support services.  This however is out of scope for the 2007-2008 year and is on the IHE roadmap for the future.
+
This is representative of the present-state use case in the U.S.
  
===Use Cases===
+
====Use Case 2:  Immunization Yellow Card====
====Use Case Name 1====
+
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.
EMR system queries IIS for Immunization Summary only.  ''Elaborate.''
+
 
 +
====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 immunizationsThe 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 Name 2====
+
====Use Case 4:  Vaccine Forecast====
EMR system sends entire Care Record to IIS or to Decision Support Service.  ''Elaborate.''
+
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 returnIt records the care plan and uses it in reminder/recall.
  
 
===Actors/Transaction===
 
===Actors/Transaction===
Line 133: Line 74:
  
 
=== Options ===
 
=== Options ===
 
 
{|style='background-color:#cfcfcf;' align='center' border='1' cellspacing='0'
 
{|style='background-color:#cfcfcf;' align='center' border='1' cellspacing='0'
 
!Actor
 
!Actor
 
!Option
 
!Option
!Section
+
|+Immunization Content Options
|+Immunization Registry Content Options
 
 
|- style='background-color:#ffffff;' align='center'
 
|- style='background-color:#ffffff;' align='center'
 
|Content Consumer
 
|Content Consumer
|Immunization Summary Option [[#note1|(1)]]<br/>
+
|No Options Defined
Care Record Option [[#note1|(1)]]<br/>
 
HL7 V2 Option [[#note1|(1)]]<br/>
 
|PCC TF-1: X.X.X<br/>
 
PCC TF-1: X.X.X<br/>
 
PCC TF-1: X.X.X
 
 
|- style='background-color:#ffffff;' align='center'
 
|- style='background-color:#ffffff;' align='center'
 
|Content Creator  
 
|Content Creator  
 
|Immunization Summary Option [[#note1|(1)]]<br/>
 
|Immunization Summary Option [[#note1|(1)]]<br/>
Care Record Option [[#note1|(1)]]<br/>
+
Immunization Detail Option [[#note1|(1)]]<br/>
HL7 V2 Option [[#note1|(1)]]<br/>
+
V2 Immunization Update Option [[#note1|(1)]]<br/>
|PCC TF-1: X.X.X<br/>
 
PCC TF-1: X.X.X<br/>
 
PCC TF-1: X.X.X
 
 
|}
 
|}
  
Note <sup ID=note1>1</sup>: The Actor shall support at least one of these options.
+
''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.
 
-->
 
 
 
=== Content Modules ===
 
Content modules describe the content of a payload found in an IHE transaction. Content profiles are transaction neutral. They do not have dependencies upon the transaction that they appear in.
 
 
 
==== Content Module 1 ====
 
 
 
=== Process Flow ===
 
<!--[[Image:seq.jpg|frame|center|Immunization Registry Content Process Flow]]-->
 
 
 
More text about process flow
 
 
 
== Actor Definitions ==
 
; Actor : Definition
 
== Transaction Definitions ==
 
; Transaction : Definition
 
 
 
=Volume II=
 
===Immunization Registry Content===
 
==== Standards ====
 
<!--; [http://www.hl7.org/v3ballot/html/infrastructure/cda.htm CDAR2] : Clinical Document Architecture, Release 2, 2005 HL7
 
; [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 ====
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Common Care Record Elements Required for Immunization Registry Content
 
|-
 
|Patient ID ||not required for VFM DSS||patient.id
 
|-
 
|DOB ||only required for VFM DSS||patient.birthTime
 
|-
 
|Gender ||only required for VFM DSS ||patient.administrativeGender
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Immunization Registry Content Data Elements based on POIZ
 
|-
 
|Immunization Record ID || instance identifier ||immunization.id 
 
|-
 
|Negation Indicator || ||immunization.negationInd
 
|-
 
|Description || ||immunization.text
 
|-
 
|Immunization Date || ||immunization.effectiveTime
 
|-
 
|Confidentiality Code || ||immunization.confidentialityCode
 
|-
 
|Uncertainty Code || ||immunization.uncertaintyCode
 
|-
 
|Dose Quantity || ||immunization.doseQuantity.value - units
 
|-
 
|Route || ||immunization.routeCode
 
|-
 
|Approach Site || ||immunization.approachSiteCode
 
|-
 
|Vaccine Code || CDC CVX code in US ||administerableMaterial.code 
 
|-
 
|Vaccine Name || ||administerableMaterial.name
 
|-
 
|Vaccine Lot # || ||administerableMaterial.lotNumberText
 
|-
 
|Vaccine Expiration Date || ||administerableMaterial.expirationTime
 
|-
 
|Manufacturer ID || CDC MVX code in US ||asMedicineManufacturer.manufacturer.id 
 
|-
 
|Manufacturer name || ||asMedicineManufacturer.manufacturer.name 
 
|-
 
|Vaccine Lot # Recalled Observation || ||???
 
|-
 
|Performer ID || ||performer.assignedPerson.id
 
|-
 
|Performer Name || ||performer.assignedPerson.assignedPrincipalChoice List.person.name
 
|-
 
|Performer Organization ID || ||performer.assignedPerson.representedOrganization.id
 
|-
 
|Performer Organization Name || ||performer.assignedPerson.representedOrganization.name
 
|-
 
|Author ID || ||author.assignedPerson.id
 
|-
 
|Author Role || ||author.role.code
 
|-
 
|Author Name || ||author.person.name
 
|-
 
|Informant Name || ||informant.person.name
 
|-
 
|Informant Mode || written/verbal/electronic ||informant.modeCode 
 
|-
 
|Informant Source || patient/relative/provider ||informant.informationSourceCode 
 
|-
 
|Vaccine Information Statement Given || ||observation.code
 
|-
 
|VIS Version || ||observation.value
 
|-
 
|Reason Not Administered || ||reason.noImmunizationReason.reasonCode
 
|-
 
|Shot Comments / Notes || ||annotation.text
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Problem Record Data Elements
 
|-
 
|ID|| ||problems.id
 
|-
 
|Problem began || ||problems.effectiveTime.low
 
|-
 
|Problem ended || ||problems.effectiveTime.high
 
|-
 
|Problem Type || SNOMED CT type of problem ||problems.code 
 
|-
 
|Confidentiality Code || ||problems.confidentialityCode
 
|-
 
|Uncertainty Code || ||problems.uncertaintyCode
 
|-
 
|Problem Code || ICD-9 or SNOMED problem code ||problems.value 
 
|-
 
|Severity || ||problems.severity
 
|-
 
|Clinical Status || ||problems.clinicalStatus
 
|-
 
|Health Status || ||problems.healthStatus
 
|-
 
|Comments || ||problems.comments
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Allergy and Intolerance Data Elements
 
|-
 
|ID|| ||intolerance.id
 
|-
 
|Intolerance Type || ObservationIntoleranceType ||intolerances.code 
 
|-
 
|Allergy Code || ICD-9 or SNOMED allergy code ||intolerances.value 
 
|-
 
|Allergen Substance || substance causing allergy ||intolerances.participant.code 
 
|-
 
|Allergic Reaction History || ||intolerances.reactions
 
|-
 
|Severity || ||intolerances.severity
 
|-
 
|Clinical Status || ||intolerances.clinicalStatus
 
|-
 
|Comments || ||intolerances.comments
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Medications Data Elements
 
|-
 
|ID || ||medications.id
 
|-
 
|Description || ||medications.text
 
|-
 
|Date Range || ||medications.effectiveTime
 
|-
 
|Drug Code || ||administeredMaterial.code
 
|-
 
|Drug Name || ||administeredMaterial.name
 
|}
 
 
<br>
 
<br>
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Simple Observations for Labs
 
|-
 
|ID|| || labs.id
 
|-
 
|Lab Code || ||labs.code
 
|-
 
|Description || ||labs.text
 
|-
 
|Date || ||labs.effectiveTime
 
|-
 
|Result || ||labs.value
 
|-
 
|Result Interpretation || ||labs.interpretationCode
 
|-
 
|Test Method || ||labs.methodCode
 
|-
 
|Author ID || ||labs.author.id
 
|-
 
|Author Name || ||labs.author.name
 
|}
 
 
<br>
 
<br>
{| cellspacing=0 border=1 align='center'
+
==== Immunization Summary Option ====
!style='background-color:#cfcfcf' |Data Elements
+
The Immunization Summary Option is based upon HL7 Version 3It includes information about immunization history of a patient.
!style='background-color:#cfcfcf' |Other Reference
+
==== Immunization Detail Option ====
!style='background-color:#cfcfcf' |Care Record Element
+
The Immunization Detail Option is also based upon HL7 Version 3It includes all of the requirements of the Immunization Summary Option, plus ancillary information to support decisions about the treatment of a patient related to immunizationsFor example, it includes the patient's allergies, which may be relevant in deciding whether or not to give certain vaccines.
|+ Existing Vital Signs Data Elements
+
==== V2 Immunization Update Option ====
|-
+
The V2 Immunization Update Option is for backwards compatibility with existing HL7 Version 2.3.1 immunization messaging.
|Observation Date || ||vitalSigns.organizer.effectiveTime
 
|-
 
|Observation by || ||vitalSigns.organizer.author
 
|-
 
|ID|| || vitalSigns.id
 
|-
 
|Observation Code || LOINC: 8310-5 body temp ||vitalSigns.code  
 
|-
 
|Observation Value - Units || ||vitalSigns.value
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Pregnancy Data Elements
 
|-
 
|ID|| || pregnancy.id
 
|-
 
|Observation Date|| || pregnancy.effectiveTime
 
|-
 
|Pregnancy Info Type || LOINC: 11449-6 Pregnancy Status ||pregnancy.code  
 
|-
 
|Pregnancy Status || ||pregnancy.value
 
|-
 
|Pregnancy Info Type || LOINC: <several codes> Estimated Delivery Date ||pregnancy.code  
 
|-
 
|Estimated Due Date || ||pregnancy.value
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Existing Advanced Directives Data Elements
 
|-
 
|ID|| ||advanceDirectives.id
 
|-
 
|Scope (Refusal Reason Code) || <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
 
|}
 
<br>
 
{| cellspacing=0 border=1 align='center'
 
!style='background-color:#cfcfcf' |Data Elements
 
!style='background-color:#cfcfcf' |Other Reference
 
!style='background-color:#cfcfcf' |Care Record Element
 
|+ Update Entry
 
|-
 
|Type Code||replace or append || reference.typeCode
 
|-
 
|Referenced Act ID||ii|| reference.externalAct.id 
 
|}
 
  
<br>
+
=== Grouping ===
 
+
==== Care Management (CM) ====
==== Document Specification ====
+
The [[Content Creator]] of this profile must be grouped with the [[Clinical Data Source]] of the Care Management profile. The Clinical Data Source actor must implement the V2 Care Management Update Option.
{| cellspacing=0 border=1 align='center'
 
! style='background-color:#cfcfcf'|Data Element
 
! style='background-color:#cfcfcf'|Opt
 
!  style='background-color:#cfcfcf'|PCC Section
 
! style='background-color:#cfcfcf' |Template ID
 
|+ Immunization Registry Content Constraints
 
|-
 
| || || ||
 
|-
 
|'''Original Care Record''' ||R|| ||
 
|-
 
|Patient ID ||C|| ||Not Required for VFM DSS
 
|-
 
|DOB ||C|| ||Only Required for VFM DSS
 
|-
 
|Gender||C|| ||Only Required for VFM DSS
 
|-
 
| || || ||
 
|-
 
|'''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
 
|-
 
|ID ||R||6.4.4.31.5|| id of section being replaced or appended to
 
|}
 
 
 
==Immunization Registry Content Section==
 
{| border=1 cellspacing=0
 
|-
 
!style='background-color:#cfcfcf;'|TemplateID
 
| colspan=2|1.3.6.1.4.1.19376.1.5.3.1.?.?
 
|-
 
!style='background-color:#cfcfcf;'|Parent Template
 
| colspan=2|CCD 3.11(2.16.840.1.113883.10.20.1.6)
 
|-
 
!style='background-color:#cfcfcf;'|General Description
 
|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 Registry 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==
 
<pre>
 
<entry>An XML Example</entry>
 
</pre>
 
=== entry ===
 
The parent of this template is CCD 3.11.
 
 
 
==Entry Template 1==
 
<pre>
 
<entry>An XML Example</entry>
 
</pre>
 
=== entry ===
 
Description of the entry element.
 
 
 
[[Category:PCC]]
 
[[Category:Draft Profile Supplement]]
 
  
<!-- {{:Content Profile Supplement Template|Antepartum Record|AR|One sentence||PCC}} -->
+
The [[Content Consumer]] Actor of this profile must be grouped with the [[Care Manager]] actor of the Care Management profile.

Latest revision as of 13:37, 2 June 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.

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

Immunization Information System (IIS)
Preferred term of the American Immunization Registry Association for "Immunization Registry"

Issue Log

Open Issues

Public comment is solicited on all of the following issues:

  1. 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 PCC-2 Immunization Summary template to contain all the fields in POIZ that are also supported in CareRecord. Template for Immunizations needs to be fixed to include Lot #, Manufacturer, and Expiration Date, and a few other items. The updated template is the equivalent of a POIZ template on CareRecord. This update needs to be completed by the appropriate means.
  2. Template for Advanced Directives needs to be fixed to include Immunization Refusal Reasons.
  3. It is expected that ballot comments on the CareRecord DSTU within HL7 will include requests to add elements available in POIZ but not accommodated in CareRecord. Assuming those elements are eventually added, this IC profile will have to be updated to also include them.
  4. Not enough is said about precisely how the HL7 Version 2 messages are to be used. HL7 Version 2 couples content more tightly with message syntax than Verion 3. Care Management (CM) provides the notification-based integration profile, and Query for Existing Data (QED) provides a query-based integration profile for the HL7 V3 portions of this profile. However, it is unclear how CM and QED will handle V2. V2.3.1 messages blend identity resolution, which is outside the scope of this profile, with transmission of clinical data; how will this be handled? Also, if a Version 2 Implementation Guide is referenced, how will updates to that document be handled?
  5. 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 or even three profiles, i.e. , one for HL7 Version 2, and one or two for HL7 Version 3 (depending upon whether the Immunization Summary and Care Record options are combined).
  6. Implementation of this profile within PCC Volumes I and II will involve a two-part exercises: (1) update of the existing PCC-2 Immunization Summary template to reflect missing POIZ fields; and (2) creation of a new profile for the Care Record Option that includes Allergies, Problems, etc. - something that looks more like a discharge summary or a transfer of care summary, etc.
  7. We assume we can use the Simple Observation template of Care Record to record Vaccine Information Statement Given (VIS Given) and VIS Version fields. Is this the best approach?


Closed Issues

  1. Where CareRecord and POIZ have different tags for the same elements, we have chosen to use the CareRecord tags in the templates and sample messages. The other possibility is to use the POIZ tags, which may be more meaningful to immunization domain experts. However, we felt that the POIZ tag names and definitions within the HL7 POIZ HMD were not significantly more descriptive to warrant "breaking" software that currently parses Care Record messages and may expect Care Record tags.

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 (IC) Care Management (CM) The Content Creator actor of the IC profile must be grouped with the Clinical Data Source Actor of the CM profile The IC profile defines the content sent in the PCC-11 transaction specified in the CM profile
Immunization Content (IC) Care Management (CM) The Content Consumer actor of the IC profile must be grouped with the Care Manager Actor of the CM profile The IC profile defines the content recieved in the PCC-11 transaction specified in the CM profile
Immunization Content (IC) ATNA Actors the IC profile shall implement the Secure Node Actor of the ATNA profile Ensures that transmissions and changes to patient health information are logged in an audit repository, and that communication is secured between nodes.
Immunization Content (IC) ATNA Actors the IC profile shall implement the Time Client Actor of the CT profile Ensures that concistent time is used in all messages.

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.

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.

Immunization Registry Content Actor Diagram

Options

Actor Option
Immunization Content Options
Content Consumer No Options Defined
Content Creator Immunization Summary Option (1)

Immunization Detail Option (1)
V2 Immunization Update Option (1)

Note (1): The Actor shall support at least one of these options.

Immunization Summary Option

The Immunization Summary Option is based upon HL7 Version 3. It includes information about immunization history of a patient.

Immunization Detail Option

The Immunization Detail Option is also based upon HL7 Version 3. It includes all of the requirements of the Immunization Summary Option, plus ancillary information to support decisions about the treatment of a patient related to immunizations. For example, it includes the patient's allergies, which may be relevant in deciding whether or not to give certain vaccines.

V2 Immunization Update Option

The V2 Immunization Update Option is for backwards compatibility with existing HL7 Version 2.3.1 immunization messaging.

Grouping

Care Management (CM)

The Content Creator of this profile must be grouped with the Clinical Data Source of the Care Management profile. The Clinical Data Source actor must implement the V2 Care Management Update Option.

The Content Consumer Actor of this profile must be grouped with the Care Manager actor of the Care Management profile.