With a certification deadline looming, EHR vendors and healthcare providers should look to 3rd-party applications that meet the promise of secure and effective data-sharing
By the end of April, only two major electronic health records vendors had achieved full certification under the 2015 Edition Meaningful Use Stage 3 criteria and the Advancing Care Information (ACI) program established by the Medicare Access and CHIP Reauthorization Act, according to the Office of the National Coordinator. For the hundreds of other EHR vendors listed in the ONC database, the Jan. 1, 2018, deadline for certification is likely to be a significant challenge, a situation that ought to serve as a wakeup call for hospitals and physicians hoping to avoid Stage 3/ACI payment penalties.
Underpinning most of the goals and metrics of Stage 3 is the long-sought and elusive dream of interoperability. You cannot meet population health objectives such as providing patients with electronic access to their health information, protecting patient-level data and coordinating care through patient engagement if you do not have robust and secure means of communicating among disparate information systems from multiple vendors. New value-based care initiatives, accountable care organizations and bundled payment arrangements demand access to patient records across the continuum of care, enabling functions such as a single, uniform view of all patient records; centralized scheduling; care management protocols; and quality measurement.
Given the nature of the challenge ahead this year, the time is now to follow the direction of the ONC and the Centers for Medicare and Medicaid Services. In looking to set a foundation for an interoperable health IT infrastructure, the agencies mandated that EHRs be capable of open application programming interfaces (open APIs) and underscored the advantages of the hottest trend in health IT circles today, Fast Health Interoperability Resource (FHIR – pronounced “fire”) in establishing that foundation. This vision of the open API would allow a patient to use a single app to retrieve medical records from any hospital, lab, insurance company or physician office simply by obtaining the secure URL for that service’s open API and providing required authentication, truly placing the patient in control of their own health information.
As Obama-era CMS Acting Administrator Andy Slavitt put it during the rulemaking phase for MU Stage 3 in 2015: “The burden needs to be on the technology, not the user. EHR vendors and hospitals that use them will now be required to open their APIs — so data can move in and out of an application safely and securely — and technology can become plug and play.”
Then came the 21st Century Cures Act, passed by Congress in December 2016, which states that any certified vendor must not “take any action that may inhibit the appropriate exchange, access and use of electronic health information” and must develop APIs or other technologies to enable the application to be “accessed, exchanged and used without special effort.” Vendors that are found to be blocking information are subject to penalties of as much as $1 million per violation.
What it all means
APIs are sets of requirements that govern how applications communicate and interact with one another. An open API is an interface that provides developers with programmatic access to a proprietary software application. The FHIR standard, created by Health Level Seven International (HL7), describes data formats and elements (known as “resources”) and an API for exchanging electronic health records. Open APIs interconnect any healthcare system, doctor, patient or medical device by normalizing all incoming requests and data as appropriate FHIR resources.
FHIR is appealing because it is based on a truly modern web services approach that makes it easier for systems to exchange very specific, well-defined pieces of information such as a medication list, a problem list or lab results, rather than entire documents.
The Drummond Group, a certification body for Meaningful Use authorized by the ONC, has more than 200 EHRs registered to go through its testing process this year. “While the FHIR standard itself is not mandated, the ONC has made it clear this is the direction they are going, and, indeed, we have yet to see an application that isn’t FHIR,” said Sonia Galvan, director of EHR testing for Drummond.
An open API using FHIR standards can be described as a new and exclusive “front door” to an EHR, eventually replacing hundreds of point-to-point connections with hospitals, doctors, billers, registries, labs and data clearinghouses that are currently used to connect, but at a high cost in dollars and labor time – a physician might spend 15 minutes logging in from outside a firewall for a single patient record. Health information exchange using HL7 links requires a separate point-to-point connection for each location or system utilizing a dedicated Virtual Private Network (VPN) connection. Some hospitals have 100 or more of these connections. And HL7 connections cannot be used to share information with patients. Even those entities that moved to a web services strategy with their EHR vendor for connectivity would experience additional benefits with an open API approach, especially by implementing a standard protocol like FHIR.
The open API in the real world
Following the release of the Meaningful Use Stage 3 Final Rule in October 2015, a health IT firm, Carefluence, realized many vendors might not be ready for the financial and resource challenges of implementing an open API, so it began to produce a low-risk, plug-and-play solution, which can be licensed as a modular solution for ONC certification. Even with the company’s extensive healthcare IT background, the solution took more than a year to build, in part because the standards being put out by the federal government were growing along with software development, but also because an open API, designed to the standards set by the ONC, can be a challenge even to the well-initiated. A vendor, even one with the most able team, would need at least six months to develop its own open API. Given that there are now fewer than eight months until the Stage 3 certification deadline, that is especially problematic. (In June 2016 Drummond made Carefluence’s modular Open API software platform the first to be certified by the ONC for health IT.)
“An EMR vendor doing its own API is probably the least common criterion we have seen,” Galvan said. “That is either the criterion they are leaving last to develop or they will be using a third-party application.”
Given the modular nature of certification in Stage 3 – meaning a vendor can certify for one or many modules of an interoperable EMR – many vendors may not fully understand that there are options to meet the requirements of an open API through software that can be deployed alongside their existing systems to make them Meaningful Use-compliant, avoiding the costly internal development of a custom open solution. Hospitals and medical groups not willing to risk waiting for their IT vendors to act can also use this solution to avoid the disruptions and costs of EHR software upgrades, not to mention significant loss of revenue from penalties.
The ONC has never been more direct about enforcing that EHRs vendors and all healthcare providers act now to ensure electronic access to patient records, and that the strategy of delaying and waiting for a perfect standard to emerge will no longer be tolerated. FHIR has emerged as the clear de facto standard for open APIs, and there are deployments in the market that are working effectively. Will the standards evolve? Certainly. And yet that is no excuse to sit on the sidelines when patients are demanding greater access to their electronic records, and thousands of apps, disease and drug registries, managed care entities, and individual clinicians will depend on this electronic access to optimize patient care and promote healthy behaviors.
In the short term, modular open APIs will give EHR vendors a much faster and easier route to 2015 Edition certification for Meaningful Use. In the long term, they will facilitate interoperability and reduce costs for accessing, analyzing and using data to improve care, becoming one of the pillars on which we can build a better healthcare system.
Adam Boris is a veteran healthcare technology executive and a partner with TechCXO, a strategic advisory and professional services firm.
The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of Becker's Hospital Review/Becker's Healthcare. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.