NB: this series is still a work in progress.
Healthcare AI Infrastructure
This post started as a brief overview of healthcare AI infrastructure and then grew into an unwieldy saga incorporating my perspectives on building and implementing these tools. As such, I split the post into a couple parts. This part provides a general introduction, aiming to ground the discussion in the existing HIT landscape and setting up the general approaches for development and implementation.
This post is followed by detailed posts on development and implementation. In addition to providing more technical details these posts also walk through a couple projects that I’ve taken through the AI lifecycle. I hope that discussing these projects will make the concepts a bit more concrete.
Additionally, I’d like to note that the primary focus will be on AI models that interact with the electronic medical record (EMR) and related enterprise IT systems used by health systems. This is partly due to the fact that this is my area of expertise - I’ve built and deployed several models in this setting. However, it is also the area where it makes the most sense to connect AI models, as these software systems are the ones most closely tied to care delivery. Given this framing, we will now lay out the major components.
Basic Healthcare IT Infrastructure
Its important to ground our conversation in the basic healthcare information technology (HIT) infrastructure, primarily focusing on electronic medical records systems (EMRs). The reason for this is that the EMR is usually the source and destination of information processed by healthcare AI systems. Having a solid understanding of the parts of the EMR is the foundation to good healthcare AI infrastructure.
You can think of an EMR system as having two main components a database and client. The database’s primary job is to store the underlying data of the EMR - patient names, demographics, vitals, labs, all the good stuff. The client’s job is to present the user the information in a way that a human can understand. There’s a whole bunch of additional code, configuration, and data that we aren’t going to directly discuss, but we may obliquely refer to the amalgamation of that stuff along with our friends the database and client. The term front end refers to the client and all of its supporting code, configuration, and data handling mechanisms. Back end refers to the database and all of its supporting configuration and communication code along with any other code that drives the logic and behavior of the EMR.
To make things more concrete I’ll briefly discuss the Epic specific names for these components.
Back end: Chronicles
Epic has a large back end written in a programming language called MUMPS (it is also known as M or Caché, which is a popular implementation of the language). MUMPS is a pretty interesting language for a variety of reasons (integrated key-value database, compact syntax, permissive scoping) - so I might write about it more in the future. The database management system that holds all of the operational real-time clinical data is called Chronicles, it is implemented using MUMPS for both the data storage and code controlling database logic, schema, indexing, etc.
Front end: Hyperspace
There are several distinct front ends for Epic; however there’s one that’s by far the most important - Hyperspace. Hyperspace is the big daddy interface that is found on all the computers in clinic and the hospital. It started out as Visual Basic application (I once heard a rumor that it was the largest piece of software ever made with VB); however, it is now mostly a .NET application. If you’re a doctor you may also interact with Epic’s other client software, like Haiku (client for mobile phone) and Canto (client for iPad). Hyperspace is the primary place that clinical work is done, notes are written, orders are placed, and lab values are reviewed here. These workflows are the primary places where additional contextual information would be helpful or where you would want to serve a best practice alert. Thus, since Hyperspace is the most likely end-target for most of our healthcare AI efforts.
There are a couple of ways to get information into Hyperspace. The first is to put stuff into the underlying database, Chronicles, and have the information integrated into the underlying mechanics of the EMR. The second is to have Hyperspace display a view of the information, but have it served from a different source (like your own web server). This is usually done through a iframe.1 These options are not limited to Epic EMRs, you should be able to take either approach with any type of modern EMR system.
Now that we have discussed the basic healthcare IT landscape we can start to talk about the specifics of making AI tools for healthcare.
AI Development Infrastructure
Now we can start to dig into the fun stuff - the actual building of healthcare AI models. At the most basic level you need two things to start building an AI model: data and development environment (a computer). Data often comes in the form of a report or extract from a database (often the EMR’s database). This data are then used to train a model using a computing environment that is set up for training models. These environments tend to be computers that are configured with special software and hardware that allow model developers to write code that can be used to develop and evaluate a model.
The above figure depicts the generic data flow for model development. Generally the data will flow linearly from a source clinical system towards our model development environment.
AI Implementation Infrastructure
Now we turn our attention to connecting models into care processes, implementation. As discussed in the previous post, implementation goes beyond the technology, however, the primary focus of this section will be on the implementation step of technical integration, the nuts-and-bolts of connecting AI models to existing HIT systems.
There are two primary ways to integrate a model into existing HIT systems and they are delineated by the relationship to the EMR: internal and external.
Internal integration of models means that developers rely exclusively on the tooling provided by the EMR vendor to do the hosting of the model along with all of the logic around running it and filling the results.
External integration of models means that developers choose to own some of parts of the hosting, running, or filing (usually its the hosting piece).
In both scenarios data ends up flowing from the EMR database to the model, however the path that these data take can be drastically different and significant thought should be put into security of the data and the match between the infrastructure and model’s capabilities.
It is important to note that these approaches delegate the display of model results to the EMR system. They do this by passing model results to the EMR and using EMR tools to display the results to users.
A Note on Color Coding
Throughout this series I have tried to employ a consistent color coding scheme to delineate the owners of different HIT components.
Everything that is made and maintained by the EMR vendor (or their proxies) is red 
.
Components owned by AI model developers are colored green 
.
Components represent shared research infrastructure that may be owned by the health system or research enterprise are blue 
.
Elements that don’t fit directly in one of these buckets are outlined in black 
.
What’s next?
Because its a shiny new toy, healthcare AI can sometime seem like it should be in a class of its own compared to existing technologies. This is absolutely not the case, good healthcare AI is good HIT. In my mind, there is no real distinction between HIT and healthcare AI, because they interact with the same data and users.
A comprehensive understanding of EMRs and associated clinical care systems is paramount in the development and implementation of healthcare AI models. In the next post we will cover some of the tooling surrounding model development. That will then be followed by a post focused on implementation. Finally there will be short post with some related miscellany (covering some of my favorite hacks).
Cheers,
Erkin
Go ÖN Home
-
This can be complicated to do because you need to maintain you own application server and also deal with passing authentication between the EMR session and your application. ↩
