Microservices in EHR

Microservices in EHR

In 2019, NeoDeck Holdings embarked on quest to recreate in less than 24 months what took almost 19 years to create, it’s primary product NeoMed EHR. The EHR also had to be fully certified in less than 10 months after development started.  That upon itself was a big challenge, but NeoDeck also decided that it would develop, from scratch a new a billing system, NeoBiller.

This journey was filled with incredible challenges, both technical and non-technical, and required a level of development speed that had not occurred in the company, ever. As companies grow old, their flexibility and speed of development usually slows down. This has many reasons, but are beyond the scope of this text. Here I will briefly discuss one of the factors, the architecture, that allowed us to swiftly accomplish our goals.

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable, organized around business capabilities and owned by a small team.[1]

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

Many EHR systems have been in production for a long time. In NeoDeck Holding’s case our NeoMed EHR 3.0 has been in production since 2002, around 19 years and counting. This was before Microservices were a thing, and before even SOA (Service Oriented Architecture) was mainstream. SOA is what Amazon originally used to develop its architecture and is a predecessor of sorts to Microservices.[2][3]

There are ways to convert an old application to a microservices architecture, but these require complex upgrades of multiple technologies stacks. NeoMed 3.0’s stack did not even lent itself much to that upgrade, been an old Client/Server monolithic application.

NeoDeck decided that, since an EHR is an extremely complex system, involving a myriad of external interfaces, international standards and both user and government requirements, a Microservices architecture would be a good fit. To make this decision, we spent various months researching exactly how we would implement it and the specifics of which technologies we would use.

One of the primary things we came to understand, as time went one was a basic principle of Microservices, that anyone who is considering the decision should take in consideration: Microservices are hard.

What this means is that the benefits of implementing microservices should outweigh the costs, considering that the costs are very high. In NeoDeck’s case, the cost could be summarized as follows:

  • Teaching the entire development team how microservices work and a whole myriad of related technologies such as Kubernetes, Docker, Service Bus, among others.
  • Creating a fully automated Development Operations flow.
  • Developing a new database system around events (Event Sourcing[4]).
  • Structuring teams to accommodate the architecture.
  • Creating a template-based approach to building new services, including a strong shared framework for development.

Each of these points deserves its own blog post, but here I only want to list the big steps that had to be undertaken to even begin the development of what became NeoMed 4.0 and NeoBiller.

Beginning Microservices development takes considerable effort. Once the project begins, you usually enjoy the benefits:

  • The team can push an update to staging and then to production in a matter of minutes, making bug fixes almost instantaneous after they are discovered.
  • Backend and frontend teams can be separated, since they worked with each other using service contracts. Making them independent doubled the amount of work they can produce because they can focus on independent concerns.
  • EHR modules could evolved independently, multiple modules can be worked on at the same time without any kind of conflicts.
  • New modules can be done in weeks as opposed to months before. Using templates for services allows us to focus only on the business needs of services instead of on how to build them.

An example of how all of this work would be when somebody logs into NeoMed and searches for a patient to see their encounters. First the user signs in, this is the identity microservice, then they go to see their list of subscriptions, here they are using the subscription microservice. Once they select their subscription they go to the search page, here they’re using the demographics microservice, and then they want to see the encounters of the patient, using the encounters microservices. For the user this is all transparent, but internally each service communicates and shares data of other services, making the experience happen fast and reliably.

Looking back from 2021 to the past two years, Microservices helped us complete our goals on time and reach a level of development speed that we did not thought would be possible, and that is not normally possible with monolithic applications, where everything is on a single code base and all features and fixes must be completed together.

[1] https://microservices.io/

[2] https://www.zdnet.com/article/soa-done-right-the-amazon-strategy/

[3] http://highscalability.com/blog/2016/7/13/why-amazon-retail-went-to-a-service-oriented-architecture.html

[4] https://microservices.io/patterns/data/event-sourcing.html