Page History

Meeting Summary for ONC Standards Group and USRPM Weekly Touchbase

Nov 05, 2024 12:02 PM Pacific Time (US and Canada) ID: 899 9986 3466

Top of Form

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.

...

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.

Proposal Presentation

The team discussed the proposal to present the proposal to optionsto Carmela by email, as she was not present on the call. They 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 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.

...

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.