As discussed by my colleague, Dave Levin MD, in his recent blog post, Liberate Applications with API-Based EMR Integration, application programming interfaces (APIs) allow seamless data exchange and integration into clinical workflows. APIs provide robust, EMR-agnostic integration that rapidly deploy and can quickly evolve. While APIs have many benefits, they also provide additional security for health systems and protection of patient privacy.
We live in a world where new technologies are providing efficiencies and conveniences in nearly all aspects of our daily lives. This is certainly true in the healthcare industry. Technology has transformed how clinicians and staff communicate and work with each other.
Unfortunately, with new technology brings new security and privacy risks. Organizations strive to secure data and the means by which data is shared. This is especially true for healthcare entities, where they are legally obligated to manage and protect health information. Fortunately, API technology provides critical security advantages to help manage those obligations and control how PHI is accessed and transmitted.
APIs enable the exchange of data via requests and commands. Through an API, software applications can request or command an action with another application. These web-based APIs, also referred to as RESTful APIs, use internet protocols such as HTTP to communicate with software.
APIs vs Traditional Methods
Compared to traditional data-exchange methods, APIs provide more security and protection of patient privacy. APIs inherently do not store any PHI data in a second database. By comparison, third party vendors that rely on HL7 integration must populate a separate data repository. Other integration companies may rely solely on HL7 and/or the electronic medical record (EMR) vendor’s limited public APIs to feed and persist data in their own database, so their APIs are accessing a replicated data store that has only a limited subset of EMR data.
Keep in mind that HL7 v2.x, which is the most widely adopted version of HL7, transmits all data via TCP/IP protocol in plain text format. HL7 v2.x does not encrypt data in transit, nor does it require digital certificates between two parties in order to exchange data.
APIs provide direct connectivity to EMR systems through vendor-supported modules, so third-party applications can have real-time access – just as the native EMR applications would – and do so in a much more secure manner than traditional forms of integration.
Here are a few examples of features offered through APIs:
- Protected HTTP methods: HTTP methods determine how the data is requested by a consuming application. The most commonly used methods include: GET to retrieve a resource; PUT to change the state of or update a resource; POST to create a new resource; and DELETE to remove or inactivate a resource.
- Whitelist allowable methods: Using an API, you can restrict actions (GET, PUT, POST and DELETE), so only the allowable actions would work. The methods not allowed would result in a 403 - Forbidden or 401 - Unauthorized HTTP status for example.
- Protect privileged actions: Not every consumer has the right to every API. APIs allow you to limit consumers and what they can access.
- Protect against cross-site request forgery: Any HTTP method requests that are exposed can be protected from cross-site request forgery through a token-based approach.
- Cryptography & use of web tokens: The benefit of token-based access is that it can be deleted at any time and for any reason (i.e. a security breach, misuse or if health system decides to no longer give that service access). Access tokens can also be used to restrict permissions.
All of these unique features reduce the potential for data breaches. As health IT infrastructures move to the cloud, and digital information becomes a healthcare standard, improving privacy and security remains a priority. Fortunately, APIs are a proven solution that secure transfer of data and simplify interoperability.