This week marks the last week of tax season! Luckily, for me, filing taxes has always been a pretty simple task. I gather all of my necessary paperwork and within a matter of hours I am able to file online with the help of a tax-preparation software. How am I able to do this? For one, I control all of my own financial records. They are in my hands at all times. Secondly, my tax software has created a secure method to transfer my data to the government.
Now imagine what a similar scenario would look like if I wanted to transfer my health records to another setting of care. For one, I would need to have my records in hand, which typically involves filling out consent forms, paying fees, and picking up a printed copy, or could mean waiting for my doctor to send my records via snail mail or fax. Once that step is complete, I would need to wait for the receiving party to scan in or hand-key entries into my chart (which could take weeks!).
How can we get to a place where health data can be accessed and moved securely, much like our taxes? CMS and ONC believe the answer lies within the creation of health care APIs.
The ABCs of APIs
Application programming interfaces (APIs) are programming routines that allow software applications to share data. It is not a new concept and Internet businesses have been taking advantage of them for years. Organizations such as Google, Amazon, Netflix, and Facebook have all created APIs that allow third-party developers to access information so they can build new applications. For example, Runtastic, a fitness application, utilizes the Google Maps API to track and measure the distance of their users’ runs.
An API can be thought of as the middle man that works between 2 applications. The middleman accepts requests (if allowed) and returns the data back to the requestor. The middleman also lets the requestor know about the data that can be requested, exactly how to ask for the data, and how it can be received.
Figure 1. An API receives, requests, and returns data between 2 applications.
Ultimately, APIs allow developers to access information from a system in a controlled fashion.
Unblocking patient data
Beginning in 2018, all 2015-edition certified EHRs will need API capabilities to respond to requests for certain patient data and return such data to the requesting system.
By requiring EHR vendors to create APIs, CMS and ONC’s goal is to unblock patient data and tackle the “multiple portal” problem by allowing patients to use APIs to aggregate data from multiple systems into one system of their choice.
As you can imagine, the use cases don’t end there. Researchers could have easier access to clinical and claims data, patients could more easily import their health data into clinical research data platforms, providers could experiment with different user-interface applications to view data from their EHRs, and the list goes on.
So what information will applications be able to request from a certified EHR? For now, ONC has decided that, at a minimum, a certified EHR should be able to pass along the following information (see Figure 2), also known as the Common Clinical Data Set. The data must be sent in a CCD format using standard vocabularies to describe certain terms where necessary (such as SNOMED for problems and LOINC for labs), so the receiving application can consume the data accurately.
Figure 2. The information ONC will be requiring certified EHRs to pass to third parties via an API.
In terms of privacy and security, the API will also need to demonstrate the capability to establish a trusted connection with the application requesting patient data, authorize the user to request data, and log all interactions with the data source.
The silver bullet?
I have a lot of high hopes for the use of APIs in the healthcare space. There are many ways to create new value by tapping into data from existing EHRs. The impact that APIs can have on the quality and cost of care (in a new P4P world), the patient’s experience, and innovation will indeed be huge. Yet I become a little less enthusiastic when the ONC creates regulations before the industry has a chance to gain any experience.
One main concern is that the ONC did not state a specific standard to use when building an API. Their intention was to allow EHR vendors to be innovative, which I am normally happy about, but not setting a common technical standard for an API could make it more difficult to build applications that can interact with other applications’ APIs. Hopefully other vendors choose to lean on the HL7 FHIR standard (even in its draft state) rather than creating an API completely customized to their products.
Additionally, the notion that a patient can choose his/her own health application could pose a patient safety and security risk. How are these applications vetted?
All in all, the only way to know if APIs are the answer to our interoperability struggles is just to start.
Diana Strubler, Senior Product Analyst, Health IT Standards, joined Acumen in 2010 as an EHR trainer then quickly moved into the role of certification and health IT standards subject matter expert. She has successfully led Acumen through three certifications while also guiding our company and customers through the world of Meaningful Use, ICD-10 and PQRS.
Leave a Reply