Summary

This presentation aims to integrate a number of different themes on how to increase collaboration within an open source electronic health record platform - OpenMRS

Specifically, the presentation proposes increasing modularity as a critical element to be able to build a platform where it is easy to collaborate among multiple EHR implementations. A

model of horizontal and vertical modularity is proposed, and the impact this can have on governance and software collaboration.

Ironically, this post is a big of a monolith. Instead of reading, consider watching the presentation and slides (in fast forward) in the YouTube video below. You can also subscribe to the podcast to stay uptodate, but I recommend for this post to watch the visuals.

Presentation Index

Part 1: Perspectives: on OpenMRS 3
- Ongoing OpenMRS 3 Conversations
- OpenMRS 3 Wish List
- OpenMRS Meta-Narrative: Fragmentation & Collaboration

Part 2: Principles: of Modularity
- Definitions: Modularity, Component, Modules, Template
- Modularity: first principles from the physical world
- Modular Organizations
- Interoperability within an EHR
- Benefits of modularity in an open-source EHRs
- eg 1. Horizontal & Vertical modularity in an EHR
- eg 2. Drag & Drop development

Part 3: Proposal: for Modular Architecture
- Architecture, Organizations, Processes
- Monoliths, Microservices, Service Orientated Architecture
- Modular boundaries
- Communication Protocols, Event Sourced,  CQRS
- eg 3. AMPATH
- eg 4. Detailed modular EHR architecture
- Downsides of these technologies
- Decomposing the Monolith

Summary & Next Steps

Overview

Today’s presentation has three parts to it.

Part 1 Perspectives: OpenMRS 3, looks at ongoing conversations, OpenMRS 3 wish list, and the overarching narrative around fragmentation

Part 2 Principles: of Modularity, highlights the role of modularity in the physical world, in being able to organize companies, and why it makes sense for electronic health records. Part 2 ends with a very high level example of a modular EHR.

Part 3 Proposal: Modular Architecture will review in more detail the software benefits to modularity, and some of the technologies that may make this possible.

As I mentioned, the overall theme is: how do we design an EHR platform that makes collaboration easy?

PART 1
Perspectives: OpenMRS 3

Ongoing Conversations

Its healthy for an organization to discuss the next steps. And this has been going on for a number of years. You can find a number of talk posts discussing new feature ideas,

You can find Talk conversations on OpenMRS 3, Monlith vs Microservices, Cloud native, foundational disease support, Docker, Kafka, Kibana going back to 2015.

Each conversation brings with it new ideas for new features and better technologies.

A few weeks ago we put out a heuristic on Talk suggesting there may be three different conversations happening about OpenMRS 3.  Some conversations were more about baseline essential operations, others about upcoming 6-18 month priorities, and some focused on large ideas with timelines in the 2-5 year timeline.

I’ve tried to go through and collect these conversations from Talk, Design Calls, Scrum of Scrums, and past implementer surveys into a single document. It’s not done yet, but I think this type of document will be very helpful to bring together past work, and identify where is common overlap in 6-18 month priorities.

OpenMRS 3 Wish List

If we were to extract some specific high level themes. In particular from Nairobi 2018 conference, users want a system that:

1. Is fast to implement, customize, and configure without developers
2. Has libraries of shared concept dictionaries, reporting indicators, clinical workflows, forms, clinical decision support tools, and reports. (eg. Disease specific libraries)
3. Has an intuitive user interface that works on mobile, tablet, and desktop designed for use at the point of care
4. Supports multi-tenancy and cloud implementations at scale, with mirroring, backup, and tighter security
5. Uses advanced sync and offline capabilities
6. Has a straightforward pipeline for tracking indicators and moving data from acquisition to report generation
7. Is interoperable with other systems, FHIR friendly
8. Uses new technologies: eg PostgreSQL, Reactive Native, Docker, etc
9. Is modular in its development to encourage multiple developer communities
10. Handles billing, insurance, and hospital features
11. Works for chronic disease, and non communicable disease (NCDs)

I think this is awesome. But the problem with this, is that no single implementor can build this. And no single commercial EHR vendor can build this. And nobody will provide a billion dollars to build this from scratch. Each of these ideas is a really big boulder to move, and it's complicated, because each boulder is tightly joined to the other parts of the system.

I think in part this is why there has been increased fragmentation, because sometimes instead of trying to work within OpenMRS, it's easier to go and build something else from scratch.

[Read the full summary of the OpenMRS 2018 Nairobi Conference, Brainstorm Session]

Meta-Narrative: Fragmentation

Which leads to a recurring theme I heard in Nairobi, and that Burke did a great job highlighting in his October presentation. That is of the increased fragmentation of OpenMRS implementations in the last few years. Fortunately, there appears to now be a desire to focus again on collaboration, and this is important.

To underscore the importance of moving from fragmentation to collaboration, a quick thought experiment comparing two futures.

In version one, Fragmentation increases. Implementations continue to develop tools that are unable to be effectively shared across the platform, this reduces the ability of the platform to develop as an EHR. Overtime the quality and usefulness of OpenMRS decreases. The technology of the system stagnates. This makes it harder for OpenMRS to be adopted as a system. It reduces interest in volunteers contributing to the platform. Fragmentation makes it difficult to fundraise to fundraise for OpenMRS. Ultimately the long-term stability of OpenMRS is uncertain, given the downward spiral caused by fragmentation.

In the second version, Collaboration increases. Implementations develop tools that are shared across the platform, and OpenMRS’s quality increases. It becomes more useful, easy to use, and stays up to date with modern technologies. This increased adoption of OpenMRS as a platform, increases volunteer support. Collaboration makes fundraising for OpenMRS straightforward. Ultimately OpenMRS has a bright future, helping improve global healthcare, as upward momentum continues to build though collaboration.

And so the critical question is, how do we design an EHR architecture that makes collaboration easy?

Which leads us to Part 2: Principles: of Modularity

PARTS 2
Principles: of Modularity

Definitions

Before we go on, we also need to define a few terms.

I’ve seen the word Module in different EHR suites used to define everything from a complete implementation of an EHR such as acute care, to a single user interface component such as medication reconciliation, to a disease type tuberculosis, to a feature, such as interoperability.

To help create less confusion, let's consider:

Modularity - to be the ability to combine isolated elements together. This may represent a

Component - a term we will use specific to user interface modularity

Modules - a term specific to the software architecture elements, loosely coupled with bounded contexts

Template - to be themes that configure a set of components and modules around a specific theme, just as Hypertension, or HIV.

We can always change and evolve these terms in the future, at least it helps define how there are different types of modularity we are talking about

Modularity: First Principles from the physical world

As you already know, I like to start projects from first principles. These are five observations about modularity in the physical world.  A we go through them, consider why they are important for the digital word.

Observation 1: Almost everything in the world involves modular components

Wherever you look, is modularity. Reusable elements coming together into larger wholes. Cells, tissues, organs. Atoms molecules elements. The materials used in the construction wood, steel, doors, windows all are manufactured with standard specifications and standard sizes. Electronic devices are assembled from standard components.

Modularity allows for nature and for us to construct and build quickly and cost effectively. It allows for efficient and effective distribution of resources and labour. It enables competition and innovation in the marketplace. Modularity, is a critical part of life. And makes sense to incorporate as much as possible in our digital world.

‍

Observation 2: Understand the module’s borders & boundaries

An important consideration when designing modularity is the boundaries and borders of the modular components. Consideration the extent that modules need to work within an internal system, versus if they need to work with an external system.

In the 1950s modular furniture systems came on the market. Each modular system was meant to connect to objects within the system, but you couldn’t transfer components between systems.

Observation 3: Modularity has well defined, small, touch points and interfaces.

When you think about how modular systems connect together, it is often at very narrow, well defined, touch points. Think of the light socket, or plumbing socket, or screwdriver.

When designing modular system, consider the touch points between systems, and how they may evolve over time.

Observation 4: Standards and specifications make the world go round.

Standards and specifications really are the magic behind our interconnected world. Most national standard bodies are part of the International Organization for Standards (ISO).

Standards (1) ensure compatibility between modules, (2) safety in products and service, and (3) the sharing of ideas and best practices. Literally everything has a standard to it. From ballpoints pens, to the standards of makes a caps reduce asphyxiation risk.

Observation 5: Focus on the end goal, not the technology

Modular systems must be designed to allow for both (a) the incremental technological advancements within a module, as well as (b) the entire replacement of an existing module(s) with new modules.

The printing press and telephone each underwent stepwise and leaps in its innovation. But the overall end goal of the technology remains stable.

[Read, or watch, the full article on Modular Design - First principles from the physical world]

Modularity & Organizations

A really important part of modularity is the way it can help organize teams and companies.

In software development and in corporate teams, there is a huge drive toward ‘two-pizza-teams’.  Teams that can be fed with two pizzas. This is generally considered up to 6 to 8 people, but no more than 12.

Small autonomous teams can be more innovative, move quicker, and have greater product ownership. It gets around a tangled web of large slow moving institutions.

A model of distributed governance, is required to permit teams to be autonomous.

On a macro model, distributed governance is the default state of the open-market. Companies and organizations form to tackle problems, have their own expertise, set their own roadmaps, and connect with other companies as required.

In many ways, a distributed governance model makes a lot of sense for an open-source project.

Modularity: Interoperability is not enough

There has been a lot of focus on interoperability of clinical data between systems. Good progress is being made recently with FHIR. However, sharing clinical data between systems alone is not enough.

Because EHRs are large monoliths with many features there are high barriers to entry in the development of EHRs, and the switching cost to an organization is high. This results in a low innovation, low energy marketplace.

What is required is not just interoperability of data between clinical systems, but interoperability of data & events between the functional components within a single clinical system. This is a really critical idea.

It means you could easily swap out the operating room scheduling component, with a better one. When an EHR is designed of individual functional components, each with their own bounded context, and loosely coupled together, it means the barriers to participate in this marketplace are lower. This is easy for implementers, university's, start-ups, and businesses.

You could imagine each functional component one day in the EHR being available in various free versions, as well as pay to subscribe models. Now functional components can compete directly on quality. Maybe one day in the future, such a model will also make it easier to introduce machine learning functional components into the EHR.

Achieving this level of decomposition of the monolith of an EHR into functional components requires mapping the anticipated boundaries of these components, and mapping their events and interactions. From what I can tell, as great as FHIR is, this has not yet been done.

[Read, or listen, to the full artcile: Interoperability is not enough]

Modularity makes sense for an open-source EHR

Let’s wrap up this section on modularity. We started by asking the question is, how do we design an EHR platform that makes collaboration easy? I believe that modularity plays a critical role in this.

OpenMRS has already adopted the general ideas of modules, but this can be further broadened, extended, and built out to help us get to an end place of independent functional components - well defined, loose coupled, elements.

Modularity helps with both the organization and the software. OpenMRS is a community of independent organizations with their own objectives. Modularity helps with distributed governance, and makes it easier for new developers to come into the codebase.

On the software side, modularity encourages the use of off-the-shelf elements, and this means that EHR development is faster and cheaper for implementations.

Loosely coupled, well defined components makes it easier to upgrade a specific component. Or rebuild and swap it out. Each component can use its own language and database structure. This makes it easier to upgrade the technology of components as required.

Let’s look at a quick concept example of how OpenMRS could be adopt vertical and horizontal modularity.

Example 1: Modular EHR, horizontal & vertical overview

Let us consider a very high level example of how modularity could operate.

Conceptual Model

(Note: this isn’t an example of a system architecture, but a conceptual model)

At the heart of the application is a foundation. This consists of foundational modules that form the core services, such as accounts, admin, security, compliance, offline, sync, backup and mirroring.

On top of the foundation, groups are able to build their own applications. These are the actual tools that clinicians use. An organization may have a simple application for community health workers, and a bigger application for the rest of the clinic.

An application uses different user interface components. These may be brought together based on the need of the application. The community health worker may only need a patient list, and access some questionnaire forms. The Chronic Disease Clinic instead of a patient list wants a patient queue, forms, and also labs, x-rays, medication orders, and reporting.

Templates can then be applied to the entire system. For instance, a HIV template may include specific forms, workflows, reports, concepts, and indicators.

In this way, we have complete modularity and seperation of all elements ‘vertically’, as well as ‘horizontally’. Permitting flexible development and assembly.

Developer Organization

I anticipate that the turnover of these elements will be at different rates. For instance, the user interface components likely will be upgrade and re-written entirely new every few years. Just as a modern day mobile or web application does. Developers who know front end languages can easily come in, build a component following its specifications and hook the component up to the API-gateway that populates it.

At the other extreme are the foundational modules. These can still be upgraded, improved, and expanded. But the skill of developer required to work on this requires more sub-domain experience, and understanding of OpenMRS software in detail.

In between is the the application construction level. Here developers with an in-between level of expertise can help bring together user interface components, and build on top of the foundational modules.

Example 2: Modular EHR, Drag & Drop Development

In this year’s Nairobi conference there was significant discussion on being able to greatly simplify deployment. Ideally implementations wanted to be able to install and use OpenMRS without requiring developers. Some may consider this ‘OpenMRS deployed as a service’, such as a subscription model. Or, the goal may be to have a local install team, but to make their work much easier. I think it is an important goal, but admittedly it is a long road to get there.

But, because people like mockups, I quickly put together some a few conceptual slides of what OpenMRS drag & drop may look like. These slides are really only for concepts, visually they aren’t very good.

Setup Wizard

When you first log in, there is an OpenMRS Setup Wizard that guides you through a series of steps to get the clinic up and running.

Ideally everything is set to defaults. Again, these are likely all separate modules: audits, Security, Offline, Backup, etc. If needed you could edit their settings.

You then move onto customize your organization’s branding, choose languages, time zone, and other geographic customizations.

Then you can manage user identities and facilities.

And move onto manage those services connected to the medical record, such as database, terminology, concept dictionary, and medication lists.

Drag-and-Drop Application Builder

There are two ways to set up an application. One is to start with a disease template, such as HIV or hypertension. In this case, looking back at the prior diagram, the system collects the required application type and needed user interface components.

The other way to build an application is choosing your own, and then add the user interface components you want, and then the disease templates after.

Let’s go back and start a new application. There are a few default frameworks to select from. Such as a simple a community health worker application, a standard clinic app, and a hospital level app.

Then to design an application, choose a navigation structure.  We’ll go with the bottom tab menu.

You can edit the tabs in their design. (click)

Add then add user interface components.  

In this case, we see components available for the Homepage. Specifically Patient List components. Two options are available a simple standard patient list and a detailed patient list. It also appears other organizations and subareas have built their own alternative patient list components.

We’ll drag in the standard simple patient list. We can then click on it to edit the details.

We could change the display from a stack/table to flip cards. We can customize what information is displayed on the card, and what action buttons the card has.

Each user interface element can subscribe to standard data streams for its data queries.

There are more detailed custom settings. Such as being able to select what type of filter and sort options are available. If the element has pagination.

This was put together quickly, but it gives you an idea.

Now we’ll add a patient Search bar. Same idea. Select the standard component and drag it in.

You can imagine there would be an extensive library of standard components that users could access, re-build, swap out, and add to themselves.

OpenMRS Workflow Builder

In this hypothetical drag and drop OpenMRS there would also be an easy to use form and workflow builder. Where similar to the general user interface builder, different question types and data displays could be assembled. Similar to Survey Monkey, as seen in this example.

OpenMRS Logic Builder

Standard business software, CRM, chatbots, email marketing, thrives off of the ability for users to easily create their own business logic without needing developers. We see screenshots here of different types of business logic builders. If you like them, I have 100 other pages of examples.

A very popular tool is Zapier. This makes it easy to integrate APIs from different companies into a single workflow.

My brother essentially built a seven figure business in under a year and a half using Zapier to join different services together to create a business order system.

Imagine if in healthcare, you could string together automated processes, with the same ease. Essentially this provides a way to help develop custom logic between discrete functional components.

For instance, when a new patient checks into clinic you may want the system to, print out their ID card, send a consult to the dietician, send a requisition to the insurance organization. This could be done by developers writing a logic orchestration code. Or maybe one day it could be done by clinical admin using a tool like this.

OpenMRS Styling

Each component should have agnostic styling. And therefore the entire application would have a uniform style to it, even if the components were designed all by different groups.

There are some technologies, such as web components, that we won’t get into today. These may, help with making it possible to design user interface components that can be shared across application frameworks using different languages, such as Angular to Vue. Unfortunately, they still don’t work as smoothly in React.

A lot of the focus here has been modularity in the user experience and application assembly part of the platform.

But in order to really make a lot of this front end work, and ultimately to solve a lot of the other problems with reporting, offline, ETL, etc we need to extend the principles of modularity down deep into the core fundamental services of OpenMRS. Which leads to Part 3.

PART 3
Proposal: Modular Architecture

Part three will continue to expand the concept of a modular architecture deeper than the user interface components, and into the software architecture.

As a disclaimer: I’m not a software architect, and so take everything you hear with a pile of salt. My hope is this section can help show the benefits of increased modularity at the code level can bring, and outline several technologies that may help get us closer to ‘full modularity’. But we really need proper system architects and experts to help weight in on something like this.

There are a lot of excellent YouTube lectures and articles on these topics. But, if you would like everything integrated into a single book, I highly recommend Chris Richardson's new book Microservices Patterns.

Architecture and Organizations

To start, it is important to realize how architecture influences organizations and processes.

A loosely coupled modular architecture with well defined boundaries and interactions between components, allows you to have small autonomous teams.  This means that it's possible to safely deploy into a large complex architecture. At one point years ago Amazon was known to commit changes every 11.6 seconds.

In the case where the architecture is a coupled monolith, you require coordination of efforts between teams in order to develop, because everything is connected, kind of like a ball of spaghetti. This will result in processes that have a high risk to break things, resulting in slow releases, and avoidance of upgrades. A culture of slow releases and avoidance of upgrades, expands as you continue to avoid upgrades.

I know here at AMPATH we have a strong interest in understanding how we can decouple our system, in order to help make releases smooter. I also know of many other implementations that avoid upgrades because it will break their system.

The key takeaway is that software architecture not only impacts the software, but also the Organization and Processes you can achieve. As well as the other non functional things: such as maintainability, extensibility, testability,

Microservices

It is time now to introduce the M-Word. I’ve been using the vague term of loosely coupled modules with well defined boundaries and interactions, as a general organizing principle to strive for.

As and I said, I think there are a lot of things we can do easily in OpenMRS to help us move in that direction, and I think a more important theme from this presentation is the general concept of increasing modularity horizontally and vertically åcross the platform as a means to increase collaboration.

A specific technology that may help move towards this goal of decoupled modularity, is microservices. Now I realize, it is a common buzzword, which in some ways gives it a bad stigma. It also means a lot of different things to everyone.

The goal here isn’t to suggest we should use microservices, or we shouldn’t, but to briefly explain what microservices are, and some associated technologies that may help with modularity.

Because we are short on time, this will be just an introduction to the general concepts. There isn’t time to go into detail why each of these technologies is actually really complicated, and may be a bad idea.

Architecture Monolith vs Microservice

Software

On the left we see the architecture of a monolith.  You may be more familiar with three-tier application patterns: presentation layer, logic layer, and database layers; but hexagonal patterns may be more helpful to represent modern applications.

In the monolith pattern, we have multiple services with their business logic at the core. This communicates with a database, often MySQL. This is surrounded by ports and adapters that communicate to third party APIs, as well as to the client layers.

The trouble is that changing the database, affects everything. Also often one database structure doesn’t work for everyone.

Also, the entire app is programed in one language. Choosing ‘what language to upgrade to’ is a huge undertaking and results in organizational standstill and use of old technology.

Changing the business logic is difficult because it is all connected.

This is in contrast to a microservice approach, where each subdomain is its own service.

Each service has its own private database. It can use whatever database it wants: MySQL, PostGres, GraphDB, Elasticsearch, PouchDB, whatever. This optimizes function, and allows experimentation with new technology. Again avoiding organizational standstill, votes, and fragmentation.

All external communication must go through the service’s API. This means that behind the API, the service can be written in any code language. If you remember the App, Wunderlist that was acquired by Microsoft, their CTO allowed developers to write in literally any language the developer wanted to try that day. I’m not saying we should do this, perhaps OpenMRS adopts several prefered languages: Javascript, NodeJS, React Native, Python.

And don’t forget, because the service’s database schema is behind the API, it also can be changed as required without breaking other services, or having to consult with other services about the change. There are also ways to build API backwards compatibility.

You get the idea. This permits collaboration, innovation, and greatly simplifies upgrading of components.

A single bug can take out the entire monolith, but in microservices there is fault isolation.

Once the baseline boundaries and interactions are established, microservices permit a Distributed Governance model, as opposed to centralized command.

No single developer can hold an entire monolith in their mind. Whereas modularity makes it easier for new developers to understand the codebase of the service they are working on.

Organization

Monoliths require input from multiple teams to coordinate upgrades, and testing before deployment. The quality assurance work in particular can be quite difficult. After deployment, other systems that rely on the main monolith may break, if they were not ready for the upgrade.

In microservices, autonomous teams each are reliable and able to develop, test, and publish their own code in a reliable way.  The loosely coupled architecture makes it possible to not break things.

Service Orientation Architecture

Some may say, this is similar to Service Oriented Architecture SOA.

The problem as Martin Fowler says with using the term SOA is that nobody knows exactly how to define it. Therefore, it is worth considering microservices as a specific domain within SOA.

Specifically, microservices focus on loose coupling.

In SOA, there is often a central database & and an enterprise service bus (ESB). These are two components that make loose coupling difficult. The enterprise service bus, helps route messages between services, but typically requires a lot of logic on how to route messages. You end up with a system that involves services that are still coupled together by shared database and ESB logic.

Microservices

Microservices, with its loosely coupled, well defined boundaries splits the code into functional components. Each with their own domain database & interactions.

Microservices, as Fowler describes, also reject the enterprise service bus, and instead use dumb pipes to carry messages and smart endpoints (on the services themselves) to interpret the messages.

Modular boundaries

Drawing modular boundaries is a tricky part of microsources. There are different approaches. Such as Business Capability or Domain Driven Design. Essentially the key sub-domains of the industry are carved out. It is important to realize that microservices in general are a misnomer, and do not actually refer to how many lines of code the service is.

There are also other considerations such as a module’s volatility to change? Where in the firewall it is? Its data consistency? Who will build it? NGOs? Private industry? The CDC?

Communication protocols

An important consideration is how the dumb pipes - how the communication protocols work.

To greatly simplify you can consider there being one to one and one to many communication protocols. And these can be either synchronous or asynchronous.

Although synchronous one to one messaging such as REST has its place and is an important tool, especially for external service, there are the downsides of service availability and needing to know an APIs location.

One way to help create loose coupling is Broker Based Messaging, such as Apache Kafka.

This handles both message storage, and message queue and publish / subscribe platform. This reduces the need to know where to deliver the message, handles buffering of messages, and guarantees delivery.

Event Sourcing

Event sourcing is a really cool architectural pattern.  Instead of updating the database directly, you append the event log.

Think of an accounting ledger or GitHub.

Your bank account balance is based on summing up the deposits and withdrawals from the month. If you lost the total, you could rebuild your balance. In the same way, the application state can be blown up at any time, and re-built by replaying the events.

Benefits of event-sourcing include

• It pairs well with the event stream model of service interactions. Kafka is an append-only message broker
• Provides a built in audit log. Which is a critical part of an EHR
• It’s good for offline, as it helps resolve some problems with syncing date stamps
• Provides a really cool Medical time-machine. I don’t have time to explain this, but if you believe you should never delete medical data (as Clem McDonald instisted), this is really the deluxe version of that principles
• Last, event source fits well with microservice logic patterns, which we won't go into today

Obviously it comes with downsides

• There is increased complexity, a learning curve
• Deleting data needs a new approach - again, think of how your bank ‘refunds’ you money if a mistake is made.
• And it is harder to query data, and slow to rebuild the application state
• There are ways around this, such as use of snapshots, and CQRS - which we will discuss later

In this diagram below, each microservice uses an asynchronous publish / subscribe model to publish the services event history, to the Event Store (eg. Kafka). The event store acts as a message broker, and database.

In this example, data comes in from different services and databases, into their respective streams. Then different services are listening on their stream for event data, and they know how to handle and ingest it as required.

CQRS ‘Command Query Responsibility Segregation’

CQRS separates the Write Services from the Read services into two seperate objects. Although they use the same ‘data’, they do not have to use the same ‘data model’.

Here you see the Command Service writing data. This data is processed into a materialized data read store. When the Application wants to update is UI, it uses a Query to read the materialized view.

Benefits

• Works well when there is asymmetry between read and write in an application. This allows you to scale read and write servers separately
• It pairs well with even source data model, because provides a method for the read side to be sped up
• Last it helps achieve eventual consistency in microservice data

The risks remain the same: increased complexity, and there can be a lag between write and read

Example 3: Ampath

It would be an exaggeration to say AMPATH has an advanced CQRS and event sourced system. But the team has set up a general CQRS data pattern.

AMPATH uses Apache Kafka, Apache Spark, and the Elastic Stack to transform data.

Data is entered on the tablet, this communicates via rest API into OpenMRS and stored in the database there. In almost real time a number of flattened tables are generated from that data store and available as rest endpoints. The tablet then views its data by reading from one of these aggregated tables, rather than the original OpenMRS database

Examples 4: Detailed Modular EHR Architecture

A really key part of being able to think about modularity, is trying to understand the subdomains of an EHR, and what the interactions between these elements are.

As I mentioned, I think that FHIR is extremely helpful in a lot of understanding this and the domains, but it doesn’t provide guidance on how the modular services would fit together as discussed previously.

The draft requires a lot more work, but it is trying to summarize all the functional requirements into one place. It will then be easier to take this type of a document to a system architect and receive feedback on ways to help divide it up into separate subdomains.

Downsides of these technologies

The recurring theme is that each of these approaches increases complexity.

1. In general, we are moving complexity in the tangled spaghetti codebase, into complexity in deployment
2. This requires highly competent Development Operations to be able to manage automated testing and automated deployment. Many recommend to not touch microservices until the organization has Automated testing and deployment finely tuned.
3. Event sourced & CQRS  is a new approach, and has new logic to learn
4. It is critical that whatever architecture is designed, it can still be deployed on a lightweight laptoping running as a server in a remote clinic.
5. This is also unchartered territory

There is no know example to date of an Open Source community moving from a monolith to microservices.

We know this because this professor, Davide Taibi in Finaland, has been studying microservices, and has asked on ResearchGate (thread here), Quora, and StackOverflow if anyone knows of an OpenSource project that migrated from monolith to microservice.

The GitHub page, continues to read:  NO

Decomposing the Monolith

If one wanted to start decomposing a monolith into smaller microservies, it is advised to

1. Start with 1 or 2 simple services not related to the monolith. Perhaps even a service that doesn’t require a data store
2. Practice operational readiness
3. automated testing & deployment
4. Secure, debug, monitor distributed architecture
5. Move onto ‘edge services’
6. Build new microservices that minimize their dependency on the monolith
7. Often best to rewrite the capability as a new service. Reuse and extract high value code
8. When comfortable, move into the core services

Link: Martin Fowler Zhamak Dehghani - How to Break Monolith into Microservices

PART 4
Summary & Next Steps

How can we summarize today?

In Part 1 Perspectives: on OpenMRS we looked at the enormous need and wish list in the community to advance the platform, with the reality of the ongoing fragmentation of efforts.

Therefore, instead of focusing in on a specific wish list item to build, today we focused on the more deeper and catalytic question of: How do we design an EHR platform that makes collaboration easy?

In Part 2, Principles: of Modularity, it was proposed that modularity may be a unifying principle to help make collaboration easier. We looked at high level example of how modularity can be delivered vertically and horizontally, and what a drag and drop development user interface components could look like.

In Part 3, Proposal: for a Modular Architecture, we looked at how software influences organizations, and some new technologies such as microservices, event-sourcing, and CQRS data structures that may help improve modularity across the system.

What are some next steps?

I would propose that we consider,

On Perspectives: of OpenMRS 3

1. Continue to map the communities baseline, 6-18 month, and 2-5 year needs. And integrate this into a single overview document.
2. This plays a critical role in being able to identify the common areas to work on in the next 6-18 months.

On Principles: of Modularity

1. The community can discuss if modularity may address the problem of fragmentation.
2. Identify how OpenMRS already encourages modularity, and how this can be expanded
3. Identify simple areas where modularity can be quickly implemented. For instance, my impression is that there is interest to create a new library of shared user interface components specifically aimed at chronic disease management.

On Proposals: Architecture

1. Continue R&D in mapping the EHR domain to understand it subdomain boundaries & interactions
2. Create as specific example to map boundaries, interactions in detail
3. Seek advice from experts on architecture & technologies, to help us understand how to improve modularity in a stepwise manner, and safe way to incrementally incorporate these technologies.

I want to underscore that this presentation should not suggest that modularity does not currently exist within OpenMRS. In fact at its heart OpenMRS is modular. The goal of this presentation is to encourage us to think how we can further expand that modularity as a means to help with fragmentation.

Continue this conversation on OpenMRS Talk here.

Or e-mail (gschmidt@medmb.ca) / Twitter (@_GregSchmidt) / or the contact form on this website. Would be great to hear your perspective.

Consider subscribing with your email (bottom of page) to get very infrequent updates of new articles.

Special Thanks: to Tobin Greensweig & Jonathan Teich for their assistance in working through these ideas

GREGORY SCHMIDT

‍

‍