FHIR blazes new (and needed) path in healthcare
A new standards framework called Fast Health Interoperability Resources (FHIR) promises to change all of that by creating plug-ins for EHRs without the need for interfaces. FHIR-based APIs, when they’re fully developed, could allow providers to pull discrete data from EHRs other than their own; could enable consumers to use data from their own electronic records in mobile health apps or store it in personal health records; and could expand the capabilities of EHRs by enabling providers to select apps that provide features not present in their EHRs.
The federal government is optimistic about the promise of open APIs such as the one associated with FHIR. In the regulations for Stage 3 of the government’s EHR incentive program, aka “meaningful use,” physicians are required to allow patients to view, download, or transmit their records either through a Web portal or by using an app plugged into their provider’s EHR. The latest certification requirements for EHRs – which vendors must meet to have their products qualified for meaningful use – specify capabilities that require the use of APIs.
But FHIR is still a work in progress, and it may not be an important factor in interoperability for three to five years, according to Mickey Tripathi, CEO of the Massachusetts eHealth Collaborative and director of the Argonaut Project, a coalition of EHR vendors and others that are testing and implementing FHIR.
One reason for this long development period, he says, is the fragmentation of the healthcare industry, which makes it difficult to orchestrate the adoption of new standards. Second, healthcare is more complex and uses many more different kinds of data than other industries, complicating the implementation of standards. Third, he points out, an ecosystem of business and legal conventions must be created before FHIR-based APIs become widespread.
[Related: Health IT glossary]
In the meantime, however, some EHR vendors are racing to build FHIR-enabled products. Both they and outside developers are starting to create plug-in apps. And healthcare providers are getting excited about the potential of FHIR to increase data liquidity and improve the usability of EHRs.
FHIR uses snippets of data known as “resources” to represent clinical domains within EHRs, such as diagnoses and medications, and other clinical entities. These resources can be built on top of standardized data types and are utilized in a Restful API similar to those that app developers already use across the Internet. The Argonaut Project is using another common Internet standard, OAuth, to enable patients and providers to authorize the use of their healthcare data.
Health Level 7 (HL7), the leading standards development organization in health care, has recognized FHIR as a draft standard and has identified 99 FHIR resources. To specify these resources, HL7’s members will have to create profiles for each of them — a long and arduous process. The Argonaut Project decided early on to focus on profiles for 16 resources that represent the common data set used in HL7’s Consolidated Clinical Data Architecture (CCDA).
Argonaut made this decision, Tripathi says, partly because the meaningful use program requires providers to exchange care summaries in the CCDA format. The other reason, he notes, is that 20 FHIR resources cover about 90 percent of everything that happens in health care. These resources are a “close fit” with the meaningful use common data set.
To date, Argonaut’s members have tested profiles for 12 resources, as well as OAuth, and will soon test several more profiles, Tripathi says. Epic and Cerner, two major EHR vendors that belong to Argonaut, are already experimenting with FHIR-based apps. Within a year, he predicts, several EHR companies may start selling such apps to their customers.
FHIR alone cannot give developers all the components they need to write apps for EHRs. It can translate clinical data into objects that apps can use, but an app developer also needs to know the restraints on vocabularies and how the data will be coded, points out Joshua Mandel, M.D., a research scientist in Harvard Medical School’s Department of Biomedical Informatics and a research faculty member at Boston Children’s Hospital. To provide these missing pieces and a graphical user interface, FHIR is being used with an open, standards-based platform known as Substitutable Medical Applications and Reusable Technology (SMART).
“SMART helps to lock down those vocabularies or data profiles,” Mandel explains. “We also provide a security layer that allows a user to approve an app and to launch it within their EHR. We provide some user interface glue so that the app can learn what’s happening around it in the EHR system: for example, what patient is currently being sought in the EHR. We try to provide the whole stack of tools that a developer would need to build a plug-in app.”
Developed by Harvard Medical School and Boston Children’s Hospital, SMART preceded Argonaut, which is using the combined approach known as SMART on FHIR. Members of the SMART collaborative developed the FHIR profiles that Argonaut is now testing and implementing, Mandel says. So, while SMART is not the only user interface that could be melded with the FHIR-based API, it is the one available out of the box.
From the viewpoint of SMART app developers, FHIR is a building block for clinical data. “When a SMART app connects with a SMART on FHIR-enabled server, it asks for data, and that’s how it gets data back. It’s using a FHIR REST API,” Mandel says.
A number of SMART on FHIR apps are displayed on SMART’s website. Some of them are already being used in large healthcare organizations that have built their own FHIR-enabled servers. For example, Duke Medicine in Durham, N.C., and Intermountain Healthcare in Salt Lake City are using a growth chart app with their Epic and Cerner EHRs, respectively, notes Mandel. The Danville, Pa.-based Geisinger Health System, which also has an Epic EHR, has introduced a rheumatology app.
Among the other provider organizations now experimenting with SMART on FHIR, Tripathi adds, are Boston Children’s Hospital, Beth Israel Deaconess Medical Center, and Partners Healthcare, all in Boston, and Hackensack Medical Center in Hackensack, N.J.
The majority of the 33 apps in SMART’s app gallery are designed to help clinicians in their daily work. Some deal with specific situations such as helping doctors treat excessive bilirubin in newborns, calculate a child’s blood pressure percentile, estimate a patient’s 10-year risk of heart attack or stroke, or predict a patient’s likelihood of adhering to prescribed medications. These functions are not normally available in an EHR.
Cerner has created an app that launches a web portal for a health information exchange network within its EHR. Instead of having to leave the EHR, go to the HIE portal, and sign in to find patient information from other providers, a physician can get that data with a single click and without leaving the electronic chart he or she is working in.
Another app from Crimson Care Management, a division of the Advisory Board Co. consulting firm, expands EHR capabilities for care management. Mandel says a lot of care coordination software vendors are interested in using SMART on FHIR.
[Related: Why Electronic Health Records aren't more usable]
Specialists might also use the plug-in technology to customize general-medicine EHRs to their fields without having to use specialty EHRs that lack the advanced features offered by the leading products, Tripathi points out.
Other apps in the SMART gallery suggest the multiplicity of directions for consumer-facing apps. For example, the Duke pillbox app educates patients about the correct dosage and frequency of prescribed medications. Mandel cites another app that helps patients shop for drugs in local pharmacies. A “metabolic meter” app helps patients understand their risk of diabetes, heart attack and stroke.
When SMART on FHIR is widespread enough to serve as the basis for exchanging health information between providers, this might be done in either or both of two ways. In one scenario, hospitals and doctors could use the FHIR API to extract data from the EHRs of other providers, perhaps on a cloud-based platform. Alternatively, patients could use apps to download their own health information to personal health records (PHRs) stored in the cloud. They could then decide which data to share with particular providers, family members, or others.
Experts are divided over which of these scenarios is more likely. Tripathi says that both will occur, but that more information exchange will occur between providers. “It’s the providers who have the immediate clinical and business need to do it every day,” he says.
Most patients today expect their physicians and hospitals to store their data and allow them to access it through a portal, Tripathi says. However, patients with serious chronic diseases are more interested in making sure that their records are shared among providers, he adds.
Mandel agrees that both information-sharing scenarios will occur. The patient-mediated method of data exchange has advantages in terms of data control and privacy, he says. “On the other hand, we’re not going to enable this data liquidity in one fell swoop,” he notes. Initially, he predicts, providers will share patient data only in ways that make business sense to them and will open it up only to apps they trust.