This document was submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) on November 25, 2024 in response to the Draft Federal FHIR Action Plan posted on the ASTP website in September, 2024 and found here:
https://www.healthit.gov/isp/about-fhir-action-plan
About MHDC
Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts’s health information community in advancing multi-stakeholder health data collaborations. MHDC’s members include payers, providers, industry associations, state and federal agencies, technology and services companies, and consumers. The Consortium is the oldest organization of its kind in the country.
MHDC provides a variety of services to its members including educational and networking opportunities, analytics services on both the administrative and clinical side (Spotlight), and data governance and standardization efforts for both clinical and administrative data (the Data Governance Collaborative/DGC and the New England Healthcare Exchange Network, respectively).
The DGC is a collaboration between payer and provider organizations convened to discuss, design, and implement data sharing and interoperability among payers, providers, patients/members, and other interested parties who need health data. It is a one stop interoperability resource. The DGC primarily focuses on three areas:
This section comments on the general approach taken by ASTP provide comments on areas that cross multiple sections of or items in the plan.
The About FHIR Components section indicates each entry includes the following information:
We agree this information is useful and would like to see it included with each entry in the plan in a standardized way. However, many of the entries do not include maturity information, and those that do include it within the main content so you have to read the entire entry to find the information.
It would be extremely useful to include a standard header section for each included API, data set, implementation guide, or other item. We recommend a heading section something like:
Name: FHIR Release r4.0.1 (FHIR r4)
Process Maturity: balloted
Implementation Maturity: production
To be included prior to the first bullet of descriptive information or structuring the entire content as:
Name: FHIR Release r4.0.1 (FHIR r4)
Process Maturity: balloted
Implementation Maturity: production
Notes:
Recommendation: Considered essential for all
If the maturity status is unknown, that could be the label used.
The entries in the plan specify a particular approved or recommended version in some cases and in some cases they do not. We realize that versions change, but the recommendations are significantly less useful without version recommendations and, given that many of the specifications, data sets, implementation guides, etc. included in the plan do have specific versions adopted as standards and/or accepted via SVAP, it makes sense to align to those versions. We urge ASTP to include specific versions of each item in the plan. If multiple versions of an item are allowed/recommended they could be incorporated into a single entry, but if notes and recommendations are significantly different it may make more sense to have separate entries for each version.
If multiple versions are included in an entry, separate maturity level information may be needed for each.
Some participants in our Data Governance Collaborative felt that version information is sufficiently important to always be included in the name of the entry.
Participants in our Data Governance Collaborative were surprised to see both prior authorization and quality measures needs addressed in the plan without the inclusion of CQL. We believe it should either be considered a foundational component found under the Core Components section or be part of the other prior authorization and quality measures entries found under the Payments and Health Quality Components section.
Participants in our Data Governance Collaborative were surprised that CDex was not included in this plan, particularly as prior authorization is addressed and CDex is the recommended IG for attachments related to prior authorization. CDex is also used for many other useful purposes, including for quality measures data exchange in some cases.
Participants in our Data Governance Collaborative were surprised that the Quality Measure (QM) IG for defining digital quality measures and especially the Data Exchange for Quality Measures (DEQM) IG for exchanging quality measures data as well as interim measure reporting and gaps in care reports were not included in this plan. These implementation guides are built on top of the QI-Core IG and are meant to operationalize that IG into useful measure-by-measure data exchange as noted in this image included in both IGs:
Source: https://build.fhir.org/ig/HL7/davinci-deqm/quality-measurement-standards-landscape.png
This section will address specific items in the draft.
Participants in our Data Governance Collaborative agree that it makes sense to bypass FHIR r5 and look to r6 as a potential upgrade path. Future backwards compatibility requirements are worth the potential disruption of a major upgrade in a way that many other features or items may not be.
Participants in our Data Governance Collaborative wonder if the recommendation for bulk FHIR should be the version currently in SVAP and include recommendations to use _since and _type for performance reasons.
We note that CDS Hooks can be used in many environments, not just EHRs.
We note that much of this entry appears to be written about the FHIR subscription support natively in FHIR r4 and not about the FHIR r5 backport.
Participants in our Data Governance Collaborative felt that this section was misnamed and network components did not quite fit the intent here. We struggled with suggestions for other names as it’s not entirely clear what else should eventually be included in this section in future versions, but for now suggest perhaps Identity Components or Technical Infrastructure Components might work.
We note that this entry is written as if the CARIN Blue Button IG is expected to be used solely for patient access to data, but this IG is likely to be used in Provider Access and Payer-to-Payer APIs as well as the Patient Access API.
We note the last paragraph of the DTR entry with recommendations has some typos and tense changes that make parsing it somewhat difficult. We suggest the following instead:
DTR IG should be considered by payers and providers to streamline the prior authorization process and reduce administrative burden associated with submitting required documentation.
We believe the descriptive text in this entry could be cleaner. The first bullet point, in particular, is a bit convoluted; the last sentence, in particular, is difficult to parse. We suggest using something like the following instead:
Implementation specification for payers to provide drug formulary information to patients via a FHIR API. The specification includes both public facing general plan formulary data and access-controlled formulary data integrated with protected health information (PHI) or personally identifiable information (PII) to provide personalized information to specific patients based on their medications.
We applaud the inclusion of the QI-Core IG defining baseline quality measures data in this plan and note that this is its first inclusion in any formal ASTP recommendations.
This section seemed a bit miscategorized to us. It includes two types of content:
As there is already a Public Health & Emergency Response Components section of the plan, we urge ASTP to move the vaccination and at home test reporting IGs to that section and rename this section to International Components.
As these IGs are meant to support international standards, it may make sense to point out some of the differences between US standards and international standards, particularly around the collection and support for race and ethnicity data. We are not familiar with these IGs, but know that most international formats are not US Core compliant – if that is, in fact, the case for these IGs that may be worth calling out as well as most US users will assume US Core compliance as a default.
Participants in our Data Governance Collaborative thought it strange that cancer registry reporting was supported but not registry reporting more generally.
