This document is submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) in response to the ONC Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1, HHS-ONC-2023-0007-0001) Proposed Rule posted in the Federal Register on April 18, 2022 and found here:

https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and

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 - Logistics

This section comments on some logistical issues that could be addressed to make this – and future – regulations easier to parse, read, understand, and implement.

Links to References

This rule is rife with references to discussions, data, and requirements outlined in other portions of the rule. Each major component of the rule is discussed in several different locations, each delving deeper into the details than the section before. There are references to data standards in the form of § N.N(a)(N)(a) and references to previous regulations and external standards (some, but not all of which, do have links).

The references of the form § N.N(a)(N)(a) are particularly problematic as the content they reference is typically defined elsewhere in the rule and cannot be located by searching for the relevant string (see next suggestion). Rather, each letter and number in the reference is its own heading in the document in a hierarchical structure working down to the specific item or items being referenced. It is difficult, time consuming, and burdensome to locate the referenced data when it’s relevant to a discussion in another part of the regulation.

It can also be difficult to determine exactly which set of codes are being referenced when an external codeset is referenced – indicating that SNOMED or LOINC codes are supported for a particular piece of data without specifying exactly which range of codes are allowed can lead to ambiguity in some cases. Linking to a page or set of pages outlining the exact range of codes supported would remove this ambiguity and also save readers the time and effort of finding the gold standard for that code system and searching for codes that may be the ones being referenced as supported in the rule.

Labels/Text Anchors for Key Content

It would be extremely helpful to include a label in the form § N.N(a)(N)(a) at the exact location in a rule where the contents of that reference are defined. This would allow readers to search for the relevant string and find not just other references specifying support for the same data but the data itself.

Discussing Topics Separately Even if Related

It is very helpful to have individual topics, even if related to other topics, discussed separately. This permits readers to better group the rules for X topic together, understand how they apply to that specific topic, and allows regulatory text to be written specifically with that topic in mind. One example of a place where two closely related topics were combined in this rule and made it more difficult to parse, read, understand, and potentially apply the rules is with DSI. After some time working through the DSI content, it became apparent to us that two separate and distinct major categories of use cases were being combined and discussed together: developing DSI and using DSI. This often made the language more general than ideal as it had to apply to a wide span of scenarios and made it much more difficult to figure out exactly what would be required for each distinct activity.

Comment Period

We respectfully note that 60 days to read, absorb, discuss, and comment on a rule this complex, dense, wide-ranging, and long is not sufficient, particularly with some of the cross-reference difficulties outlined in our other process comments. We understand the need to get regulations on the books to prevent implementation delays, but we believe an extra 30 days up front would have been extremely helpful and not posed a significant delay to timely finalization of regulation while permitting sufficient implementation time. Further, having comments and issues identified ahead of rule finalization when they can be addressed much more easily seems worth a short delay. We respectfully request that any future rules involving multiple different types of programs should have 90 day comment periods. We note that this is a standard comment period for recent CMS proposed rules related to interoperability (some of which were extended further) and setting the same standard across HHS should not constitute unacceptable delay.

General Comments - Content

This section comments on the general approach taken by ONC in their posted proposal or comments on items that cross multiple sections of the proposed rule.

Coordination of Rules

It is essential to look at the health IT ecosystem as a system with components in different environments with different primary users. Regulations covering these components are not generated from the same agencies, but they must work smoothly together to ensure success generally. We encourage ONC to work closely with CMS and other rulemaking agencies to ensure that all health IT-related regulations are compatible with each other both in terms of content and timing.

One area we see potential rule coordination issues existing is around the patient consent/do not share data flag support outlined in this proposed rule. We realize that no one is obligated to honor these requests, but if the decision is made to honor the request except in limited circumstances needed to facilitate payment and operations (such as to ensure a claim gets paid), there is no mechanism for indicating the patient requested the data not be shared further, nor is there a carve out for not sharing such data further in CMS API rules applying to certain payers. Once data contained within the supported USCDI version is in the possession of these payers, existing regulations require they share it further to third party apps requesting patient data (with a global opt-in, so the patient may see the data was shared despite their request not to do so), other provider organizations (currently only with a global opt out option), and potentially other payers (currently only with a global opt-in option). Supporting “do not share” flags in certified health IT is only one part of the equation needed to give patients some means for control over their own data and how it is shared. Patient education may help them understand this and why data is unexpectedly showing up where they don’t expect it to show up, but education is not a real substitute for a consistent, coordinated approach.

We also note that there is a lot of ongoing legislative and regulatory activity around AI from all sorts of agencies and places that may not normally interface directly with ONC. We know of current or recent RFIs or NPRMs from agencies as diverse as the White House Office of Science and Technology Policy to the FTC to NIST and beyond. Coordination of rules that are specific to healthcare and those that are more generally applicable will be a challenge, one we urge ONC to keep front of mind in its work in this area.

Expiration Date of Current Standards

Several existing definitions within these standards including those for sex, gender, and SOGI appear to expire on December 31, 2025 with new definitions taking effect on January 1, 2026. Given that most other standards-related provisions of this rule go into effect on January 1, 2025, we strongly recommend applying the same date to this change to avoid confusion.

Demographic Data Specification

ONC has repeatedly indicated that USCDI is supposed to define a minimum set of data requirements for general healthcare use and exchange. It includes a section of demographic data, so logic dictates that the demographic data included there should represent the expected level of general demographic data support.

Given this, it is a mystery why a separate demographics certification section exists at all at this point. Perhaps there was a historical need for a separately outlined demographic data specification before USCDI existed and incorporated such data, but setting separate requirements outside of USCDI for a type of data included in that standard is both confusing and a maintenance nightmare (in terms of ensuring continued alignment of versions and content for those data elements that overlap).

Further, ONC made a specific choice not to include sex for clinical use, recorded sex or gender, pronouns, and preferred name data in USCDI v3. A discussion of the rationale why is included in ONC Standards Bulletin Issue 2022-2. Further, none of these data elements were proposed as part of USCDI v4 draft, meaning ONC still felt they should not be required for general support at the time that version was developed. Perhaps they are slated for inclusion in the USCDI v4 final version yet to be released – we know that ONC often makes significant adjustments to USCDI between a draft version and the associated final version released later the same year – but that does not change their absence in USCDI v3, the version mandated by this rule.

Respectfully, saying that the industry should not be required to support these data elements when it's time to support USCDI v3 then separately requiring their support in the same regulation initially mandating support for USCDI v3 is sending a mixed message about the intent and importance of USCDI to the industry, its data standards, and interoperability expectations. The more consistent approach would be one of the following:

1. Adding these data elements to the USCDI v4 final version or USCDI v5 (or some other future version) and then waiting to mandate their support until those versions are ready to be included in regulation
2. Adding these data elements (and others) to a USCDI+ for Equity data set and allowing their mandate for equity-related use cases in various federal regulation including an optional future certification against USCDI+ for Equity

We urge ONC to consider one of these paths instead.

Discontinuation of Named Editions

We appreciate ONC is looking to simplify the certification process and encourage health IT developers to maintain the most current certification criteria, but having specific versions attached to support is important for understanding exactly what a particular product does or does not support. Having a named list of criteria tied to a certain version – be that version dated, numbered, or otherwise uniquely labelled – is important to ensure that customers understand what a particular piece of certified health IT offers them and ensuring that in their own conversations about the functionality they need is included in the software they decide to purchase or otherwise use.

We encourage ONC to set clear guidelines and rules about how to reference the specific functionality included with any certifications granted to health IT to limit any confusion or miscommunication between developers of certified health IT and those looking to use it.

USCDI Version and Its Impact Beyond Certification

We understand the need to progress the baseline USCDI version supported by health IT forward, particularly as new USCDI versions are released more quickly than new regulations. In general, we are supportive of the choice to require USCDI v3 at a well designated future date (such as incorporated in this rule). However, we note that this choice affects more than health IT certification; other HHS regulations rely on the USDCI version as specified by ONC. In particular, we urge ONC to consider that its adoption of new versions are automatically expanded into adoption by CMS regulations and elsewhere even when public comment on those regulations were based on the then-current standards in play.

We urge ONC to consider how updates to the baseline USCDI version as outlined in this rule will affect other regulations that may become effective after this upgrade, particularly CMS regulations where public comment has already occurred (such as CMS-0057-P). We are not suggesting that the version should not be advanced in this rule, but rather that some discussion of how the change impacts other regulations that rely on the ONC decision to change the standard version supported changes or affects the provisions of those regulations be part of the regulatory language mandating those updates. We realize this may mean working in concert with CMS (or others) and that ONC cannot speak for CMS, but the fact remains that the ONC USCDI version decisions outlined in this rule affect the impact of CMS rules that have already gone through the public comment process (and potentially other regulation). Some mechanism for addressing this and providing guidance and information related to the wider impact of the upgrade seems warranted.

Status of USCDI v2

The proposed rule as written discusses the deprecation of support for USCDI v1 in favor of USCDI v3 but does not explicitly address the status of USCDI v2. A logical assumption is that support for USCDI v2 will also be deprecated at the time USCDI v3 becomes the baseline supported version but its status should be explicitly addressed in the regulation.

Electronic Case Reporting Formats

We understand and agree that not everyone is ready to move to a FHIR-based case reporting system and agree that certification should support both FHIR and C-CDA formats. However, we believe that the choice of format should be up to the users of the data exchange and not forced on them by one end of the exchange having chosen a product that only supports one mechanism or the other. This seems particularly important given that ONC has indicated the industry has generally expressed interest in moving toward FHIR for this functionality but just isn’t ready to rely on it 100% of the time. We believe using certified health IT that chose to only support C-CDA for this feature should not be a gating factor for moving to FHIR-based reporting to public health agencies ready and willing to accept data via FHIR. Therefore, we recommend that certified health IT be required to support both FHIR and C-CDA case reporting to be certified, with the choice of format used dependent on the preferences and support of the various organizations using the data.

Electronic Case Reporting Endpoints

If the goal is to move toward and, to some extent, encourage FHIR support for electronic case reporting, some mechanism for supporting standardized endpoints and endpoint discovery should be outlined in the rule. As seen in the adoption of FHIR for other use cases, having easily recognized and discoverable endpoints is a key element of success in the implementation phase.

Standardized API: Confidential App Refresh Tokens

The proposed rule outlines that confidential app connections automatically get refresh tokens valid for a period of no less than three months with no noted expiration (indefinite refresh) or expectation that the app should ever have to be validated again.

The authentication tokens requested by SMART on FHIR apps include the scope of access available to the application. This scope is verified to be valid (the entity issued the token has the right to access the requested data) and/or negotiated at the time the original token is issued but may change over time for a variety of reasons (contractual changes requiring different data access, revocation of treatment relationship status, change from in-network to out-of-network provider, etc). We respectfully note that some connections between certified health IT and authorized apps may be time-limited or benefit from the ability to review and change the terms of connection either periodically or on a regular basis. In fact, automatically renewing these tokens as originally granted is a potential privacy and security risk if the tokens wind up out of sync with the current permissions allowed to the bearer.

We suggest changing the three month requirement for duration of refresh tokens to a recommendation when appropriate for the type of partner and application/use case in question. We further suggest outlining some cases where a shorter timeframe may be warranted. We also suggest making it clear that the entity may be required to request a new token with a new scope of access instead of using a refresh token at times and that’s not a violation of refresh token policies as outlined in the rule.

US Core Version

We note that US Core v6.0.0 was released in May 2023. This version was designed to represent USCDI v3 in FHIR. While both CMS and ONC are generally reluctant to require IGs soon after their release, ONC indicated willingness to require its use in a final rule if available at the time of that rule. We believe this version of US Core should be mandated in keeping with the requirement that USCDI v3 is the baseline data standard used by the rule.

Publication of Service Base URLs

We support the requirement for certified health IT developers to publish the base URLs of all customers regardless of whether they use centralized/hosted services or their own installation of relevant technology. We further support designation of a specific format for these URLs and associated specific endpoints they support.

We urge ONC to define and publish a specific URL format for use as part of the final version of this rule.

Revocation of Patient Access Tokens

We support the one hour revocation requirement and the subsequent notation that certified health IT developers may choose to only grant tokens that are valid for 60 minutes or less at a time in lieu of supporting revocation within this timeframe.

Sex Data Element (and Approach to USCDI)

We realize that this was decided as part of USCDI v3, but as the public was not able to comment on the change at the time (it was not part of USCDI v3 draft), we would like to register our disappointment in a change that makes this data element more generic and less specified than it was in prior versions of USCDI. In general, health data is not as well defined and specific as data used in APIs and other similar data exchanges in other industries. Data can often be interpreted in multiple different ways and without understanding what a particular piece of data meant at its source it is extremely difficult if not impossible to understand how to interpret it when received as part of a larger data exchange. Respectfully, in changing sex assigned at birth to sex with a specific note that sex assigned at birth was too limiting and this renamed element provides more flexibility, we feel ONC took a large step in the wrong direction. A more consistent and standard way to address the need to document and exchange multiple types of sex-related data is to define a series of specific data elements with clear definitions matching each of these types. This provides clarity in terms of the meaning of the data and how to interpret it to entities receiving it without any further explanation or context (as would almost certainly be the case in bulk data exchanges of either a patient or population data).

We realize it is too late to change USCDI v3. However, with the expectation that this version will move into general use once the enforcement date of this rule occurs, we urge ONC to provide further guidance on acceptable uses for this data element and what type of data can be expected there/how to interpret data received under the label of “sex” when no further context is provided.

We also urge ONC to keep the need for specific data definitions in mind in future updates to USCDI (including the upcoming USCDI v4 final release expected next month) and to consider providing a public feedback period for post-draft versions of USCDI before finalizing them when there are significant changes from the draft version of the same release (which has generally been the case in the past). Finally, we realize this may not be a proscribed way to provide the USCDI process feedback found in this paragraph. We apologize if this is the case and note we would be happy to engage on the matter in other ways as opportunity allows.

Race and Ethnicity Changes

We note that the OMB is in the process of a major overhaul of the way the federal government categorizes, collects, and reports race and ethnicity data. In its OMB-2023-0001 proposed rule (published this past January) OMB indicated it expected to finalize a new rule with significant changes to federal race and ethnicity data standards sometime this summer.

While we understand the adoption process will not be immediate and the proposal would likely also need to flow through the CDC before being applied to health data, the new rules may be in effect or imminent by the time the provisions of this rule take effect.

This poses a challenge to race and ethnicity data collection using USCDI v3 standards, based on the current pre-change rules. We do not know the proper solution regarding how to address the upcoming expected changes, but we feel it is important for ONC to address this issue in some way in the final rule even if it’s just an outline of the process that will lead to eventual adoption of the new scheme/rules in the future.

LOINC Codes for Pronouns

The LOINC codes referenced for pronouns are listed in the LOINC taxonomy as an example answer list (see https://loinc.org/90778-2). ONC’s intention in terms of whether this list is intended to be a proscriptive list that provides all allowed values for pronoun choices or if there is some other mechanism supported is unclear. At a minimum, ONC should specify the exact set of LOINC codes intended to be supported for pronouns and address the notation of “example answer list” found on the related LOINC entry for reported pronouns.

Further, we note that Dr. Elizabeth Petty of the University of Wisconsin and the AMA gave a presentation at a WEDI conference in November 2021 on health disparities in LGBTQ+ care that spent a lot of time on culturally competent care including listing the most commonly used pronoun sets at the time (but emphasizing they are a small subset of the options in use). We realize the data may still be in flux and data from 18 months ago may be out of date now, but the two lists only overlap superficially (the first few rows with he/she/they pronouns are identical, but after that the way pronouns are combined/used together differs between the two lists and there are sets of pronouns on each list not present on the other).

Dr Petty’s list included the following (we note that “ers” in the first row is likely a typo and meant to be “hers”):

Further, the LOINC codes in the example answer list do not support mixed pronoun choices such as she/they and he/they which are common enough that they are supported by various Fenway Health pronoun projects such as the buttons described here: https://fenwayhealth.org/fenway-health-launches-employee-pronoun-workgroup/ or the color code outlined here: https://fenwayhealth.org/wp-content/uploads/9.-Collecting-Sexual-Orientation-and-Gender-Identity-Data-Grasso-1.pdf

In addition to the pronouns outlined in any of the above lists/documents (and potentially other sets of common pronouns), the choice of using no pronouns seems to be growing in popularity and should be accounted for in the list of options given that this data point is a notation of patient preference.

Finally, we strongly recommend supporting an “other” or “ask me” option given the variability of the options and the continued evolution of available options and their popularity among the LGBTQIA+ community.

If pronouns are going to be required as part of demographic certification despite not being part of USCDI v3, having a clear list of the pronouns that should be supported as well as guidance on how to interpret options like “ask me” or “other” or “none” is essential, particularly given the lack of general consensus on which pronouns to support across the industry.

Definition of enabling a user to flag restricted data

In its discussion of enabling a user to request restrictions on the use/sharing of specific data elements, ONC provides the following definition:

`We propose that “enabl[ing] a user to flag” means enabling the user of the Health IT Module to indicate that a request for restriction was made by the patient and that the user intends to honor the request.`

We respectfully suggest that the concepts “request for restriction was made” and “request for restriction was granted” be separated in the requirements. We suggest that both concepts should be recorded and permanently associated with the relevant related data. Further, a rejection reason should be required if the request was not granted.

We further recommend that retention and exchange of the patient request alongside the related data be required if the request is rejected. This would enable the next recipient of the data to potentially decide if it wishes to honor the patient request (if doing so does not violate any laws or regulations).

Granularity of Patient Consents/Requests to Restrict Data

We believe the all or nothing approach outlined in this regulation is a start, but makes it more likely that requests to restrict data exchange will be rejected. We support development of more granular approaches to patient consent and, when possible, more affirmative consents (as opposed to consent by default with the ability to request revocation in limited circumstances). Patients should be able to allow data use/exchange with some parties but not others to support use cases such as the ability to get independent second opinions based only on relevant data and not the opinions/interpretations of previous clinicians. Patients should also be able to group data by type of data or encounter/procedure date to limit the use and exchange of data related to subpar care or to only allow data related to particular conditions to flow to those treating the patient for that condition or whatever other criteria the patient wishes to impose on data use and exchange.

As noted above in the coordination of rules discussion, we urge ONC to work in conjunction with CMS and other entities to develop a comprehensive approach to patient consent that provides clear and consistent rules regardless of the portion of the healthcare industry the patient is dealing with at any given time.

Methods for Requesting and Viewing Patient Requested Data Restrictions

The current proposal indicates that patients must be able to use an internet-bases method to request a restriction be applied to any of their data in USCDI v3 and to later view, download, or transmit such requests. This is later defined to include patient portals, APIs, and potentially other mechanisms. We strongly urge ONC to require support for both patient portals and API methods. There are many patients who for various reasons (including disability) cannot access patient portals – providing them with an API-based mechanism will allow these patients to make these requests via mechanisms they can access. Further, requiring support for APIs means that third party apps that wish to support patient requests in this area can do so, providing more access and visibility into their ability to make such requests.

Behavior of SMART on FHIR apps, Questionnaires, CDS Hooks, and Other Automated Requests for Restricted Data

We ask for clarification on the expectations when some type of automated processing via SMART on FHIR apps, CQL, CDS Hooks, questionnaires, or some other mechanism requests data that is marked restricted. Is the requestor notified that the data exists but is marked do not share or is the data supposed to be treated as if it doesn’t exist.

If the former, the requesting application/process can build in rules for how to handled the missing data. If the latter, its lack may lead to the need for manual interventions and additional requests for the data that was not automatically forthcoming. It may even result in repeated requests to the patient themselves which they may find perplexing and/or annoying having already marked the data restricted.

We recommend a standardized approach to indicating specific USCDI v3 data that might otherwise be expected as part of all manner of automated data processing is deliberately being withheld per patient consent rules, but even if the decision is to treat this case as if the data doesn’t exist in the source system, we strongly recommend making the expected response standard across all cases.

Emphasis on Transparency for AI

We commend ONC on its focus on emphasizing transparency around AI including both its development and its application to healthcare uses. We note that many developers of AI, particularly machine learning algorithms, see the specific details of how their models were developed as proprietary and are often reluctant to share more than a cursory overview of their process. Piercing this barrier to transparency is important and we see some of the DSI provisions of this proposed rule as an important step toward doing so.

FAVES in DSI

We approve of the acronym FAVES to represent fair, appropriate, valid, effective, and safe DSI and of the sentiments behind each of these elements as desirable and important. We do have some concern that there may be a move to stamp specific algorithms or other DSI components as FAVES independent of their context and use within a specific scenario or workflow. Several of the factors that go into FAVES are extremely context-dependent – for example, appropriate use of a specific algorithm may depend on how similar the population it’s applied to is to the training data used to develop it – and therefore these are conditional labels that cannot be universally applied.

We urge ONC to explicitly stress this in its discussion of FAVES and to note the goal is to have FAVES DSI as evaluated within the context of the specific use cases, not to generally develop DSI that can meet those conditions all of the time no matter how it’s used or the population it’s evaluating.

Educating Patients and Clinicians on How to Interpret Information on AI

We attended an ONC listening session led by Stephen Konya in Spring 2022 on AI use in healthcare and steps ONC could take in this area. One of the things we emphasized at the time was the need to better education both patients and providers on how AI works and the probabilistic nature of its results/determinations. Topics like discussing how to understand the role of threshold values and what a positive match or result does and does not mean were discussed as essential to understand.

As part of that session, we also suggested standing up some type of a national healthcare AI education center/help line for answering questions from clinicians (and perhaps patients) on how AI works and how it is commonly used in healthcare settings (not on the specifics of any particular model or implementation) for assisting those provider organizations too small to have their own data science or AI experts on staff. We would like to renew that suggestion as part of the overarching AI/DSI discussion generated by this rule.

We feel the need for such education will increase significantly if the DSI provisions of this rule are adopted and urge ONC to include some level of additional training/education components as part of certifying DSI and also consider some type of help line to improve the general understanding of how AI works and what it does/does not provide to a clinician looking to apply its results.

This is particularly important given the decision to provide the tools needed to evaluate whether DSI meets the criteria for FAVES as opposed to defining explicit criteria to be met. We understand why this decision was made and concur, but it places a great deal of trust in the knowledge and understanding of the inner workings of DSI on the clinicians and other individuals making the decision that it meets the necessary criteria for use. It is therefore essential that the relevant workforce is educated on how to understand the factors involved and the implications of their decisions to use a particular DSI.

Missing Source Data Information in DSI

ONC indicates the following:

“We expect that Health IT Modules certified to § 170.315(b)(11) would provide users with source attribute information from these other parties. In circumstances where the developer of certified health IT does not receive source attribute information, we propose in § 170.315(b)(11)(vi)(D) that Health IT Modules clearly indicate when source attributes related to DSIs developed by others are not available for the user to review. We believe it is important that users be made aware when source attribute information is missing or unknown.”

We understand and agree that the lack of information about a small subset of source data may be normal and expected when using third-party developed DSI, but we are concerned that this provision places no limits on how much or what type of data can be missing while still complying with source data transparency requirements. It seems like this clause is an open invitation to not provide any data that might show bias or lead to any type of negative conclusion by potential users.

We understand a lack of desire to outright prohibit use of DSI that provides no information about race and ethnicity, SOGI, disability, or other factors that commonly lead to biased results, but in order to assess appropriateness of an algorithm it is essential to understand the population a model was trained on. We feel that some type of limit on what can be missing and still be allowed as part of certification should be set – in common ONC parlance there should be a floor to what data must be present.

We would suggest that no more than 10% of the required source data elements can be completely missing unless certified as not used in the decision making process and that at least two of the following data elements be present for at least 50% of the patients used as source data: race, sex, gender identity, sexual orientation, disability status. We do not know if this is the correct formula but believe something similar should be adopted.

Risk Analysis, Risk Mitigation, and Governance

We ran out of time to review specific proposals in these areas so we will provide a general comment here. We approve of ONC’s approach of separately looking at risk analysis, risk mitigation, and governance as essential tasks in ensuring proper DSI development, management, and use.

Response to Specific Questions – Summary of Major Provisions

This section will list specific questions asked in the summary of major provisions section of the proposed rule and our responses to them.

We also seek comment on ways health IT can support EHI segmentation for access, exchange, and use of EHI; and particularly how the Program, through the certification of health IT to certain functionalities and/or standards, can support EHI segmentation for access, exchange, and use, including to assist health care providers with sharing EHI consistent with patient preferences and all laws applicable to the creation, use, and sharing of EHI.

We support giving patients granular control of their data both in terms of the type of data and data associated with specific events like a particular encounter, test, or procedure and the places it’s acceptable to share it with. This level of consent is currently possible with paper consent management forms and is needed electronically to encourage patients to use electronic means of managing consent. However, we realize that the industry is not currently in a place to support this level of digital/electronic consent management.

However, we believe all data associated with a particular event can, at this time, be flagged as such. Further, data associated with key diagnoses can also be flagged as such. We recommend mandating a list of common conditions requiring management of multiple providers (cancer, diabetes, asthma, arthritis, etc.) be supported, allowing the separate exchange of all data related to those conditions at the patient request.

We are also in favor of the patient defining when a treatment relationship exists with a provider and only allowing exchange with those providers who quality without explicit consent from the patient. At a minimum, patients should be able to specify the following and have the specified data – and only the specified data – shared as directed:

1. Send my medication list to provider X
2. Send my allergies list to provider X
3. Send all data associated with condition X (on the supported list of conditions) to provider Y
4. Send all data associated with encounter/procedure X to provider Y
5. Send any of the above to my preferred third party app

We also feel strongly that, despite its inclusion in USCDI v3 and thus being part of the baseline data exchange expectations, patients should be able to control who sees their SOGI, SDOH, and other sensitive data. While we understand both are essential to providing care and to ensuring health equity, every single participant in our Data Governance Collaborative felt that this type of data should only be exchanged with the express permission of the patient with rules similar to that of protected behavioral health or substance abuse data. In addition, we have heard providers specializing in LGBTQIA+ care indicate that a portion of their patients feel violated if they discover clinicians they did not disclose SOGI information to has it available to them (this is particularly true for transgendered patients).

We realize that to some extent this ship has already sailed (especially with the move to making USCDI v3 the new baseline data standard), but we still recommend working with specialty provider organizations like Transhealth in Northampton, MA and Fenway Health in Boston on appropriate ways to segment this particular type of data and rules around consents that should be required to exchange it.

Response to Specific Questions – Certification Program Updates - Standards

This section will list specific questions asked in the Standards section of the Certification Program Updates section of the proposed rule and our responses to them.

We have taken note of the substantial effort in this area to develop a clinically meaningful way for identifying a patient's sex from observable information ( e.g., Clinical Observation, Radiology report, Laboratory report, genetic testing data) that may be suitable for clinical care, including the development of a new data element Sex for Clinical Use, which we may consider including in future standards adoption. We welcome public comment on this concept and approach.

In general, as noted above in our discussion of the Sex data element in USCDI v3, we believe that data should be assigned to properties that convey context and meaning about the included data. We would prefer data elements like physical sexual characteristics, sex chromosome data, etc.

That said, we believe that Sex for Clinical Use might be helpful as a way to collate together some of these options, but only if it comes with notation of how it was determined. Further, it needs to be a repeatable property as someone may have multiple different specific instances of observations providing implied or observed sex information. Basically, it might be helpful if implemented as a repeatable set of observation type/observation pairs. This necessary context would serve a similar purpose to defining a series of specific ways that sex could be observed and remove the need to create a separate data element for each. Further, if extensible, it could allow some of the desired flexibility while still providing the clarity needed to understand how to interpret the data.

We would welcome such additions to future versions of USCDI and subsequent regulations that use those versions.

We request comment on the following options we could pursue for a final rule.

Option 1 (proposed in regulation text): Require health IT developers to record Sex as proposed in § 170.315(a)(5)(i)(C). This would enable Sex to be recorded in accordance with the SNOMED CT standard, specified in § 170.207(n)(2), as well as the standard specified in § 170.207(n)(1) for the time period up to and including December 31, 2025. It would mean, however, that health IT developers would not be required to differentiate between sex and/or gender information when recording the information.

Option 2: Replace Sex with Recorded Sex or Gender in § 170.315(a)(5)(i)(C). Adopt the data element Recorded Sex or Gender as specified in the HL7 Gender Harmony Project. This would require health IT developers to capture the source documents while recording sex and/or gender information. Recorded Sex or Gender would further provide an opportunity for health IT developers to differentiate between sex or gender information that exists in a document or record, from Sex for Clinical Use (SFCU), which is designed to be used for clinical decision-making.

In theory, we are predisposed to supporting option 2 with the caveat that both data elements should require both the value and notation of its source (see discussion of sex data above). However, by deliberately choosing not to include these values in USCDI v3 we feel like ONC has already made the decision to use the data elements that were included there as the only “required to support” sex data.

Respectfully, the place to define minimum demographic data requirements is the same as the place to define other minimum data requirements – within the USCDI framework. While USCDI is meant to be a floor and not a ceiling and we support exchanging standardized, well-defined additional data by agreement (including, perhaps, the additional SOGI and demographic data outlined by ONC above and beyond the USCDI v3 demographic data), we do not understand the role of USCDI as the required minimum data set for collection, use, and exchange If additional data elements are defined as required to support data outside of that framework.

ONC clearly felt these specific data elements were not ready for inclusion in USCDI v3 and explicitly stated so in the standards bulletin released at the same time as USCDI v3. Respectfully, we do not believe it serves anyone to artificially impose their use anyway outside of the normal data standards setting process as it weakens that process and the standards that emerge from it.

Response to Specific Questions – Certification Program Updates – Patient Restriction Requests

This section will list specific questions asked in the Patient Restriction Requests section of the Certification Program Updates section of the proposed rule and our responses to them.

We seek comment on whether, and by how much, the use of this criterion as part of broader privacy workflows might represent a reduction in manual effort for covered entities, a positive impact on uptake by patients, or other benefits

We believe any mechanism to both make patients aware of their rights to request restrictions on use/exchange of data and their ability to implement that right is important. In the current landscape, it is nearly impossible for patients to exercise this right in any real sense. Provider organizations often do not have a clear mechanism for making such requests or know how to process/adjudicate/implement them if they do receive requests in this area. Some of our MHDC staff, well versed in the technical letter of the law when it comes to HIPAA, still find it nearly impossible to request restrictions and, when they do, discover that most of their provider organizations have no idea how to process them.

We therefore also recommend a degree of provider/customer education also be included as part of the certification criteria. Specifically, in addition to implementation, we urge ONC to consider requiring specific documentation and other educational materials be required to help customers understand this feature, how it works, its implications, and the rights of patients under HIPAA it helps facilitate.

We welcome public comment on these three alternate proposals, including which approach would be most effective or feasible in terms of implementation of the standards options described for the proposed criterion in § 170.315(d)(14).

We do not have strong feelings about exactly how patient-requested (and other) restrictions should be implemented but support mechanisms that would allow for increased granularity as time goes on, notation of rejected requests for restrictions with reason for rejection, and (if possible) standardization of the allowed options in a scalable manner.

We also favor an approach that can be scaled to more general patient consent management as industry standards evolve in this area.

Response to Specific Questions – Requirements for Certified Health IT Certification Updates

This section will list specific questions asked in the Requirements for Certified Health IT Certification Updates section of the proposed rule and our responses to them.

We welcome comments on this proposal.

1. Provide vs make available

We appreciate ONC’s attempt to clarify the use of provide vs make available to customers. However, we feel the definition of provide is still somewhat vague and needs further clarification. ONC implies that provide is more than make available but less than having all customers using the functionality and explicitly notes “there must be demonstrable progress toward implementation in real world settings” without clarifying what that entails or how to ensure that the preferred features are widely used and not just widely available.

We also realize it is not ONC’s place to regulate the commercial interactions of certified health IT developers and their customers, but one issue that continues to crop up is the difference between having additional functionality that can be purchased vs functionality that’s considered a core part of the certified health IT module/product/implementation.

We, too, do not wish to interfere with the commercial viability of any certified health IT developer or their right to charge reasonable fees for their products and services. At the same time, we have seen the level of additional charges required to support FHIR APIs impede their use by certain provider organizations using certified health IT supporting such APIs.

We do not know what the correct answer is here beyond working with CMS and other agencies to impose regulatory requirements or regulatory enticements (such as increased payments under plans overseen by CMS) to mandate active implementation and use rather than just availability of functionality with no requirement it be used.

We also recommend ONC clearly state expectations in terms of adoption, collect metrics on an ongoing basis (via Insights outlined elsewhere in this rule and other means), and make them publicly available. We also recommend ONC explicitly make it clear that health IT certified against particular criteria does not mean every user of that certified health IT is using the functionality outlined in that criteria.

2. Clarity around what is included in a certification

We understand the rationale provided for eliminating the dated certification editions, but it is important to have clear mechanisms for understanding exactly what certification criteria was used for each bit of certified health IT functionality within a product. Customers need to be able to compare and constrast what is and is not supported by different options when choosing which certified health IT to purchase and use.

Without some type of clear certification versioning, maintaining and disseminating this information with real clarity in an easily digestible manner is at best difficult and perhaps impossible. If a module certifies on June 27th and the criteria for that certification changes on July 1, the module may not comply with the listed public certification rules for that criteria but can still reasonably say they were certified in that area because they were – using older certification criteria.

At the same time, it is not reasonable or supportable to invalidate existing certifications each time the criteria changes. It remains unclear to us exactly how this process will work under the new system and what obligations certified health IT developers have to ensure that potential customers understand exactly what they will and will not get if they choose to purchase a particular piece of certified health IT.

We ask ONC to consider outlining some clear rules and expectations around the communication of certification levels and how to make it clear exactly what functionality is and is not supported by health IT certified to a standard that may have changed after certification was granted. We also ask ONC to consider how potential customers of certified health IT can verify/validate the expected support for a module validated against criteria that have since changed.

Since it’s so closely related, we will also add a comment on the requirements outlined in the assurance condition and maintenance of certification discussion immediately below this section of the rule here. We ask for further clarification -perhaps with an example or two – of the update timelines and potential simultaneous version support as outlined in the assurance condition and maintenance of certification requirements section in terms of the expectations during the 24-36 month and 12 month timeframes outlined therein and what that means for existing and new customers of existing certified health IT as well as newly certified health IT criteria where all customers are considered new customers.

Response to Specific Questions – Insights Condition - General Requirements

This section will list specific questions asked in the Insights Condition and Maintenance of Certification General Requirements section of the proposed rule and our responses to them.

We welcome comments from the public on the proposed measures and overall Program processes related to the Insights Conditions and Maintenance of Certification.

We will provide feedback on specific measures under sections for those individual measures, but a few general comments:

1. Aggregated data for all versions of a product

We respectfully suggest that it would be useful to understand functionality, support, and usage by both product version and by whether the certified health IT is hosted by the developer or installed locally/under the direct control of the user. For one thing, different versions of a product may support different functionality and grouping all versions together may artificially deflate data around the adoption of certain functionality by those customers that can access it. Further, understanding the breakdown of hosted vs installed products might provide insight into usage patterns and adoption of cloud services and other technology that may feed privacy, security, and other regulations within HHS and perhaps related certification criteria from ONC.

2. Documentation around measures and how the related data is produced

We are in favor of requiring certified health IT developers to explicitly outline how they collect, aggregate, and analyze the data supporting Insights measures. We further encourage specific discussion of the differences in data collection ability and processes for hosted vs locally installed instances of a product.

We particularly encourage the discussion of assumptions made about the data and decisions made about the inclusion or exclusion of specific data and/or installations.

3. Direct submission of numerators and denominators instead of calculations

While ONC webinars presented the requirement to submit the raw data outlined in each measure rather than any calculations based on it, it would be helpful to note this in the general requirements/overview section of the Insights discussion

4. Sharing data across numerators, denominators, and measures

We encourage as much reuse as possible. However, if the same data is being reported multiple times there should be some type of check that the data is consistent across each submission and, if not, inquiries/rejections/requirements to resubmit should be considered (dependent on the severity of the disagreement).

Any time data is being replicated or resubmitted there is an increased maintenance burden. This should be balanced against the benefit of collecting the data once.

If viable, a submission process that allows the data to be sent once and tagged with all of the measures requirements it meets might be considered to reduce the likelihood of error/inconsistencies.

5. Reporting requirement thresholds

We are, with one exception noted below, generally accepting of the size thresholds proposed for reporting. We would prefer to have data from everyone but understand the added burden may be quite disproportionate for a very small specialty developer shop.

6. Semi-annual reporting requirements

We agree that reporting every six months seems like a reasonable approach. Providing six months to collate the data from a given six month period seems generous to us, but as it makes it easier to align dates when everything is six months apart we are okay with providing the full six months for collation.

We also approve of the April-October reporting periods as a frequent complaint is how much annual reporting is due in January every year.

7. Attesting to non-qualification of reporting

Attesting to not meeting reporting requirements because of the user base size makes sense, but we question the need to attest to non-certification requirements for measures that do not apply to the certified health IT of a particular certified health IT developer. ONC and the entities overseeing real world testing as well as Insights data collection should know which modules a particular certified health IT developer certified to which criteria. It seems a bit redundant and pedantic to require every certified health IT developer to attest that they have no modules certified to relevant criteria when ONC has the data to prove or disprove that.

8. Public availability of reporting

We strongly support the public availability of all reporting data.

Response to Specific Questions – Insights Condition – Individual Access to EHI Measures

This section will list specific questions asked in the Insights Condition and Maintenance of Certification Individual Access Measures section of the proposed rule and our responses to them.

We believe this proposed individuals' access measure will provide a national view into how individuals access their EHI and will inform ONC and health IT community efforts to empower individuals with access to their EHI. We welcome comments on our proposed measure.

We approve of this measure, but respectfully suggest that while tracking the number of individuals who use a portal, HIPAA covered app, or third party app once is useful, being able to compare those numbers against those who use them more than once in the same reporting period is useful.

We also wonder if there is a way to capture the number of people who tried to use these methods and failed. For example, many patient portals are extremely difficult and, in some cases, impossible for patients with certain disabilities to use. Other patients may have limited high speed internet access or limited technology literacy and tried but failed to viably use a patient portal. It may be useful to measure the number of patients who create an account they do not use or who try to interact with their portal and fail to log in. We note there may be other modes of failure but those likely could not be measured without direct patient input.

Furthermore, at the current time the most common mechanism for authenticating users of third party health apps is via their patient portal account at a provider organization. There may very well be a segment of portal users who only use their portal in order to have the ability to use their app of choice.

Patients falling into these use cases may still be counted as one-time users of their portal even if they never successfully used it or were only using it as a means to access an application requiring it for authentication purposes. In some cases, if each app authentication counts as a portal login, they may be repeated portal users without ever actually using their portal.

Given all of this, we wonder if an additional metric signifying some type of meaningful portal use would be worth collecting (downloads actual data, sends a message via the portal, etc). It could be useful to know what percentage of portal logins are likely happening solely to support app access.

Response to Specific Questions – Insights Condition – Clinical Care Information Exchange Measures

This section will list specific questions asked in the Insights Condition and Maintenance of Certification Clinical Care Information Exchange Measures section of the proposed rule and our responses to them.

We seek comment on whether it would be meaningful to further reduce the mechanisms of exchange measure into fewer categories, by combining regional HIE and/or national HIN and developer-specific HINs into one category (network-mediated exchange) and combining Direct Messaging and “other methods” into a second category (exchange directly between two entities).

The discussion of this measure notes a desire to examine different methods of information exchange and how they compare to each other over time, yet this measure is solely tied to exchange of C-CDA documents and does not consider more modern clinical data exchange mechanisms such as FHIR. If the goal is to compare the use of different exchange mechanisms over time, this measure should also look at the exchange of clinical data via FHIR including directly from provider => provider, facilitated FHIR exchange through an intermediary, and the CMS mandated exchange flow of provider => payer => provider.

We request comment on whether focusing on the three types of C–CDA documents described above in the proposed numerator (CCD, Referral Note, Discharge Summary) would impose a substantial burden beyond summary of care records. We request comment on the value of focusing on these three document types relative to all types of summary of care records. We also request comment on whether meaningful measures could be generated without de-duplication of C–CDAs, how often duplicate C–CDA documents may be obtained by customers of certified health IT, and how much of a burden it will impose on developers of certified health IT to ensure that C–CDA documents are not duplicates.

We repeat our comment on the first clinical data exchange measure – our expectation is that a larger and larger portion of clinical data exchange will be happening via FHIR or in a hybrid form using FHIR data structures exchanged via some other means. Any measure that ignores these modalities will increasingly be out of date and become less and less useful over time. We urge ONC to adjust these measures to consider the shift toward FHIR and consider both FHIR and C-CDA data exchange when looking at any measure related to clinical data exchange (at least for now).

As far as the C-CDA data goes, we feel it would be useful to be able to compare the number of reconciled C-CDA documents to the total number of received C-CDA documents and suggest updating the measure to support this.

Response to Specific Questions – Insights Condition – Standards Adoption and Conformance Measures

This section will list specific questions asked in the Insights Condition and Maintenance of Certification Standards Adoption and Conformance Measures section of the proposed rule and our responses to them.

This measure would produce a list of apps that would provide information on the degree to which apps are able to connect to multiple different certified health IT systems in a seamless manner. We believe capturing this information over time would provide insights into the evolution of the types of apps that are available for meeting the needs of various end users of app technology to support a variety of critical purposes. We welcome comments on our proposed measure.

We agree that the collection of this information is useful and propose that it be made public as well as reported to ONC. The usage categories outlined in the proposed rule make sense for non-patient facing apps where a single app connection might gather data for multiple patients, but for patient-facing apps slightly different criteria is needed. We recommend supporting an “inactive” option for apps that have requested a connection to certified health IT but transferred no EHI through that connection as well as noting whether an app is used just once or more than once if connected. This would mean organizing applications info the following categories for each instance of an app connection:

1. Connected but has not transferred any EHI.
2. Connected but used by patient less than K times (3? 5?)
3. Connected and used K or more times to transfer patient EHI

A report for a specific patient facing app might be: N inactive users, M evaluating users, and P active users during the reporting period whereas a similar report for an app used by clinicians might be: J inactive apps, L active apps transferring data for 10 or more patients. We also recommend providing specific numbers of users for each active app to get a sense of how popular each is. In the future it may be desirable to have a “superactive” designation for apps that transfer some large number of patient’s data (hundreds? Thousands?) but we suggest using the initial collection of usage data to help inform how to define that or any other future collection categories deemed useful.

As far as application categories go, we feel the categories suggested by ONC form a useful first level of data. However, we feel like several of the categories could and probably should have a second level of categorization. For example, it would be useful to know what type of clinical decision support an app provides and which apps are helping to automate prior authorization or collect SDOH data via automated questionnaires. Providing a second level of subcategorization under clinical tools would be helpful.

We also recommend the ability to provide context for apps that fall under the other category and, perhaps, to note specialty care apps such as apps for managing a particular condition (diabetes, hypertension, etc) or for assisting with a particular type of treatment (physical therapy, nutritional support, etc). These apps may cross multiple categories listed by ONC and thus perhaps should be listed separately.

We request feedback on whether information on both aspects of the measure, FHIR version and U.S. Core Implementation Guide, are necessary as each provides unique insights or whether focusing on just one of these (either FHIR version or U.S. Core Implementation Guide) would be feasible and sufficient for understanding where the industry is with regards to the implementation of FHIR. We also seek comment on the feasibility of reporting the use of different HL7 FHIR implementation guides and FHIR versions overall, versus stratified by type of endpoint, type of FHIR resources, and by the number of certified API technology deployments.

We approve of collecting data by FHIR version and US Core version, but do not believe these are sufficient metrics to understand how FHIR is being used by the industry as a whole.

FHIR version is important because there are many implementations still using pre r4 versions of FHIR according to Lantern. Tracking their move toward compliance with current standards (we hope) will be an important component of tracking industry adoption as a whole.

In addition, tracking the US Core version is important for understanding compliance with industry expectations, particularly as they move from USCDI v1 to USCDI v3 and their corresponding US Core versions. It would also be interesting to have visibility into the percentage of users choosing to implement USCDI/US Core versions supported via the SVAP process as newer versions appear there before being included in future regulations.

However, we note that USCDI/US Core is considered a floor for FHIR data exchange and, particularly as time goes on, ONC should expect a growing amount of data exchange that is compatible with but goes beyond US Core compliance. Resources that are compliant with a specific version of US Core will not necessarily explicitly be marked as US Core vX resources.

Many of the resources in this category will be defined as profiles in other implementation guides both from standards organizations and, in some cases, from specification developers in smaller communities and/or representing a specific entity interested in developing innovating data exchanges not supported by a wider industry effort.

Being able to track resources by IG conformance beyond US Core is essential to understanding how the industry is using FHIR and the data being exchanged via FHIR. Knowing that data was sent using CDEX or PDEX or a CodeX or a PACIO or a Gravity IG with their specific extensions to US Core resources will be an essential part of understanding whether and how data is being formatted, defined, and exchanged for specific purposes.

In theory, if requiring tracking of the specific IG each resource conforms to will automatically come with knowledge of the FHIR and, if compliant to US Core, the US Core version the resource is compatible with because the specific IG will be based on a specific version of US Core that requires a specific version of FHIR.

In addition to tracking the resources exchanged by IG (and inferring FHIR and US Core versions later as desired) we suggest tracking IG conformance at an installation level. That is, in addition to reporting the data exchanged by resource type per IG, requiring a server-level report of the IGs supported by the server, at least until such time as reporting all supported IGs in the capability statement is commonplace and collecting this data via Lantern is standardized.

We also feel it is important to understand not just the total traffic/distribution of resources across the product line as a whole but also across each installation. Thus, in addition to requiring each separate FHIR installation to report on its supported IGs, we also recommend some type of similar “inactive/Piloting/Active” usage levels for each type of IG to track adoption of things like the DaVinci CRD/DTR/PAS implementation guides supporting automated prior authorization, PDEX for payer=>payer data exchange, PACIO IGs for exchange of advance directive data, and so on.

We do not want to make reporting an overly burdensome process, but we also believe collecting this data as FHIR adoption grows is essential to understanding which IGs and use cases are gaining industry acceptance and how to focus limited resources to best support how the industry is evolving when it comes to using FHIR. We would be in favor of loosening reporting requirements in other areas to better support more extensive reporting in this area if deemed necessary to keep overall burden to an acceptable level.

We also feel strongly that the server level support metrics should be reported by even small certified health IT developers that otherwise do not qualify for insights reporting as long as they certify to FHIR API criteria.

We also note and clarify that non-standard or proprietary resources ( e.g., non-FHIR based) transferred would be excluded from this measure, and that we propose data for this measure would not include patient-facing applications, as individual patients only have the right to access their own records or records of patients to whom they are a personal representative. We welcome comment on our proposed measure.

We agree with these limitations and note that bulk FHIR can be used for a variety of purposes. We think it would be interesting to collect data on how often data for all patients visible to the user vs data for a specified group of patents (defined cohort) is requested via bulk FHIR.

We are not sure if there is any way to determine the specific use case resulting in the bulk FHIR data request, but, if possible, it would be nice to see what percentage of these requests are being made to support research vs financial operations vs care management of a particular cohort of patients vs public health surveillance/electronic case reporting, etc.

Current data sources to provide insights on the use of the EHI export function are limited, and our experiences with surveys of health care providers indicate that many health care providers, particularly office-based clinicians, may not be familiar with the technical terminology, and thus survey data would not serve as a useful data source for the use of this functionality. Therefore, by requiring data to be reported under this measure, we would be able to understand if the capability is functioning in the market as intended. We welcome comments on our proposed measure.

We support the metrics outlined in the measure in the proposed rule.

Given the statement above, we also support additional educational resources for the provider community around EHI and patient access rights. Given that the EHI language is becoming pervasive in interoperability rules, individual clinicians need to understand what it is in order to support their patients/their patients’ data needs, particularly in small offices that may not have dedicated technical personnel but still need to fully understand this requirement in order to comply with information blocking rules and other requirements.

Response to Specific Questions – Insights Condition – Public Health Information Exchange Measures

This section will list specific questions asked in the Insights Condition and Maintenance of Certification Public Health Information Exchange Measures section of the proposed rule and our responses to them.

We believe “replays” should qualify as a successful submission since the purpose of this proposed measure is to identify administrations successfully submitted, not necessarily those submitted on the initial try, and welcome public comment on this.

We believe knowing how many submissions need to be repeated may be useful data. Thus, we suggest collecting “successful on the first try”, “eventually successful”, and not successful data.

We also ask ONC to consider how data submitted from a secondary source should be considered. During the height of the pandemic many immunizations were being given in non-standard locations and data collection may not have been as robust as desired in all cases. Here in Massachusetts patients who noticed that one of their vaccinations was missing from their MIIS record were instructed to have their primary care provider submit the correct information even when they were not the source of the immunization. This meant that data was, in theory, manually collected and submitted as external data well after the fact. It is unclear how it was entered into the PCP’s certified health IT system since it was not associated with the actual provision of the immunization and in many systems externally sourced data is not directly integrated with local data. We know of some cases where this data never actually made it into the state MIIS system; it is unclear if its lack is from a submission error, segregation of external data that kept the immunization submission from seeing the correct information, or lack of follow through by an overworked PCP office being asked to do extra work generated outside of their practice. Having some way to track how often this type of correction request happens and the success rate of the data actually appearing in the IIS system beyond manual requests for immunization data by the affected patient would be helpful in theory, but we do not know how much extra effort it would entail or if the insight gained would be worth that effort. Regardless, having a specific, standardized way to address reporting these cases (as if the immunization was given locally, for example) so everyone understands if and how it’s being reported would be helpful.

We also wonder how you know the number of immunizations given if some were not successfully sent to the IIS system, or, if based on locally administered data, how do you account for the cases outlined above where clinics are being asked to submit missing immunizations they did not provide to the IIS system.

We propose developers of certified health IT with Health IT Modules certified to § 170.315(f)(1) would attest that they are unable to report on this measure if they have no users that administered immunizations during the reporting period. There may also be providers who do not administer immunizations but would want to query an IIS to determine whether their patient has received a vaccination. We seek comments on whether we should include this exclusion or suggestions on how we could better refine it.

We believe an attestation that no immunizations were made is better suited to the previous measure than this one which is more about querying the system for data than reporting data. We believe it very likely that providers who do not administer immunizations will query the system for immunization data for their patients. Our staff have experienced this repeatedly in their own medical care. Further with the increase in immunizations provided by pharmacists and in other non-traditional settings this number is only likely to increase over time.

We believe it makes sense to segregate the reporting of immunization data and its request/receipt into two separate measures as outlined but they should be independent – the submission measure should not make any assumptions about data requests and the query for data measure should have no dependence on whether the requestor has the ability or need to submit immunization data.

Response to Specific Questions – Information Blocking – Infeasibility Exception – Uncontrollable Events Condition

This section will list specific questions asked in the Uncontrollable Events Condition of the Infeasibility Exception for Information Blocking section of the proposed rule and our responses to them.

We welcome comments on this proposal, including whether alternative or additional refinements to the wording of the condition may make the causal connection requirement more immediately obvious from the face of the text in § 171.204(a)(1).

We do not understand the need for the change from “due to” to “because of” as they mean exactly the same thing, but have no problem with the change.

What we do feel needs more clarification is exactly when this exception applies as many of the conditions that could potentially be the cause of uncontrollable conditions are temporary and not permanent conditions. Having specific guidance on how long to wait before determining that fulfilment of a request is not merely delayed but not possible within some reasonable timeframe. Further, if such a timeframe passes, does the entity invoking the exception provide the requestor the expected timeframe for when their request could be fulfilled? Are they obligated to try to fill it later after the situation resolves or is the burden on the requestor to track when the uncontrollable event is resolved and make a new request?

We understand that actors have 10 days to notify requestors they are invoking this exception, but no other timeframes or guidance on how to deal with disruptions expected to be longer than a week or two but not ongoing indefinitely (such as a service outage or many natural disasters) are provided. We see this as a major gap in understanding how this exception applies.

We also wonder if many of those uncontrollable events are sufficiently disruptive that the actors in question would lose the ability to access both existing and new requests sent to them during the disruption. Requiring a 10 day response in the middle of a major hurricane (for example) may be unreasonable if power is out, facilities damaged, and key staff is homeless. Even providing an actual response to requests that may have previously been underway is not likely to be front of mind in this situation and any new requests may reasonably not be received in any real way during the disruption. We suggest a longer response timeframe or a grace period for this type of situation may be warranted.

Response to Specific Questions – Information Blocking – Infeasibility Exception – Manner Exception Exhausted Condition

This section will list specific questions asked in the Manner Exception Exhausted Condition of the Infeasibility Exception for Information Blocking section of the proposed rule and our responses to them.

In seeking comment on the proposed new § 171.204(a)(4) manner exception exhausted condition, we seek comment specifically on whether commenters expect the needs of patients, health care providers, and the advancement of interoperability, EHI exchange, and/or health IT innovation would be better served by the factor proposed in § 171.204(a)(4)(ii), requiring the actor have offered all alternative manners consistent with § 171.301(b)(1), or by simply requiring that the actors offer only two or three alternative manners so long as at least one of those manners used either certified technology consistent with § 171.301(b)(1)(i) or used content and transport standards consistent with § 171.301(b)(1)(ii) in order for the request to meet this condition. We note that an actor whose practices cannot meet § 171.204(a)(4) manner exception exhausted condition could consider aligning their practices to satisfy the § 171.204(a)(5) infeasible under the circumstances condition instead. We also specifically request comment as to whether this alternative approach could lead to less incentive to adopt certified health IT

We ask for some clarification here as we thought it was up to the requestor of data to continue to request alternate formats until such time as they have exhausted the formats they’re willing to consume. While technically a negotiation either way, the original information blocking text appeared to give the requestor the power to control the negotiation process and decide when it’s been concluded/the two parties cannot come to agreement and then to decide if the actor was being reasonable or, if not, choose to file a complaint.

It sounds like the new process being outlined here shifts control to the actor to push back once with any or all alternatives they find acceptable. The requestor is never given the option to specify their second or third choices for the data format/exchange mechanism if the required response is now “no to option #1 but here is a list of what we’re willing to do”. The actor may not have even considered the requestor’s other options as possibilities and may, in fact, be able to fulfill one of them.

We believe the power to suggest and accept/reject should remain with the requestor unless or until they are deemed unreasonable. We suggest a minimum of three different requests should be allowed by the requestor and that follow up requests to the first rejection be allowed to either be “here’s my next request” or “here are four other ways I can absorb the data in my order of preference” – and the actor should be required to explain why they’re taking option #3 instead of 1 or 2 in that case.

If the current system outlined in the rule is retained, we do believe the actor should be required to support all industry standard mechanisms for the requested data exchange and not just support 1-2 of them as outlined in the current proposed rule. We do believe the current language disincentivizes supporting more than 1-2 options of the actor’s choice and feel that any incentives for expanding beyond that should be leveraged. We understand the need to continue supporting legacy formats and exchange methods during a time of transition, but we worry that continuing to allow actors to say “we only support these two legacy formats” indefinitely provides no incentive to start supporting newer options that help the industry as a whole improve its standardization and interoperability.

We request comment on whether we should provide more textual specificity or clarity as to the proposed text “a substantial number of individuals or entities that are similarly situated to the requester.”

We understand the rationale ONC supplies around the reason for not being more specific in its language in this area, but we are concerned that the vagueness will allow actors not to supply access they should be able to supply.

Also, we note that generally availability, go live, or other terms indicating the state of a product or service are not typically dependent on the number of users but rather the ability to service any requests for that functionality that do occur. Thus, we find equating the idea of “a substantial number of users” to the availability of a feature a bit strange. While everyone hopes that available features see a lot of use, there is never any guarantee of such and lack of adoption may occur for many reasons that have no bearing on the usefulness of the feature (poor marketing, lack of advertising, bad user experience, poor documentation, etc). If functionality is considered usable by customers then having any customer use it should be considered normal and customary practice. It doesn’t matter if (for a time, at least) they are the only customer using that feature.

We also note that many useful features are offered to potentially interested customers during a late pre-release phase or beta testing. We point out that having requestors interested in using a particular new feature is useful marketing and business planning information for an actor and may even be actively helpful in testing features in late planning/implementation phases.

In addition, adoption levels can fairly easily be kept artificially low if desired by telling those initial requests no. If an actor currently doesn’t support FHIR access to clinical data because they haven’t turned on the functionality made available by their certified health IT then they have no customers using this functionality. However, we believe it is unreasonable not to turn on the feature to support the request. By this definition of Manner Exception Exhausted it seems like they would not be required to do so.

We are also concerned about the lack of clarity related to the similarly situated clause of the requirement. This, too, is very vague and open to extreme levels of interpretation.

Another alternative to these types of vague definitions might be an explicit “actors are not required to implement custom features or code to meet any data request – rejecting requests that would require custom code is not information blocking”

Regardless of its final format, we suggest some level of reporting on the rejected requests be required (to be reported to ONC or some other entity) to both hold the actors to account for their decisions and to better understand the types of requests being made that cannot be fulfilled/to make sure this exception is not being used to avoid implementing common functionality that ONC would like to encourage (such as an actor turning on FHIR APIs made available by the certified health IT they use). If a substantial number of requests are being made for reasonable format X and rejected, work on ways to incentivize supporting X should commence.

Regardless of how this exception is addressed in the final rule, we respectfully request ONC address whether actors who have FHIR APIs available to them but choose not to turn on the feature for some reason (not wanting to pay for it is the one we’ve heard most frequently) can be considered information blocking if they do not fulfill requests for FHIR data exchange. We understand ONC cannot comment on specific cases, but this general case seems like a bit of a potential loophole to regulations intending to increase FHIR support generally.

Response to Specific Questions – Information Blocking – Manner Exception – TEFCA Condition

This section will list specific questions asked in the TEFCA Condition of the Manner Exception for Information Blocking section of the proposed rule and our responses to them.

We welcome comments on this potential requirement for satisfaction of the new proposed TEFCA condition. We also welcome comments on all aspects of the new proposed TEFCA condition for the Manner Exception.

ONC states:

“We believe it is reasonable and necessary for actors who have chosen to become part of the TEFCA ecosystem to prioritize use of these mechanisms rather than other mechanisms—that are potentially less interoperable, less secure, or less scalable—for sharing EHI with requestors who have also chosen to become part of the TEFCA ecosystem”

We strongly urge ONC to reconsider this idea. While certainly there will be many participants (we will use that term to represent all three types of entities for purposes of this discussion) who are quite happy to use TEFCA for any or all allowed data exchange, others will sign up for TEFCA with the intent to use it only for a specific purpose. Further, in many organizations, it may be a specific business unit that signs up for TEFCA access and implements it without other business units at that organization even knowing that they did so. Should this condition apply to the entire organization despite most of it having no idea they even belong to TEFCA let alone having no way to connect their IT systems to it or just to the business unit that signed up to get data via TEFCA? This scenario where one business unit or a team specifically tasked with doing one particular thing implements functionality that the rest of the organization is mostly unaware exists may be indicative of an unfortunate lack of internal communication, but is very common in our experience. Requiring the entire organization to use TEFCA because one business unit signed up and implemented it is burdensome and may impose additional burden on groups that are using another mechanism (such as FHIR) for its data exchange needs.

Further, what if an organization sees TEFCA as an easy FHIR endpoint directory (for example) and signs up to access only this one specific somewhat segregated service with no intention of using TEFCA for anything else. Having done so without understanding this decision meant they may be required to use TEFCA whether or not it appears to be the best option to accomplish their goals and objectives is extremely problematic. There is no general mandate that an entity using TEFCA is required to use it for any possible purpose it can be used for, but that is exactly what you’re proposing in this rule for the context of information blocking.

We believe this condition is burdensome, particularly given the current state of TEFCA and the stated slow timeline for wide adoption outlined by Sequoia. It is not at all clear what the current state of TEFCA will be at the time this rule goes into effect. Regardless, we strongly believe entities should be able to choose the best interoperability mechanisms for them and be able to request data in any format the current source can reasonably support using an exchange mechanism both parties can support. There is no logical reason to carve out TEFCA from this more general requirement.

Response to Specific Questions – DSI

This section will list specific questions asked in the DSI section of the proposed rule and our responses to them. We note we feel this section suffered the most from not having more time to review, digest, and comment on the rule. We hope for future avenues for commenting on these provisions further and hope that a clearer distinction is made between development and use of DSI in the future.

We welcome comment on the proposed scope of these feedback data, utility for evaluation of their DSIs, and the potential for such data to be used in conjunction with quality metrics.

We approve of logging the actions taken based on presented DSI interventions. In addition to the data listed in the proposed rule, we wonder if notation of other available data considered in evaluation of the DSI is appropriate. For example, if certain clinical data was presented in addition to the results of the DSI to support its findings, knowing what that is would be helpful.

For example, the result of a specific DSI is that a patient qualifies for and should be enrolled in a specific transportation program that takes patients from their homes to local grocery stores once a week. In addition to this result, the DSI information screen is designed to present relevant additional known clinical data that may affect eligibility and relevance of the program: it notes that the patient is disabled and the patient has diabetes. The clinician sees this data and approves patient enrollment. The interaction log should note that the DSI recommended enrollment in that program and that it highlighted the patient’s disability status and diabetes diagnosis to the clinician to assist in their decision process as well as the clinician’s decision to enroll the patient.

We propose that such feedback data be available for export by users for analysis in a computable format, so that it can be associated with other relevant data, such as diagnosis, other inputs into the DSI, and the outputs of the DSI for a particular patient, to evaluate and improve DSI performance…We invite comment on these proposals.

While we think having the patient data available for association is helpful, it is less pertinent if not being actively presented to the clinician while they’re being asked to decide about the intervention as there is no way to judge whether the clinician making a decision based on the DSI knew or was likely to consider that information as a factor in their decision. Thus, while we approve of this proposal, we feel the data outlined in the previous comment to be more directly relevant.

The proposal would not require the automatic display of source attributes information when a recommendation, alert, or decision support output is presented that resulted from a DSI. We invite comment on this proposal.

It is unclear to us how this information is presented to the clinicians using DSI, particularly if they are not knowledgeable enough to know how the source attributes might affect the outcomes and applicability of the recommendation. If they are not automatically notified this information is available, how do they know to look at it? In particular, we are concerned that all of the required documentation/information about DSI be buried behind a small link at the end of some type of about screen only accessed via an obscure help menu. Some guidelines on how to present this information, or at least to ensure it’s not completely buried via obscurity seems warranted.

We are soliciting comments in this proposed rulemaking on whether we should require developers of certified health IT with Health IT Modules certified to proposed § 170.315(b)(11) to make all source attributes information in the proposed § 170.315(b)(11)(vi) publicly available or accessible, for example, on a website

We are in favor of public release of all documentation and information related to the source attributes, data quality, model validation, source of output information, intervention details, and other relevant information related to model development and usage.

We solicit comment on whether having this information publicly available would be beneficial for potential users that purchase models or associated technology or software, and would help inform them prior to procurement of certified health IT and procurement of predictive DSIs integrated with certified health IT.

Yes, we believe this would enable those with sufficient knowledge to understand the data to make informed purchasing decisions. We note that the education deficit is such that this may not be the case for everyone, but that should not preclude making the information available to those who will find it helpful and perhaps it will help others understand how much they still need to learn.

We also solicit comment on whether having this information publicly available would improve public confidence in predictive DSIs by enabling research on source attribute information.

Yes, this would be generally helpful in improving public confidence. In addition, we further suggest that patients be given sufficient information about any DSI used in their care to know how to look up this information for those specific DSI later to read about how it may have affected their care and the decisions made by their clinicians.

We welcome comment on whether we should require a certain format or order in which these attributes must appear to users.

There are two common ways to present this type of long list of data: alphabetically or by type (often organized alphabetically underneath each category). In this case, we recommend categorizing by type of data then presenting each list therein alphabetically. For example:

Demographic Data: date of birth, race, sex

Health Status: disability status, smoking status

if a patient requests access to their information held by a health care provider, the designated record set (DRS) could include, for example, the underlying data used to generate recommendations about their healthcare, underlying information about any use of predictive DSI generated as part of the healthcare decision, and other information ( e.g., summary information about intervention risk management practices) associated with such use of a predictive DSI

We believe this information should be part of the patient’s designated record set and available as part of their EHI/covered by the rules around dissemination/requests for EHI including HIPAA and information blocking.

Response to RFIs – Laboratory Data

This section will address specific questions asked in the Laboratory Data RFI section of the proposed rule.

We seek public comment generally on any topics identified above for the Consolidated Appropriations Act, 2023, Section 2213(b) study on the use of standards for electronic ordering and reporting of laboratory test results, such as the use of health IT standards by clinical laboratories, use of such standards by labs and their effect on the interoperability of laboratory data with public health systems, including any challenges of the types identified above.

We note the importance of code systems and being able to convert from internally common code sets to those required by FHIR for laboratory data. We have attended several sessions at WEDI conferences and elsewhere where well meaning individuals trying to make laboratory data more interoperable were brought to a complete standstill because the internal laboratory IT systems used completely different code systems than those used by clinicians for the same or related data.

4. Would developers of laboratory information systems or in vitro diagnostics systems that have not traditionally submitted products for certification under the Program seek out and benefit from certification to criteria relevant to such developers' products?

Presenters at some of the same public sessions noted above have noted that at least a non-negligible subset of laboratory IT systems do not use consistent standards among themselves. There might be some role for ONC in setting additional standards for laboratory IT systems and certifying to them.

If the goal is to have consistent, standardized data exchange between two systems – those used by traditional clinical healthcare settings and those used within the laboratory spaces – both sides of the exchange must follow consistently defined and applied rules for the exchange interface. This would be difficult to implement, monitor, and improve without having some level of knowledge and oversight over both sides of the exchange.

Response to RFIs – Real Time Pharmacy Benefits

This section will address specific questions asked in the Laboratory Data RFI section of the proposed rule. We also note that this section appears to skip directly from subsection A (background) to subsection C (certification criterion) giving the appearance of missing information.

We seek comment on the value of negotiated price to patients and prescribers to aid in their discussions and decision-making during prescribing. Patient cost-sharing responsibilities are often driven by their plan design, deductible, copay requirements, and other related factors, thus it is unclear whether including such information will improve the utility or usability of technology certified to a real-time prescription benefit certification criterion.

Cost of medical care is increasingly cited as a major reason why care is not completed and why adherence to medication regimes is low. Being able to discuss the actual cost of a medication with the clinician prescribing it and looking for alternative options that may be more affordable may be the difference between a patient getting the care they need versus getting a prescription they never actually fill.

That this pricing is personalized makes the need for supporting real time accurate patient cost information available more important, not less. There are already many industry efforts and requirements to incorporate personalized plan and benefit information into pricing efforts (No Surprises Act immediately comes to mind). We argue that it is essential that any prices take into account a patient’s current coverage including their approved formulary, deductible status, whether a medication counts toward their deductible or is covered at 100% immediately, out of pocket maximum status, need for prior authorizations to get desired medications, and more are all essential to the real time discussion between a patient and their clinician as care decisions are made. Technology can and should be required to support these discussions.

We are seeking comment on whether the real-time prescription benefit certification criterion under consideration should only require and test XML format or both XML and EDI formats.

We are not experts in the NCPDP requirements, but we note that XML is not a new format and, in fact, has already largely been replaced by JSON in modern data exchanges. Requiring support for XML does not seem like a stretch. We would also urge consideration of a move toward JSON at some point in the future.

Would requiring demonstration of compliance with both NDC and RxNorm in a real-time prescription benefit criterion support improved adoption, maintenance, and harmonization between code sets?

Harmonization between NDC and RxNorm is a wider issue affecting medication data standardization and exchange more generally. We saw this and similar issues with other widely used code systems as a major blocking factor when looking to move our quality measures exchange from a legacy flat file format to FHIR, so much so that we explored standing up our own code mapping service to provide standardized mapping between different code systems (we found the industry wasn't ready to support this but we still hope to stand up this type of service in the future). We are in favor of any and all efforts to define a clear, consistent, and comprehensive data mapping between the two code sets for use in this and any other pertinent circumstances.

What would be the consequences (positive or negative, intended or unintended) of establishing “RxNorm as the single source of clinical data for clinical care, research and administrative workflows, replacing NDC for such purposes,” as recommended by the HITAC?

Because of the amount of data currently stored as NDC codes, having a clearly defined mapping and programs to accomplish mapping existing data in place would be a requirement for such a declaration. However, if it can be accomplished, we are in favor of standardizing the data used for specific purposes and would be in favor of always using a single code set to represent medication data. We have no independent comment regarding whether it makes more sense to use RxNorm or NDC for this purpose, but trust HITAC has a logical reason for selecting RxNorm as the winner in this case.

Would a requirement to demonstrate use of both ICD–10–CM and SNOMED CT within the Clinical Segment as part of an RTPB certification criterion support a more seamless transition between ICD–10–CM and ICD–11, in the event ICD–11 is adopted? Are there other benefits to requiring certified Health IT Modules demonstrate compliance with both terminologies?

We would favor requiring support for both SNOMED and ICD-10/11 over just ICD-10/11 support, but ask is there benefit to supporting both ICD-10/11 and SNOMED or could the same purposes be met just by supporting SNOMED given that SNOMED is becoming the de facto clinical default for condition reporting in general. That said, we note that the US Core MedicationRequest profile supports ICD-9, ICD-10, and SNOMED codes for the equivalent information so supporting both ICD-10/11 and SNOMED would be consistent across different formats.

Should ONC consider requiring alternative or additional demographic data elements or sets of demographic data elements as part of a real-time prescription benefit certification criterion to further improve patient matching? For instance, should ONC consider requiring the Patient Demographics/Information data class identified in USCDI Version 3? What additional benefit would this offer to health IT developers, health care providers, patients, and the healthcare industry in general? What additional burden would these or other alternatives impose on health IT developers?

For the purposes of patient matching, the information-based data elements such as address (as opposed to the demographic related elements such as race and ethnicity) might be helpful. However, there are other benefits to requiring exchange of the full data class such as better equity tracking and equity-related data collection around which patients are/are not filling their prescriptions or in how different medications are prescribed for the same conditions.

At the same time, there are privacy concerns around sharing some of that data with an ever wider audience. SOGI data is particularly sensitive in this regard. We’ve noted elsewhere that some patients equate sharing their gender identity information to others, even other clinicians, without consent as a form of outing them.

We leave it to ONC to weigh the pros and cons here; if there were more consistent consent controls around the data we would be wholeheartedly in favor of sharing it.

What benefits would come from supporting the exchange of prescription benefit information for vaccines, medical devices, or supplies?

We are increasingly concerned on the split between medication and other clinical care elements when it comes to interoperability. Patients do not understand that there are different processes, nor should they have to do so. However, it causes rifts in patient-facing data availability such as the proposed carve out of prior authorization for medication in the recent CMS proposed rule despite medication prior authorizations being the most commonly encountered by most patients. We pushed back on this carve out to the CMS proposed rule and believe that all efforts should be made to present data to patients without such artificial divides.

That said, we believe it makes sense to exchange prescription benefit information about the items listed and if the only way to do so is to incorporate them into a real time pharmacy benefit system then we approve. However, we caution that the related information should still be available for standard, more encompassing data exchanges and processes. In particular, as noted above, all attempts should be made not to require additional carve outs to any interoperability processes in current or future rules to accommodate this choice.

Should ONC propose a new certification criterion that would enable a user to use a Health IT Module to obtain formulary and benefits information using a more recent NCPDP Formulary and Benefit standard?

We are in favor of requiring formulary information as part of any real time pharmacy benefit functionality. However, we note there are also FHIR-based standards for this information (such as the DaVinci PDEX Formulary IG) that are used for patient access to the same information and other purposes. We urge ONC to consider adopting a consistent standard across all use cases to ensure that the same information is presented to patients and clinicians at all points of interface to the information.

We ask ONC to consider whether the two formulary standards are compatible with each other and how to ensure the same data is consistently available to all interested parties at the time and in the manner appropriate to each situation.

We are not suggesting ONC consider certifying against the PDEX Formulary IG for real time pharmacy benefits at this time, but we urge consideration of the entire medication ecosystem during all evaluation of related real time pharmacy benefit (and related electronic prescribing) certification criteria and that the patient view of data be considered along side that of payers, PBMs, and providers.

We invite comments on the potential incorporation of these transactions [prior authorization] into the “Electronic prescribing” certification criterion and whether we should consider requiring certification to these transactions in a future rulemaking.

We urge ONC to require real time incorporation of prior authorization requests into the electronic prescribing process. We also urge ONC to consider how the related data could be incorporated into existing FHIR data exchanges and upcoming requirements around prior authorization. While we understand the actual behind-the-scenes process of requesting a PA for medication will likely remain different from other medical items and services, we urge that ONC (and HHS as a whole) prioritize integration of the related data into existing and upcoming mechanisms for managing the prior authorization process and in sharing data related to it with both providers and patients in a consistent way. In particular, the CMS Patient Access, Provider Access, and Payer => Payer FHIR APIs all will require inclusion of prior authorization status and the related clinical data used to make PA decisions as of January 1, 2026 – but medications are currently carved out. We believe this will lead to a less effective and more confusing view of data for patients.

On a similar note, management consoles or other aspects of clinician PA management should integrate both medication and other prior authorization requests seamlessly. We believe this part of the equation is firmly within ONC’s jurisdiction to impose and we urge that it be part of any upcoming rulemaking covering certifications related to prior authorization. In addition, direct interoperability and consistent data views of all related data is needed between PBMs and payers given that the patient data in these areas flows from their payer even when the payer subcontracts actual management to a PBM.

Might there be additional opportunities to reuse testing resources and streamline the testing experience for health IT developers while taking additional steps to ensure that certified health IT is optimized for prescribing safety, efficiency, and usability?

We cannot comment on the specific testing requirements for real time pharmacy benefits or electronic prescribing, but in general we support end-to-end testing of the entire prescribing process as one component of required testing. This would likely involve components of both criteria and could, in theory, provide a useful way to bundle together functional testing of multiple different items requiring testing. This would not replace more detailed, focused testing requirements to ensure specific aspects of the system are working as intended (especially when something goes wrong or some unexpected data is introduced into the system).

Response to RFIs – FHIR - Subscriptions

This section will address specific questions asked in the FHIR Subscriptions RFI section of the proposed rule.

FHIR Subscriptions are enabled by the following resources: Subscription,^[376] SubscriptionTopic ^[377] and SubscriptionStatus.^[378] We seek input on the maturity of these resources in the FHIR Release 4 standard

This is not entirely true. There are two types of FHIR subscriptions: query based and topic based subscriptions. FHIR r4 natively supports query based subscriptions. Topic based subscriptions, along with the SubscriptionTopic and SubscriptionStatus resources, were introduced in FHIR r5. Topic-based subscriptions were backported to FHIR r4 and FHIR r4b but they are accomplished in a completely different way in those versions. The backport to FHIR r4 is something of a hack because of restrictions in place around the inability to make certain modifications and additions for more robust/consistent support.

Additionally, we seek comment on whether the FHIR Subscriptions capability aligns with the adoption of the FHIR Release 5 standard, and whether alignment with FHIR Release 5 would avoid any costly refactoring of the resources and give more time for industry to test the various features and capabilities under development

As noted above, topic based subscriptions do align much more clearly with FHIR r5 and, in general, we would be in favor of aligning support for topic based subscriptions to support for FHIR r5 or later. However, there is a wrinkle that may make that a less than ideal choice.

Upcoming changes to the DaVinci CRD, DTR, and PAS IGs that collectively define a FHIR-centric automated prior authorization process (and the expected path to future conformance with the pending CMS prior authorization PARDD API requirements), have decided to use the backported topic-based subscription mechanisms. Thus, while immature and likely to require refactoring when FHIR r5 or later is eventually adopted by the industry, it may not be possible to avoid implementing and perhaps certifying to the FHIR r4 version of topic based subscriptions in order to fully support upcoming electronic prior authorization requirements.

We request comment on whether there is a need to define a minimum set of Subscription Topics that can be consistently implemented by all health IT developers of certified health IT to provide a base level expectation for clients using the services.

We are in favor of defining a list of common subscription topics that must be supported but do not yet have any thoughts on what that list should be beyond those required by the upcoming changes to the DaVinci burden reduction IGs per discussion above.

We also invite comments on appropriate industry led activities to maintain and keep the artifacts up to date.

We have no comment on the best “keeper of the official artifacts” might be, but wonder if the process of defining the list of topics might be best handled as an offshoot of the USCDI development process and also be part of the USCDI+ definition for specific use cases. This has several benefits:

1. Having a well understood process for definition and decision making
2. Having a regular cadence for updates and adjustments
3. Having a known process for public input and comment
4. Having the ability to define major use case specific subscription needs (as associated with specific USCDI+ data sets)
5. We don’t know if there are equivalent subscription/notification processes in other standards adopted by ONC, but having standards agnostic subscription/notification topics/requirements would be helpful if there are, and the USCDI process is already designed to be standards agnostic

We have no idea if this is remotely feasible from an authority or implementation perspective, but wanted to throw it out as a possible idea.

Response to RFIs – FHIR – CDS Hooks

This section will address specific questions asked in the CDS Hooks RFI section of the proposed rule.

We request comment on the scope and maturity of the FHIR CDS Hooks specification v1.0, which we are considering for future inclusion as part of the Program.

CDS Hooks have been in wide use for several years and is among the most mature FHIR based technologies available. Further, CDS Hooks are widely adopted as part of various FHIR workflows and essential implementation guides including the electronic prior authorization process outlined in the DaVinci CRD/DTR/PAS IGs (the expected path to future conformance with the pending CMS prior authorization PARDD API requirements).

The lack of support for basic CDS Hooks in EHRs and other health IT is a significant barrier to FHIR adoption, particularly in terms of provider systems. We strongly urge ONC to include strong certification requirements around CDS Hooks support for certified health IT modules supporting FHIR.

We note that the current version of CDS Hooks is v2.0 and some major industry players are currently supporting CDS Hooks v1.1 (Smile CDR, for example) so ONC might consider its adoption instead of v1.0.

We further request comment on specific hooks that we might include in future certification criteria

While not all implementations are required to support all of them, the hooks noted in the DaVinci prior authorization workflows include:

• appointment-book
• encounter-start
• encounter-discharge
• order-dispatch
• order-select
• order-sign

We note that this is a substantial percentage of the existing defined hooks and that two of the three others (patient-view and medication-prescribe) seem like useful hooks to support. Given that there’s only one additional hook (encounter-dispatch) it may just make sense to require support for all hooks defined by the CDS Hooks standard.

Response to RFIs – FHIR – Standards for Scheduling

This section will address specific questions asked in the Standards for Scheduling RFI section of the proposed rule.

We welcome comments on how to support the scalability of the standard for use in a variety of healthcare settings, in order to achieve our goal of providing this capability across all certified Health IT Modules in a consistent and standardized manner using an already adopted standard.

We have no specific knowledge of or comment on the SMART Scheduling Links IG or other scheduling data and workflow standards, but we support development of and future certification requirements around industry standard FHIR-based data and exchange standards for appointments and scheduling be it through this SMART approach or some other.

We also urge ONC to consider how to encourage better integration between scheduling and other administrative systems and clinical systems. In particular, we’ve found useful SDOH-related information is often lost in administrative/front office systems and not visible to clinicians or other staff looking to explore SDOH and the needs of a patient population.

For example, patients will tell scheduling staff that they will be late for an appointment because a bus never showed up and be advised that they need to reschedule. If this happens frequently for the same patient is it evidence of transportation insecurity that perhaps could be addressed through available SDOH interventions, but the patient isn’t identified as a candidate for those programs because the data supporting their transportation issue is trapped in the scheduling system if it persists at all.

Similarly, data around accommodations needed for disabled patients to receive their care may be provided during appointment scheduling but it’s never integrated into the clinical systems used at the time of the encounter when the data needs to be acted on and patients show up without the necessary accommodations available for them, delaying or preventing needed care.