Application programming interfaces (APIs) provide the means for one software program to access the services of another.
Analogies abound for explaining how APIs work, but one that is particularly compelling is the wall socket analogy. Rather than having to hardwire a new appliance to the power source, a person need only plug it in to draw electricity. That person doesn't need to know anything about the concept of electricity or even how it's delivery — just that the plug fits correctly into the socket.
The electricity drawn through the socket represents the information contained in a piece of software; the socket, the API enabling a request to be made and answered; the appliance, the other piece of software developed to use the requested information in a novel way.
Given the healthcare industry's history with closed health IT systems and siloed data stores, many subject-matter experts and innovators continue to tout the potential of widespread API use in healthcare to enable health data exchange and interoperability.
Late last year, the authors of a Harvard Business Review article stressed the potential of APIs to have a significant positive effect on the healthcare industry.
In a health care market where APIs are commonplace, patients could have easy, efficient access to their own data, which would help them understand their own health and make more informed choices," wrote professor Robert Huckman and White House policy adviser Maya Uppaluru.
"Providers would be empowered by innovative user interfaces and analytics platforms that could support their clinical decision making," they continued. "Researchers could have easier access to detailed clinical and claims data to create hypotheses and identify trends — and create a better experience for individuals donating their data for science."
Beyond these more immediate effects, a secondary benefit of healthcare API use would be opening IT innovation up to those without a history with healthcare.
"Finally, the availability of data would lead to the development of an entirely new group of health care innovators: developers who do not have particular expertise in health care but, when given secure access to clinical data from the industry, could create tools of significant value. Together, these benefits could allow the health care system to tap the true potential of its massive data resources," added Huckam and Uppaluru.
Addressing privacy, security concerns of healthcare APIs
To better inform the use of APIs in health IT certification (e.g., 2015 Edition Health IT Certification Criteria) and provider incentive programs (e.g. Stage 3 Meaningful Use), the Health IT Policy and Standards Committee formed the API Task Force.
Of particular significance to the group's scope were "perceived security concerns and real security risks" that represented barriers to widespread API use in healthcare.
The API Task Force identified many of these fears in an April report shared at a joint meeting of the two federal advisory committees.
"There are fears that APIs may open new security vulnerabilities, with apps accessing patient records 'for evil', and without receiving proper patient authorization," the report stated. "There are also fears that APIs could provide a possible 'fire hose' of data, as opposed to the 'one sip at a time' access that a web site or email interface may provide."
However, the API Task Force ultimately found these concerns to be largely unfounded based on the ability of well-manage APIs to provide superior security compared to "ad-hoc interfaces or proprietary integration technology" already in use.
"While access to health data via APIs does require additional considerations and regulatory compliance needs, we believe existing standards, infrastructure and identityproofing processes are adequate to support patientdirected access via APIs today," the group ultimately concluded.
Health data security and privacy risks associated with healthcare API use will still warrant active oversight by the appropriate federal agencies, but they pose no greater a threat than any other technology when properly managed.
The regulatory push for healthcare APIs
Two incentive programs set to begin at earliest in 2017 have identified healthcare APIs as a means of enabling health data exchange among providers, between providers and patients, and between providers and public health agencies.
Hospitals already prepared for Stage 3 Meaningful Use can begin participating in the final stage of the EHR Incentive Programs as early as 2017 and be responsible for less rigorous requirements and measures.
In its final rule for Stage 3 Meaningful Use, the Centers for Medicare & Medicaid Services (CMS) has set a target for establishing interoperable health IT infrastructure across the United States. Key to realizing this end is the use of APIs to unlock clinical health data and enable information sharing.
For instance, as part of the Stage 3 Meaningful Use objective for patient access, CMS includes the use of APIs to enable patients with the ability to view, download, or transmit their health information and patient-specific resources " using any application of their choice that is configured to meet the technical specifications of the API in the provider's CEHRT."
Similarly, the advancing care information performance category in the Merit-based Incentive Payment Systems also calls on eligible clinicians to use APIs to satisfy several measures.
In order to give patients, "timely electronic access" to health data and educational materials, a MIPS eligible clinician must have recourse to an API in his certified EHR technology to make that information available. API-enabled health data exchange in MIPS also applies to the view, download, transmit measure until the coordination of care through patient engagement category.
Extant and emergent healthcare APIs
While the Fast Healthcare Interoperability Resources (FHIR) specifications and API are receiving the most attention at present in the discourse about healthcare API use, other APIs are already at work enabling health data exchange.
But most recently the Blue Button toolkit — which allows users to view, download, and transmit sensitive health data securely — has taken a shine to FHIR.
Developed by Health Level Seven International (HL7), FHIR has the potential to be a real game-changer — as far as its proponents are concerned.
Last month, HL7 CEO Charles Jaffe, MD, PhD, stated that "the marketplace will decide the utility of FHIR" and he cited three programs exploring the utility and application of FHIR in the healthcare industry — the Argonaut Project, Partners in Interoperability Program, and another in the field of genomics for use in precision medicine.
Jaffe explained how FHIR works in simple terms.
"FHIR uses the exact same technology as does Google," Jaffe went on to say. "When you ask for the five best restaurants in Baltimore, there's not a database of restaurants in Baltimore. Google goes out and looks for that query on the web, albeit with a rather exotic algorithm to find those things, and assembles that information for you."
FHIR combines this call and response approach with proven internet standards for security and authentication. "We didn't reinvent; we use the ones that are used around the globe for authentication and security. If I'm going to another system and present credentials, the other system will allow me to query its data," he added.
Most recently, researchers at the Regenstrief Institute have set about proving the usefulness of FHIR specifications and the FHIR API to aggregate and merge patient health data from disparate data sources.
"We can really stitch together information in various sources using FHIR in a way that is user-centered and would be accepted by physicians and patients," Regenstrief Institute investigator and Clem McDonald Professor of Biomedical Informatics at Indiana University School of Medicine Titus Schleyer, MD, PhD, told HealthITInteorperability.com.
Despite proving the usefulness of FHIR in sandbox testing, Schleyer acknowledged that variation in FHIR implementation, differences in data vocabularies used by FHIR-enabled systems, and a lack of a standardization patient matching solution could end up hold the specifications and API back from reaching their full potential.
Whether it's FHIR or another API, the growing interest in healthcare API isn't going away.