[This post is part of a series I am writing as a HIMSS17 Social Media Ambassador (four years in a row!) in the run up to HIMSS17, in Orlando, February 19-23. Stop by and meet me at the first ever HIMSS Makerspace, booth 7785 in the Innovation Zone!]
The Interweb is a wondrous place.
A couple months I go wrote, From APIs to Microservices: Workflow Orchestration and Choreography Across Healthcare Organizations, featuring the Jolie programming language, the first programming language for programming microservices. (See the postscript to the previously mentioned blog post for my initial experience using Jolie.) Then I interviewed one of its creators on Firetalk, Wonderful Video Chat About Microservices in Healthcare, With Real Code Examples!
🔥🗣 in
— Charles Webster MD🤖 ()
Today, I get this extremely interesting proposal, to create an honest-to-good EHR workflow management system, using microservices and the Jolie programming language. There’s even code! I look forward to going through the proposal in detail, as well as downloading and executing the code — after HIMSS17. I am truly overwhelmed at the moment, between running the first ever HIMSS Innovation Makerspace, and my mountainous pile of Social Media Ambassador responsibilities… just kidding about that last part! 🙂 Anyway, I’m just putting this proposal as is, because I think it is an interesting addition to the #HIMSS17 health IT social media conversation. Feel free to comment at the bottom of this post, or in response to any of my tweets about this fascinating idea. Also feel free to contact Balint Maschio directly on Twitter () or by email (using my blog contact form to contact me so I can supply to you Balint’s email address).
The Interweb is a wondrous place.
(The rest of this post is written by Balint.)
This post is the result of a series of conversation between Chuck Webster and members of the Jolie developing team. Starting from the interest that Chuck payed to Jolie language, the conversation progressed on the possibility of use Jolie and microservices to implement EMR workflow management systems.
Abstract
The nature of EMR workflow management system can result a bit of ordeal for any software architect and programmer approaching it.
Typically a EMR workflow management system has the following characteristics:
- Extreme heterogeneity of database technologies and structures
- Highly dynamic and complex processes to be modeled
Therefore, to meet the challenges posed by an EMR workflow management system we need a design approach and technology that would be able to adapt effectively over time.
So what can it be the right approach: is it a
- Data centric
- Process centric
The data centric approach easier to start; but as the project gains complexity it fails to deliver the right degree of flexibility due to the ever more complex data structures required to represent complex processes . Also the process-centric approach presents its evident shortfalls; systems designed using a process centric approach often are very demanding on memory resources and they also require a complex management of messaging.
In our opinion, the solution lays in a different paradigm: the microservices paradigm. This paradigm allows to work indistinctly with both a data-centric approach and process driven approach The software architect will be able to:
- Design microservices that have operations and messages type highly coupled with the structures of a specific database( Data centric design)
- Design microservices that expose operations that represent specific step of a process with the process logic coded in the microservice and not in a data structure
Furthermore, the designer will be able to use the specific characteristic of each microservice to compose new processes, being able each time to shift the focus on the more convenient.
Also microservices have some innate characteristic :
- Easy to scale up only on real demand with dynamic deployment
- Messaging via lightweight protocols and using service discovery mechanism.
We believe that a microservices approach could be valid option in designing a EMR workflow management system. In the following pages the authors will propose an microservices architecture, that they hope will create interest among the Health IT community to this new paradigm.
Representation of EMR Workflow Actors via Microservices
The proposed architecture attempts to model the typical EMR workflow actors via microservices,
We have identified that microservices in such an architecture can be categorised into two main families
- Long lifecycle services: they are related to those activities or entities whose processes and data structures do not change considerably during their lives (ex: blood test laboratories)
- Short lifecycle services: they are related to those roles or activities whose processes and data can change a lot of time during their lives
This subdivision, in our opinion, will help the designer to crystallise some of the design decision that are so important when approaching complex architectures. In the following we illustrate them in details.
Long lifecycle services
- The microservices belonging to this family have some distinctive features.
- Their application scope is wider that a single instance of a process execution
- Their exposed operation can be consumed parallel by more actor
- Model clinical/administrative functions in the clinic.
- They are services that pivotal to functioning of the architecture
List of long lifecycle services can be :
- Resource services ( all those services that permit to access to the clinical or administrative capability present in the clinic)
- Data consolidation service ( The service that is responsible to consolidate patient and process data)
- Services registry ( the provider of a currently available instances of dynamically instantiated service)
- Planner Service ( service responsible of proving scheduling and planning of both human and clinical resources)
- Workflow Dictionary ( Service that provide pre constructed workflow matching specific clinical accident )
- Entry Service ( Service to deal with patient check in)
Resource Services
The nature of services belonging to his category is that they give access to the IT resources of entities such as:
- Blood analysis laboratory
- Electronic imaging department
- Physiotherapy department
- Billing department
One could think at these microservices as being data centric being strongly coupled to the data that the above stated entities, this is in general true but they could be also be approached as process driven when the microservices will act as orchestrator or data federator.
The advantage of approaching the modelling of clinical resources using microservices are:
- Facilitated remodelling of the microservice interfaces to fit the change of the clinical resources availability ( a new exam is available or the capability of a department has been increased)
- Possibility to expose easily part of your capability to external process ( cross hospital resources , clinical data sharing without duplication)
Data Consolidation Service
This service it is essential to maintain the data consistency of the all workflows, all though most of the cross microservices data exchange will not require accessing to Database resources we can identify several instances in microservice life cycle where an access to to data consolidation will required
- At start of service loading up characteristic data or historical data ( Patient clinical history, doctors or nurses scheduled appointments )
- At the end workflow critical step
- At the end of microservice instance life cycle.
The data consolidation service should not be used as a decision making tool, because in our proposed architecture the decision are devolved to the microservices cooperating in specific manner described by process.
On the other hand the data consolidation service can act as data federator accessing to several data sources, to present a process significant view of original data. This gives service some other interesting characteristics
- Capability of “retrofitting” existing database structures
- Increasing the decoupling between process and database structures
Services registry
The dynamically created instances of microservices are not aware of the location and status of the other dynamically created instances microservices, so it is necessary to implement a register that keeps track of all the short lifecycle microservices instances.
Such register service should expose these three basic functionality
- Adding a Service ( Any new instance of a microservice should register itself to register)
- Remove Service ( Any instance of a microservice before stopping to exist should unregister itself)
- Search Service ( Any service consumer should be able to get the location of any available microservice)
The register service will have not any function of message broker.
Planner Services
Any system that deals with resources allocation needs a strong core of resources planning, in our proposed architecture this task will be undertaken by a specialised microservice
Workflow Dictionary
Pivotal to the proposed architecture is the possibility to design specific EMR process independently by the existing workflow. Each designed process ( workflow) will be contained in a workflow dictionary. The user will be able to select any of designed workflow and generate a new instance of the selected workflow
Entry Service
This service acts as initial entry point for the start of any process ( Check-in, initial medical check up ecc ecc)
Short lifecycle services
It is always difficult to define what one means by short lifecycle, are we talking minutes ,hours , or days? We like to call “short lifecycle services” those microservices that halt to exist on the end of EMR workflow or the end of working shift.
In our architecture we identify two types of microservices
- Patient Services ( Instances of workflow applied to a specific patient)
- Staff Service ( Services that represent a specific member of staff)
Patient service ( Workflow instance)
A patient can be thought as instance previously defined microservices: working with instances instead of monolithic services will allow us to have a process of microservice behavioural template selection that is data aware.
For example:
- Mr Jones age 43 is admitted to our clinic ER for a trauma that requires a specific orthopaedic ER workflow.
- Several weeks after Mr Jones register himself at clinic for a scheduled follow-up visit.
- Months later Mr Jones turns up at the clinic general health check up.
In our approach Mr Jones is represented by three behaviorally distinct microservices instances, with some common EMR data from Mr Jones personal data and clinical history
We believe that our approach presents the following advantages
- Being process centric, new or more updated versions of the pre-designed process can be easily produced reducing greatly the burden of data remodeling.
- Processes ( instance of microservices ) can be generated at any point so that the patient will be the “owner” of several process. This should allow a greater degree of freedom in representing a real clinical workflows. (Ex The orthopedic specialist while visiting Mr Jones suspects an internal bleeding and order a MR workflow , pausing the initial orthopedic ER workflow)
- The lifecycle of each microservice instance can be decided by the designer allowing him/her to better fit the electronic workflow to the real world process. The designer also will be able to decide the granularity of each process, For example the orthopedic ER process maybe at a first instance designed as a unique microservice, then in a second moment split in several smaller “microservices”.
The patient’s microservice will be itself a orchestrator working with other microservices or software entities.
Staff Service
Following the same architectural paradigm the staff of a clinic can be also represented by an instance of a microservice The nature of the microservice behaviour can be model before to suite the professionality of each member of staff.
For example at first the designer may want design a staff’s ecosystem where only two type of microservices exist
- Nurse Service
- Doctor Service
- Patient Service
After some consideration you may want to specialise the behaviour in several new “types” of microservices
- ER Nurse
- Cardiac Nurse
- Orthopedic Specialist
- Cardiac Physician
- Cancer Specialist
All these new type of microservices may expose identical or similar interfaces but they will have a specific behaviour in terms of patient data visibility and human machine intractability. The instance of the microservices should also have their run time data reducing greatly the access to storages or DB.
The idea being that each microservice is self aware of is operative status having in memory most of the data that define such a status. The microservice will interact with a DB or Data Consolidation Service only at the change of status, or when its runtime data are not sufficient to complete a specific task ( viewing CT scan data ).Each instance of the staff microservice is available to be called by any instance of the patient service.
What technology to use to implement EMR microservices solution
We believe that Jolie language could represent a good technological choice for the implementation of microservice based solutions in the framework health organisations. Jolie has seen its genesis from a solid theoretical work aimed to create a new light weight microservice capable programming language.
The linguistic approach to the microservice programming , proposed by Jolie , gives the possibility to the programmer to use Think Micro Program Micro without needing to switch paradigm from the design phase to the implementation ( ex OOP or functional )
Furthermore Jolie has some characteristics that are very attractive for anyone approaching microservices programing
- Protocol agnostic ( you do not need to write a single line of code to handle protocol issues )
- All the variables are XML like tree without the burden of extra characters
- Can load and execute dynamically other services
Connected to this post we thought to be useful providing a simple example of the proposed architecture : as a demo the scope of this example is that of providing a working sample of some of the concept proposed in this post HealthServiceDemo.
[CW: As I previously indicated, feel free to contact Balint Maschio directly on Twitter () or by email (using my blog contact form to contact me so I can supply to you Balint’s email address).]