Dynamic Shifts in Regulatory Landscape and Their Impact on Your Organization

The final form of the TEFCA safe harbor is a win for FHIR-based connectivity, while accomplishing its primary objective of promoting TEFCA. It establishes a preference for interoperability through TEFCA when connectivity is viable between active participants but doesn’t eliminate support for FHIR-based interoperability as an independent obligation of Info Blocking Actors. The initial proposal would have eliminated that independent obligation when Info Blocking Actors as responders opted for TEFCA-based connectivity. b.well was one of several voices in the proposed rule’s notice-and-comment period that helped ONC move away from its original proposal.

The ONC’s initial proposal would have been bad for FHIR-based interoperability. It would have allowed Information Blocking Actors to circumvent FHIR-based interoperability requirements outside of the TEFCA framework, and at the same time, allow QHINs to extract economic rents. In effect, it  would have altered TEFCA from being a voluntary framework, forced more information requesters to bear the costs of TEFCA’s legacy interoperability infrastructure, and enabled QHINs to become private sector toll-takers. These conditions would have been especially problematic for consumer-directed health information exchange, which is supposed to be free to requesters offering applications that help consumers build their longitudinal health summary. 

The initial proposal raised vociferous objections by a large number of commenters to the proposed rule. We’re pleased that the final TEFCA safe harbor does away with provisions that would have weakened competition, encouraged consolidation, and stifled the introduction of new and innovative applications and technologies. By preserving TEFCA as a voluntary framework, protecting FHIR-based connectivity as an equally important manner of interoperability, and ensuring that the Info Blocking fees and licensing conditions apply in like measure when connectivity is sought through TEFCA or FHIR-based APIs, the final rule enables more effective information sharing to promote innovation, while protecting the interest of patients.

The current Information Blocking Rule includes an exception that allows an Information Blocking Actor to decline requests for information sharing that are infeasible (the “infeasibility exception”). However, the current rule doesn’t provide clear guardrails about when a response to a request is infeasible.

The updated rule offers new guardrails. In the final rule, which takes effect February 8, 2024, the infeasibility exception can be invoked as long as the Information Blocking Actor offers at least two alternative manners of exchange. One of these manners of exchange must either be a certified API or other FHIR-based API approved by ONC as part of its standards version advancement process. However, the infeasibility exception is not available when the requested manner of access, exchange, or use is already offered by the Information Blocking Actor for a substantial number of individuals or entities that are similarly situated to the requestor.

This updated infeasibility exception reinforces the Cures Act mandate to promote interoperability through open standards. In practical terms, all Information Blocking Actors will be required to support healthcare interoperability through FHIR content and transport standards, and they won’t be able to claim the exception for one requester when the actor already supports a given content and transport method for a similarly situated requester. 

Like the TEFCA safe harbor, this is a big win for interoperability, especially for healthcare providers that aren’t required to support interoperability through certified APIs. In particular, we expect more pharmacies and labs will become cooperative in our efforts to connect with them directly.

USCDI Standard. By Jan 1, 2026, EMR developers must support USCDI v3 in the certified APIs they offer to their customers. FHIR-based APIs on USCDI v1 or v2 will not meet certification standards after December 31, 2025.

Following is a list of data types that are net new compared to USCDI v1. 

• Social Determinants of Health
  • SDOH Assessment (under Assessment and Plan of Treatment data class)
  • SDOH Goals (under the Goals data class)
  • SDOH Interventions (under the Procedures data class)
  • SDOH Problems/Health Concerns (under the Problems data class)
• Care Team Member
  • Name
  • Identifier
  • Role
  • Location
  • Telecom
• Discharge Summary Note (under Clinical Notes data class)
  • Admission Date
  • Discharge Date
  • Discharge Location
  • Discharge Instructions
  • Reasons for Hospitalization
• Clinical Tests
  • Clinical Test
  • Clinical Test Result/Report
• Diagnostics Imaging
  • Diagnostics Imaging Test
  • Diagnostics Imaging Test Report
• Encounter Information
  • Encounter Type
  • Encounter Diagnosis
  • Encounter Time
  • Encounter Location
  • Encounter Disposition
• Health Insurance Information
  • Coverage Status
  • Coverage Type (e.g. Medicare, Commercial, Managed Care – PPO)
  • Relationship to Subscriber
  • Member Identifier
  • Subscriber Identifier
  • Group Identifier, and 
  • Payer Identifier
• Health Status Assessments
  • Disability Status
  • Mental/Cognitive Status
  • Functional Status
  • Pregnancy Status
  • Health Concerns
  • Smoking Status
• Laboratory
  • Specimen Type
  • Result Status
• Medications
  • Dose
  • Dose Unit of Measure
  • Indication
  • Fill Status
• Patient Demographics/Information
  • Sexual Orientation (under Patient Demographics/Information data class)
  • Gender Identity (under Patient Demographics/Information data class)
  • Sex for Clinical Use
  • Current  Address (following the Project @US standard)
  • Previous Address (following the Project @US standard)
  • Related Person’s Name
  • Related Person’s Relationship
  • Date of Death
  • Occupation
  • Occupation Industry
  • Tribal Affiliation
• Problems
  • Date of Diagnosis 
  • Date of Resolution
• Procedures
  •  Reason for Referral
• Unique Device Identifier(s) for a Patient’s Implantable Device(s) (singular data element in same data class)

Over the next two years, more EMR vendors will implement updates to their certified health IT, which will broaden access, exchange, and use of the new data elements in USCDI v.3, compared to USCDI v.1. These new data elements will support more personalization in the health journeys on the b.well platform. 

For example, with the Health Insurance Information data elements, users could be prompted to establish health data connections with health plans identified in their connections with clinical APIs, saving a couple of search steps. Also, when payer and coverage data is known, and combined with risk factors revealed in health status assessments (HSAs) and social determinants of health (SDOH) data, the platform would be better equipped to deliver and measure clinical and non-clinical interventions.

Consider the case of a user with asthma that receives benefits through a Medicaid Managed Care Organization and has concerns about mold in their home. Through the b.well platform and integrated care partnerships, a customer would be able to offer solutions digitally (like a smart inhaler or in-home air filtration system) to improve health outcomes and determine whether the intervention helps reduce avoidable Emergency Department visits or hospital admissions.

By Jan 1, 2026, certified APIs must conform to the C-CDA Companion Guide 4.1, and corresponding code sets in SNOMED CT; the FHIR US Core Implementation Guide version 6.1.0 and the SMART App Launch Guide version 2.0.0 for the latest FHIR API capabilities. These are technical updates that will lift Certified APIs to more mature industry standards.

Certified APIs will also be required to support short-lived access tokens (up to 1 hour). The purpose is to improve information security and support timely action on patient revocation requests.

Over the next two years, EMR vendors will update their certified APIs to the new standards. While the impact won’t be readily apparent to b.well customers, the updated APIs will standardize connections, which will help b.well streamline more of its existing platform services, which should improve operational performance and efficiencies over time.

The updated standard will set a de facto standard to support partner integrations on the b.well platform, which will support scaling of the app-based, patient-centered ecosystems that b.well builds with and for its customers.

Requirement.  No later than December 31, 2024, developers of certified APIs must follow FHIR R4 data formats when they publish service base URL (using the FHIR R4 “Endpoint” resource) and publish details about each healthcare organization associated with a given endpoint (using the FHIR R4 “Organization” resource). They must also publish this information together as a “bundle” (using the FHIR R4 “bundle” resource).  

No later than December 31, 2024, developers of Certified APIs must begin quarterly review of this information for accuracy, and update as needed.   

These requirements apply for all of a Certified API Developer’s customers, and not just for customers whose certified API technology is centrally managed. Developers of certified APIs that publish out of date, incomplete or otherwise unusable information about these service base URLs and organization details for more than 90 days  will be considered in violation under the Certification Program, which could lead to corrective action or other remedies under ONC’s program authority.

Most people think of interoperability through technical and data standards, but the ability to build a scalable interoperable ecosystem is also influenced by the quality and enforcement of operational standards. The new publishing standards for service base URLs is an example of ONC adding operational standards that should help b.well and our customers in our efforts to develop a connected, app-based ecosystem for patients and a reimagined healthcare experience.

Even though developers of certified APIs are currently required to publish service base URLs for all their customers in a machine readable format, publicly and free of charge, the lack of data formatting standards has led to wildly inconsistent approaches. Organization details are sometimes published in text strings and are either incomplete or contain errors. Sometimes, developers of certified APIs don’t provide the service base URLs for customers whose API endpoints are managed locally rather than by the certified API developer.  

App developers like b.well must accommodate inconsistent approaches through more complex mapping schema and manual processing. Further, the ability of patients to easily search for provider data they want to connect can be negatively impacted whenever details about an organization are incomplete, out-of-date, or not in easily computable form. The final rule goes a long way towards alleviating these problems. As a result, we should see operational and performance improvements in b.well’s access to health data experience over the course of the next two years. 

Notably, ONC sets December 31, 2024, as the deadline for these publishing standards to be implemented. This is a full year before developers of certified Health IT technologies must implement other updates to the ONC’s certification program. This signals an urgency to fix an operational problem that will be of great benefit for the patient experience and will enable app developers to streamline their operations. We’re pleased to have been part of the community that informed the ONC about the benefits of adding operational standards to its certification program.

In the sub-regulatory commentary published with the final rule, ONC explained that developers of certified health IT would not be required to test every release and update to their certified APIs. But, recognizing the variability in performance of these releases in real world production environments, ONC has committed to making enhancements to Inferno, an open source test bed for FHIR-based connections. The objective is to encourage app developers connecting to certified API endpoints to participate in open source testing and report their real world results, which allow bugs to be validated, reported, and prioritized in a more transparent manner. See https://github.com/onc-healthit/inferno-program

While the ONC did not impose more real-world testing requirements on vendors of certified APIs, ONC’s sub-regulatory solution is a constructive step towards improving FHIR-based interoperability by surfacing bad results as “bugs” that get reported to the developers of certified APIs through a crowdsourcing mechanism, leveraging the feedback of app developers connecting to these API endpoints. This approach will attract more transparency, especially when multiple developers report similar results for a given API endpoint. We expect this approach will incentivize developers of certified APIs to prioritize fixes to certified APIs faster, to avoid being out of compliance with conditions of certification.

While improvements may be incremental, ONC’s decision to crowdsource real world testing offers an innovative approach that should improve conformance of FHIR-based APIs to published and regulatory standards, which supports the ongoing maturity of an app-based connected health ecosystem. A key dependency will be ONC’s timeline and specifications for updating the Inferno test bed. b.well is working through CARIN Alliance and other communities to help ONC define and offer feedback with these planned enhancements, as illustrated in the Best Practice Recommendations for HL7  FHIR Based Deployment published in December 2023 by the CARIN Alliance.

By January 1, 2026, EMR Developers must support an internet-based method for patients to request restrictions on their health data use and sharing. ONC declined to specify further technical standards for implementing this requirement.

Over the next two years, EMR vendors will select different methods for patients to request restrictions on the use and sharing of their health data. Operationally, these requests will need to be supported at patient access APIs within one hour through token revocation standards. Ideally, we would like to see EMR vendors support for patient-requested restrictions at their certified patient access API endpoints, both proactively by giving patients choice in the health data they wish to share with third party applications, and by giving them an ability to revoke access through an application by revoking a connection becomes interoperable under USCDI v3. However, without a technical specification, we can expect variability, especially from smaller EMR vendors, in how they choose to support patient-requested restrictions through certified APIs. Some of these approaches may frustrate consumer expectations.

Since interoperability through TEFCA is live, the more pressing concern is that EMRs will block all interoperability, even from patients that request access for themselves through their choice of application. This is an area of attention that we expect to follow closely, to ensure patients can continue to exercise their rights of access under HIPAA.

By January 1, 2026, EMR Developers must start collecting data that supports annual reporting on measures of interoperability. The first metrics must be reported by July 1, 2027. These measures relate to individuals’ access to EHI, public health information exchange, clinical care information exchange, and standards adoption and conformance activities.

For individual access, the insights establish important quantitative benchmarking to measure the emergence and ongoing maturity of an app-driven interoperability ecosystem. Reporting will be supported at the service base URL level, meaning that it will be possible to know the number of apps that connect to individual organizations, who the intended users of these apps are, what their intended purposes are, and the kinds of FHIR resources that patients are requesting.

Starting January 1, 2025, developers of Health IT Modules certified to the decision support intervention criterion will be required to affirm whether patient demographic, SDOH, or health assessment data are used in DSIs. They will also be required to finalize policies that: (1) establish a definition for algorithm-based and model based “predictive” DSIs; (2) require Health IT Modules certified to the DSI criterion to enable users to access information about the design, development, training, and evaluation of Predictive DSIs, including descriptions of training data and information on whether the Predictive DSI was tested and evaluated for fairness; (3) require developers of certified health IT to apply risk management practices for all Predictive DSIs that are supplied by the developer of certified health IT as part of its Health IT Module; and (4) make summary information regarding these practices available publicly.

The b.well platform sits outside the system of record where predictive decision support interventions might be used at the point of care in treatment decisions. For this reason, the timelines and requirements that improve algorithmic transparency in Health IT Modules presented for certification are not applicable to the workflows enabled by the b.well platform.

Even so, the requirements for building algorithmic transparency in predictive decision support interventions at the point of care set a de facto standard that will support health equity and fairness over time. We are committed to these principles and will be evaluating opportunities to voluntarily support algorithmic transparency to customers in relevant areas of the platform. These opportunities will present themselves organically as more patient demographic, SDOH, and health assessment data becomes available at APIs that support interoperability consistent with USCDI v3 standards.

ONC requested input for a Congressionally mandated study to improve standards for electronic lab test ordering and reporting of results, and improve interoperability. While ONC did not provide a summary of information received, the RFI creates an expectation that lab data interoperability will be an area of increasing focus for communities that advance health interoperability standards under the ONC’s informal and formal convening authority.

ONC requested input on how developers of certified health IT may be able to support drug price transparency and patient choice through real-time benefit tools, while ensuring reliable and trusted performance. While ONC did not provide a summary of information received, the RFI creates an expectation that drug price transparency will be an area of increasing focus for communities that advance health interoperability standards under the ONC’s informal and formal convening authority.

ONC requested input about several extensions of the FHIR API standard, including FHIR Subscriptions, CDS Hooks, FHIR standards for scheduling, and SMART Health Links. These standards are used today to streamline API call transactions, increase real-time read and write functionality, and enable more personalized experiences.  b.well uses these standards on our platform already, but they are not required features of certified APIs.

While ONC did not provide a summary of information received, the RFI creates an expectation that ONC will expand FHIR API certification standards to support use cases beyond data access.  That development is consistent with broader aims of enabling an increasingly connected app-based health ecosystem, to drive value and address administrative burdens.