DX, API Design & Documentation

Architecting healthcare integrations for scale

339views

Nick Hatt is a Staff Engineer with Redux. In this article, he discusses patterns in the healthcare industry for integrating data.

The healthcare industry has many patterns, and many of them are historic. Old standards are not always developer friendly. But recognizing these patterns and designing your app can help you scale.

Typically, in healthcare, there is a source system that generates a lot of data. It could be a system of record for whatever kind of workflow you’re trying to accomplish. There is a receiver (client), which could be a data consumer. In healthcare, we call such a system an Ancillary system. The source system and the ancillary system have a synchronization mechanism that allows for data exchange.

It is a null case if there are no connections or integration. There is no data exchange.

Pattern 1 – Query

The ancillary system connects to the source system and initiates a request for some data. The Source system responds synchronously or asynchronously with the data.

Pros of querying are –

  • It defaults towards statelessness. You can query and get the most current snapshot of whatever data you’re trying to get. And if the data changes and you query again, you get the latest data.
  • RESTful architectures fit naturally.

Cons of querying –

With querying, you do not get automatic real-time updates; you must query to get the data. You depend on the source system and the query to get the data.

Pattern 2 – Event + Query

This pattern is closer to real-time events. An event triggers information from the source system. The source system sends out a notification to the ancillary system. It may have all the required information, or you may have a query and go back to the source for more data. This is a good pattern because you do not expose too much information till there is a specific query.

The event plus query solves a few of the problems of only query. You don’t always have to “pull” data; the event will trigger data exchange. So, it allows more flexibility with architecture.

The real con is that there will be multiple connections and multiple directions of flow. This becomes query-intensive.

Pattern 3 – Event-carried state transfer

In this pattern, everything is in the payload. There is no query back from the ancillary system. If you miss out on any update, there is no way to get the missing information because a query is not possible.

The source system blasts out a big payload of data according to an established format or standard. Then it’s on the receiver to just receive it. So, the benefit is that it is decoupled; you listen to a feed, and you can do whatever you want with it. The source system doesn’t need to do too much logic or anything similar; they format a payload and blast it out.

On the flip side, the volume of data that gets exchanged and stored is large, and over a period of time, data consistency can become an issue.

Pattern 4 – Event sourcing

It is a good pattern for healthcare but is difficult to implement. Events build on top of each other. Git and Bitcoin work on this pattern. The complexity of healthcare data doesn’t lend itself to this type of flow.

Pattern 5 – Update-Command

In this case, the source or ancillary system makes a command on the other system and gets data or action based on that command.

This has a high level of coupling, which is a necessary evil.

Pattern 6 – Single Sign On (SSO)

A very common workflow is to embed an application within the ancillary system, an IDP (Identity provider). The user is involved in authorization, and then you can go back and do a query workflow.

HL7

Health Level Seven, or HL7, is a range of global standards for transferring clinical and administrative health data between applications.

HL7V2 closely resembles event-carried state transfer, but some domains look like commands.

FHIR is mostly architecture agnostic

CDA is totally architecture agnostic

Nick Hatt

Nick Hatt

Product Designer at Redox
Nick was one of Redox's first engineers. Today he continues to work on the Redox API, and obsesses over making Redox developers lives as easy as possible. He regularly writes and speaks about about interoperability in healthcare, life as an early startup employee, and developer relations. Prior to Redox, Nick was an engineer at Epic. He lives in State College, PA.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture