This document was submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) on October 2, 2024 in response to the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2, HHS-ONC-2024-0010) proposed rule posted in the Federal Register on August 5, 2024 and found here:

https://www.federalregister.gov/documents/2024/08/05/2024-14975/health-data-technology-and-interoperability-patient-engagement-information-sharing-and-public-health

About MHDC

Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts 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.. 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.

Pathway for Technical Corrections

As with many previous proposed rules, the HTI-2 proposed rule includes some typos that make it difficult to determine the intent of particular concepts or proposals within the rule. Most of those that impact the ability to understand the intent or evaluate specifics involve issues with references to federal code, either already existing or proposed elsewhere in this rule.

If there is any way to legally do so, it would be extremely helpful to have a pathway for reporting such issues during the proposed rule evaluation period and to get back some type of information about the intent of the accidentally incorrect content, perhaps via some public errata website with a response to the original reporter that there’s a related update on the errata site.

This would allow commenters to address that content as intended rather than being unable to comment on it prior to a final rule. It also would help ensure such issues are caught and fixed prior to the final rule.

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 appreciate that ASTP has often provided a short “preview” period off the books (and were generous with its length for this rule), and we understand the need to get regulations on the books to prevent implementation delays, but we believe an extra 30 days would have been extremely helpful and not posed a significant delay to timely finalization of regulation.

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.

Further, having the comment deadline coincide with the end of Rosh Hashanah further compressed the process in our case. We understand not everyone observes the Jewish High Holidays and that it would be difficult to track all possible religious observances for all of the religions common in the United States, but it should be possible to avoid deadlines on major holidays from major religions, particularly holidays that require taking time away from work that even those who are not particularly observant tend to observe.

Coordination of Rulemaking

We appreciate efforts by both ASTP and CMS (as well as other parts of HHS) to coordinate rulemaking. We understand this is a difficult undertaking, but it is essential that rules for payers, providers, and patients be consistent across all of HHS.

We note that a section of this proposed rule is designed to reinforce existing CMS rulemaking around the use of FHIR APIs. We applaud this and hope to see more of this type of rulemaking in the future.

However, one thing we’ve noticed is a bit of circular logic wherein CMS chooses not to include or require a specific piece of functionality because it’s not incorporated into any ASTP rulemaking as a standard or otherwise not supported by ASTP in its regulations and then ASTP makes similar choices around its related rulemaking because CMS did not require support for a particular piece of functionality. We want you to act in concert, but unless rules are going to be released simultaneously (such as the May 2020 interoperability rules) someone has to go first. Otherwise, it turns into a vicious circle where no progress is made on those features getting this treatment.

This is particularly noticeable in the commentary about the new Patient, Provider, and Payer API certifications, but it is not inherently specific to those topics.

Consistency in How Criteria are Split/Structured

We appreciate that a proposed rule of this sort is large undertaking with many different moving parts and various potential organizational decisions. We acknowledge there are many approaches ASTP could take, and our main criteria is consistency when possible. There are a few places in the rule where we respectfully suggest ASTP may not have quite gotten things right in this regard.

For example, the SMART App Launch user authorization modular API criterion covers both end user/patient users and clinician/professional users. In many other similar criteria, ASTP chooses to separately call out these types of users and discuss them separately. While there’s no technical reason to make this split, it does make it more immediately apparent which set of users is being supported by a particular piece of certified Health IT, and because other criteria do include this information not including it here could lead to some avoidable confusion.

Another example is the inclusion of vaccination-specific requirements for the SMART Health Cards modular API criteria. While vaccinations are the top of mind application for this technology thanks to Covid, they are by no means its only use. Given that there are separate public health criteria specifically covering requirements for immunizations, it seems more consistent to include this specific use case under the larger requirements for that use case (see discussion under SMART Health Cards below).

We do not profess these to be the only two examples, but they are two that were specifically noticeable to us.

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.

QI-Core

Now that ASTP is adopting FHIR implementation guides as supported standards, we would like to see the QI-Core implementation guide adopted as an official standard. This is a fundamental IG that other existing quality measures implementation guides leverage as the core, baseline data expectations. In particular, the Quality Measure implementation guide (QM IG, available here: https://hl7.org/fhir/us/cqfmeasures/) and the related Da Vinci Data Exchange for Quality Measures implementation guide (DEQM IG, available here: https://hl7.org/fhir/us/davinci-deqm/) are both built on top of QI-Core.

The QM IG provides a standardized way to digitize quality measures while the DEQM IG provides a standardized way to exchange data needed to calculate quality measures results as well as request/send gaps in care data, individualized patient needs reports, and other related reporting.

This image, part of both the QM and DEQM IGs, represents the dependency of the two quality measures IGs on QI-Core: https://hl7.org/fhir/us/davinci-deqm/quality-measurement-standards-landscape.png

Enshrining QI-Core as an officially supported ASTP standard would improve its adoption and increase the use of industry-standard implementation guides for exchange related to quality measures. It would also help a somewhat fractured industry inclined to rely only on official standards and workflows entrenched in regulations align around consistent approved standards designed to meet the specific needs of quality measures rather than trying to cobble them directly on top of USCDI in ad hoc or differing ways.

We also suggest that a symbiotic relationship between QI-Core and USCDI+ for Quality be explored (see the section on USCDI+ below for more on this idea).

USCDI+

We were disappointed this proposed rule does not include any substantive reference to any of the USCDI+ data sets, adoption of any as standards, or certifications around their support.

In industry discussions around the various USCDI+ datasets, we continue to hear that many organizations will not engage with USCDI+ unless or until they appear in regulations. We also hear from other organizations interested in exploring their possible use but frustrated by the lack of general adoption and/or support for these data sets.

We believe that certification programs for USCDI+, even if optional, would be immensely helpful, as would adoption by ASTP as official standards as the data sets mature.

Putting some type of stake in the ground in terms of versioning while still allowing expansion and change – similar to the annual USCDI cycle – would also be helpful, as would encouraging development of analogous FHIR IGs meant to make the USCDI+ data sets supportable in FHIR and that iterate with versions of USCDI+. We note that the QI-Core data set is an excellent candidate for a symbiotic relationship with USCDI+ for Quality, similar to the way that USCDI and US Core work.

USCDI v4/US Core v7.0.0 as the new floor and future updates

We agree that it makes sense to continue adopting newer versions of USCDI and corresponding versions of US Core as time goes on, and wonder whether it makes sense to make some attempts to move faster – by the time this rule goes into effect and makes USCDI v4 the adopted standard for general use, the final version of USCDI v8 should have been released and USCDI v9 draft will be imminent. That’s a significant gap between data set development and adoption.

At the same time, during some of our industry activities at WEDI and elsewhere, we have heard some individuals express surprise at how quickly they are expected to move from USCDI v3 to USCDI v4. This likely comes from organizations used to having multi-year planning processes followed by multi-year development processes to implement those plans; moving at this pace does not work in the modern IT world but the adjustment will likely be difficult for many organizations.

We believe some type of roadmap indicating loose expectations for the adoption of new versions and, more specifically, the expiration of older versions might help the industry as a whole get used to the idea that they are expected to adjust and start using newer versions of USCDI and the corresponding US Core versions on a regular basis.

Minimum Standards Code Set Updates

We note that the minimum standards code set updates outlined in the proposed rule do not match up to the code set expectations for USCDI v4:

We believe it is imperative that the versions adopted in HTI-2 match those specified in USCDI v4 given the expectation of USCDI v4 usage.

Relying on the Patient Access API for Formulary data

We approve of the decision to rely on the Patient Access API to provide formulary data to patients. However, we note this API is only required for certain types of payers at this time and thus access via FHIR APIs may not be available for all patients. Any mechanism that encourages wider adoption of this (and the other CMS-mandated APIs) would be welcome.

Enforcement Dates

It would be helpful to have clear effective dates for all of the components of this proposed rule (or a default effective date for those components without a date specified). In some cases where effective dates are supplied they seem somewhat arbitrary or inconsistent. For example, the various public health criteria have different dates – it seems like these should work as a module, or at least all of the provider health IT components should be grouped together, the public health IT components grouped together, etc. Another example is the January 1, 2028 date for Provider Access API – client even though the CMS API goes into effect on January 1, 2027. We respectfully request ASTP consider ensuring that there are clear dates associated with everything in this rule and that some of the dates that are included in the proposed rule be reconsidered to ensure certifications are grouped together in sensible groupings or are available prior to or simultaneous to other requirements for the functionality being certified.

Promoting Adoption of Payer API certifications

ASTP specifically discusses working with CMS to include requirements to certify against prior authorization (and perhaps other) APIs as part of the MIPS program, but does not include a similar discussion of promoting certification on the payer side. We respectfully suggest that ASTP is used to thinking in a box where they only certify provider-facing health IT and thus can only discuss adoption via CMS provider-facing programs. We encourage ASTP to think about the wider landscape they have started exploring within this rule and consider ways it can engage with CMS and others to encourage the adoption of Payer API certifications (and other new and future certification programs that fall outside of the scope of provider-facing use).

Certification Naming Conventions

We notice that ASTP has chosen to reference the certification components of the two CMS APIs with both payer and provider components differently. In the case of the Provider Access API, ASTP has chosen to use client and server labels for the provider and payer components. However, in the case of the Prior Authorization APIs, ASTP is using payer and provider labels. We respectfully suggest that using payer and provider labels throughout would not just be more consistent, but also likely make the most common user of a particular piece of certified health IT explicit.

Administrative Simplification Requirements and Prior Authorization

We understand that the letter of the law is that prior authorization requests are required to use X12 278 transactions per the HIPAA Administrative Simplification Rule. However, as noted in this proposal, the release of the final rule covering the CMS prior authorization APIs came with a notice of enforcement discretion that indicates it is acceptable to implement these APIs without converting between FHIR and X12 solely to meet the HIPAA requirement.

We strongly urge ASTP to take the same approach in certification and allow solutions that choose to take advantage of this decision and not arbitrarily convert between data formats for no reason other than compliance (which has been lifted) to still certify against the prior authorization APIs.

Participants in our Data Governance Collaborative thought certified health IT should be required to support both the option with X12 and the option that uses just FHIR.

Role of Testing in Patient, Provider, and Payer API Certifications

Participants in our Data Governance Collaborative believe there should be a specific testing requirement incorporated into the Patient, Provider, and Payer API certifications, perhaps leveraging the Inferno test tool. Having a specific set of tests that everyone has to pass to be considered conformant would better ensure consistency among certified health IT solutions.

Response to Specific Questions – Standards and Implementations Specifications

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

We propose to update our current maintenance of certification (MoC) requirements in § 170.404(b)(2) that reference FHIR resources and elements directly and adopt Brands in § 170.404(b)(2)(iii) as a replacement… We welcome comment on this proposal.

We approve of the adoption of a standard mechanism for specifying available endpoints. At the current time, the Endpoint resource is most commonly used for this purpose. We are not opposed to switching to the Brands mechanism (which incorporates endpoints) but believe it is important to use the same standard across all common FHIR endpoints, be they for payers, providers, health IT developers, HIEs, or other entities that might be using FHIR.

We understand that ASTP only has oversight over a portion of these entities, but it is not helpful to the industry as a whole to have different types of organizations using different mechanisms to advertise their endpoints/how to connect to their FHIR services.

We urge ASTP to work in concert with CMS and others to standardize this across the industry as a whole. As an interim step, perhaps using the same Brands mechanism for related endpoints could be a certification requirement for the optional payer APIs.

we propose to revise three certification criteria by adding new provisions to include support of a link to diagnostic imaging… We welcome comments on these proposals.

First, we welcome the addition of requirements to provide direct access/interoperable images. As the use of CD and DVD drives has decreased, it has become increasingly difficult to use physical media to deliver imaging results outside of the originating system. One of our staff members received physical therapy in a large PT office over a decade ago and even at that time there was only one computer, located in a back office inaccessible to patients, where staff could view imaging results brought to them on CDs or DVDs. They could not discuss what they saw directly with patients or how it affected their treatment in any but general terms since they could not point out features on the images or how they impacted care. In 2019 that same staff member brought a copy of an MRI to a different PT office after they requested it but the office had no way to view physical media and sent it home with the patient sight unseen. They were unable to take the results of the imaging test into account when devising the patient’s treatment plan.

That said, it is our understanding that current PACS systems generally do not offer a general use URL to permit access to an image. Rather, each link is generated after some form of authentication and is tied specifically to the authenticated user. Storing that link in an EHR, data warehouse, or other data store is only useful if it will continue to be used by someone with access to the specific account/credentials used to generate the link. Including the link in any type of data exchange is not helpful unless some mechanism for allowing any legitimate recipient of the link to follow it and view the related image data without authenticating as the original user.

Perhaps it is possible to structure these links so that they generate some type of registration process for additional users, but that is both a barrier and a burden on anyone who legitimately receives the link via valid, permitted data exchanges. Further, without some guidelines requiring the owner of the PACS system to accept registrations from all sorts of entities they may have no direct relationship with, it may not significantly improve access to the image.

Unless possession of the link is sufficient to allow viewing of the associated images, including links to images in allowed data exchanges is not that helpful. We realize imaging results can be quite large so direct exchange of the actual results may not be a great answer either, but if the goal is to provide access to images as a core part of data exchange, it may be necessary, especially if the data flows through multiple organizations before landing with someone who wants to retrieve the link (and therefore may have no relationship at all with the originating organization).

We welcome comment on expanding our CIRI certification requirements to only a limited set of USCDI data classes versus referencing all USCDI.

Participants in our Data Governance Collaborative felt that in made sense to require incorporation of all USCDI data classes and elements.

We propose that Health IT Modules must support the proposed automatic reconciliation and incorporation capabilities on and after January 1, 2028. We welcome comment on this proposed functionality.

Participants in our Data Governance Collaborative appreciate the option to choose which data elements are automatically incorporated and which must be manually reviewed. In other recent comments related to incorporating received data automatically into provider systems, the general consensus of our group was to allow a short time window – perhaps 30 days – for manual decision making and then, if no one has accepted or rejected data it should be automatically incorporated. There was some concern that folks would delay review for a sufficiently long time as to practically automatically reject all external data incorporation.

We suggest that a third option be offered/required which incorporates this “delay then automatically accept after X time” to allow the option to manually adjudicate the status of certain types of data but not allow an indefinite delay. We suggest providing either a set timeframe for X, a maximum timeframe for X, or a set of allowed values for X. We suggest 30 or 45 days as the maximum allowed.

Response to Specific Questions – Electronic Prescribing and Real Time Pharmacy Benefits

This section will list specific questions asked in the Electronic Prescribing and Real Time Pharmacy Benefits section of the proposed rule and our responses to them.

on and after January 1, 2028, a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to perform the following prescription-related electronic transactions in accordance with only the standard specified in § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011)… We welcome comment on this proposed functionality.

We note several issues with the proposals in this portion of the rule.

First of all, this section indicates support for NDC is required. However, the ASTP standard for medications is RxNorm; support for NDC was removed in the HTI-2 proposal. There is a note indicating NDC is required for compounded medications, but if that’s the case then it should be supported as an ASTP standard. Requiring the use of a code set that isn’t adopted as an official standard seems contrary to the whole concept of conforming to standards.

This section also notes that some previously required transactions are no longer required for certification but are required by some CMS use cases and health IT must still support those transactions for those use cases. This seems counter to the idea of certifying health IT modules to ensure they meet the minimum requirements to support the expected use cases for those modules. If those use cases cannot be achieved without certain transactions, those transactions should be part of the certification covering the functionality. We further note that, while these transactions are noted as optional in the text discussions, the table 1-A containing the electronic prescribing transactions lists them as not supported. At a minimum this should be consistent across both appearances of the transactions.

In addition, this section references transactions in passing that are not listed as required or optionally supported in the certification. For example, the notes for PANotification discuss RxChange and RxRenew transactions that are not mentioned anywhere else (there are similar transactions such as RxRenewalRequest/RxRenewalResponse and RxChangeRequest/RxChangeResponse that may have been the intended reference).

we believe that it is appropriate to propose in § 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions…We request comments on this proposal.

Our Data Governance Collaborative is in favor of requiring use of the standards leveraging standardized structured data elements for prescribing instructions in a Signatura.

We invite comments on this proposal and request information on whether there are other SCRIPT transactions that include data fields for race and ethnicity we should consider specifying to enable exchange of race and ethnicity data with providers in pharmacy settings.

Participants in our Data Governance Collaborative feel that it is important to include race and ethnicity information in NewRx requests provided that the transaction supports providing it.

We request comment on these proposals, especially regarding the impact of these proposals on health IT developers seeking to ensure their products meet the Base EHR definition that are not currently separately certified to the “electronic prescribing” criterion.

We believe it makes sense to tie the certification of electronic prescribing and real time pharmacy benefits together to provide a cohesive service to clinicians and their patients, but it would be appropriate to mention this under the discussion of electronic prescribing and not just real time pharmacy benefits.

We also believe it makes sense to require these modules be part of the base EHR definition. Electronic prescribing and the ability to communicate electronically between pharmacies and provider organizations is essential in the current landscape, particularly given how many provider organizations require that refill requests come from pharmacies and not directly from patients. Real time pharmacy benefits will also help ensure patients are prescribed drugs they can afford whenever possible, and that when multiple options are medically appropriate they can choose to try the least expensive option first and only move on to more expensive options if the cheaper options are ineffective. Considering the number of patients having difficulty paying for their medical care and how, for many of them, prescription medication is the most expensive part of their normal care, ensuring access to pricing information in real time seems not just appropriate but necessary. We hope to see real time price transparency for other types of care follow in the near future.

we propose in § 170.315(b)(4)(iii) that scope of the criterion is limited to medications and vaccines covered by a pharmacy benefit. We invite comments on this proposal.

While we understand the impetus to exclude all medical devices, medical supplies, and similar prescribed items from the real time pharmacy benefits requirements, participants in our Data Governance Collaborative feel that, at a minimum, items related to diabetes should be included as part of the ongoing efforts to lower costs for diabetics (we believe there may be other specific common conditions with regular supply needs that might be appropriate for inclusion, but we could not name others).

Most diabetics regularly test their blood sugar at home. This involves the use of either disposable continuous glucose monitors that last a week or two each or the combination of a reusable glucose meter, disposable test strips, and disposable lancets. From the perspective of price transparency issues, the meter/test strips/lancets combination is the more complex scenario and we will focus on it here.

Most clinicians who prescribe such items are aware that most insurance companies only include one or maybe two models of reusable glucose meters on their formularies. They have that conversation with patients and note that the price of meters that aren’t covered is usually under $100 if they do not wish to go through the process of elimination to find a meter that will be covered for them. What is missing entirely from this conversation is the greater expense of the disposable supplies.

Each glucose meter has its own corresponding set of lancets and test strips (some may be used for multiple models from the same manufacturer, but even within a manufacturer there are often a few different sets). The strips, in particular, are expensive and amount to a significantly greater expense for patients over time than anything else, often even including any actual medication taken for diabetes (especially now that the price of insulin has been capped for many patients).

We know a diabetic who pays ~$200/month for test strips that are covered by their insurance (they would be about $400 without the insurance). Their pharmacist believes there are probably other test strips that would be less expensive on their plan, but the $200 strips are needed for the glucose meter they currently use (which was selected because it was the meter that was covered by the same plan and had no associated patient expense). The patient had other meters that would have been perfectly acceptable to their medical team that would incur a one-time expense of $60-80 out of pocket (not counting toward deductibles or out of pocket maximums); some of these would use other test strips that most likely would be cheaper, lowering the patient’s overall cost unless they meet their out of pocket maximum for the year (which this particular person usually does, thanks in large part to the cost of test strips).

The problem is that they have no reasonable way to find out the total expenses associated with using one complete testing system over another because there is no real time benefits checker to tell the patient or clinician the total cost of the complete testing system. Figuring out the cheapest system would require multiple rounds of experimentation involving filling multiple prescriptions for the same class/category of thing which would be onerous, time consuming for both the patient and the clinician, and likely flagged as problematic by the payer. Thus, the one element which can most easily be determined, albeit with the delay and annoyance of trying to fill a prescription, having it denied, then trying the next until one works, is what is currently done.

In addition, diabetics who use insulin often must separately buy needles to inject their insulin and these, too, can be a considerable expense even with insurance. We do not have a current specific story to relay here that would illustrate how much real time pharmacy benefits checks could help patients, but we know that it would.

We can think of few situations where being able to check the cost of pharmacy items at a medical appointment when the options can be discussed between patient and clinician before being prescribed would improve patient care more, simply because of the interdependence of several different prescriptions. While paying for anything outside of insurance coverage when there are covered options is typically galling for patients, it may be the right financial decision for them when all of their related expenses are known and put in front of them for discussion – they can’t know or make that choice without the underlying data. Even just the knowledge of which meters are and are not covered can be a helpful, time and effort saving step of the process for everyone involved over the current guessing system.

Response to Specific Questions – Public Health Data Exchange

This section will list specific questions asked in the Public Health Data Exchange section of the proposed rule and our responses to them.

As such, we request comment on whether the time period to phase out the ELR IG is sufficient, or if there needs to be a longer transitional period where both LRI and ELR are allowed for the purposes of transmitting laboratory results/values to PHAs.

One of the provider participants in our Data Governance Collaborate noted they were uncomfortable with the looseness of some of the requirements in this section as well as the requirement to do so much at once. Perhaps a slightly longer transition period would allay some of those concerns, although it seems the lack of specificity is the larger concern. This was a general reaction to the entire laboratory section and did not call out one particular area or requirement needing more specificity.

We further request comment on whether we should specify the LOI IG standard, or whether we should instead include the functional requirements for the receipt, validation, parsing, and filtering of orders without referencing a specific standard.

We are not familiar with this specific standard but firmly believe that requiring a standard is better than not requiring a standard. That said, we believe optional support for a FHIR IG if an appropriate one exists would also be helpful.

However, we request comment on this approach and on whether we should instead require a Health IT Module certified to this certification criterion to support both the CDA IG and the FHIR reporting bundle and accompanying profiles within the Central Cancer Registry Reporting Content IG for the purpose of cancer registry reporting.

We believe it is okay to adopt an either or both approach at this time, but believe the ultimate goal should be to transition to FHIR whenever FHIR solutions are available. There is significant benefit to the system as a whole when all of the underlying data systems are built expecting the same types of (mostly) structured data. We believe in meeting people where they’re at but encouraging them to move to where they should be over time – this approach would be consistent with that worldview.

That said, since the Cancer Pathology functionality would require FHIR now, it may make sense to move all cancer reporting to FHIR in one fell swoop. We would not be opposed to this choice should it be made.

We propose to maintain in § 170.315(f)(5)(ii) adherence to specific aspects of the HL7 FHIR eCR IG…We welcome comments on this proposal.

We approve of the plan to require use of the FHIR IG.

We have not proposed to include this newer, FHIR-based standard for healthcare survey information at this time, but request feedback on whether it should be an option for health care surveys.

We believe the FHIR IG should be an allowed option, with a goal of requiring FHIR at some point in the future.

As an alternative to the IG proposed above, we propose, and seek comment on, adoption of an interim standards-agnostic functional criterion for electronically transmitting medical and health information from birth certificate reports to PHA

Participants in our Data Governance Collaborate feel very strongly that functional criteria, particularly criteria based on content that’s no longer officially maintained by anyone, is the wrong approach. We believe that a standardized implementation guide using specific structured data is always better than more general options, and in this case, given that a FHIR IG is available for use, its use should be mandated.

we have not proposed to specifically adopt auditable event or audit and disclosure log standards for the proposed certification criterion in § 170.315(f)(9) because the specific audit requirements vary across states, access roles, and use cases. However, we seek comment on the potential applicability of such standards for the proposed PDMP data certification criterion.

We believe that including specific audit requirements is important if making auditing part of the certification requirements. We understand that having different rules across different jurisdictions makes this difficult, but that is going to be the case for many use cases within public health since public health is, in large part, managed on a state-by-state or even locality-by-locality basis.

One solution is to adopt a superset of the various requirements that exist across jurisdictions. Another is to disregard state regulations entirely in terms of certifications given that you are defining national certification standards. Those health IT developers who wish to meet the requirements for specific states should, in theory, be able to do so independent of certification requirements.

We believe the first approach is better if the time and effort needed to develop that criteria is available, but believe the second approach would still be preferable to not imposing any specific requirements for auditability.

Are there additional functional capabilities that would support effective SUD/OUD prevention and treatment that should be considered for a future version of the proposed certification criterion?

We believe it is important to develop a FHIR IG built on top of FHIR r4, US Core, and other applicable FHIR standards. Specifying functional capabilities is better than not specifying anything, but it is not conducive to imposing any real standardization across the industry. This type of standardization is required for true interoperability, especially in cases where care may cross jurisdictional borders and communication with multiple PDMP systems is necessary.

seek comment on patient access as a complement to the proposed updated requirements in § 170.315(f)(1)

We believe patient access to immunization records is important. Patients need this information for a myriad of reasons – school registration, access to older records not readily available via other means, or proof of vaccination during a pandemic to name just a few.

The last time one of our staff members tried to access her vaccination records in the state IIS system here in Massachusetts, the only available option was via a web portal. Individuals are asked to fill out an online form which is then processed (presumably manually, although we do not know this for certain). A few days later, the individual is emailed a link to view their personal records that is only valid for 24 hours. If the patient is unable to look in that timeframe, they need to start the process over.

This access could and should be provided in a variety of better ways. Patients who use portals should have the ability to access their records in their portals if they so choose. Third party apps that provide patients with direct access to their health information, particularly those that collect and collate together data from multiple sources, would benefit from the ability to directly query state IIS systems with the proper consent from the relevant patient. In addition, immunization records were among the early use cases for Smart Health Cards; having a mechanism for individuals to carry around proof of vaccinations in ways that do not reveal other PHI or PII remains a useful option even though pandemic vaccine requirements have mostly been removed.

As far as patient access to update their immunization records, that too would be useful. We do not know the proper procedure for updating records in other states, but here in Massachusetts the designated mechanism for updates – either corrections or the addition of missed vaccines – is to request primary care providers to submit an update. This means the patient and provider must spend already limited encounter time discussing this and recording the necessary information and that someone on their staff must actually do the updates.

One of our staff members undertook this process when one of her Covid booster shots was not recorded in the IIS system. Following the instructions she was given by the public health authorities when she asked how to add the missing vaccine to her record, she requested her primary care provider update the record as part of her next encounter. It took almost 10 minutes of her appointment to explain that she was told they have to do the update and to convey all of the necessary information about the missing immunization. Despite this, the record in the IIS was never updated and is missing to this day. There has to be a better way, and we suggest that way is permitting API access via the patient’s choice of a web app or mobile app – FHIR APIs could enable either.

We understand there may be some concerns about just taking a patient’s word without some paperwork or other proof to back it up. We suggest uploading a scan or photo of a vaccine card, appointment email, encounter note, or other similar documentation be required to accompany patient requests for modifications or additions to the official IIS record.

As a data point, all of our staff members surveyed (an admittedly small sample) have at least one vaccine missing from the Massachusetts IIS system. These vaccines were typically provided at pharmacies or vaccine clinics sponsored by local (town/city level) public health authorities.

We propose functional requirements in § 170.315(f)(21)(iv) to respond to both incoming patient-level and immunization-specific queries from external systems…We welcome comment on these proposals.

Participants in our Data Governance Collaborative thought it made sense to support an automated grab of immunization data for a set cohort of patients on a quarterly (or other regular) schedule. They suggest this should be a required feature that can be turned off by users of certified health IT if they do not wish to use it. There was some mention of the need for PCP offices to always have the most up-to-date immunization data and also for payers to have it to feed their Patient Access, Provider Access, and Payer-to-Payer APIs.

In general, providers should also be able to query the system and get results for the data needed to populate both of the following:

• What vaccinations do the patients I’m seeing tomorrow need?
• Which of my patients are due to receive an X vaccination?

Obviously, this would need to mix a set of rules about vaccination timing with queries to the IIS system (or use of data previously received from the system) to determine whether those patients qualified for a specific vaccine have already received it.

In addition, we had a lengthy discussion of cross-jurisdictional data sharing. We wondered how the systems know if a patient’s vaccination should be reported to an outside jurisdiction such as another state’s IIS system. Does the patient tell the clinician giving them the vaccine? That could be extremely error prone. We eventually suggested a requirement that IIS systems query for patients with addresses within their jurisdiction on some type of periodic basis. We also wondered what happens when someone moves – do they do an IIS change of address that requests all of their existing vaccination data from their previous state?

We do not have all of the answers to these questions, but would like to see discussion and processes for this type of data sharing in the final version of the rule.

We propose to adopt a new criterion for the functional requirement to receive, validate, parse, and filter incoming syndromic surveillance information…We welcome comment on these proposals.

We note that there is commentary around supporting interstate requests but we do not see any actual requirements for it and wonder if this was an unintended oversight. In addition, there appears to be a circular reference where the processing section references the parse and filter section and the parse and filter section references the processing section for details on the specific requirements and thus they are never specified.

Participants in our Data Governance Collaborative suggest that this section should outline specific use cases for syndromic surveillance and make sure the data needed for each is present. Some specific use cases we discussed include:

• Cases of rare diseases suddenly appearing
• Unexpected increases in the occurrence of more common diseases
• Unexpected increases of symptoms that may not yet have a clear diagnosis (we wondered how this one might be tracked, but felt it was important – especially given recent experiences during the pandemic)

We also wondered how probable diagnoses are or should be handled and would like to see this case addressed so some consistency can be applied to it. For a variety of reasons there are instances where probable diagnoses are noted but no definitive diagnosis is ever determined for patients. Because they are not official, definitive diagnoses they are not added to the patient’s problem list but they are part of their record and monitored/further investigated as clinicians deem appropriate.

This could happen because the procedure that would normally be used for a diagnosis was inconclusive or is deemed too risky to perform or because there are two equally likely potential causes for the symptoms and evidence available or because different clinicians disagree about what the proper diagnosis should be or perhaps for other reasons. While not an everyday occurrence, these cases are not rare either and some mechanism to account for them seems appropriate when doing population-level surveillance.

We propose to adopt a certification criterion for health IT for public health that focuses on the receipt, validation, parsing, and filtering of electronic case reports… We welcome comments on these proposals.

We approve of the move to require FHIR for case reporting.

We propose to introduce a functional certification criterion focused on the ability of health IT for public health to receive and validate reported PDMP information, to respond to queries from providers or other PDMP databases and hubs, and to initiate queries to those other PDMP databases and hubs… We welcome comments on these proposals.

Participants in our Data Governance Collaborative wondered why NCPDP standards were not being used for the medication information component of the PDMP databases given that NCPDP is the de facto standard for prescription drug information and exchange.

We also wondered how interstate exchange is supposed to be supported without the use of a standardized IG or at least a set list of required data elements? If each system is allowed to be different, cross-communication will be difficult at best, and likely impossible in any truly automated or programmatic way.

We welcome comment on our proposals for public health information access and our proposals to require support of HL7 FHIR Profiles as specified in the USPHPL IG as the foundation for Health IT Modules certified to § 170.315(g)(20).

We are in favor of requiring use of FHIR for this purpose. We note that ASTP mentions incorporating some elements of USCDI+ for Public Health into the USPHPL IG, but we suggest that an effort to synchronize USCDI+ for Public Health and the USPHPL IG on an ongoing basis may be appropriate (see our comment in the general comments section above for a more general discussion of this type of symbiotic relationship between USCDI+ data sets and relevant FHIR IGs).

Response to Specific Questions – Bulk FHIR

This section will list specific questions asked in the Bulk FHIR section of the proposed rule and our responses to them.

We welcome comment on our proposal to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification.

We believe this is an improvement over v1 and approve of its adoption. Ensuring that _since is required will improve performance of the system and reduce repetitive requests that result in the need to filter out duplicate data once received.

We welcome comment on our proposal to require support for the “_type” parameter for certification.

Participants in our Data Governance Collaborative believe requiring support for the _type parameter is entirely appropriate. By limiting data requests to those resources that are necessary for a particular use case or workflow, the system will be more performant and, likely, less expensive just by virtue of moving less data over the transom and, subsequently, needing to store less data in the receiving system. In addition, if only a small number of resource types are needed, not having to find them in a much larger set of superfluous data will increase efficiency greatly.

We seek input on Bulk FHIR API performance experiences from users in the field and seek comment on any potential performance bases, expectations, thresholds, industry standards, etc. that we could consider in the future for Certified Bulk FHIR APIs as a baseline.  

We believe some mechanism for monitoring performance should be required, and perhaps some basic level of reporting should be adopted (perhaps as a new Insight condition).

Even if not formally reported, we think it would be helpful to develop a standard set of metrics to consistently gauge performance. We also believe it’s important to set reasonable expectations – it will take longer to process 100 records than 10 records and much longer to process 10,000 records than 100 records. Without some baseline performance testing it’s hard to set industry expectations appropriately.

It is also important to clearly communicate how the use of different options will affect performance. The way populations/cohorts are grouped will likely have a significant effect on performance. So will the use of _since and _type (which hopefully will significantly improve performance over systems that do not use them).

We also suggest the adoption of some type of paging system that people can use to pull information in pieces would be appropriate.

We also welcome comment on the latest developments in the Bulk FHIR space, like the early-stage proposals for Bulk FHIR import functionality

While we welcome the development of these features, we suggest that support for individual write operations should be developed, supported, and widely adopted first. Features such as patient corrections via FHIR write have been discussed, considered, and worked on without coming to fruition for several years now. A concerted effort to support a variety of FHIR write/FHIR import would be welcome; we believe this is a higher priority that bulk FHIR import which could and should follow later.

Response to Specific Questions – Modular API Capabilities

This section will list specific questions asked in the Modular API Capabilities section of the proposed rule and our responses to them.

We propose to adopt the CDS Hooks Release 2.0 implementation specification…We request comment on these proposals

We are in favor of supporting modular certification of CDS Hooks and believe that the proposals cover all of the CDS Hooks components related to the prior authorization workflows (we did not evaluate them in terms of other potential use cases, but note such use cases exist and should be considered).

Participants in our Data Governance Collaborative wonder if the name of these criteria should explicitly include CDS Hooks as it may not be intuitively obvious to everyone that Workflow Triggers for Decision Support Interventions means CDS Hooks. Also, while we agree it’s more wide ranging than this, many also associate DSI with AI functionality thanks to the HTI-1 rule and may be confused by trying to figure out how CDS Hooks fit into that landscape.

Participants in our Data Governance Collaborative also note the absence of specific mention of support for resulting actions that do not include launching some type of GUI or application. While this support is implied in the included set of requirements, we note that many people think of CDS Hooks solely as a mechanism for launching some type of helper application based on some sort of triggering action so we feel explicitly calling out this is not a requirement is warranted.

We propose that a Health IT Module presented for certification to § 170.315(j)(22) support the issuance of verifiable health records according to the SMART Health Cards Framework version 1.4.0 standard (SMART Health Cards)…We welcome comment on our proposals.

We are in favor of supporting modular certification of SMART Health Cards and agree that vaccination records are a prime use case, but they are far from the only use case. Participants in our Data Governance Collaborative felt they were given a bit too much emphasis in this certification criterion. Rather, we suggest that this certification be specifically about supporting SMART Health Cards and that vaccine-specific requirements using SMART Health Cards be incorporated into the public health certification criteria portions of this proposed rule.

We seek public comment on the listed US Core resources in § 170.315(j)(23)(v)(B), and we alternately propose to require client servers to support the ability for a client to subscribe to notifications filtered by all, meaning any, USCDI/US Core resources for “category,” “code,” and “subject” data elements where applicable.

While we think it would be better to support any and all USCDI data, we also believe some of the customized filters that are specific to particular types of data/resources are extremely helpful.

We suggest explicitly calling out those data elements where other filters make sense in a list similar to the one currently supplied in the proposed rule followed by a general statement along the lines of “and all other USCDI data/US Core resources filtered by any or all of the category, code, and subject data elements they contain”. We note that there may be data/resources where some other property name serves the same functional purpose as data elements typically tagged with those labels serve. These should be sought out and included in the list of explicitly listed data/resources.

We also note this is a somewhat complex approach and could live with a subset of USCDI/US Core with explicitly listed filters, but we wonder if such a list could somehow be supported by reference even though it’s not maintained by an external organization so that it can be updated without requiring inclusion in new regulation first.

Response to Specific Questions – Patient, Provider, and Payer APIs

This section will list specific questions asked in the Patient, Provider, and Payer APIs section of the proposed rule and our responses to them.

We request comment on our decision to not propose to include imaging links, and whether interested parties believe a requirement to support imaging links, in a manner similar to the proposed requirements for the certification criteria mentioned above, would be appropriate and desirable for the proposed certification criteria in § 170.315(g)(30), (32), and (33).

We respectfully suggest that, while ASTP should act in concert with CMS as much as possible with certification of CMS-mandated FHIR APIs, someone also needs to go first when it comes to adding support for additional features. We note that, in the case of these APIs, it likely will be easier for ASTP to require things that are not (yet) required by CMS since most of the certifications are optional.

That said, as noted in our discussion of image links elsewhere in this response, we question whether image links can successfully be exchanged via API because authentication requirements tied to the original requestor of image access are frequently incorporated into the supplied links. We do not have a proposed solution to this issue, but believe that exchanging a URL which will result in access denied responses (or information not found responses sent because access was denied if that’s their preferred response) is not helpful to anyone. Because of this technical issue, we agree with the decision not to require inclusion of image links.

We propose to adopt “provider access API—client” and “provider access API—server” certification criteria… We request comments on this proposal.

We appreciate having the option to certify payer technology and requirement to certify provider technology for the Provider Access API. However, we do see a major hole in the certification criteria as outlined in this proposed rule.

In order to use this API, providers are required to establish a patient treatment relationship with each patient whose data is being requested by a provider. This requirement is not captured in any way in this certification program.

We understand that CMS did not outline a specific mechanism or requirement around how this relationship is established, but omitting it from the certification because CMS permits flexibility is a problem and greatly reduces the usefulness and effectiveness of certification. Users looking to ensure that a solution they select has been certified against something they need to implement expect that solution to conform to all requirements they need to meet.

ASTP has already established they believe certification can be more specific than the CMS rules covering the same features by requiring the use of specific FHIR implementation guides that are not required by CMS. In order for this certification to have any teeth, you must make a similar choice for patient attribution/showing a treatment relationship exists.

Because CMS does not outline any specific requirements, we suggest ASTP offer several options that an organization can choose among for their certification. At a minimum, though, we think some type of attribution mechanism that a process exists is absolutely required (we do not believe this is sufficient, but it would be a start in the right direction).

To assist with this process, we repeat below our comment to CMS on the patient attribution process from our response to the proposed version of the CMS-0057-P rule:

We believe that out-of-network providers should be able to access the Provider Access API so long as they can meet the requirements for showing they have a treatment relationship with a patient. This standard should be the same for all providers, regardless of network status.

We also believe that the standard of patient relationship should not hinge on a patient having a single appointment on the books with a provider, particularly given that this API is set to opt out rather than opt in. In particular, we are concerned about the ability of patients to get independent second opinions if their second provider has full access to all of the data, treatment notes, comments, opinions, diagnoses, and other data from the original provider. This information will bias the second provider even if they make an attempt at independent evaluation (which not every such provider will do). Another concern with a standard of a single appointment is that the patient and provider do not know if this will be an ongoing relationship or a one time appointment. In the latter case, there is no need for the provider to have access to the patient’s data and, in some circumstances – such as the patient choosing not to return because of an issue or problem with the provider – it would be inappropriate for patient data to be maintained by that provider.

Given that the patient does not have to opt in to this API, we favor some type of model whereby the patient identifies the providers they consider “their providers” – i.e. those providers with a treatment relationship with the patient. Some form of trigger or inquiry could optionally be sent when a new provider is seen, if desired. If this is deemed too onerous or difficult to maintain, we believe a second appointment with the same provider – not the same office, but the same individual clinician – would be a reasonable trigger to indicate a treatment relationship exists. In the interim, the provider could acquire any data specific to the first visit either by virtue of being the ordering clinician, via direct patient request that the data be shared (patient consent form, etc), or by the patient directly sharing data they’ve acquired through other means (Patient Access API, patient portals, health record requests, etc). Once a formal treatment relationship has been established, direct electronic versions of any data acquired via other means would flow and backfill the electronic records at the provider.

Another option would be to open the formal patient attribution mechanism to out of network providers, allowing providers to send payers verified patient lists of the patients they treat. We propose that a second visit still be the threshold for this mechanism (we considered the idea of scheduling a second visit rather than having one, but many providers schedule appointments without patient permission or knowledge with the expectation that the patient can change or cancel it if they wish so having a second appointment scheduled does not convey patient intent to have an ongoing relationship).

We understand there may be cases where a patient wants a new clinician to have a treatment relationship in place immediately and get all of their data ahead of time; this is part of why we favor the “patient identifies who they have a treatment relationship” model. However, when the patient wishes are unknown, we believe in erring on the side of not sharing, per the reasoning outlined above. Once seen, the data cannot be unseen.

As a corollary, we believe it is essential to have a clear mechanism for severing the treatment relationship with a provider. Our Data Governance Collaborative participants agree that this is a necessary component of the rule. Again, ideally this would be patient-driven – patients should have the ability to sever a specific relationship at any time (an alternative to this would be a more granular opt-out process allowing the patient to opt out of sending data to just that provider).. We also believe that a timeout process whereby if a provider isn’t seen within a certain length of time – perhaps 2 or 3 years – the treatment relationship is either automatically severed or, if possible, the payer sends an inquiry to the patient asking if they are still seeing that provider. If they say yes the relationship is retained, no it is severed. While this would not remove data already acquired by the provider, it would prevent them from getting new data the patient doesn’t want them to have.

As noted above, we believe a treatment relationship should be between a patient and a particular clinician, not an entire provider organization. We realize that data sharing among that organization may be automatic and this may be an artificial consideration from the standpoint of data access, but for the purposes of treatment relationship if a patient sees two different clinicians from the same office once each, that should not be considered two visits to the same provider if such counting is a consideration for determining if a treatment relationship exists.

Finally, our Data Governance Collaborative participants believe CMS should directly address the case where requests are coming from a third party, such as a vendor acting on behalf of a provider. How does a vendor show that they have permission to act on behalf of a provider? Can different components of the required information come from different sources – for example, can the provider supply patient opt out information while the vendor handles the actual API requests? Does the vendor need to be part of the provenance information (we vote yes to this)? Are there other considerations when a vendor is handling the provider data access and exchange?

We propose to adopt a “prior authorization API—provider” certification criterion… We also propose to adopt a complementary “prior authorization API—payer” certification criterion…We request comments on this proposal.

Participants in our Data Governance Collaborative believe the provider certification should specifically call out a requirement to support CDS Cards, not just the specific CDS hooks used to trigger the workflow. While technically this is covered by a requirement to conform to the CRD IG, we feel specifically calling it out would be in line with the other specific requirements called out in the certification. Similarly, requiring some type of explicit notification that a PA is or is not needed seems warranted.

Our participants also strongly recommend that certification require support for both light and full DTR rules (that is, that certified health IT be required to support both direct DTR functionality and the use of SMART on FHIR apps).

We also note that some requirements for supporting workflow/functional integration into EHR and other provider technology features seem warranted, including some mechanism for following up on requests while they are pending or to view historical requests for later review and related workflow elements such as assigning responsibility for specific PA requests to specific staff members or other common support tasks.

We also believe some providers will continue to use portals for some time to come. There is no reason why portals could not support the CRD-DTR-PAS API workflows under the covers. However, there has been some discussion in the Da Vinci Burden Reduction working group to consider such use non-conformant with the IGs. We strongly urge ASTP to take the position that APIs used to power portals are conformant with the IGs and permit them to be certified under this program. The main purpose of APIs is to enable standardized communication between two software applications; it should not matter what those two applications are so long as they conform to the API contract and use the APIs to perform the intended actions within the allowed data use parameters. The answer is not to forbid the use of portals, but to encourage portals to use the same APIs that everyone else uses so processing requests from them can happen in exactly the same ways as requests from other sources.

Participants in our Data Governance Collaborative also wondered if it made sense to include certification against a particular X12 ó FHIR mapping, certification for any additional payer-side tooling (such as software used to manage the adjudication process, manage appeals, or the actual PA processing tools), and/or CQL. We note that a general CQL certification should also consider its use in quality measures and digital measure definition.

We also request comment on whether or to what degree existing guidance for the Program, such as the relied upon software policy described above, would address scenarios in which distinct health IT products are used to support different elements of the prior authorization workflow

Participants in our Data Governance Collaborative find the use of the terminology “relied upon software” interesting given that in some cases, particularly that of rules engines, the third party offering the relied upon software is often the beneficiary of significant market power and not someone a typical health IT vendor can place any pressure on to conform to specific needs of a certification.

For this reason, we do wonder if it makes sense to offer two pathways for payer certification – one that certifies the entire solution, and one that certifies a subset of the payer processing. We would suggest organizing 3-4 bundles of functionality that carve out those components that often are serviced by the same handful of vendors (such as rules engines). This would put some pressure on those vendors to obtain certification that other vendors can then rely upon for their own solutions needing to integrate with the rules engines or similar tooling.

we invite comments on alternative approaches to organizing the “prior authorization API” certification criteria.

Participants in our Data Governance Collaborative strongly believe that it makes sense to offer separate certifications for CRD, DTR, and PAS. The industry has seen significant benefit just from the use of CRD APIs and many organizations will be implementing their prior authorization solutions in stages starting with CRD, then adding DTR, and finally supporting PAS. There are vendors in the market that specialize in one of the early steps or in doing all of the processing prior to the actual decision making covered by the PAS IG. These vendors should have the opportunity to separately certify their components.

While one of the benefits of using standardized APIs is that you should be able to pick and choose vendors to support any or all of the components and they should interact smoothly and with full support for all end-to-end functionality as long as each component is fully compliant, we understand there may be some hiccups in the early days including differing interpretations of IGs that may not always be as specific as API specifications require as well as other issues. At the same time, users of prior authorization IT may be new to APIs and not fully trusting in the concepts of plug and play. We therefore suggest that, at least initially, ASTP also support a model that certifies complete solutions composed of components supplied by multiple vendors. Vendors should be allowed to certify their components in conjunction with multiple other vendors offering the pieces they do not (or even as an alternate option to using their solution for everything). For example, if Vendor A offers a CRD solution, they should be able to certify just their solution as compliant with CRD but also certify that the combination of their solution and Vendor B’s products are fully compliant with the CRD-DTR-PAS combination and that the combination of their solution and Vendor C’s products are also fully compliant with the CRD-DTR-PAS combination.

Response to Specific Questions – Information Blocking: Definitions

This section will list specific questions asked in the definitions portion of the Information Blocking section of the proposed rule and our responses to them.

We leveraged the definition of “health information technology” from…We welcome comments on this proposal.

Participants in our Data Governance Collaborative wondered if it made sense to explicitly call out healthcare operations or healthcare workflows in the definition of what constitutes health IT. To extend that thought further, perhaps the end of the currently proposed definition should list a subset of the allowed/expected uses of health IT. Perhaps some variant of the following would be appropriate:

hardware, software, integrated technologies or related licenses, intellectual property, upgrades, or packaged solutions sold as services that are designed for or support the use by health care entities or patients for the electronic creation, maintenance, access, or exchange of health information used for treatment, operations, or other purposes central to healthcare workflows and processes.

We specifically ask if we should add “including health IT for a competitor or potential competitor” at the end of the paragraph

Participants in our Data Governance Collaborative thought adding the text about competitors would be helpful.

We specifically used the term “agreement” instead of “contract” because we recognize that such clauses can also be found in licensing agreements and other agreements that are not typically referred to as a contract.

Participants in our Data Governance Collaborative suggested that using “agreement or contract” made the most sense.

We also ask, more broadly, whether there are other types of agreements that should specifically be identified in the text

Participants in our Data Governance Collaborative had a fulsome conversation about issues surrounding Non-Disclosure Agreements. The entire purpose of an NDA is to limit the sharing of information and many NDAs explicitly prohibit disclosing data provided by the other party to the agreement. There was also some concern that NDAs could include clauses that prohibit someone from complaining about or reporting information blocking practices by a party to the agreement.

We are not lawyers and do not understand the complex interplay of such binding agreements that are often necessary when working across multiple organizations, but it is clear to us that an exploration of how NDAs and information blocking interact is warranted.

Response to Specific Questions – Information Blocking: Privacy Exception

This section will list specific questions asked in the Privacy Exception portion of the Information Blocking section of the proposed rule and our responses to them.

We propose to slightly modify the header of § 171.202(e) for ease of reference to “individual's request not to share EHI…

We welcome comments on this proposal.

We will split our reply into subsections for easier parsing.

Timely documentation requirement

While we recognize that the language is in the currently adopted version of the Individual’s Request Not to Share EHI sub-exception, participants in our Data Governance Collaborative pointed out that the current language requires the actor to document the individual’s request not to share specific EHI in a timely manner which means that an individual can make a request in good faith, be told it will be honored, then find out it was not honored because the actor failed to document it in a timely manner and thus the actor could face information blocking charges for not sharing it.

The individual should not suffer unintended consequences of an actor’s oversight. We believe the proper action in this situation is to provide the information blocking exception protections needed to allow the actor to safely honor the individual request even if an arbitrary deadline to properly document the request is missed. Obviously in this case the formal documentation should be addressed retroactively with a note about the oversight once it comes to light, but this should not open the actor up to claims of information blocking given that it’s the individual who would suffer for it.

Verbal requests

We also had some discussion about the option to allow the actor to document verbal requests and agreement to requests not to share information. On one hand, the practice seems to open the door for bad actors to claim individual requests occurred when they did not in order to limit data sharing. On the other hand, some of our provider participants noted that there may be cases where individuals are making these requests when angry, often when discharging themselves against medical advice, and staff might be fearful of the patient’s actions should they request/require paperwork at that point in time. There needs to be some structure to protect the system from bad actors while simultaneously ensuring staff safety on the front lines of care. We are not certain exactly what that structure should be.

Response to Specific Questions – Information Blocking: Infeasibility Exception

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

Would extending the segmentation condition to situations where a health IT developer has chosen to withhold EHI consistent with the Privacy sub-exception “health IT developer of certified health IT not covered by HIPAA” (§ 171.202(c)) pose too much risk of such developers avoiding individuals' EHI requests by choosing not to develop segmentation capabilities in the health IT they provide their customers who are not HIPAA covered entities? We welcome commenters' thoughts on this question

We believe the industry as a whole is not stepping up to develop and apply robust, granular segmentation or other mechanisms for stating and enforcing granular levels of consent. This is true whether or not HIPAA applies to the entity holding the data or any actor working on their behalf. That the Segmentation condition of the Infeasibility exception is needed for any circumstance is a failure of the industry writ large.

However, we acknowledge the current reality that it is, in fact, necessary to have this condition on the books for now. At the same time, prioritizing and incentivizing the use of structured data that is easily separable and independently taggable with consent conditions that are well understood and obeyed by the larger system or the creation of some other system that permits granular consent that only applies to the specific data it’s meant to act upon rather than incorporated other entangled data is essential.

We do not have any specific suggestions regarding how to incentivize this behavior, only a firm belief that doing so is important.

We solicit comments on these proposals

Participants in our Data Governance Collaborative expressed frustration that they are sometimes met with responses of “it’s in our EHR and therefore we can’t share it because of other data there” when looking to acquire data for which they have a valid business need – they called this a false crutch some organizations lean on and use as a reason not to expend the time it might take to clearly separate discrete data from documents that combine a variety of data together. There was clearly a belief that at least some organizations were not making any real effort to segment data in such a way that maximizes the amount of data that can be shared because they know they can rely on a lack of segmentation to justify not sharing the data.

As noted above, we understand why the Segmentation condition of the Infeasibility exception is needed at the current time, but at least some actors may be using it as a handy excuse. It is not clear how to provide the environment, incentives, and potential penalties to ameliorate this behavior.

An uncontrollable event's impact on a particular actor's systems or operational status may render it infeasible for the actor to receive some requests until a time when restoration or recovery efforts have progressed far enough that the actor's staff are able to access and use the actor's systems… By revising the wording to focus explicitly on the actor receiving the request, we hope the proposed revised wording will make it easier for actors to consider the distinction between requests that can be received and processed using only automated means and requests that require a human to do something—such as log into a system or obtain and open a piece of paper mail—in order for the actor to, in fact, receive the request…We welcome comments on this proposal.

We agree that it makes sense to start the clock for responding to uncontrollable events at the point in time when a request has been accessed or otherwise made available to whomever would normally process that the request was received. However, we question whether it then makes sense to provide a full 10 business days from that point to respond. If an uncontrollable event is underway and impeding normal operations to the extent that the condition is appropriate to invoke, the actor will likely already know that’s the case for any requests prior to the act that precipitates officially receiving the request. In theory, they should be able to respond to requests with a form letter explaining the existence of the uncontrollable event and any other pertinent information. Even if it takes a day or two to write such a letter, it should be feasible to respond within 3 or at most 5 business days. The only limiting factor might be having such an overwhelming number of requests piled up that it is not possible to physically process them in a handful of days. We propose that an extension be offered specific to this case should it occur.

We understand that ASTP may prefer a consistent timeframe for the response across all of the Infeasibility conditions. We respect that notion, but feel in this case that not adding extra time to what may have already been a considerable length of time while waiting for access to pending requests should trump any understandable desire for uniformity. In addition, ASTP has already opened the door to adopting different timeframes for different conditions and we feel this would be an appropriate way to exercise that option.

We also propose in the alternative to enhance the revisions to § 171.204(b) by adopting … a specific maximum timeframe for the § 171.204(b)(2)(i) determination of infeasibility related to § 171.301. Under this additional requirement, the maximum timeframe would be one of the following: three, five, ten, twenty, or thirty business days…We welcome comments on the possible additional requirements proposed above.

Given that the manner used to send requested EHI is effectively a negotiation if the initially proposed manner is not accepted, participants in our Data Governance Collaborative believe it makes sense to place a time limit on each round of negotiation. We believe that allowing either 3 or 5 business days for each round trip communication about the manner is the most sensible approach.

We also believe the final step – the stage at which an actor invokes the Manner Exception Exhausted condition – should most likely conform to the same timeframe as it’s essentially just the last instance of a series of similar decision points.

We note this allows for a fairly lengthy total process if multiple rounds of negotiation are undertaken before the actor gives up on reaching an agreement. That said, as noted above in our comment on uncontrollable events, we understand that ASTP may want to retain a consistent 10 business day timeframe for final responses exercising an exception. We normally applaud consistency, but feel the need to expedite what is likely already a slow process just because of the back and forth nature of the necessary negotiations trumps that in this case.

Response to Specific Questions – Information Blocking: Protecting Access to Care Exception

This section will list specific questions asked in the Protecting Access to Care Exception portion of the Information Blocking section of the proposed rule and our responses to them.

However, we are interested in actors' and other commenters' views on whether these standards might help to reduce potential misunderstanding of § 171.206(a) and what would be necessary for an actor to meet the proposed “good faith belief” standard.

We agree with the requirement of a good faith belief vs belief or honest belief. The provided argument that good faith belief has a clear, consistent, well understood definition is persuasive and the idea that a stated belief meets the threshold unless evidence shows otherwise seems reasonable.

We welcome comment on both of these approaches to the good faith belief requirement where the actor implementing the practice is doing so in relation to EHI maintained on behalf of another actor.

Participants in our Data Governance Collaborative believe a two step approach is appropriate. The first step is a decision on whether to invoke the exception by the actor “owning” the EHI. If that actor decides to invoke the exception, any actor with a BAA or otherwise performing work on behalf of the owning actor should be bound by that decision since they are acting on behalf of that actor.

If the owning actor chooses not to invoke the exception, we believe others with access to the owning actor’s EHI (secondary actors) should be able to make an independent decision that their organization may be at risk of legal action and choose to invoke the exception on their own behalf. We believe this is appropriate because an organization should not be forced to take an action they believe will put them in legal jeopardy because they also believe not taking the action will cause jeopardy. Further, while a finding of information blocking may seem less severe than the type of legal action likely in court cases and other scenarios covered by this exception, information blocking itself is starting to appear as part of the judgement criteria in civil actions that could result in significant financial harm to organizations (this one of many websites outlining one such case: https://www.legalhie.com/lessons-learned-from-real-time-vs-pointclickcare-mind-your-information-blocking-ps-and-qs/)

It is less obvious to us that the secondary actors should be able to make a similar determination on behalf of the patient if the originating/owning actor does not do so. However, we believe it is better to err on behalf of protecting against risk and allowing the secondary actor to make their own good faith decisions in accordance with their own consistently applied criteria.

We seek comment on this potential additional requirement for an actor's practice to satisfy the proposed threshold condition (§ 171.206(a)).

We find the discussion around the increase of fees related to this condition slightly confusing. It is not clear if it is meant to apply to any individual request or only those individual requests that, like the requests from counsel, are specific to an ongoing or potential future action or claim. Further clarification around the allowed fee structure would be helpful.

We welcome comment on all aspects of the proposal for a new Protecting Care Access Exception to the information blocking definition.

We will split our reply into subsections for easier parsing.

Scope of Exception

We applaud the inclusion of the new Protecting Access to Care Exception, but participants in our Data Governance Collaborative feel its scope is too narrow. Rather than specifying that it is only applicable to reproductive healthcare, the threshold should be any lawfully provided healthcare that might put someone at risk of legal action. For example, providing lawful gender affirming care might cause similar issues to providing lawful reproductive healthcare in some jurisdictions, and this exception should be just as applicable in those cases. If additional, as yet unforeseen, similar categories of care emerge they, too, should be covered.

We realize that, to a degree, this exception is provided in parallel to the HIPAA Privacy Rule changes specific to reproductive healthcare, but as noted many times in the proposed rule, information blocking applies to actors not subject to HIPAA and is not specifically restricted to the language or scope of HIPAA and therefore there is no need to always maintain a direct parallel.

Conditions known or likely to lead to reproductive healthcare

In terms of the information potentially covered by this exception, we applaud the thought behind including data about conditions known to lead to the need for reproductive healthcare in many patients. However, our Data Governance Collaborative feel a specific definition or criteria for what qualifies is warranted. Are there specific conditions that would qualify? Does it matter whether the actor invoking the exception is treating that condition? Is it acceptable for them to take the patient’s word that they have the condition if mentioned during a discussion of medical history? Are they expected to confirm the existence of the condition even if that would require testing or other potentially time consuming, expensive, painful, or even possibly risky actions? What if there’s disagreement regarding whether the patient has a relevant condition or not? There are relevant conditions that are most typically diagnoses in adolescence and may not be treated in any way but might be listed on the patient’s list of diagnosed conditions for the rest of their life – does that mean that an actor can choose not to share the list of a patient’s conditions if they cannot successfully suppress that one entry?

Practice could reduce risk threshold

The choice to make the threshold for applicability of the exception that the practice of not sharing data could reduce risk, compared to other choices such as would or likely would or should is interesting. Could only requires a slight chance that it will reduce risk, compared to should or likely will which imply that most of the time it actually will reduce risk or would which indicates it will always reduce risk. Of the possibilities, this is the one that makes it the most likely data will not be shared. In the current landscape, and given the potential consequences of being wrong if evaluating that the risk is acceptable, we approve of this choice. However, we note that is somewhat contrary to normal ASTP (and often CMS and other HHS partners) practice of trying to maximize sharing of data when balancing sharing and some other interest which might inhibit sharing.

Written Policies

We applaud the desire to ensure consistent application of this exception and understand the desire to require a written policy regarding how an organization will apply this exception. However, a written policy on its own may not be sufficient to meet the stated goals. We respectfully suggest if a written policy is expected, some requirements around publication and dissemination of an organizations rules or, alternately, submission to some centralized database available when adjudicating information blocking claims seems warranted. If a policy is not widely known it is difficult to judge if it is being adequately applied. If the policy is only produced after a claim of information blocking is filed, there is no way to determine if that was, in fact, the policy in place at the time the exception was invoked.

We note a similar mechanism for storing/retaining documentation of ad hoc decisions is likely needed as well. We believe the vast majority of organizations are good actors trying to do the best they can in a sometimes complex and difficult to navigate space, but many of information blocking updates in this proposed rule appear to be looking to provide protections against bad actors; we are evaluating some of the proposals with that world view in mind.

Response to Specific Questions – Information Blocking: Requestor Preferences Exception

This section will list specific questions asked in the Requestor Preferences Exception portion of the Information Blocking section of the proposed rule and our responses to them.

We welcome comment on this proposed new exception.

Because ASTP just had a single blanket request for comment, we will split our reply into subsections for easier parsing.

Scope of Exception

We question the applicability of this exception to a case where the actor is specifically sending the information being requested by someone. If information is not being requested and not required to be supplied automatically, then there is nothing to which an exception could or should be applied. The idea that an actor would send extra information that was not requested is problematic on its face (unless required by some regulation or contract, in which case requesting it not be sent may be just as or even more problematic).

Support for Refraining to Follow Normal Automated Processes

In cases where information is automatically provided by default – such as lab results in a portal – we understand this exception’s potential applicability.

However, we question whether the current state of technology allows this level of personalization of which information is and is not being provided to a patient’s portal or some other automated release of information (the situation where it makes sense to use this exception). If the goal is that health IT developers will add functionality to support this in the future once this exception is finalized (if it is finalized), that may be a big lift if such functionality is not required as part of certification programs.

Interplay with Segmentation Condition of the Infeasibility Exception

We also point to the poor availability of granular segmentation of data and request ASTP specifically address how the Segmentation condition of the Infeasibility Exception is meant to apply to these types of requests. If an actor specifically requests that Y be sent and X not be sent and X and Y are inextricably linked in the actor’s data stores, is the proper action here to invoke the Infeasibility Exception to not send Y or the Infeasibility Exception to send X anyway? Should a conversation be required to individually determine which part of the request wins on a case-by-case basis as part of the transparency requirements? Does an actor just decide which is appropriate and include its rationale in the transparency documentation? Some guidance on how this situation should be handled should be included in this exception if adopted in the final rule.

Use of Verbal Instructions with Documentation

Given that portions of this rule fall into the “cover your back” arena, and some of the other adjustments and comments in the information blocking rules fall into “prevent bad actors from doing bad things” we also wonder if verbal communications related to the invocation of this exception accompanied by documentation that the conversation took place should be considered sufficient or if actual written communication should be required even if only as a follow up to verbal communication of the same information to prevent disagreement between what was supposedly said vs what was captured in the documentation of the conversation.

Timeframe

We agree that it’s generally better to provide some timeframe for required actions and, if the HIPAA right to access timeframe is convenient, then we would be okay with it. That said, this timeframe is currently longer than most timeframes granted to invoke exceptions and we wonder if 10 or 15 days might be a better option. However, if part of the concern is determining the technical feasibility of requests prior to documenting them might take some time, we could accept the 30 day timeframe as reasonable.

Response to Specific Questions – Information Blocking: TEFCA Manner Exception

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

should the limitation be expanded to include exchange based on versions of the FHIR standards that are more advanced than those adopted in 45 CFR 170.215 or approved through the 45 CFR 170.405(b)(8) “Standards Version Advancement Process—voluntary updates of certified health IT to newer versions of standards and implementation specifications”?

We believe that the exception should include any versions of FHIR standards that are adopted by ASTP whether in regulation or via the SVAP process. If the requestor asks for an SVAP approved version the actor cannot accommodate, this could be handled via the normal Manner Exception process whereby a different version or alternate mechanism is suggested (which could be via TEFCA).

We believe this question only applies to the actual version of FHIR and not the various implementation guides and other related standards and workflows involved in FHIR use. If that was not the intent, we believe that this exception should cover the use of any FHIR implementation guide built on top of a supported version of FHIR regardless of whether that implementation guide is separately accepted by ASTP as an official standard, who developed it, or how widely it’s used. Again, if the actor cannot accommodate the use of a specifically requested IG, the normal Manner Exception could be used to resolve how the data would be exchanged.

Another option would be to sunset the limitation in § 171.403(c) if all QHINs, Participants and Subparticipants support facilitated FHIR exchange.

We do not believe organizations should be forced to use TEFCA if they do not intend to use TEFCA for that purpose, especially if those organizations have already set up alternate mechanisms for FHIR exchange prior to the full TEFCA support for brokered FHIR.

whether or not the limitation should remain as it is currently.

We believe the exception should be expanded to incorporate any supportable FHIR exchange as noted above. As an aside, the current version limitation as expressed in this proposed rule was not clear to us and may not be widely known across the industry. If the exception is retained as is, some further education or guidance on exactly when it does or does not apply would be helpful (as possible within the constraints of the type of guidance ASTP is allowed to give on information blocking).