In last week's post, we introduced Meaningful Use (MU) and some of the ways its objectives could improve access to electronic health data, particularly through the use of APIs. This week, we'll dig a little deeper into the details of APIs and what they could mean for the future of healthcare.
Application Programming Interfaces, or APIs, are the "digital glue" that allow exchange of data between different sources. For example, Amazon can easily make the same deals available on its website and on its mobile app through an API. Using a request structure specified by the API, the mobile app can ask "What is the bonus deal of the day?", and the API will send back a structured response that includes the item name, the item image, the price, etc. APIs have broad usage: their job could be as simple as specifying how a computer communicates with a printer, or a bit more complex - such as enabling developers to embed Google Maps on web pages. What APIs have in common is that they specify how software components should interact, making it easier to develop a program by providing a set of building blocks.
As we discussed last week, the proposed MU3 rule requires that providers give patients timely access to their PHI through an API, and that patients interact with their PHI by downloading it or accessing it through a third-party application using an API. APIs are ideal for patient engagement purposes because they open up the ability for developers to create vendor-agnostic patient portals or other patient apps, eliminating the need for providers to purchase and implement EHR vendor-specific portals for providing secure transfer of PHI. With standard APIs, patients could potentially collect their health information in a single place using a third-party application that accesses data from multiple providers through the API and presents the information usefully and uniformly. This kind of access will enable developers to make applications that empower patients to take a more active role in their own care.
In addition to playing an important role in MU3, standard APIs for health data will also be a key ingredient to improving interoperability, broadly defined as the ability of disparate records systems to communicate with each other. Interoperability has been a problem in healthcare for a while: past attempts at improving interoperability include several versions of Health Level 7 (HL7) "standards" for the exchange of electronic health information. These specifications focus on standardizing the content of shared data (rather than on how to share the data), and have been largely unsuccessful due to customization of individual implementations.
The newest HL7 standard is called Fast Healthcare Interoperability Resources, or FHIR (pronounced "fire"), and takes the form of a Representational State Transfer (REST) API. A REST API is simply an API that follows a few simple rules that confer various benefits, including scalability and easy learning for programmers. For those who are curious, the major rules are:
- All things/objects (e.g. "Patient X's visit to Dr. Y on 06/29/1990") are given globally unique IDs (addresses) and are called "resources"
- Resources can be represented in different formats (JSON or XML)
- Each request contains all information necessary for its interpretation
- Resources link to each other (for example, a prescription can be linked to the provider who wrote the prescription)
- Standard methods (for example Read, Write or Delete) can be applied to the resources. To read further, you can check out a less technical and/or more technical article on REST.
FHIR's current list of resources was created using an “open” development process, meaning that it was developed by the public working together with the HL7 organization (in contrast to HL7’s previous standards which were entirely closed until recently). The list includes relevant clinical concepts such as encounters, medications, patients, providers, and so on. Software engineers are used to working from clearly defined specifications such as these, and can make many assumptions about how FHIR works based on the knowledge that it is a REST API.
Digital health innovation could take off rapidly if FHIR-based APIs catch on. Thoughts on why API culture hasn’t quite caught on yet in healthcare will be discussed in our next post - check back again next week to continue reading!
Post A Comment:
0 comments: