Quashing Myths That Obstruct Implementation of FHIR APIs

By Vanessa Candelora, Senior Consultant 

The federal government and many stakeholders are looking to accelerate interoperability as well as improve the capture and exchange of patient and administrative data. One answer: application programming interfaces (APIs) based on HL7’s Fast Healthcare Interoperability Resources (FHIR) standard. 

Yet despite the considerable progress — and expense — that has been invested in driving adoption, uptake by payers and providers is surprisingly low. In fact, a recent study found that only 24% of leading health care organizations currently use APIs.

So, what’s behind the holdup? We believe it’s the prevalence of four myths surrounding FHIR-based APIs. Let’s take a deeper dive.

Myth 1: FHIR is not ready for prime time. What started out as a spark in 2014 has turned into a raging FHIR in 2021. Its use has allowed stakeholders and developers to hit the ground running with a wide range of applications that address a variety of needs. But the speed at which FHIR spread throughout the health care scene caused many to think it was just the latest shiny object in the glacially paced world of health information technology (health IT) standards. Many 

thought, “Why invest in a potentially immature standard that could be the latest flash in the pan?”

Reality: The reality is that FHIR is here to stay. All the players needed for an industry shift are finally at the table and participating in not just adoption, but development of the standards. On the business side, organizations are making sure these standards are part of their overall strategy. As the standard has matured, several drivers have quickly cemented its place in the health care ecosystem. They include:

• Regulations and policy levers. Regulations and policy levers are drivers for adoption. Two federal regulations that recently went into effect are a case in point. The Interoperability and Patient Access final rule from the Centers for Medicare and Medicaid Services (CMS) requires applicable payers to implement APIs based on FHIR 4.0. The final rulefrom the Office of the National Coordinator for Health Information Technology (ONC) calls on medical providers and device developers to promote patient data access using third-party applications and APIs with FHIR as the foundational standard. 

Implementation timelines are short with these rules and hefty fines are possible for noncompliance. In addition, other regulations are sure to be on the way, including a final rule for electronic prior authorization. In short, payers and providers should not bury their heads in the sand; additional FHIR-based mandates are guaranteed to come along through legislation and regulation.

In addition, ONC has named FHIR as a key element in its 2020-2025 Federal Health IT Strategic Plan.

• Value-based care. As value-based care arrangements grow, data accessed and shared via FHIR will be essential to making the process work. Policy, regulations, and realities of responding to economic demands will be the fulcrum to assist with the heavy lift of moving from fee-for-service to value-based care. Public and private payers will reward and penalize providers based on care outcomes and costs.
• Adoption by Big Tech. It speaks volumes that Big Tech — Apple, Google, Amazon, and Microsoft — have adopted FHIR for data exchange in their health care offerings. They weren’t forced to adopt FHIR, but developers found that the standard offers many relevant capabilities compared with other standards. Big Tech will pull FHIR adoption along with their entry into the health care space, bringing other stakeholders along with them.

Myth 2: FHIR APIs are less secure than current electronic and paper methods.

Hardly a week goes by without the media reporting on yet another health care data breach or ransomware attack. It’s no wonder that privacy and security concerns are among the adoption barriers to FHIR-based APIs. Some stakeholders find it hard to believe that these newcomer technologies can offer better protection than traditional methods that have been around for years.

Reality: To be sure, there are security concerns around ANY method for accessing and exchanging health care data. Health care entities must keep up to date and exercise due diligence when it comes to protecting their data. But if truth be told, FHIR-based APIs are oftentimes more secure and accountable than conventional methods — even paper. Here’s why:

• Health care traditionally has moved massive amounts of patient information and claims data through large batch files. The size of these files inherently puts patient privacy at risk — not to mention that their reliance on manual processes increases opportunities for error.
• Patient portals can provide easy access to all records. All it takes is a hacker who’s guessed one PIN or password, which are notoriously easy to figure out. This can undoubtedly lead to the exposure of everyone’s personal and financial information.
• Even paper records and faxes can pose risks, despite the requirements of the Health Insurance Portability and Accountability Act of 1996 Security Rule. For example, the flow of paper-based personal health information among endpoints is not always traceable or secure. This potentially puts the information in easy grasp of prying eyes.

In contrast, APIs can securely control access to their systems and data. Since APIs are in the middle of requests and data, additional security can be enabled. Making discrete information available on a just-in-time basis minimizes exposure of the entire patient file or health care system.

• Many applications using APIs rely on the cloud for data exchange and storage. As one analysis noted, a “cloud-based API can leverage all the comprehensive services for security that already exist in the cloud. Leveraging a cloud provider for securing an on-demand API is an established method. Management of identity, security, encryption, and compliance are all services offered by the major cloud providers. These capabilities are mature, comprehensive, HIPAA compliant, configurable, and embedded in API services. If needed, they can be integrated with on-premises systems.”
• Many APIs provide additional levels of security and privacy by using well-established industry standards for authentication and authorization, such as OpenID Connect and OAuth 2.0. These are among the protective measures used by some social media platforms to help guard a user’s identity and data. SMART (Substitutable Medical Applications and Reusable Technologies) adds a layer of security in front of FHIR interfaces. This enables safe access to data in an electronic health record or any other data repository.
• Finally, APIs have tools for monitoring data streams that enhance security by making patterns and fraud easier to spot. Credit card companies have adopted them. As a result, consumers may get almost immediate notification when potentially fraudulent activities have taken place on their account.

Myth 3: Implementation is expensive, burdensome, and just another “tech project.”

Health care decision makers may not be paying much attention to APIs, which many consider to be “just a tech project” and another expense to manage. Some may think they should just do the bare minimum to be compliant with federal mandates.

Reality: While there is expense and effort involved in implementing FHIR-based APIs, it should be an extension of what the company is already doing. Those focused on the bare minimum for compliance are missing the boat on new opportunities when implementing FHIR-based APIs.

For example, APIs can bridge the gap between legacy systems and new technologies.

• They can create a quick and relatively inexpensive way to transfer data from huge onsite systems to various internal and external endpoints. This will go a long way toward meeting regulatory requirements (current and future), business needs and customer demands.
• FHIR-based APIs also can help payers and providers keep up with the growing volume of data requests. They increasingly are being asked to share data with other health care entities and consumers. Proprietary APIs may not be interoperable with requestors’ systems.
• Moreover, health care entities may be missing real competitive and economic advantages by a “check box,” piecemeal implementation process and just using FHIR where it is legally required.

FHIR-based APIs can be a market differentiator, which is a necessity in an increasingly competitive environment. For example, they are a key component of the growing and interconnected world of virtual health care, including telehealth, specialty care and personal diagnosis and monitoring.

Health care entities run the risk of losing market share and reimbursements if they don’t build FHIR-based APIs into their strategic and operational planning. And better patient management of their health care through APIs leads to improved outcomes and lower costs.

Myth 4: There is no patient demand for their data. They were given patient portals to access their data and didn’t use them.

Patient demands concerning their health care data are part of the growing trend of consumerism, which is one of the biggest and most transformative in the industry. Consumer-facing APIs, which are FHIR-based, are at the heart of this trend. Many believe that consumerism and the use of patient-facing tools are permanent features of the evolving health care landscape. Already, social media is targeting individual consumers to take control of their aggregated health data.

Patients are not only at the heart of the consumerism, but they are also health care’s customers. As such, they need to be consulted and their needs and preferences need to be considered — not only in what data are accessed and shared, but also how that happens. A successful API can’t be built without that basic knowledge.

Consumerism also is important because consumers are gaining input on how payers and providers are being evaluated. For example, the consumer experience is a growing reimbursement metric. Moreover, patients want their health care experience to be easier, more transparent and electronic — such as they have been accustomed to with banking, travel, and online shopping. Patients want to track and manage their health care outside of the doctor’s office on their smartphone or computer, and that increasingly is being facilitated by FHIR-based APIs.

Finally, consumerism will have a direct effect on patient/member retention, which will become a growing cause for concern among providers and payers. One study found that two-thirds of consumers revealed they will consider changing their physician and hospital providers in the coming year after learning how their health record was not shareable, available or was blocked in the past year. As consumers become more aware, many will understand that they can vote with their feet and dollars.

In short, APIs are putting economic purchasing power — and decision making — in the hands of consumers. They enable patients to compare services and costs among health care providers and payers as well as facilitate bringing their information with them if they do make a switch. Giving patients access to their data will change the dynamic, creating a more collaborative relationship between patients and providers while empowering them to manage their own care.

Conclusion.  FHIR-based APIs are a growing part of the health care ecosystem and an integral part of achieving real interoperability. Point-of-Care Partners is uniquely positioned to provide insights and guidance on this transition. We co-manage the Da Vinci Project, a FHIR-based accelerator aimed at using FHIR to promote payer-to-payer data exchange in value-based care. Our consultants are heavily involved in other FHIR HL7 accelerators, standards development organizations and industry organizations focusing on data sharing within and across stakeholder groups. These include the CARIN Alliance, ONC FHIR at Scale Taskforce (FAST) and CodeX. We’d be happy to discuss our knowledge and capabilities and how they can be help your organization. Reach out to us at vanessa.candelora@pocp.com and teresa.younkin@pocp.com.