Travis Broughton | Enterprise Architect
May 09, 2014

API Gateways: Preserving the Value of Legacy Healthcare Data


As new devices and technologies promise to deliver ever-improving healthcare to more individuals, it’s easy to lose track of the tools that we already have.  It’s also important to remember that the best outcomes involve a combination of old and new technologies.  Healthcare can be made more efficient and more effective by allowing improved access to information - across multiple devices, and across multiple providers.  In this post, we’ll look at a few areas where APIs can enable new consumption models for legacy data:  mobile applications for caregivers, mobile apps for patients, and Health Information Exchanges (HIEs).

Can You Read That?

The stereotype about doctors’ handwriting is probably as old as the profession itself.  Fortunately longhand notes seem to be going away, replaced by computerized records.  However, as even the most routine appointments frequently involve multiple caregivers (nurse interview, a few minutes with the doctor, possibly a stop by a lab), these records need to be available to multiple people immediately after they are recorded.  Some offices and hospitals use laptops to accomplish this, but many providers see even more benefit from the increased mobility of tablets.

Tablet devices introduce additional IT challenges that can be addressed - at least in part - through APIs.  By using APIs, back-end services can be consumed through a wide variety of apps, from native or HTML5 apps on mobile devices to web or enterprise apps on laptops.  Unfortunately, the legacy services on the back end may not be presenting data in a mobile-friendly manner.  The service may be using XML (if you’re lucky), an older, non-XML based variant of HL7, or a proprietary data format.  This can prove challenging to the app developer, who is probably expecting to consume JSON or at least depend on an XML-based HL7 library to simplify coding.  Also, even though the provider may manage the device, identity management and other security concerns may prove difficult to negotiate between modern mobile app architectures and legacy data services.

Checking In

Doctors aren’t the only ones who see the benefit of mobile apps and multiple devices.  Consumers want to be able to use their phones and tablets to make and check appointments, review and pay bills, and even monitor their health.  Mobile apps can allow patients to more easily use services from providers and insurers.  While most devices can deal with a well designed web portal and downloaded PDFs reasonably well, a better user experience can be delivered through an app.  Native rendering of the data can reduce confusion while providing a more responsive experience.

This B2C model comes with all the usual complexity of mobile devices, along with the security concerns that arise when exposing data outside of the corporate firewall.  The breadth of customer devices and consumption models requires a secure, device-independent mechanism for exchanging data.  But it is more cost-effective to layer these capabilities on top of existing services rather than replacing them all at once.

Agents for (ex)Change

Health Information Exchanges have perhaps the most audacious goal:  facilitating access of data across organizational boundaries.   When done correctly, these exchanges can improve continuity of care while lowering costs.  Similar to the internal (tablet) case mentioned above, HIEs can deliver near real-time access to patient data across multiple providers and provider groups.  No more photocopying charts and sending them across town with a courier, meaning less expense and less room for error.

Health IT and Meaningful Use legislation are going a long way towards streamlining some of this interoperability.  It’s clear that APIs will play a significant role in enabling the exchange of patient information.  Standards like HL7 are emerging and evolving to address interoperability concerns.  But these will only go so far – there is still a need to map back to the provider’s internal system and bridge formats, protocols, and identity systems.

Gateways to Success

To bring about the good kind of disruption as quickly as possible — while minimizing the bad kind of disruption — it’s desirable to preserve access to legacy services.  Rather than undertaking the cost and time of migrating to new “mobile-ready” versions of software, it can be more cost-effective to provide a layer of middleware to expose legacy services for mobile until a natural upgrade cycle provides native functionality.  A service gateway can allow a provider to repackage internal, legacy services as APIs for mobile, partner, and customer interactions.  The gateway can handle data format exchanges, wrapping the internal representation with an HL7 schema or wrapping HL7 in a JSON schema for easier mobile app development.  The gateway can also address security concerns, from encrypting the data to mapping between identity systems.

The other advantage of a gateway approach is that it allows for forwards- and backwards-compatibility.  As a simple example, versions 2 and 3 of HL7 are markedly different from one another.  Version 2 was character-delimited, while version 3 is XML-based.  A gateway protects investment, allowing interchange between different data formats, so a provider that begins today can protect their investment if the format changes in the future.