Vaccine Funding Source
afitzsi...@gmail.com
sheryl...@nist.gov
sheryl...@nist.gov
Hi,
The immunization subject matter experts have reached their decision.
It’s important for an EHR-S to be able to message the Vaccine Funding Source in order to promote interoperability. A CDC project last year produced updates to the Vaccine Funding Source codes, which are reflected on page 25 in the Addendum to the Implementation Guide for Immunization Messaging R1.5.
Though there appears to be a conflict in Appendix B Table B-2 of the Implementation Guide that shows the Vaccine Funding Source as Optional, this table explains a base standard on which the Guide was, in part, based. The Vaccine Funding Source values are defined in the relevant value set (PHVS_ImmunizationFundingSource_IIS). Therefore, in the V04_Z22 messages for the vaccine administration Test Cases, for each RXA segment in which RXA-9 is populated with “00^New Record^NIP001” an OBX segment containing Vaccine Funding Source is included.
Thank you for your question.
usabc...@gmail.com
Can you please clarify whether the Funding Source codes, reflected on page 25 in the Addendum to the Implementation Guide for Immunization Messaging R1.5, replaced the codes reflected on page 54 in HL7 Version 2.5.1 Implementation Guide: Immunization Messaging (Release 1.5)? Or were they simply updates to the existing list? Thank you!
Craig Newman
The new values below (from the addendum) replace what was in Release 1.5. These were the product of additional work by the CDC in this area after the publication of Release 1.5.
Code | Label | Definition |
PHC70 | Private | Vaccine stock used was privately funded |
VXC50 | Public | Vaccine stock used was publicly funded |
VXC51 | Public VFC | Vaccine stock used was publicly funded by the VFC program |
VXC52 | Public non-VFC | Vaccine stock used was publicly funded by a non-VFC program |
--
You received this message because you are subscribed to the Google Groups "HL7v2 Immunization Testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hl7v2-immunization-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
catherin...@cerner.com
• The main implementation guide on page 371 declares Vaccine Funding Source (VFC) optional as acknowledged by NIST
• The value set table on page 25 of the Addendum DOES NOT indicate that the field is now changed from O to RE or R. It is a value set, not a change to the level of required nature of the field.
• Presence of a value set does not constitute a field becoming required. It only means that when the field is used, those are the values to use. The value set could indicate whether it is restricted to those values or could have additional values added as the user sees fit, but that is the sum of the scope of the value set.
• In the absence of an errata, there is no statement in the addendum that makes VFC required.
Thank you for your re-review of the IG and addendum and the update to the tool (or in lieu of a tool update, an entry in the companion guide).
Catherine
sheryl...@nist.gov
> To unsubscribe from this group and stop receiving emails from it, send an email to hl7v2-immunization-testing+unsub...@googlegroups.com.
Craig Newman
Catherine,
Can you please clarify why you are opposed to implementing functionality to support messaging the funding source? Funding Source is important for accurate inventory management and is often requested by IIS. Are you getting push back from providers about documenting this information? Is there a workflow issue at the time of vaccination administration?
Thank you.
Craig
From: hl7v2-immuniz...@googlegroups.com [mailto:hl7v2-immuniz...@googlegroups.com] On Behalf Of sheryl...@nist.gov
Sent: Friday, September 30, 2016 8:37 AM
To: HL7v2 Immunization Testing <hl7v2-immuniz...@googlegroups.com>
Cc: usabc...@gmail.com; catherin...@cerner.com
Subject: Re: Vaccine Funding Source
Hi Catherine.
> To unsubscribe from this group and stop receiving emails from it, send an email to hl7v2-immunization-...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
While we appreciate the input, we respectfully disagree with the conclusion and request NIST to update the validator to the requirements in the guide and make the funding source optional.
• The main implementation guide on page 371 declares Vaccine Funding Source (VFC) optional as acknowledged by NIST
• The value set table on page 25 of the Addendum DOES NOT indicate that the field is now changed from O to RE or R. It is a value set, not a change to the level of required nature of the field.
• Presence of a value set does not constitute a field becoming required. It only means that when the field is used, those are the values to use. The value set could indicate whether it is restricted to those values or could have additional values added as the user sees fit, but that is the sum of the scope of the value set.
• In the absence of an errata, there is no statement in the addendum that makes VFC required.
Thank you for your re-review of the IG and addendum and the update to the tool (or in lieu of a tool update, an entry in the companion guide).
Catherine
--
You received this message because you are subscribed to the Google Groups "HL7v2 Immunization Testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hl7v2-immunization-...@googlegroups.com.
Britton,Catherine
Hi Craig
I am absolutely not opposed to implementing this capability. What I am opposed to is marking it required for certification (an error in the NIST tooling) when it is clearly optional (warning in the NIST tooling) in the ONC required specification. The tests (data, tools, procedures, guides) are intended to create a level playing field and VERIFY the ONC requirements from the final rule; the tests cannot CHANGE the requirements of the final rule and it’s referenced specifications.
The current behavior of the tool is changing, specifically increasing, the requirements by making mandatory that which is optional in the specification. This is a tool defect and should be corrected by making this optional field optional with a warning not an error.
Thank you for your attention to this issue,
Catherine
Snelick, Robert D. (Fed)
Hi Catherine,
Thank you for your question. The NIST test cases are designed to test to the requirements (and only to the requirements) as stated in the ONC-referenced standard and addendum. However, sometimes the requirements are not clear or there are conflicting requirement statements in these documents. This is one such case.
In consulting with the authors of the implementation guide Release 1.5, it was explained to us that Table B-2 (Appendix) on pages 369 - 372 in the IG was not intended to be normative, only informative (though the guide gives no indication as to whether the table is normative or informative). This table was intended to link the core data elements defined by CDC for use by IIS to their corresponding HL7 message elements. The “Support Status” values are not equivalent to the HL7 v2 “Usage” values and, therefore, do not indicate messaging requirements. The Support Status footnote 46 on page 369 of the IG is a bit unclear; but it is being interpreted as indicating that “Required” in the table means “Support and Send”, while “Optional” means “Support and Send if Known” (meaning Optional is a “must support”).
Additionally, in the messaging requirements, support for observations is required and specific observations are defined for the OBX segment (i.e., OBX-3 requires support for the NIP003 value set). Code 30963 (LN) in the NIP003 value set indicates support for the vaccine funding source. Observation results for vaccine funding source are to be conveyed using the PHVS_ImmunizationFundingSource_IIS value set (updated in the addendum—which ONC referenced for the 2015 Edition immunization messaging criterion) as indicated in the NIP003 table (value set) section of the guide. Such requirements are normative.
When conflicts occur in requirements (although it is not clear here that there is a conflict), NIST defaults to the messaging requirements. Since there is clear indication that observations for vaccine funding source must be supported, no changes to the validation is necessary.
Regards,
Rob
NIST
catherin...@cerner.com
Thank you for your response. We have analyzed your response and the specification, IG and addendum and provide the following to additionally substantiate the request for change. While we understand from your response that perhaps the intent of the authors may have been for all NIP003 values to be supported, the implementation guide does not specify that implicitly nor explicitly and, therefore we request that in the absence of a published update to the implementation guide and inclusion in an updated certification edition that the vaccine funding source is not required. Our rationale is:
• On page 16 of the IG it states “It is expected that systems that are using this Implementation Guide will be able to support these data elements and include them in a message. See Core Data Elements in Appendix B.”
• When navigating to Appendix B, page 4, Vaccine Funding Source is clearly marked “Optional”.
o Footnote 46 furthermore states (bold highlighting is mine) “46 Support Status indicates [BOLD whether the field must be supported] by the information system and messaged if known. It does not indicate whether all messages must contain the data element. That is indicated in the usage column for each field.” further underscoring that this is about the information system supporting its capture and messaging.
• Then continuing on page 16 of the main document it states “These core data elements will also be included in conformance statements. This may be at the HL7 message component level or a data concept level.16 It is important that these data elements are supported by both sender and receiver.” This indicates that further guidance may be stated through conformance statements. But there is no conformance statement that makes an overriding statement about Appendix B’s “optional” statement. While there is a conformance statement (table 5-8) for the NIP003 value of Patient Eligibility for funding, which is defined in the IG as distinctly different than Vaccine funding source, and this value is marked as Required in appendix B, Table 5-8 does not include vaccine funding source.
• Continuing on to OBX to understand the value set to be used, OBX-3 indicates use of NIP003. On page 90 (as well as 173 and 251) it indicates that “This indicates what this observation refers to. It poses the question that is answered by OBX-5.” There is no indication that all values must be supported. We note that a reference from a segment to a value set does not mean that everything needs to be supported as frequently subsets are used.
• Moving to NIP003 it states these are used in OBX-3. The descriptions provide the necessary characteristics to properly populate OBX-2 and understand what the allowable values are in OBX-5 where coded, but there is no statement that indicates that all values must be supported.
The only clear statement of use in Appendix B with no overriding statements anywhere else. Any intent that may have been verbally discussed with the authors was not clearly documented such as done in the Lab implementation guides where every value set member has a clear, unambiguous indication of whether it must be supported, is optional to support, or is disallowed.
Absent such clear guidance with everything else pointing to optional use as indicated above, it is not appropriate to mandate their use through test scripts. Rather any required support for vaccine funding source should be deferred to the next update of the implementation guide where this can be unambiguously documented.
Catherine
Snelick, Robert D. (Fed)
Your points are well taken. There is no disagreement about the lack of clarity in the specification regarding this issue. However, for each of the points you make an equally valid opposing argument (interpretation) can be made. There is evidence on both sides of the fence. When not explicitly stated, our testing policy is that ALL codes in ALL value sets bound to data elements with usage of R, RE, or C(a/b) [where either a or b is one of R or RE], are subject to testing. However, we don’t test to all; we selectively test to a subset based on needed functionality to support the use case (indicated by the ONC criterion). We rely on SME input to determine the testable set.
We do agree that precise specificity of value set requirements is necessary. NIST was the originator and led the effort for getting such specificity in the lab specifications. We are now leading efforts to apply this method to other domains. Clear specifications will ease the efforts of implementer and testers alike. However, we understand that this doesn’t do us any good for this issue and that this answer is likely not to be satisfactory to you. We consider all information, are cognitive of end-user needs, and take SME and IG authors’ input to make an informed decision when there are conflicting requirements—we have done that here. Furthermore, all test cases were published in late fall of 2015 and were open to public comment (before they were finalized in February).
If you are unhappy with this decision, you may wish to raise your issue with ONC.
Regards,
Rob
NIST
Dan Chaput
On Thursday, August 4, 2016 at 3:49:02 PM UTC-4, afitzsi...@gmail.com wrote: