I’ve been working in the health care domain for the last 12+ years, and spent a lot of time researching how health care information systems (HCIS) were designed and built. On this journey, encountered many faulty architectural designs, and many great specifications, standards and patterns that could lead better quality clinical software.
For any IT professional working in health care, software architecture should be an area of interest, and each project should start with an architectural design. Building software is like building a house, we need to think where each component (room) goes, their size, features, try different alternatives, find which ones fits our needs, estimates costs, etc. Also we need to create blueprints with very detailed specifications, especially when the construction is complex. And trust me, building an EHR, LIS, RIS, PACS, Pharmacy and other clinical software, and make them work together, is very complex. So good architecture design is not optional in health care.
“Good architecture design is not optional”
Some time ago, I presented a paper at MEDINFO 2015 that was related to the design of a platform of individual reusable components to build better clinical systems. The basic idea was to have one component in charge of one area of the domain and one specific set of features. For instance, in the paper I separated the Clinical Data Repository component from the Clinical Data Entry applications (EMRs), as a way to cut the complexity of EMRs in half, and allow to scale and update EMRs more easily. Now I realize what the paper proposed was really a microservices architecture.
What is a microservice architecture?
There are many definitions of microservices. Martin Fowler says there is no precise definition, and states that a microservice architecture can be defined by its characteristics. While Fowler’s article has an in-deep analysis of these characteristics, I would like to propose a definition and some characteristics that are important in the health care domain.
A microservices architecture is a way or style of implementing a Service Oriented Architecture (SOA), where each component (microservice) is loosely coupled with the rest, but the components work together seamlessly to implement more complex business processes. Technically, a microservice is an application, with all the architectural layers (persistence, business logic, presentation) and includes a service layer, which is used to communicate with other microservices.
Some interesting characteristics
1. A system is made of many microservices
2. Each microservice can be developed, modified, tested and deployed individually
3. Each microservice is focused on a specific fragment of the whole domain
4. Each microservice can be replaced independently
5. Microservices need to talk to each other and collaborate to implement use cases
6. Freedom for scaling microservices individually to the required level
In comparison, monolithic architectures should be developed, modified, tested and deployed as a whole, and scaling requires to copy the whole monolith on different servers, and doesn’t allow to scale individual components when needed.
A side effect of scaling individual microservices under demand, is a better usage of server resources, since you only scale the microservices that are required to scale, not the whole monolith. This has a direct relationship to costs.
Some advantages of a microservices architecture
1. Fault tolerance
2. Simpler high availability implementation
3. Fine grained scaling
4. Simpler development management
The extra overhead added by this kind of architecture, is the need for APIs, or some kind of interface, on each component. And that should be well documented so developers can use the services they need.
Challenges for microservice architectures in health care information systems
There are many cultural and psychological barriers for microservices to be implemented effectively in the health care domain. The challenges come from the use of outdated or even obsolete architecture design methodologies from IT professionals who didn’t continue to study and update their knowledge on these areas, and could be 20 years working with methodologies 20 years old, or having people that are not trained on software architecture design which are actually “designing” complex architectures for health information systems, there are thousands of programmers designing systems and they are not even trained on software engineering. This includes the “no architecture design at all” (bad) practice that goes from directly requirement gathering to programming. This is very common in health care providing organizations with internal IT teams, but also happens on a lot of software providers which previously provided management and accounting software for hospitals and clinics, and now try to enter the EHR market using the same design principles as their management and financial software, and we know these clinical software is a totally different beast.
As a result of not having trained people on modern software architecture design, and trying to apply architectural techniques, that might work on systems that are not related to health care, we end up with highly coupled monoliths, that are difficult to modify and test, are not fault tolerant, and don’t scale well.
Some characteristics to know if your architecture is a monolith:
1. The system manages different unrelated areas of your domain (e.g. EHR and Pharmacy).
2. Data from different unrelated areas is stored on the same database (e.g. Patients and Medications).
3. There is only one database.
4. All the functionality to manage different areas is on the same “executable” program.
5. Does not interchange information with other external systems, or this is an exceptional case.
6. All data flows are controlled by the same software component.
And some red flags to take into account:
1. Architectures that are not based on standards, patterns of good architecture design practices.
2. Not having an specialists in software architecture, that keeps updated in that area.
3. Not reviewing the architecture design when doing major system modifications.
4. Not reviewing the architecture design oftenly to find problems or improvements.
5. Not keeping the architecture documentation updated when the system is modified.
Which micro-services do we need for health care systems?
There is a minimal set of micro-services that we need to create any architecture for clinical software:
1. Clinical Information Management: aggregator of clinical data coming from different systems (Medical Recording Apps, LIS, RIS, Pharmacy, ...), so this is basically the centralized and unique EHR of each patient in the platform.
2. Demographic Information Management: people, places, roles, capabilities, devices, for instance patients and human resources are managed here.
3. PACS: stores and provides services to access multimedia clinical data (e.g. CT scans), and related radiology reports. Is multimedia and not just imaging because it can manage stuff like waveforms (ECG, sound) and also videos (e.g. angiography).
4. DICOM Viewer: one kind of advanced viewer is used to diagnose, another kind of basic viewer is used to look at the DICOM objects for reference, sometimes integrated into Medical Recording Apps.
5. RIS: Radiology Information System is used for order entry, scheduling and managing the worklist for each imaginology modality, and sending results (radiology reports) to the EHR (Clinical Information Management).
6. LIS: Laboratory Information Systems is used for order entry, scheduling and sending results back to the EHR (Clinical Information Management).
7. Pharmacy: manages stock, receives orders, delivers drugs to patients on different internal services of the hospital or clinic.
8. CPOE Middleware: sometimes a component to route orders to the correspondent system and receive results or feedback from them is needed, the CPOE sits in the middle of the EHR (Clinical Information Management) and the Order Filler system (LIS, RIS, Pharmacy, etc).
9. Terminology: provides services to access standard terminologies to be used to record and analyze clinical information stored in the Clinical Information Management.
10. Clinical Decision Support: allows to define, manage and execute rules related to CDS, that will result in some kind of action, like showing an alert or reminder in real time on the Medical Recording Apps, or sending email notifications in batch e.g. when more than 5 cases of some kind of infection are detected inside a hospital.
11. User Authentication: infrastructural security component to manage users and permissions on different systems and services in the platform.
12. Audit Trail: log of events that happened on different apps and services of the platform, and allows to detect unusual activities and control the whole platform.
13. Medical Recording Apps: front end applications for clinical users that allow to record new clinical information and access historical records from the Clinical Information Management, each medical specialty could have it’s own, specialized Medical Recording App.
14. Scheduling: each resource or service in a hospital or clinic should be schedulable, so it is assigned to a specific patient in a specific timeframe. Since many apps and services in the platform require to schedule a resource, we could separate that into a specific microservice in the platform.
These components are really defining a platform for health care systems, since the services provided can be used to create any kind of application, even to design higher level services that are closer to business processes. Think of this as the App Store or Google Play platforms, they provide services to build, test, publish, distribute, and monetize mobile apps, where all the services are well defined, publicly available, and are pretty standardized. Imagine what would happen if we follow a similar approach providing and standardizing most of the services all health care apps need? In my opinion we will move to another level of problem solving, adding more value to the market, and reducing variability and complexity on the apps because most is taken care of in the infrastructure.
Think of starting a new project, and instead of thinking about how to store clinical information, which formats to use to exchange it, how to implement certain REST API or how to parse certain JSON format, you just choose services to use, and configure what should be integrated with what, then map your data to a canonical format, and that’s it. The rest of the time is dedicated to solve problems specific to your application, to fulfill your users needs and to provide higher level services.
Can this platform idea scale?
I think the only way of making this approach appealing to software companies is to define an open platform, composed by open micro-services. This is not related with open source. When I say open I mean openly available, and openly documented. Then if the components are open source, that depends on the provider. There are companies that are taking this approach, and in the near future we will have companies divided into focused on platform and focused on end-user apps. And as you can guess, the later will be customers of the former. Another important area is to implement openly available specifications and standards. It is difficult to use something based on an standard that is actually not openly available, also that difficult the access to a community to ask questions when we don’t understand something. Open standards tend to have wider communities. Some of this open standards are: HL7 (v2.x, CDA, FHIR), DICOM, SNOMED CT, LOINC, IHE profiles (PIX, PDQ, XDS), openEHR.
My recommendation for building microservices for this platform is to not only document the APIs and services, but also document the internal architecture and components of the micro-service. Then is up to you if you want to open the source code or not. But you need to provide your customers all the information they need to be able to pick the right micro-service and use it effectively.
Conclusion
Almost without knowing it I’ve been working on this for the last 6+years, creating one of the code components of this platform, the Clinical Information Management microservice, also known as the EHRServer.
Personally I think this is the best approach, and it’s what we need in the current ecosystem. This could change the status quo of huge companies in the marked, and generate market for new smaller companies, while satisfying clinical needs of clinicians, organizations and patients, at a reduced cost, and at the same time generating the platform market.