Web Application Programming Interfaces (APIs) are certainly not new. Web API use in healthcare, however, is a growing approach for exchanging health data. Currently for Meaningful Use Stage 3, providers will have to employ an open, patient-facing, read-only API with a deployed CEHRT (certified EHR). To get an idea of why API use is expanding in the industry, you can download our useful API Guide here. Providers allow outside parties access to portions of patient data stored in a database via open web APIs. The API defines the layer on top of an application that allows other applications to interact with its data. But, for the purposes of this blog, let’s look at five questions IT teams need to consider as they explore API connectivity.
What workflow are you looking to solve?
It seems logical, but many interface developers or analysts will skip straight to the technology aspect of APIs before answering this crucial first step. Just like any other interface, each API should have a stated objective or goal. Once that is defined and documented, the function of the interface becomes evident. Am I the provider or the consumer of the data? A great majority of the time healthcare providers utilize an API as a data consumer as opposed to a data provider. The data consumer in an API transaction wants to reach into another database for particular data elements or to push data in.
Where’s the developer guide?
Once the purpose for the API has been clearly defined, the interface developer will need to locate the developer guide to learn the requirements of utilizing the vendor’s API. Usually it has words like “implementation guide” or “development guide.” The guide defines a set of data elements and security standards that outside applications must follow to send or retrieve data via the API. The guide may have a title such as “Cerner HIE WS documentation” and are typically available via the Internet. Many state reporting agencies have good documentation on their website in the form of a PDF.
What kind of transport mechanism will be used?
External applications are almost always based on Web Services, so the data transport method will be via SOAP or RESTful web services; very few systems support both. SOAP interfaces require a WSDL, which is an XML file that describes what the different services and data elements that are exposed by the API. Ideally, the developer guide will provide a URL to the WSDL for use in creating the interface. If it’s REST based, the developer guide is even more important. REST interfaces always use raw HTTP calls which can contain any data format as opposed to SOAP which always encapsulated in XML. The developer of the REST API defines what the calls are and how to call them. Ideally, the guide or the vendor will provide you with an example message.
What type of authentication is required?
Healthcare providers and vendors are not going to let unauthorized individuals or entities to access the patient data within their databases. Outside organizations and vendors must get authorization and discover the rules for “talking to” the provider’s application. Ideally, authentication and security details are provided in the documentation. Sometimes, especially in publicly accessible APIs, authentication requires an application approval process that results in a unique API “key” that allows access to the host database. The two most common authentication keys that are provided by the application are user name/password and token authentication. In the latter case, the authentication info is included in the web service http header on every future data request, which prevents the need to authenticate every time.
What data format does the host require? What format will you receive?
Data queries to vendor APIs must be made to adhere to strict parameters to be successful. Organizations utilizing a provider’s API must know how to properly ask for the specific data they need. For example, some systems support responses in the form of JSON. They also need to know how that data will be formatted when it is received, which will help determine the steps you need to take in your integration engine to ensure you successful achieve your stated workflow objective. If you’re simply pushing your patient data to a state’s HIEs, then you’ll want to log that data in the case of an audit so you can prove the transaction occurred. This is typically done in your integration engine. If you’re receiving data to be used, you’ll need to determine what to do with the data. Display it on the screen? File into a database? Attach it to a virtual patient folder? Send it to another internal application? …the sky is truly the limit with what you can do with data when it is made available by web APIs.
