The March 2020 endorsement of HL7® FHIR® R4 by both the CMS and ONC final rules may be the impetus for FHIR to move from a niche application programming interface (API) standard to a common API framework. While FHIR is already showing promise to grow healthcare interoperability, its real value will come when utilization moves beyond a handful of workgroups, EMR suppliers, and niche vendors.
While healthcare waits for an industry-defined data model that’s pragmatic for business-critical analytics and outcomes improvement, FHIR is emerging as a capable candidate, driving the healthcare information exchange industry to consider how their platforms align with FHIR. The potential FHIR use cases in Table 1, below, underscore the following significant interoperability themes moving through the industry, which the CMS and ONC final rules reinforce:
Closed Loop (Results)
Notifications and Alerts
|Quality Measure (QM) Reporting
Library of QMs
Patient Access API (Payers)
SDOH Risk Assessment
Gaps in Care
|Supplemental Clinical Data for Quality Measures
|Systems Integrations (M&A, Partner, Client System)
|Care Coordination Support
Transition of Care
Community Data Sharing
|Chart Review Automation
Coding and Billing
|Provider Directory API
Payer-to-Payer Data Exchange
|CMS and ONC Final Rules
Many organizations will have a FHIR service implemented to meet the federal requirements and succeed in using FHIR to achieve improvements. Complex use cases will require more data from more sources, and FHIR will require not only a broad adoption but a culture of data sharing and outreach to new customers.
Figure 1 illustrates an adoption model in which organizations assume a few complex, high-value FHIR use cases early. Point-to-point projects should expand quickly and simplify processes, such as data acquisition and publishing data from an EMR. Expanding beyond an organization’s IT ecosystem requires that data trading partners have a comparable readiness level. For example, an organization can do great things with FHIR and its acute EMR by embedding applications or data into provider workflows. The EMR approach should succeed, but for a broader provider community in which the EMR mix is diverse, it will require scaling the FHIR solution and the supporting services.
Achieving and sustaining data-driven healthcare improvements with FHIR relies heavily on the technical readiness of the vendor and partner systems, as the vendor community is a partner in this FHIR ecosystem. Acquiring the technology and team member skills to implement and maintain the FHIR solution could be a multiyear effort. Understanding the readiness of data trading partners will allow organizations to select use cases with the highest likelihood of success, grow expertise, and prepare for the more complex use cases.
When selecting a FHIR pathway, a few simple questions inform the strategy:
The United States Core Data for Interoperability (USCDI) standards, a foundation for broader sharing of electronic health information to support patient care, should be the minimum data set. When an organization expands into more complex use cases, additional data and systems contributing to the FHIR strategy grow.
Organizations that target the consumer with their FHIR strategy will need to consider how consumer-generated data fits into the organization’s data strategy. Entities that grow through mergers and acquisitions will need to understand how to include the additional data sets, likely from a different EMR, in the FHIR strategy as well.
EMR users will be the early FHIR adopters, as the EMR vendor community is offering an increasingly robust FHIR service. Even organizations tackling the less complicated use cases, such as closed-loop or embedding applications, can quickly hit the limits of their own systems. Expanding the FHIR solution beyond the EMR requires more effort and understanding around the technology capabilities, the workflow impacts of new partners, and the talent needed to implement and maintain a growing list of API connections.
Critical to those leading their organization’s FHIR initiative is understanding which use cases to implement and whether they have the resources to maintain and scale as FHIR adoption matures. The FHIR implementation strategy is critical to success.
Figure 2 illustrates three common FHIR implementation architectures—loose, hooks, and deep:
If the organization has specific use cases to adopt and has just begun assessing its long-term FHIR strategy, it might look at a solution architected similar to column 1. In this model, team members will learn more about the technology along the way, inform their strategy with experience, and limit the risk and investment until they have defined the strategy and have some expertise.
If an organization has a strategy, resources (both internal and external), and the desire to use FHIR in the platform-as-a-service (PaaS) model (e.g., Amazon Web Services or Microsoft Azure), it will have greater flexibility to determine which use cases to support. The model in column 2 provides managed FHIR services that allow the organization to focus on the use cases and customers, not the technology.
Investment in a FHIR-enabled platform modeled in column 3 (e.g., an EMR, EDW, or a cloud-based data platform) will provide additional advantages, particularly in governance and limiting replication of data for FHIR. FHIR would be one of many capabilities of the data platform, deeply integrated with other services such as a master patient index, terminology services, telemetry, and other platform management services.
The healthcare industry stands to benefit by adopting the FHIR API. Federal compliance pressures may cause some short-term challenges, but organizations can ready themselves with an adoption strategy that looks beyond the initial push for compliance and accommodates complex use cases that require more partners, more connections, and likely more time.
Would you like to learn more about this topic? Here are some articles we suggest:
Would you like to use or share these concepts? Download the presentation highlighting the key main points.