The healthcare industry yearns desperately to find the key to interoperability among disparate electronic health record (EHR) systems. Physicians need the capability to exchange health information easily to improve care coordination, which could lead to better patient outcomes and possibly lower costs. But the current methods used to exchange data have fallen short. Health information exchange networks have not spread widely, and a method of secure messaging that uses Internet protocols has not yet caught on with a critical mass of providers. Even when physicians do exchange information, it is usually in the form of PDF care summaries.\u00a0\nA 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\u2019re 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.\u00a0\nThe 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\u2019s EHR incentive program, aka \u201cmeaningful use,\u201d 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\u2019s EHR. The latest certification requirements for EHRs \u2013 which vendors must meet to have their products qualified for meaningful use \u2013 specify capabilities that require the use of APIs.\u00a0\nBut FHIR is still a work in progress, and it may not be an important factor in interoperability for three to five years, according to Micky 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.\u00a0\nOne 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.\u00a0\n[Related: Health IT glossary]\u00a0\nIn 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.\u00a0\nFHIR resources\nFHIR uses snippets of data known as \u201cresources\u201d 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.\u00a0\nHealth 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\u2019s members will have to create profiles for each of them \u2014 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\u2019s Consolidated Clinical Data Architecture (CCDA).\u00a0\nArgonaut 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 \u201cclose fit\u201d with the meaningful use common data set.\u00a0\nTo date, Argonaut\u2019s 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.\u00a0\nSMART on FHIR\nFHIR 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\u2019s Department of Biomedical Informatics and a research faculty member at Boston Children\u2019s 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).\u00a0\n\u201cSMART helps to lock down those vocabularies or data profiles,\u201d Mandel explains. \u201cWe 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\u2019s 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.\u201d\u00a0\nDeveloped by Harvard Medical School and Boston Children\u2019s 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.\u00a0\nFrom the viewpoint of SMART app developers, FHIR is a building block for clinical data. \u201cWhen a SMART app connects with a SMART on FHIR-enabled server, it asks for data, and that\u2019s how it gets data back. It\u2019s using a FHIR REST API,\u201d Mandel says.\u00a0\nA number of SMART on FHIR apps are displayed on SMART\u2019s 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.\u00a0\nAmong the other provider organizations now experimenting with SMART on FHIR, Tripathi adds, are Boston Children\u2019s Hospital, Beth Israel Deaconess Medical Center, and Partners Healthcare, all in Boston, and Hackensack Medical Center in Hackensack, N.J.\u00a0\nProvider- and consumer-facing apps\nThe majority of the 33 apps in SMART\u2019s 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\u2019s blood pressure percentile, estimate a patient\u2019s 10-year risk of heart attack or stroke, or predict a patient\u2019s likelihood of adhering to prescribed medications. These functions are not normally available in an EHR.\u00a0\nCerner 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.\u00a0\nAnother 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.\u00a0\n[Related: Why Electronic Health Records aren't more usable]\u00a0\nSpecialists 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.\u00a0\nOther 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 \u201cmetabolic meter\u201d app helps patients understand their risk of diabetes, heart attack and stroke.\u00a0\nWhither interoperability?\nWhen 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.\u00a0\nExperts 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. \u201cIt\u2019s the providers who have the immediate clinical and business need to do it every day,\u201d he says.\u00a0\nMost 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.\u00a0\nMandel 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. \u201cOn the other hand, we\u2019re not going to enable this data liquidity in one fell swoop,\u201d 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.