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).

About DGC

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:

1. Collaboration: Development of common understanding of and specifications for data standards, exchange mechanisms, and what it means to participate in the modern health IT ecosystem
2. Education: helping members understand their regulatory obligations, the data and exchange standards they're expected to use, and modern technology and related processes
3. Innovation: Identification and development of projects and services needed to make modern health data practices and exchange a reality

General Comments

This section comments on the general approach taken by ASTP provide comments on areas that cross multiple sections of or items in the plan.

Standardized Information and Format

The About FHIR Components section indicates each entry includes the following information:

1. Standard/Implementation Specification – lists the name of the specification – an Implementation Guide in most cases –and the hyperlink to the specification.
2. Standard Process Maturity – lists the specification’s maturity in terms of its stage within a particular organization’s approval or voting process. Balloted indicates the standard or implementation specification is in an official Draft or Trial Use state, per its organization. In development indicates the standard or implementation specification is currently in development or is in the midst of being balloted. These standards would generally benefit from lessons learned through development and pilots.
3. Implementation Maturity – defines the specification’s implementation state. Production indicates the standard or implementation specification is being used in production to meet a health care interoperability need. Pilot indicates the standard or implementation specification is being used on a limited scale or only as part of pilots to meet a health care interoperability need.

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:

• Baseline FHIR standard that provides foundational “FHIR Resources” that are stable and mature …
• While a newer version of the base standard, FHIR Release 5 FHIR R5) …
• …

Recommendation: Considered essential for all

If the maturity status is unknown, that could be the label used.

Versions

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.

CQL

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.

CDex IG

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.

QM and DEQM IGs

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

Response to Specific Items in the Document

This section will address specific items in the draft.

FHIR r4

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.

Bulk FHIR

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.

CDS Hooks

We note that CDS Hooks can be used in many environments, not just EHRs.

FHIR Subscriptions R5 Backport IG

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.

Network Components

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.

CARIN Blue Button IG

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.

DTR IG

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.

PDex Formulary IG

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.

QI-Core IG

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.

Care Delivery and Engagement Components

This section seemed a bit miscategorized to us. It includes two types of content:

• Public health reporting IGs
• IGs supporting international formats/standards

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.

IPA/IPS IGs

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.

Central Cancer Registry Reporting Content IG

Participants in our Data Governance Collaborative thought it strange that cancer registry reporting was supported but not registry reporting more generally.