Stream: argonaut
Topic: gForge #20029
Hans Buitendijk (Apr 22 2019 at 16:26):
There is a gForge (#20029) that proposes to make the Device attributes that support UDI elements MUST SUPPORT in FHIR R4 US Core. That proposal was originally found persuasive with mod where the mod was to only make Device.udiCarrier.carrierHRF and Device.udiCarrier.carrierAIDC MUST SUPPORT.
Last Thursday a motion to re-open passed with the intent to address a new motion to make all UDI elements MUST SUPPORT, i.e., per original tracker item proposal.
The following are concerns we would like those participating in in the discussion and intending to join the next call to be aware of as we believe there is a better approach to pursue the intent, allow for further implementation experience, while doing so in sync with C-CDA and v2 where such information can be conveyed.
We are very concerned with the proposed motion and propose an alternative solution to make progress to persist and communicate UDI elements in addition to the HRF, which to date is the agreed to singular field that must be communicated and persisted. Note that neither the Harmonization document, UDI Pattern R1, nor UDI Pattern R2 currently in ballot, require to persist individual elements upon receipt of an HRF. It is indicated as a best practice but leaves it to subsequent implementation guides to address this. These documents only indicate what Device attributes are to be used for what UDI elements, all along keeping in mind this is about communication, not internal storage.
As we understand it, the motion is to mark the Device.udiCarrier.deviceIdentifier, Device.manufactureDate, Device.expirationDate, Device.lotNumber, Device.serialNumber, and a yet to be defined extensions for the Distinct Identification Code (all elements of the UDI) as MUST SUPPORT in FHIR R4 US Core.
Considering how MUST SUPPORT is interpreted by ONC certification testing, that means that at time of certification one must demonstrate that one can populate those fields. Thus this effectively imposes an indirect requirement that either one must always store the individual elements as parsed from the HRF (the agreed to singular component that needs to always be conveyed and preserved), or that at time of creating the Device resource instance the HRF must be re-parsed and the separate elements are included separately as well.
This approach would impose an unexpected, last minute substantial change for EHRs during the ONC rule making process that heretofore did not persist such information, rather just the HRF. Furthermore, this is not synchronized with C-CDA nor v2 where similar guidance would need to apply. We note that even though in the HL7 CCD C-CDA Supplemental Template the Implantable Device Observation includes all elements as SHALL (while allowing for unknown to still be used as an absent reason), there is still no indication that the individual data must be included, i.e., “The UDI carrier should be parsed and the Device Identifier (DI), and each of the available Production Identifiers (PIs) should be populated in the Implantable Device Observation template.” where “should” is used, not “shall”.
Considering how ONC will test this in certification (and has done so to date) is important as the overwhelming suggestion, including from HL7, is for ONC to adopt FHIR R4, rather than a prior version where associated Argonaut and US Core implementation guides do not include MUST SUPPORT for these elements. The problem is that while FHIR R4 is out and available for review, US Core is not. FHIR US Core R4 is not expected to be published sufficiently in time before end of the review period, if at all, to allow for adequate review and response. As well as that a cohesive approach across C-CDA and FHIR at a minimum are essential, while clearly changing the expectation from persisting and communicating the HRF at a minimum to also persisting and communicating the individual UDI elements.
We therefore urge the submitters to withdraw the motion and rather than putting this into US Core, that a separate cross-paradigm implementation guide be created that addresses the requirement to persist the elements transparently and clearly, and indicates in HL7 v2, HL7 CCD C-CDA, and HL7 FHIR then become MUST SUPPORT (thus RE in v2) under that implementation guide. This would be using a properly constraint based on US Core for HL7 FHIR. Subsequent rule making can then include that guidance with adequate initial implementation experience, review time, perhaps consider the proposed SVAP process to enable early support and maturation, while keeping the scope of US Core in this round as close as possible to the FHIR DSTU 2 Argonaut and FHIR STU 3 US Core scope and not introduce new requirements on what aspects of the UDI to persist this late in the process.
Last updated: Apr 12 2022 at 19:14 UTC
