Meeting Summary for ONC Standards Group and USRPM Weekly Touchbase
Quick recap
The team discussed the representation of the sex parameter for clinical use' Gender Harmony FHIR-based extension, considering the possibility of extending an existing extension since USCDI requires LOINC use as a terminology. They also discussed the implementation of a new device profile for Udi, the history and implications of the UDI, and the issue of downloading the C-CDA value set update. Lastly, they discussed the ideal timing for a project, the possibility of a Github release or an HL7-based release, and planned to further explore these topics in future meetings.
QA Review of current C-CDA and US Core ballot design was deferred
Next steps
Sara to schedule a meeting with Carmela and the team to discuss the sex parameter for clinical use extension issue before Thursday's call.
Brett and Gay to prepare a proposal for addressing the UDI (Unique Device Identifier) profile update, considering both implantable and non-implantable devices.
Gay, Reuben, Graham, and Dan to develop an alternative solution for value set distribution, potentially using GitHub or an HL7-based release method.
Summary
Sex Parameter Representation Discussion
The team discussed an issue related to the representation of the sex parameter for clinical use' extension based on the existing Gender Harmony design and the importance of re-using existing work the issue being that USCDI requires LOINC as the terminology, but the existing extension carries the same meaning as 99501-9 Sex parameter for clinical use inherent in the elements of the extension itself. Note that C-CDA uses the LOINC code as an observation, because the CDA standard is not amenable to the widespread use of extensions
Options:
- Reuse the Gender Harmony developed pre-existing design and in USCDI V6 add the FHIR vocabulary answer set to USCDI terminology as an “OR”
- Reuse the Gender Harmony developed pre-existing design and provide guidance that existing extension carries the same meaning as 99501-9 Sex parameter for clinical use inherent in the elements of the extension itself.
- Create a local extension in US Core, based on the GH extension that adds the 99501-9 LOINC code. Note that the existing extension is already considered a “Complex” extension and this new extension would conflict if vendors have already implemented the balloted and approved GH extension
The team agreed to further discuss this issue in a future meeting.
The team discussed present the optionsto Carmela by email, as she was not present on the call. Instead, hey agreed to schedule a meeting including Carmela for the following day or early Thursday. Brett expressed a need for a clear answer to the question of why they didn't follow the approach of what ONC funded.
UDI Device Profile Implementation Discussion
Sara, Brett, Alex, and Gay discussed the implementation of a new device profile for Udi, focusing on the distinction between implantable and non-implantable devices. Brett emphasized the need for clarity on the expectation of device communication and the potential for new workflow burdens. Alex clarified that they are not seeking to introduce new workflows but rather make existing data available. The team agreed that systems must have the capability to send Udi data, but they do not dictate when it is appropriate to do so. The discussion concluded with the understanding that factors beyond their control would determine when it is appropriate to send a Udi.
UDI Implications and Profile Adjustments
Brett, Gay, Sara, and Alex discussed the history and implications of the UDI (Unique Device Identifier) in their product. Brett recalled his efforts in 2014-2015 to make the profile non-device specific, but they were eventually pressured to make it implantable device specific. The team considered whether to adjust the current profile or create a new one, with Brett emphasizing the importance of clear communication to implementers. They also discussed the potential challenges of capturing and identifying devices.
Discussing C-CDA Value Set Download Methods
Sara and Gay discussed the issue of downloading the C-CDA value set update in Excel format via the VSAC, comparing it with other potential methods. Sara shared that approximately 500 downloads occur annually; however, Gay questioned the accuracy of this figure, suggesting the actual number could be lower, as some downloads may come from individuals casually exploring C-CDA rather than actual implementers. Sara mentioned that VSAC cannot provide further detail on the downloads, likely due to technical or privacy limitations, but she will follow up on this again.
Gay reiterated the team’s shared understanding that the existing value set update project is no longer necessary in its current form. With the annual ballot process now in place, updates are regularly integrated, making the traditional project redundant. However, stakeholders have expressed interest in continued access to annual packages. Gay proposed an alternative approach where value sets could be accessed via a different pathway, using the FHIR IG Publisher’s VSAC package retrieval process. This approach could include a link to the package stored on GitHub, with references available on various platforms, such as the HL7 website, HL7 Confluence, and within the implementation guides themselves.
This proposed method offers several advantages: it would provide a comprehensive package containing all value sets used in the guides—not just a subset from VSAC—and it would be available in a computable format rather than a spreadsheet. This shift could reduce vendor burden and potentially save ONC and HL7 significant costs annually. The team agreed to explore alternative methods for making the value sets available.
VSAC Method of Delivery Timing and SVAP Publication
Sara, Gay, Brett, and Alex discuss the ideal timing for the VSAC package if that were still to be the method of delivering the subset of IG VSAC value sets. Gay suggests April, which aligns with IG May publishing required by ONC. Brett proposes the end of April or when the SVAP is published, as this is when some vendors begin work. Alex clarifies that the SVAP is typically published in June, but not available for updates until two months later in August or September. The group acknowledges that the SVAP publication date could be a logical alternative if the ideal April timeline cannot be met. However, Gay notes the larger topic is that the project may no longer be needed.
Exploring Github and C-CDA Release
In the meeting, Gay and Sara discussed the possibility of a Github release or an HL7 based release. They agreed to further explore this topic, with Gay mentioning that they needed more time to clarify the approach with Grahame, Dan, and Reuben. Gay will let Sara know when this meeting has been scheduled and then report to this team the results of the meeting.