Rhapsody recently hosted a webinar called API 101: An introduction to APIs and how they are transforming health IT. It was by far our most popular webinar to date, with attendees representing all sectors of healthcare—providers, payers, public health, and health IT vendors—from across the globe. We’ve recapped the session with the transcript of the webinar, edited for brevity and clarity.
Webinar speakers included:
- Panelist Damian Leopard, vice president of growth and innovation, Rhapsody
- Panelist Katelyn Formal, solution consultant, Rhapsody
- Moderator Shelley Wehmeyer, director of product marketing, Rhapsody
Throughout the 35-minute webinar, the team discussed:
- What are APIs?
- Examples of APIs in the context of day-to-day life
- Examples and benefits of APIs in healthcare
- Technology drivers of API adoption
- Other drivers of API adoption, including the shift to Service-Oriented Architecture (SOA)
- FHIR APIs
- Corepoint Integration Engine and Rhapsody Integration Engine capabilities to support APIs
- APIs in healthcare: An example from a prominent specialty care center
- APIs in healthcare: An example from an academic medical center
- Rhapsody API Gateway for healthcare
- API-related training from Rhapsody
- API glossary
- Speaker bios
Skim through the webinar topics below or watch the on-demand recording.
Shelley Wehmeyer: What is an application programming interface, or API?
Katelyn Formal: An API simply defines how two systems communicate and exchange data with one another. The API defines what information I need to send to an application, or an application to send to another application, to get the data I need. This includes how I authenticate and authorize myself, and rules around what I’m allowed to do. For instance, am I allowed to delete certain things? What am I allowed to update? Anyone using a web browser or a smartphone has interacted with APIs.
SW: What are some examples of APIs in the context of everyday life?
KF: I recently bought something online from Sephora. Sephora sent me an email and told me when my package would be delivered. Sephora is calling an external API to display the shipping information within the email they sent me. It’s telling me what date my package will arrive.
Sephora doesn’t have its own shipping and tracking information. It’s calling externally to FedEx. An API allows Sephora to call the data from FedEx and send the details I need, such as a tracking number.
Another example is Uber calling the Google Maps API. When I tell Uber I need to go from point A to point B, Uber uses the Google Maps API to do some of the mapping of the drivers and send me my receipt.
SW: What does this mean in the context of healthcare, and what are some of the benefits of APIs over traditional or legacy healthcare integration standards?
Damian Leopard: Historically, data went point to point. You would write an interface that went directly from one system to another system. As the number of systems that needed to communicate grew, you can imagine what that started to look like. It looked like a big spaghetti ball. It was relatively brittle, and you had to re-implement the routing and interactions from a specific system to a specific system over and over every time you wanted to add another system.
Later we moved into more of a hub-and-spoke architecture where you only had to write from a particular system one time into an integration engine, such as Corepoint or Rhapsody, and from there the interface could distribute the everywhere it needed to go. It could also aggregate the returns back into your EHR, for example, coming through a single point.
Then we wanted to have reusable services because there were more people who we needed to exchange data with. The service-oriented architecture started to come into healthcare.
The service-oriented architecture is about creating a common service that you can call with a specific set of logic that is reusable and can be used for multiple systems. Inside the four walls of a facility, you might reach out to certain services that you always want to send your demographic information in a particular way, well as more systems that needed to identify a patient more accurately. For example, you can introduce systems like EMPI or terminology services, and those expose an API.
Initially, many APIs were SOAP-based. SOAP is an XML-based protocol that sits on top of HTTP and uses XML. It’s still relatively prevalent, but they carry a lot of overhead. We started to see RESTful HTTP-based APIs were much easier to implement and lighter weight.
They used the standard HTTP protocol as well as lighter-weight data formats like JSON, and in healthcare, FHIR. But there are also many custom APIs that are around JSON and REST, so you can build it once and reuse that surface repeatedly. Those services are exposed through those SOAP or REST endpoints.
SW: What are the technology drivers behind the push for APIs?
KF: The technology used in APIs is quite transferable. Instead of it being a healthcare specific standard or using healthcare-specific protocols, we see some benefits in that there’s a broader set of users or engineers out there who are familiar with these pieces of technology. APIs give us a wider pool of talent to work with.
SW: Katelyn, you and Damian touched on the fact that APIs work with JSON and XML, which are also self-describing payloads, and so both of them say, “Hey, this is the patient identifier,” whereas in HL7, those of us that know it well, know that that identifier is in PID 3. APIs are a more adaptable skill set to not only users that are in IT, but also more engineers are going to have familiarity with these types of payloads and interactions.
The shift to Service-Oriented Architecture (SOA)
SW: A lot of that service-oriented architecture, and APIs in general, is about that intersection of the technology and usability. A lot of the payloads that cross those APIs are now self-descriptive. Katelyn, your example is a perfect one: Here’s the patient identifier, and here’s a name—it allows for easier machine-to-machine communication. And people working on those machines need the ability to also read that information relatively easily.
There are some other drivers of API adoption in healthcare. One that I’m familiar with is from a regulatory or national guidelines standpoint. A national guideline or regulation at some level was encouraging providers to become versed in APIs, either for themselves so that they could work with IT, or so that they could work with their HCIT vendors to comply with standardized data exchange guidelines coming from some level.
One example I’m familiar with was in the UK when NHS Digital released—and continues to release—the set of FHIR-based APIs to be used as a standard for specific initiatives, such as generation of standardized Transfer of Care documents.
DL: APIs are an easy way to get access or to share data from one organization to another organization. Many drivers are around being able to access things like information from people’s Apple watches, Garmin smart watches, smartphones, or smart scales. You need to be able to call out to the APIs of the platform that’s collecting that data to pull it into the systems and make it available to the users within the hospital, payer, or HCIT vendor space.
SW: How does Rhapsody help our customers with technology and services to support working with APIs?
KF: First we’ll look at what Corepoint and Rhapsody do with APIs and how our customers are using the API capabilities within the integration engines.
Both engines allow users to host or connect to a SOAP or a REST-based web service. SOAP is still there in healthcare because it was one of the first ones so we see that a lot, especially for document exchange in different registries across the ecosystem.
But because REST is more lightweight, I see most of our newer APIs being implemented for REST, and our engines can support that. As FHIR has become more prevalent in the ecosystem, we can support all of those payloads because those are XML and JSON, which are both native to our engines.
Additionally, we can also do those different things like all the things that need to support those types of integrations make sure that we can authenticate via whether that’s a TLS connection or an O-Auth type authentication
In healthcare there is a migration toward REST APIs, but some systems need to contact an SQL database, or communicate via HL7, and so we have tools to do those different transformations to make sure that those types of more complex orchestrations can be achieved. Corepoint and Rhapsody integration engines have those capabilities.
APIs in healthcare: An example from a prominent specialty care center
This specialty treatment center uses Corepoint Integration Engine. They need to consume different data elements, and they need to most of them HL7 V2, but also some messaging between customers but they need that actually to be posted to their Salesforce customer relationship management (CRM) system. Within that external trading partner side, here that you can see on the right are going to be different APIs that need to be called.
This particular implementation is done over SOAP, but this could be done over REST. Salesforce does introduce with SOAP and REST-based APIs, but this implementation happened to be configured about seven years ago, and we’re able to consume both HL7 V2 and those XDR dark secure messaging within Corepoint, and then call the relevant SOAP APIs to do the relevant updates and vice versa.
As healthcare has evolved our ecosystem has become not just healthcare applications. There is also a lot — Salesforce does healthcare—we have to integrate with people that perhaps don’t speak HL7.
DL: In addition to Salesforce, I remember one implementation where we had to interact with Workday, the staffing system, and also Chronos, the time-keeping application, via APIs and interact between the EHR systems and payment systems, as well as those back-office systems.
APIs in healthcare: An example from an academic medical center
Another example, also via Corepoint Integration Engine, is where we needed to integrate an AI application that needed to consume data from multiple applications within an academic medical center. These applications were not necessarily API, so there was no way for them to interact directly. Some were specific to clinical trials, so we needed to execute a SQL query so we can do database connections to feed that data back into the AI platform.
Additionally, it could be REST APIs on both ends. That’s also a common use case for activities such as managing appointments with different referral partners. Also, there could be different documents and PDFs that the AI platform that need to be parsed out. We’re able to host that REST API endpoint within Corepoint so they could make the queries they needed.
We used the technology within the product to do this orchestration, say where it needed to go make the appropriate queries and feed that data back so that that application could be completely enabled.
SW: I’ve seen this same architecture on the inverse—where, looking at this diagram—the external trading partner is our customer, such as an HCIT vendor or a digital health app, and they’re using Rhapsody Integration Engine or Envoy iPaaS to get information from a variety of EHRs, or a variety of providers that they connect with, to then ingest and feed into their proprietary REST API for whatever magic they’re doing with it on their end. It’s common use case we’re seeing more.
SW: APIs in healthcare: A public health example
Damian, tell us about an architecture you’ve been working on for one of our state department of health customers and how they’re using APIs to solve for identity management use cases.
DL: I’ve seen a lot of pressure to modernize—in particular, public health infrastructure as a response to the COVID-19 pandemic and being prepared in case there is another one coming.
In this case, a large state department of health had a combination of Rhapsody already deployed within the department and an Envoy instance in front of that for specific types of interactions.
When we first implemented this, we were exposing SOAP-based web services out to the providers, laboratories, and testing or immunization sites for mass vaccinations. We had to pull in information from that mass vaccination implementation. We’re also pulling in data from Salesforce over REST APIs and getting data from the providers, laboratories, and large pharmaceutical chains like CVS, which also do immunizations, and updating the immunization registry in the background.
The department had a number of these systems that you see across the top of the diagram below—everything from the disease surveillance to that immunization registry to customer-facing portals—batch files that they had to move around. They were also building a data lake so they could offer better support to the communities that that they’re working with.
Every single one of them was solving for things like patient identity in a different way. We were having trouble trying to resolve across all of those, for example, what a specific patient was, so that the state wouldn’t have report doses multiple times or identifying populations that needed outreach.
We talked about that enterprise master patient index (EMPI) and creating that service across all of the different programs within the department so that no matter where you were, you could always identify a patient uniquely or to the best ability that you could.
It’s exposing that as an API, in this case a REST API, that each one of those different silos can interact with, whether it’s the orchestration layer for all of those at the integration and orchestration layer that’s done in Rhapsody or Envoy or the individual systems within those different programs calling out to that EMPI.
It also introduced the notion of needing to have both an externally facing and internally facing gateway to make sure that only the appropriate people were able to call those surfaces and that they were trackable and self-healing. You can see how that worked across the whole state.
SW: You made that transition super easy for me, Damian, so customers ramp up the use of APIs, meaning more traffic or endpoints, what does Rhapsody do to support them, and when is an API gateway important?
What is an API Gateway?
DL: Built for healthcare, Rhapsody API Gateway is meant to be that digital front door. When you’re exposing APIs, you have the actual systems that publish them, that create those endpoints, and then you have systems that want to call those endpoints.
In between, if you want to have a single place to manage the authentication and access control you can put a gateway in place, which tracks where those users are coming from.
It can also provide protection so that attacks don’t come in and overload the system so you can control the way in which those APIs are called from outside of your organization.
As I mentioned within that state department of health, they were also using the Rapid API gateway for internal calls. So, the various systems that were across the whole thing, they intend to go through that gateway—whether it’s being called from Salesforce, the disease surveillance systems, or e-case reporting. All of those will go through that gateway.
It is that digital front door that allows people access to those endpoints—as well as offering peace of mind around exposing those endpoints. A little bit of peace of mind goes a long way.
Rhapsody API training
Interested in API training? Rhapsody offers several courses for customers and non-customers. These include:
Rhapsody: Professional (includes working with Web Services)
Curious about APIs and privacy and security?
Download How API technology enhances privacy and security and protects patient data (for U.S. readers)
Or download A global view of how API technology enhances privacy and security (for international readers)
Learn more about how to evaluate API gateway options.
API Glossary
REST API
REST (Representational State Transfer) is a web services approach used heavily in social media sites. Uses HTTP in conjunction with GET, POST, PUT, and DELETE. The use of RESTful web services as an API has been on the rise over the last decade across all industries. RESTful web services is embraced by organizations such as Facebook, Twitter, and Amazon as their primary API. In addition, related technologies such as XML, JSON, and Oauth, are also common when dealing with encoding and authorization. These technologies have well supported tools and a large talent pool of IT resources.
SOAP API
SOAP (Simple Object Access Protocol) is a web services protocol used heavily in healthcare to implement IHE profiles. SOAP is an enterprise standard that is typically used by business applications to exchange information across the enterprise.
Payload
Payload refers to the content of the message being sent (i.e., the message body). A payload, for example, could be JSON, HL7, CSV, PDF, or other file or message type. Corepoint and Rhpsody engines have the capability to do all payloads including custom payloads.
Speaker Bios
Damian Leopard, vice president of growth and innovation, Rhapsody
Damian has over 20 years of experience working in healthcare and interoperability. As the vice president of growth and innovation at Rhapsody, he thrives working with customers, partners, and R&D teams to bring innovative implementations of products to life. He is passionate about pushing for new product capabilities and expanding the product road map. As a former Rhapsody Integration Engine customer, he has firsthand experience working with the product and joined Rhapsody in 2011.
Katelyn Formal, solution consultant, Rhapsody
As a solution consultant at Rhapsody, Katelyn is involved in diverse integration projects, ongoing client support, and proof of concept demonstrations for existing and prospective customers. Katelyn has more than 10 years of experience working in healthcare and has knowledge of HL7 integrations, API based integration including HL7 FHIR, workflow optimization, and EHR implementations.
Shelley Wehmeyer, director of product marketing, Rhapsody
Shelley dedicates her career to simplifying the complexities of health and social care delivery around the world with technology. Whether in the context of navigating the requirements of a new market, launching a new product, or enabling client-facing teams and clients on product strategy, the most rewarding part of Shelley’s experience is the ability to bring together cross-functional, cross-organizational teams to a common goal—doing what is best for the patient and the clinician.
