What is an API?
CCN Health is a device and EHR agnostic software platform empowering healthcare providers to implement, manage, and scale successful RPM programs.
As CEO of CCN Health I have the opportunity to speak with all types of groups involved in the care continuum of a patient. An outsider listening in on a conversation surrounding the complex layers of the modern healthcare system might have a hard-time following along, while those of us living it day in and day out are able to successfully communicate using a shared vocabulary of words, phrases, and acronyms.
Provider: A person or organization that provides health care services - Doctor
Payor: Entity that pays for the care services administered by a healthcare provider - Insurance Company
CPT: Medical code set that enables providers to describe and report the medical, surgical, and diagnostic procedures and services they perform to payers.
However, there is one word I often hear mentioned – typically with varying degrees of confidence - integration.
In this post I thought it would be a fun idea to explore this word integration. My goal is not only to define it, but through real-world examples show exactly how an integration works, and what it means for healthcare providers, patients, and technology partners.
- Integration: The process of connecting one software application with another, typically through their application programming interfaces (APIs)
- Application Programming Interface (API): Set of rules that let software applications communicate with each other to exchange data, features and functionality.
The first thing to point out is APIs are not unique to healthcare. If you've ever used the internet (you must have if you're reading this blog!) you've been interacting with APIs without even knowing it!
Let's take a simple example - Wikipedia. More specifically, let's look at what happens when you search for a topic using the search bar.
To demonstrate this we'll have the developer tools visible, which give us a view into exactly what is happening behind the scenes. (If you'd like to follow-up along you can right-click and choose inspect to launch the developer console).
I've chosen the search term api, which I'll begin searching by typing the letter a.
The developer console shows a request being made to wikipedia with the search query title?q=a&limit=10. In other words:
(q)uestion = 'a'
limit = 10 - return 10 results
You'll notice the developer console shows Wikipedia's API returning the result as structured data - pairs of keys and values surrounded by {}. This is called JSON (JavaScript Object Notation) and is a common data interchange format for programs to exchange human-readable information. The web page is then able to read that information and display it in the list at the top.
Let's continue our search by adding one more letter 'ap'. Once again a request is made and we see the Wikipedia API returns the results, which are rendered to the page.
Completing our search term 'api' we once again see the final results returned from the API and rendered on the page.
By clicking on the request we can use the Request URL field to understand where the Wikipedia API is serving this information from
What happens if we open that page in our browser?
Not pretty, but we can see the actual raw JSON response!
With the help of a formatter we can make it a bit easier on the eyes.
By this example alone we know that the API allows us to retrieve information by sending requests to en.wikipedia.org/w/rest.php/v1/search/title and telling it exactly what we want with ?q=search_term and how we want it: limit=10.
In other words:
Hey, en.wikipedia.org/w/rest.php/v1/search/title, I want to know about zebras and only want you to give me the top 10 results.
en.wikipedia.org/w/rest.php/v1/search/title
q=zebras
limit=10
Putting it together our request would look like the following
en.wikipedia.org/w/rest.php/v1/search/title?q=zebras&limit=10
Great, but how about the part of the API definition that describes how APIs allow software applications to communicate with each other to exchange data.
In the example above we've been fetching data from a web browser, which many of us are familiar with. Did you know a web browser is just one type of, albeit very common, software application that can access data on the web. Since this is an API we could access this same data from any other software program that speaks HTTP. - a separate web page, an RPM platform, or even just my Macbook's terminal as seen below.
If you've made it this far give yourself a high-five as we've covered a lot. Now let's bring this full-circle back to healthcare.
For this next example we'll be focusing on Alis by Medtelligent - a senior living Electronic Health Record and prime example of a powerful EHR providing an intuitive API.
Learn more about our Alis integration here.
Lucky for us the team at Alis provides instructions, known as documentation, or docs for the nerds, for how our programs can interact with their EHR.
Now this is just a subset of the EHR functionality we can interact with, but at a high-level it tells us which URLs we can request to read (GET), update (PUT), delete (DELETE), and even upload (POST) information.
If I wanted to get a list of all Alis communities CCN Health has access to, our program could send a request to /v1/integration/communities and in return retrieve a list of communities.
Even better the Alis team lets us test API requests right within their documentation. Let's get a list of current residents for a specific community.
Just like Wikipedia we send a request to a URL v1/integration/residents?communityId=25&status=CurrentResident
communityId: 25 - community we would like to get the residents for
status: CurrentResident - only give us the current residents
and in return the Alis API returns a list of current residents in JSON.
We've covered two APIs - Wikipedia and Alis. Do you know how many EHRs there are in 2024?
By most estimates there are over 500 EHR platforms, and nearly all of them provide API capabilities for third party platforms such as CCN Health to integrate. Not only that, but most EHRs APIs have become just as easy to interact with as the two seen above!
The point here is that APIs aren't some sort of black magic. They all function similarly, if not exactly as shown above. Now that we know how they work, the better question to ask would be - what can they do for us?
Wikipedia's API enables you to search for a topic that interests you
Alis's API lets us search resident information and store it in CCN Health.
PointClickCare's API support of ADT webhooks allows CCN Health to get notified when a resident moves in, moves out, or is transferred.
Athena Health's API enables CCN Health to post real-time vitals observations into patient charts.
Charm Health's API gives us the ability to initiate and persist secure patient SMS conversations across both platforms.
Now, there's one last subject I'd like to cover. I was hesitant to dive into it, but in the healthcare technology world it is a hot topic and thought it was at least mentioning.
Just as our industry has standardized on common vocabulary, so have EHR APIs with the introduction FHIR.
FHIR /faɪər/, like fire - set of rules and specifications for exchanging electronic health care data. The goal of FHIR is to enable the seamless and secure exchange of health care information, so that patients can receive the best possible care.
Simple put, FHIR defines the language (think nouns and verbs) two programs can use to communicate healthcare information regardless of how those programs store that information.
This means that an RPM program, EHR, and an eMAR might each have the concept of a patient, but internally they each call them three different names!
RPM: Participant
EHR: Patient
eMAR: Resident
If the EHR wanted to get medication information from the eMAR it might ask it for a specific Patient, but the eMAR wouldn't know how to respond, as it only knows about Residents. Now imagine 500 different programs trying to communicate with each other using distinct vocabularies - it would be (and has been) a complete nightmare.
What FHIR has done is defined a common terminology for all of these concepts as well as how to access them. This means that as long as various programs support FHIR they can all seamlessly communicate.
I think that's enough for now, but if you're interested in learning more about CCN Health's supported integrations feel free to reach out - we would love to chat.