Last updated: 6/6/18
Moving to the web for integration between third-party applications and EHR systems will require moving EHR APIs from behind the firewall to the wilds of the Internet. It’s no delicate transition and forces you to think differently about the APIs your organization supports for third-party application integration. Let’s look at why it’s so important and what you can do about it.
In the early days, APIs were developed around a remote procedure call (RPC). RPC made APIs look and feel like executing code locally. While these APIs were powerful and behaved a lot like functions, it was more difficult transitioning to the web. This is because the HTTP protocol is naturally connection-less and requires developers to think about it differently. Along the way, many “technology stacks” – a combination of software products and languages – tried to solve this problem by giving developers an RPC-like stack to hide the details. This approach helped move applications to the web faster, but left developers writing inefficient code. Amid this, an influential technology surfaced that addressed building web-based APIs in a better way: representational state transfer (REST).
How REST Can Help
REST is an architectural style that uses simple HTTP calls for system-to-system communication instead of more complex options like CORBA, COM+, RPC or SOAP. With REST, your calls are message-based and rely on HTTP standards to describe these messages. Using the HTTP protocol means REST is a simple request/response mechanism. Each request returns a subsequent response. Below is what a simplified request and response look like:
Requests are made up of a verb (GET in this example), headers that describe the message (content length) and a body (greeting). The request is a message that describes what you want the server to accomplish. Likewise, the response consists of three pieces: an HTTP status code (200), headers describing the response and the body itself. HTTP verbs describe the type of operation:
- GET: Retrieve a resource
- POST: Create a resource
- PUT: Update/replace a resource
- PATCH: Update/modify a resource
- DELETE: Delete a resource
As you think about integration against an EHR system, let’s look at a real-world example like a third-party application that wants to show a patient’s current list of diagnoses. The application would make a request to the EHR system:
The EHR system would respond with a response:
- HTTP/1.1 200 OK
- Cache-Control: no-cache
- Pragma: no-cache
- Content-Type: application/json; charset=utf-8
- Expires: -1
- Server: Microsoft-IIS/8.5
- X-Sansoro-RequestId: f712b69a-4894-47d1-9219-ec19c6ed4824
- X-AspNet-Version: 4.0.30319
- X-Powered-By: ASP.NET
- Date: Fri, 20 Apr 2018 12:58:32 GMT
- Connection: close
- Content-Length: 732
The response below is in JSON format, which allows the calling application to programmatically deserialize the response in any programming language (Java, C#, VB.net, Perl, Swift – and yes, even Fortran) and pick individual parts of the patient’s diagnosis that the application wants to show or use for back-end processing.
The third-party application may want to display the “ClinicalDiagnosis” value to the clinical user so it’s clear the patient has ‘COPD with Asthma.’ The third-party application may also use the “ICD10” value to perform normalized diagnosis value matching in the background for analytics or other business processes.
Advantages of REST
With REST, a third-party application may execute a request (like the example above) in real-time against the EHR system without needing it to send diagnosis data to a separate repository, which is traditionally done with outbound HL7 interfaces. REST API methods effectively eliminate the need to develop custom, negotiated HL7 interfaces and allow third-parties to determine if the response should be stored at all. In many cases, once the third-party application is closed, the data simply disappears and is not stored externally. This deteriorates the threat of compromised PHI compared to a traditional HL7 interface model, which sends tons of data from the EHR to a third-party system, in the hopes that some data will be used at some point in future. REST is stateless, meaning it does not remember certain information from one API execution to the next. In the example above, the API server does not keep the diagnosis information once the response is returned to the calling application. The calling application moves on to execute subsequent requests and all requests are oblivious to one another. This affords the ability to scale (infinitely in most cases) several API servers that can handle many requests (at the same time) from a variety of third-party applications. The ability to scale up and down is immensely powerful when supporting enterprise scale integration.
REST in Health IT
At the end of the day, REST is incredibly useful for building large, scalable systems. Remember, our jobs as health IT professionals is providing extraordinary solutions to our clinical users, which translates into better patient outcomes without the roadblocks and impediments of traditional interfacing methods. As an industry, we are doing better, but need to continue challenging the status quo to achieve true interoperability.