• By Terry (Coach T) Bazemore
• 03/27/2017

Improving Patient Outcomes with MicroServices (DIY)

Be sure to share and re-tweet this as a way to increase awareness.  Sometimes, the business functionality that an organization needs to systematically improve patient care and outcomes, is just not available in the systems that they use on a daily basis.  Every day, some health care business executive or IT leader, faces the pain of asking a health care systems vendor to change their "flagship" solution, in order to add some capability, that they know will improve patient care.  The response of long timelines and prohibitively high development costs is routinely disheartening.  The fact is that rapid changes to health care systems are risky to patient care and the requested changes may not match the direction of the system vendor's product.  As a result, rapid enhancements requests never happen fast.   The cost of forward progress is often exorbitant and usually associated with long turnaround times that include rounds and rounds of regression testing. 

With the advent of modern APIs and now MicroServices, the delivery landscape is changing.  Enhancing existing, and delivering new and valued capabilities may be accomplished without vast changes to flagship systems.  This can be done by leveraging MicroServices in combination with well-known interface engine technologies and already familiar web and mobile delivery patterns.    Because you have access to information in flight, extending capabilities may begin to seem like a do-it-yourself (DIY) pattern.  Here we provide an example of how to accomplish this with a walkthrough of a real-world health care scenario.  

Hospital and health care information systems share data typically in a human readable (but difficult to quickly decipher visually) format called HL7.   Sometimes, information needed by health care professionals is not available in the systems that they use, at least, not in a timely and accessible way that facilitates enhanced excellence in patient care.  This is because much of the data is typically hidden in non-human readable transactions or deep within information systems in a way that is hard to get at while serving patients.  Not only can this thwart increased excellence, but it can potentially lower the effectiveness of services provided to patients.  Here we discuss and provide an example of using MicroServices to enhance processes that aid in improving patient outcomes. 

A great use case for a MicroService is a Medical Document Management (MDM) producer service.   To paraphrase, HL7 guidance at HL7.org, the MDM message is intended to provide a comprehensive account of services delivered to a patient, in a health or clinical setting.  However, not every health information system provides the right MDM capabilities out of the box.  

A great way to augment existing health care information systems is to leverage an interface engine  with MicroServices.  The combination provides standards based health care message management and parsing along with the compartmentalization of reusable business services.  The result is, enhanced business processes to facilitate enhanced patient care, and all without demolishing the yearly IT Budget. 

Use Case Overview:  

In order to improve the effectiveness of patient care and outcomes, the Hospital Radiology Team wants to make available, human readable Radiology Transcription Reports (MDM Report) and MDM messages.  These messages would be generated in real-time, from transcription notes created by offsite Radiologists.  This information is currently trapped in HL7 Order Result messages and only partially accessible in current systems, or not available as a legible and legally compliant document or report.

A great way to augment existing Health care systems is to leverage an interface engine with MicroServices.

 

The Problem: Health Care Information Systems Vendors can’t change their systems rapidly for fear of impacting integrity.

It is the patient that may suffer when information is hidden or unavailable.  However, it is quite normal to need capabilities not found in primary health care management systems.  These systems do change and improve over time.  However, system and information integrity far outweigh the need for speed.   This is because changing a core, flagship system is difficult, costly and time consuming.  Hospital and radiology management information systems vendors typically do not favor quick turn-around, one-off enhancements in their core systems, even when doing so may improve overall patient care.   This is because, quick turn-around changes could mean introducing defects into systems.   Consequently, defects may negatively impact patient care.  Vendors certainly do not like to make changes that don’t match the core value of their systems.   

The Solution: Insert an Interface Engine & MicroService combination into the Messaging Pipeline

The best solution is often to intervene in the normal message flow, to systematically screen and direct targeted message types in real time, to MicroServices.  This can be done without changing the current business process. Thus, primary systems are not affected and the new capability is functional in less time, and at a lower cost than requesting changes to a vendor's “Flagship” system.   By doing so, you extend the capability of your overall operational process without changing the primary or ancillary systems. 

The Medical Document Management (MDM) Producer MicroService would be an autonomous business function that provides a very specific and reusable capability that aids in enhancing transparency and effectiveness in patient care.  By transparency I mean, getting the right information to the right health care professional, in real-time, at the right time.

The Example

For this initiative, our MicroService will receive medical order results (HL7-ORU) messages that may contain doctor’s notes about a given patient study or test.  The MicroService will generate in real-time, human readable MDM Reports (in Word or RTF format) and MDM messages to synchronize dependent health information systems.  Legible MDM reports will be placed into a secure repository adjacent to the Radiology Information System (RIS).  MDM messages will be sent directly to the RIS system’s interface and will include a reference to the human readable and printable MDM Report located in the adjacent file store.  This means that users could be provided with secure access to legible content via the RIS, or perhaps via a secure web or mobile enabled portal.   The MicroService could even provide health care professionals with up to the minute status changes for specific transcriptions, in the form of mobile notifications or alerts.  This could allow professionals to quickly retrieve and view, or forward the sequenced updates to another professional involved in the patient’s care.

What makes this a MicroService:

MicroServices typically manage their own data.  This service would maintain a database of transcription session's identifiers, sequencing information and the status changes for each session.   Thus, this MicroService would be an autonomous application, maintaining its own data and exposing an endpoint to receive messages from an interface engine that is non-invasively intervening in normal flow of information.  The end solution would facilitate a singular business focus, be exposed via an API gateway (external) or TCP endpoint (internal).  It will synchronize its data with dependent systems.

Components:

A.    MDMProducer MicroService Model

o   MicroService Server Connection        

§  Service Endpoint

§  Source Code

o   Synchronization Route

o   Synchronization Connection and Endpoint

B.    MDMProducerDatabase

o   Tables

o   Stored Procedures

C.    File Repository

D.    MicroService Unit Test Client

E.    MicroService Unit Test Messages

Steps:

1.    Create MDMProducer Database

The MDMProducer database will be a simple design (containing a single table) to track the processing status and sequencing of HL7 Order Results generated from transcription sessions that are completed in the upstream medical transcription system.  As Order Results (HL7-ORU) are received by the MicroService, it stores a record of the event.  Because “Order Results” may be received in phases (e.g. Initial, Amended and Final) the MDMProducer MicroService stores a record for each phase reported. This is important because Medical Personnel need to know if the study results transcription is Initial, Amended or Final.  In addition, the content of the Medical Document may be different depending on the previous state of the transcription session.   The MicroService may execute different logic based on the previous state or triggering event.  The trigger indicates the event that caused the communication.

2.    Create File Repository

For the purpose of this article, the File repository will be a simple folder on the file system.  However, in a full enterprise implementation, the file repository could be exposed by a web service, a B2B managed file transfer endpoint, etc. 

As an example, customers could leverage a NexusHIE Secure Cloud Managed File Transfer Service (Monthly Fee) to receive binary files and standards-based messaging files to route and store content in their local repositories.

3.    Create Stored Procedures

This simple Micro Service will have 3 stored procedures (Create, Find and Update).  The methods allow the MicroService to track the state of each Order Result that it processes.

4.    Create MDMProducer MicroService Model

We will use tools from the ConnectMate Interoperability Suite to create configurable MicroServices and messaging interfaces.  We will start with ConnectMate Studio, a graphical modeling tool for creating MicroServices and health care interfaces.   Within the ConnectMate Studio, we set up the properties of the MicroServices, we define routing and synchronization elements and properties, and add code to event handlers in order to round out the functionality.  Once complete, we can publish the MicrosService as well as synchronization elements to our targeted test (and ultimately our production) processing server. This is done in accordance with your delivery lifecycle.

    o   Add MDM Server Connection and Unit Tests

In the figure above you see that we have added:

A.    The MDMProducer MicroService

B.    A Synchronization Endpoint to synchronize changes with the Radiology Management System

C.    A Unit Test driver which is responsible for sending test messages to the MDMProducer MicroService

D.    A Unit Test Endpoint that connects to the MicroService either via an API Gateway endpoint or an internal TCP Connection

 

§  Add Service Endpoint Configurations (HTTP or TCP Socket)

In the figures below, we see endpoint configuration examples for the MDMProducer MicroService.  This shows how the MicroService can be exposed as an internal service, via https or TCP, or as an external REST API via the ConnectMate API Gateway.

·       Add Source Code

Next we add reusable functions and event handler code:

o   Reusable functions such as:

§  ProcessOrderResults()

§  CreateMDMDocument()

§  CreateMDMMessage()

o   MicroServices Process Event Handlers:

§  To accept and parse the inbound ORU messages

§  Transform and generate both MDM messages and readable MDM Reports

§  Write transcription status events to the MDMProducer database

§  Store MDM Documents

§  Synchronize MDM messages and document references with the Radiology Information System (RIS)

§  Send update notifications and alerts

§  Handle exceptions and send alerts

Below is an example of source code in a MicroService event handler.

5.    Publish MDMProducer MicroService and Unit Test elements

To complete the development phase, we publish (deploy) the new MicroService configuration and unit test (including scripts or compiled code modules) to the processing server.

6.    Test MDMProducer MicroService and Unit Test elements

Once the MicroService is published, testing is a matter of initializing the unit test with data (ORU messages).  In our example, we give the Unit test harness an endpoint that points to a file folder, similar to the way that we configured our REST and TCP endpoints for the MDMProducer MicroService.  So, we can simply drop sample ORU messages into the file folder that the test harness monitors and the test harness will send messages to the MDM Producer Micro Service. 

7.    Monitor MDMProducer MicroService and Unit Test elements

During testing and in production, we monitor the processing and performance of our MicroService and test harness using the ConnectMate Management center.

In Summary

Every company, in every industry, wants to increase its agility in bringing new capabilities to market, in order to serve its customers better.  MicroServices provide a new approach for delivering, enhancing and maintaining system functionality, to extend overall business capabilities.  MicroServices have the ability to increase speed to market for new business capabilities, and enable better maintenance of existing services.  When coupled with an interface engine like ConnectMate that offers specific capabilities for health care (e.g. HL7, C-CDA, FHIR and NCPDP message parsing along with multi-protocol support and routing), MicroServices can change the agility landscape of any organization whether in or outside the “Health Care Continuum”.