Immunization Registry Content
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 Registry Content Profile (IRC)
Glossary
- Term
- Definition
Issue Log
Open Issues
- What PCC templates should be used?
- 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?
- 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?
Responses:
- Immunizations, Allergies & Intolerances, Vitals, Medications, Past Medical History, Problems
- Order does not matter. This is the precedent from other content profiles.
- IHE may leave codesets to implementation, following HITSP recommendations, etc. Keith: 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 will be done by the next conference call.
- CareRecord can include person who administered vaccine in Performer role. That would amount to an update to the current immunization template.
- 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
Volume I
Add the following bullet to the list of profiles
- Immunization Registry Content - The Immunization Registry Content profile identifies the data to be sent to Immunization Registries
Dependencies
Add the following row(s) to the list of dependencies
| Integration Profile | Dependency | Dependency Type | Purpose |
|---|---|---|---|
| Immunization Registry Content |
Profile Name
The Immunization Registry Content Profile (IRC)
And then some more introductory text.
Use Cases
Use Case Name 1
One or more paragraphs describing a clinical scenario.
Use Case Name 2
One or more paragraphs describing a clinical scenario.
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 Patient Care Coordination Technical Framework
Options
| Actor | Option | Section |
|---|---|---|
| Content Consumer | View Option (1) Document Import Option (1) |
PCC TF-1: 2.13.1 PCC TF-1: 2.13.2 |
| Content Creator | Referral Option (1) Discharge Summary Option (1) |
PCC TF-1: 2.13.5 PCC TF-1: 2.13.6 |
Note 1: 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 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
More text about process flow
Actor Definitions
- Actor
- Definition
Transaction Definitions
- Transaction
- Definition
Volume II
Immunization Registry Content Content
Standards
- CDAR2
- Clinical Document Architecture, Release 2, 2005 HL7
- CRS
- Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm), 2006, HL7.
- CCD
- ASTM/HL7 Continuity of Care Document (Draft)
- 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.
- HSSP Retrieve, Locate and Update Service
- Implementation Service Functional Model (SFM), balloted HL7 Draft Standard for Trial Use (DSTU) HL7.
- HSSP Retrieve, Locate and Update Service
- Initial submission to OMG includes a profile that demonstrates immunization data retrieval and update in conformance to SFM
Data Element Index
| Data Elements | Other Reference | LOINC Section or CDA Element |
|---|---|---|
| Data Element 1 | ||
| Data Element 2 | ||
| Data Element 3 |
Document Specification
| Data Element | Opt | Section | Template ID |
|---|---|---|---|
| Data Element 1 | R | 1.3.6.1.4.1.19376.1.5.3.1.3.X | |
| Data Element 2 | R2 | 1.3.6.1.4.1.19376.1.5.3.1.3.Y | |
| Data Element 3 | O | 1.3.6.1.4.1.19376.1.5.3.1.3.Z |
Section Template 1
| TemplateID | 1.3.6.1.4.1.19376.1.5.3.1.3.X | |
|---|---|---|
| Parent Template | 1.3.6.1.4.1.19376.1.5.3.1.3.Y | |
| General Description | This section shall ... | |
| LOINC Code | Opt | Description |
| #####-# | R | Description |
| Entries | Opt | Description |
| 1.3.6.1.4.1.19376.1.5.3.1.4.A | O | Description |
| Sub-sections | Opt | Description |
| 1.3.6.1.4.1.19376.1.5.3.1.3.D | R | Description |
Header Template 1
<entry>An XML Example</entry>
entry
Description of the entry element.
Entry Template 1
<entry>An XML Example</entry>
entry
Description of the entry element.