Apollo on FHIR Architecture

Recently, I’ve been answering a lot of questions about integrating Meteor on FHIR and the Clinical Meteor project with different back-end technologies. The questions are somewhat all over the place, and generally include the following:

Q: Can Meteor apps connect to our SQL database? 
Q: Can Meteor on FHIR work with our Hadoop datalake? 
Q: Our iOS client is written with React Native; how can we integrate Meteor on FHIR into our stack and contribute to the project?
Q: W’ve been moving away from Meteor towards React/.NET. How can we use the Meteor on FHIR webservices? 
Q: We have an existing Python based genomics pipeline. How would you integrate with us? 
Q: Do you support R, Python, and SAS bioinformatics pipelines?
Q: Do you support graph databases?
Q: How can we integrate the _____ web API? 
Q: Do you support Internet of Things and other smart devices?
Q: Blockchain!

And so on and so forth.

These questions have been kicking about in one form or another for years, and today I’d like to introduce to you the outlines of the next-generation architecture for Meteor on FHIR, Clinical Meteor, and Symptomatic Apps. Today, we’re going to introduce a database proxy. Specifically, we’re going to start outlining how the Apollo GraphQL server integrates with Meteor on FHIR.

Before diving into the Apollo on FHIR architecture, let’s review a couple ideas about how we prepare and send data from servers to clients. We’ve spent much of past two decades sending data on the internet through REST endpoints. REST endpoints are server-oriented, in that they general represent an underlying database, data query, or collection. It is up to the client to contact multiple REST endpoints, gather the data necessary, and do something with it in the web page or webapp.

GraphQL is a newer client-oriented technology. With GraphQL, data is assembled on the server, and sent to the client in a format as close as possible to what the client needs for final page rendering. Each GraphQL endpoint is designed for a specific client; and often a specific client component or user interface. In this sense, it’s similar to a mainframe terminal or thin-client, in that page layout and data parsing is done on the server as much as possible.

The Apollo server builds upon GraphQL by fetching external endpoints, bundling them up into GraphQL queries, and exposing them as publication/subscriptions so apps can have real-time responsive interfaces.

Credit to:

Fantastic. We can consolidate our client side queries into single lines of communication with the server; which reduces network bandwidth, and simplifies client side development. So, how does this relate to Meteor on FHIR?

Well, to answer that question, we need to step back, and take a look at what the Meteor architecture looks like. Extending the above network diagram, the Meteor stack can be roughly described as a MongoDB database, connected to a Node.j server, which instantiates the Meteor object. The Meteor object sets up publication/subscriptions via the Data Distribution Protocol to the client, which is running React. And in the case of Clinical Meteor and Symptomatic Apps, is also running Material UI.

So what does Meteor on FHIR bring to the table? First and foremost, it brings the FHIR standard, which is essentially a REST API. But it also brings data schemas. And what’s really fantastic about Meteor, is that it uses isomorphic javascript. Between these two things, we can use the FHIR schemas as our database schemas, server validation schemas, client schemas, and via our REST endpoints. This is phenomenally useful; and creates what we refer to as our data layer.

So, what does Apollo provide, then? Having a FHIR compliant data layer seems really great. Why would we need Apollo?

Backwards compatibility. As much as we may want to focus on next-gen interfaces and protocols; the fact of the matter is that the bulk of healthcare is squirreled away behind firewalls and in proprietary data-stores. So, what Apollo provides is a database proxy, which can connect to multiple database backends…. SQL, Oracle, Cassandra, Hadoop, BigTable, etc. The Apollo database proxy is designed to manage database queries, and map them onto a GraphQL data query.

What’s of particular interest, however, is that this database proxy isn’t just limited to static databases. It can also handle web APIs, twitter feeds, RSS feeds, and other forms of streaming data. And that means it can connect to the Meteor on FHIR endpoints.

So, bringing it all together; what we want to do is layer the Apollo database proxy so it queries the Meteor on FHIR rest endpoints. With such an architecture, our GraphQL queries can proxy to SQL, Oracle, and Apache databases, as well as connect to FHIR databases, FHIR caches, FHIR proxies, and FHIR enabled apps.

Pretty exciting, right? A FHIR enabled healthcare interoperability data layer. There’s a few refinements we’re still working out, but this is the general idea. Apollo proxies to web services, database, and Meteor on FHIR; and Meteor on FHIR is providing schemas between our FHIR database, server, client, and REST endpoints.

Thanks for reading through.

References

GraphQL and the Amazing Apollo Client
Fast Healthcare Interoperability Resources
Clinical Meteor Track