Quick answer
Confirm the jurisdiction’s onboarding and reporting arrangement before buying an IIS interface. Distinguish doses administered at the facility from historical records, preserve vaccine-event identity and inspect acceptance, correction and query behavior. Sending an HL7 message does not prove the registry stored the intended event or that every SNF must report directly.
Determine who reports the vaccination event
A pharmacy vaccinates residents during an on-site clinic while the SNF documents the event locally. Before purchasing a registry interface, establish which organization submits the event, under which facility identifiers and how the other party avoids duplicate reporting. Physical location alone does not settle reporting responsibility.
CDC's current IIS messaging page, dated March 31, 2026, identifies the consolidated HL7 v2.5.1 immunization guide, Release 1.5 with its addendum, as the recognized standard. The relevant jurisdiction's implementation, authorization and onboarding process still determines the actual connection requirements.
Ask the IIS for its current specifications, test environment, approved submission route, consent/privacy requirements and production approval process. Record whether the EHR connects directly, through an intermediary or through another authorized reporting organization.
Model events before mapping fields
CDC's immunization data elements distinguish a historical vaccination record from an event administered at the identified location. They also describe vaccine product, manufacturer and lot information. These distinctions support data quality; they do not determine which vaccine a resident should receive.
Use an original event test pack:
| Case | Data-quality question | Result to inspect |
|---|---|---|
| New dose administered at the facility | Correct event, person, date, product and applicable details? | Stored registry event and acknowledgment |
| Historical dose from an outside record | Provenance and event type preserved? | Not misrepresented as new facility administration |
| Same event retransmitted | Stable identity and duplicate handling? | One intended event or documented registry behavior |
| Corrected product or date | Supported update path used? | Old and corrected states reconciled |
| Erroneous event removed | Authorized correction/deletion procedure? | Registry and local record agree on disposition |
| Query with ambiguous identity | Safe handling of uncertain match? | No automatic incorporation into the wrong chart |
Use jurisdiction-approved synthetic cases. Do not create fictional vaccination events in a production registry.
Follow acknowledgment through resolution
Separate transmission, transport acknowledgment, application acceptance and data-quality resolution. A message can reach the endpoint while containing a rejected event or a warning requiring review. Keep message/event identifiers, status, error detail, corrective action and resubmission outcome linked.
In a fictional clinic, 40 events are prepared. Thirty-six are accepted, two fail validation and two remain awaiting an application response. “40 sent” is not a completed reporting reconciliation. The unresolved four need distinct actions; blindly resending all 40 could create unnecessary duplicates or conflicting updates.
Document which warnings permit storage and what they mean in the local IIS. Do not assume every jurisdiction uses the same acknowledgment details or accepts the same optional fields.
Treat query results as sourced information
A registry history may be incomplete, contain duplicates or require identity clarification. Show the source and retrieval time, and route incorporation through the facility's reviewed clinical workflow. A forecast or recommendation returned by a system is not a substitute for qualified clinical assessment and current immunization guidance.
Test a resident who moved across jurisdictions and a record with limited identifiers. An empty query result should not automatically become “no prior vaccinations.” Provide a route to verify history through appropriate sources.
Accept the production relationship, not only the interface
Require evidence of jurisdiction approval where applicable, correct organization/facility identifiers, supported event and query functions, error ownership and a completed initial reconciliation. Establish how changes in the EHR, intermediary or IIS specification trigger testing.
Include ongoing data-quality work in the staffing and support plan. The full-platform buyer should know who resolves rejected events and partner duplicates after implementation, rather than assuming the interface vendor owns every clinical or jurisdictional decision.
Questions & answers
Does CDC’s messaging guide impose one reporting workflow on every SNF?
No. Jurisdiction rules, authorization, reporting responsibility and onboarding requirements must be confirmed for the actual facility and arrangement.
Should a historical dose be reported as administered by the SNF?
No. Preserve the event’s actual provenance and use the jurisdiction’s supported representation. Historical and administered-at-location events are distinct data concepts.
Primary sources
Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.