API Management Gateways. It’s all the trend in Health IT. But what are API Management Gateways? For that matter, what’s an API? And what does this have to do with Health IT? Mike Farahbakhshian dives in and explains. Suggested drink pairing: The Moscow Mule(soft).
Spring is in the Air… and the Cloud
Happy March, Meaningless Useketeers. Spring is nearly upon us! March brings signs of life and growth such as Mardi Gras, Daylight Savings Time, St. Patrick’s Day, and the vernal equinox which heralds the coming of Spring.
When I think of Spring, I usually think of pleasant weather, the Persian new year, and relentless allergies. However, this is an article about Application Programming Interface (API) gateways and I don’t actually have a segue into my main point. So, for the purpose of this article, let’s pretend I am a nerd with no life — one whose first thought upon hearing the word “Spring” was of the Spring Cloud API Gateway.
Ha ha! Mike is a dork. Now let’s get to the nerdy stuff.
As Health IT becomes more standardized and modular, applications begin to act like Legos, with mix-and-match components that plug into each other in various ways. These components have had many names in the past, but nowadays we call them Microservices.
When Health IT applications are open to the world, we want to make sure only the right Legos are facing the outside. We don’t want you just plugging into any old Lego, I mean Microservice. Enter the API Gateway. API Gateways, like NGINX, Zuul, and Spring, are a way of protecting your Lego castle from security or load issues. The remainder of this months’ column will explain why API gateways are important, and how to separate facts from hype.
APIs: IT’s Unfunny Knock-Knock Joke
So why an API gateway? Hold your horses. Before we dive into the pros and cons, I’d like to explain in plain language what an API is. The formal definition of an API is dry and filled with jargon:
In computer programming, an application programming interface (API) is a set of subroutine definitions, communication protocols, and tools for building software. In general terms, it is a set of clearly defined methods of communication among various components. A good API makes it easier to develop a computer program by providing all the building blocks, which are then put together by the programmer.
A more intuitive way to describe an API is that it is like a knock-knock joke:
- Knock, Knock!
- Who’s there?
- $VARIABLE.
- $VARIABLE who?
- $PUNCHLINE.
There are other formulaic jokes, such as “Why did the chicken cross the road?” or more off color ones like The Aristocrats. They all operate in the same way: there is a standardized and orderly format with predictable room for flexibility. Children love knock-knock jokes because humor is new to them, and it provides them a structured concept to explore.
In the early days of computing, APIs were meant to allow a standardized, Lego-like way of doing things. If you’ve ever used Windows, you can recognize the Win32 API, even if you don’t know it by name. The Win32 API provided a consistent look and feel, and a consistent behavior of buttons and scrollbars and other widgets. Other APIs, like Borland’s, do the same things, but look or behave differently:
On the left, Win32. On the right, Borland. Source: http://alycesrestaurant.com/messageboxes.htm.
Some APIs, like the GNU Tool Kit (GTK), look and act even more differently, as you can see.
As computing became a bigger and bigger part of our lives, APIs became more than simply ways to enforce look or feel. Network APIs allow applications to communicate with the outside world. This can be basic like the Berkeley Sockets API, which allows basic communication across the Internet to other computers. We stopped referring to “programs” and started talking about “services.”
As services become more complex, network APIs evolved. Enterprises started using Remote Procedure Calls (RPCs), which allow one application to ask another application directly to do something. You may have heard of Electronic Data Interchange (EDI), often used for financial and claims transactions like referral and authorization. This is a form of API. An EDI transaction is like an extremely unfunny knock-knock joke:
- Knock, Knock!
- Who’s There?
- EDI Form!
- EDI Form who?
- EDI Form 271, Eligibility and Benefit Inquiry! Is this patient eligible?
- Oh! In that case, EDI Form 271, Eligibility and Benefit Response! Hell yeah!
- [laugh track]
More recent forms of RPCs include Simple Object Access Protocol (SOAP), which use standard Web technologies. SOAP was cutting edge in an era of connected computers, with built in security models and a robust ability to access databases across tiers. This has given way to RESTFul (more on that later) with the rise of mobile computing and IoT. However, some major applications like Salesforce are still SOAP heavy. In the Federal Health IT arena, the SOAP-based VA’s Medical Domain Web Services (MDWS) is still around and ticking, for now.
The new hotness is Representational State Transfer (RESTful) APIs. RESTful was designed during the era of mobile computing. If using SOAP-based APIs is like flagging down your waiter (“Hey, Garçon! Please get me a Coca-Cola!”), using RESTful APIs is like ordering from a vending machine. It is quicker, more lightweight, and is usually simpler. However, RESTful APIs must use Web technologies; SOAP can use any language or protocol. A great analogy that is often repeated is, “SOAP is an envelope; RESTful is a postcard.”
One big thing to remember is that RESTful is stateless, which means a RESTful microservice doesn’t store data between requests. SOAP, on the other hand, can be stateful. RESTful requests can therefore be chattier, as this formulaic joke explains:
It’s not a knock-knock joke, but you get the point.
We will explore why this matters in the next section.
API Nous, Le Déluge: Managing a Storm of Data
Nowadays, enterprise applications ask many things of each other, especially in an era of connected devices, mobile and tablet computing, and cloud hosting. You’re not talking to one waiter or one vending machine, you’re talking to hundreds, maybe thousands. With distributed, cloud-based systems, your menu is huge – you’re requesting all sorts of things. Now we are in the realm of microservices.
Microservices have a lot of advantages. They allow for more fine-grained responses. Do you need to verify eligibility for a patient? There’s a microservice for that. Do you need to ensure encounter data is properly copied to a reporting database? There’s a microservice for that. Need to ensure your appointment API works on mobile apps? There’s a microservice for that.
Microservices do have a major disadvantage though. The constant churn of apps asking and answering questions, statelessly, leads to network load and security concerns. Chatty systems without restrictions sound like a squawking flock of birds. This cacophony gets geometrically louder, and more chaotic, as the system scales in the cloud. An API Management Gateway allows developers to structure and protect their APIs from this kind of anarchy.
To use our knock-knock joke analogy, an API Management Gateway is a book of knock-knock jokes, with an index to let you find just the right one without having to read every joke.
A good API Management Gateway allows DevOps types to do the following with ease:
- Create and edit an API, including drafts for comments, publishing, upgrades, etc.
- Set up Service Level Agreements for your API, including credits and penalties for exceeding or failing to meet the SLA
- API security, including: protection against denial of service or code injection, libraries for encryption, identity management, authorization and authentication (i.e., OAuth, DSLogon)
- Analytics/monitoring dashboard
- A portal to allow end users to discover your API and leverage features
A bad API Management Gateway, on the other hand, merely gives you an Error 502. (Sorry, HTTP humor.) There are a number of API Management Gateways out there, but names you may have heard in the Federal Health IT realm include Mulesoft, Kong, Azure API Management, and the Amazon API Gateway. You may have also heard of VA’s Lighthouse API Management, which acts as an API Gateway for VA microservices that help Veterans access their health information; file and track benefits and claims; find the nearest facilities; and enable Veteran verification of disability and demographics.
Gateway to Heaven: Why This Matters for Health IT
API Gateways are all the rage in the commercial and Government contracting world, but why Healthcare and Health IT specifically? Glad you asked. There are a few good reasons:
Bridging Legacy Silos. Health IT developed over a series of independent silos that use entirely different technology stacks and standards. Since I was just talking about VA, let’s use it as an example. VA’s legacy Electronic Health Record, VistA, uses MUMPS on Caché. Its patient portal uses LifeRay, but the main VA.gov website that borrows the APIs uses Ruby on Rails. Its Fraud, Waste and Abuse tools use IBM technologies. There are both SOAP and RESTful ways of having mobile applications access the data. Some data is stored using hierarchical NoSQL databases; other data is stored using Relational Databases. Supporting information for disability and benefits are stored on everything from Cloud-based systems to old-school mainframes. An API Management Gateway allows all of these disparate sources of information to be bridged in a way that makes sense.
Secure Interoperability. As more and more organizations share vital health information, API Gateways allow for a secure way for that information to be accountably shared. This is also good for the move from fee-for-service to value-based care, as properly structured, interoperable data may be computed and trended. The results of this trending allow Accountable Care Organizations (ACOs) to calculate whether treatments are working and patient outcomes are improving. FHIR is a major API supporting this interoperability, and any Health API Management Gateway worth its salt has got to speak FHIR.
Data Standardization. Health data is not clean. There are many reasons why:
- Human error in transcription: misspellings or misrecordings
- Error in conversion from legacy to digital records: fuzzed out OCR files, misplaced records
- Extract-Transfer-Load (ETL) errors: delimiting errors, file transfer timeouts
- Inconsistent taxonomy: are you referring to high blood pressure, HBP, Elevated BP, hypertension, etc?
and my personal favorite:
- Free-Text, Unstructured Data: The clinician has, for reasons of convenience, put all of the encounter data in free text notes instead of computable fields. This is a pet peeve of mine. Time to bust out Harry the HIPAA Hippo.
Don’t be Harry the HIPAApotamus. When normalizing health data, use a tool with Natural Language Processing (NLP) and deep Machine Learning (ML) to make the process as painless as possible. Meaningless Use endorses the use of HealthFlow (healthflow.io) as an Intelligent Integration as a Service (I2aaS). HealthFlow: An intelligent alternative to being sprayed with hippo feces.
APIs: Joke No Longer
Now, Meaningless Useketeers, you have an understanding of what an API gateway is for and why it is of critical use for Health IT. There are many options out there, but whatever we choose, we know that we will be future-proofing our Healthcare delivery.
We don’t yet know if Blockchain or biometrics will cease being toys and actually change the Health IT landscape. We don’t know what sweeping changes IoT and wearables will usher in. We don’t know what the future will bring. We only know one thing: Health IT is going to get more complicated. Although you can retrieve jokes via APIs, I hope this month’s column shows that they are in fact no joke. They are tools to solve real problems and are evolving as quickly as the landscape.
With all these tools flying around, we need a high-quality toolbox. API Gateways are just that. An API Gateway will allow any new advances in Health IT to fit within an established framework, rather than forming a new silo. In a world of “unknown unknowns,” having the ability to think two steps ahead is a godsend. Let’s take advantage of it.
