Healthcare is poised for significant change over the coming years as a result of emerging technologies like artificial intelligence (AI), virtual assistants, sensors, and wearables. Significant investments have been made in transitioning providers to EMR systems, but the benefits of this digital transformation has not yet been fully realized. Microservices are a new software development technique that provides a number of advantages in architecting back-end solutions while offering particular benefits in developing digital and connected healthcare solutions.
There are significant market pressures in developing new healthcare solutions. Expectations are that these solutions will improve outcomes while also reducing costs as providers and payers look for added value, new operating business models, and improved patient engagement. The opportunities within this sector are also bringing in new competitors to the fold like Google, Amazon, and Apple, along with nimble start-ups, so time to market is becoming increasingly important.
Data volumes are increasing in all sectors, and healthcare is no exception with the adoption of wearables, electronic medical records, and medical-grade sensors. Data privacy and regulatory requirements in the healthcare sector drive additional demands around how this data is collected, stored, and managed, particularly around access to personal health information (PHI).
The traditional approach to developing back-end platform technologies is to develop it as a monolithic architecture. This has a significant drawback in limiting reuse of components for use in developing other solutions. For instance, if you have a successful chronic disease application targeting people with type 2 diabetes and you want to adapt that solution for managing patients with COPD, there is likely a significant portion of your original diabetes solution that you could reuse but that would be difficult to do.
With a chronic disease platform built as micro-services, you could replace the component that interfaces and manages data from patients’ connected glucometers with one that tracks readings from their pulse oximeters instead. The services that communicated with a companion mobile application or that captured additional insights from an Alexa virtual assistant would all be reusable in each case.
Advantages of a Microservices Architecture
So, let's get into more detail around how microservices provide these unique advantages and some of the elements to consider in mitigating some of the concerns that have been expressed around this architectural approach. It's important to note that microservices are a new approach to architecting software solutions to address complex system level problems. There are still architectural decisions that need to be made to get the most benefit out of them. Given that it is a tool to encapsulate specific functionality in a healthcare solution, the first decision to be made is around how to structure those components or services. It is important to define services that are loosely coupled and independent of each other, with a clear and simple interface/protocol. Ideally you would target components or services that are complete in and of themselves and that are tied to a specific function or user service that you are offering, or a component or service that has potential for use in other applications outside of the one you are designing it for.
The portability and interoperability benefits from a microservices architecture stems from their adoption of open standards such as JSON and HTML, which allows for integration of third-party solutions and integration with micro-services that are written using different programming languages. This results in the development of building blocks that can be repurposed in new projects or solutions in the future. It also means introducing new technologies or components in a future road map enhancement can also be accomplished more easily and with less risk of impacting existing components in the process.
One advantage of particular importance in a healthcare solution that falls under regulatory oversight is the isolation achieved between components. In a medical device, this isolation on an electronic printed circuit board would be achieved through an optocoupler that completely isolates (electrically) one part of the board from another. The equivalent functionality is delivered through message queues between microservices. The practical implications of this are that components of a solution that deliver a diagnosis through a proprietary algorithm or machine learning tool can be isolated from components that manage networking functionality, device connectivity, or other nonpatient critical capabilities of the solution. The latter might need to be updated to patch vulnerabilities in a networking stack or to update support for a new communication protocol while ensuring that there is no unintended impact to other microservices within the system.
Microservices are naturally event and data oriented, lending themselves well to solutions that require compliance under HIPAA or GDPR regulations as personal health information data can be isolated from other system data, and access to that data can be more readily audited for specific access.
The Hive Architecture
Macadamian's Hive implementation of a microservices architecture, for example, goes one step further and implements user-based roles and authentication mechanisms to ensure that at the fundamental data access points, only users authorized by role to access specific patient information can, and the architecture is intrinsically secure by design.
It has a message-driven, microservices architecture designed to support a Backend-as-a-Service (BaaS) offering. The system is deployed into a container system (Docker) that is instantiated into typical cloud infrastructures (Azure being its primary choice in that realm). The entire platform is optimized to provide recomposable application logic “building blocks” running in the cloud. These building blocks, which Macadamian refers to as cells are derived from common patterns the company has seen in developing solutions over the years.
The goal of this approach is to be able to quickly assemble a working set of backend services and application logic out of pre-existing cells that maintained or created as part of typical application development sprints. The benefit to a customer using Hive is that it implements only the innovative elements of that customer's solution rather than reinventing the wheel for each customer.
The platform can be understood by analyzing the typical cloud/Web application that might be implemented in an MVP product. On average, a standard cloud-based Web application is composed of several layers:
Back-end volatile and persistent storage (databases and caches).
Intermediate “application logic” that assembles models and the relationships between them.
Optionally, an API that provides access to the application logic across the network.
Optionally, a streaming network end-point for submission of transient information like device telemetry or state.
A front end that captures user interaction and translates this back into the application logic.
The thesis of the platform is that 1–4 are nearly identical throughout the types of solutions implemented. The only thing that usually differs is the semantics of the models, their relations, and the orchestration of the activity between them. Therefore, the platform replaces those components with a composable set of generic services that are knit together with a light orchestration logic that is implemented on a per-solution basis.
Additionally, there are some common elements in the user interaction logic that can be captured in shared front-end components. In this system, this commonality is shared via reusable patterns of interaction rather than via reusable code.
Figure 1 provides additional details that visually summarizes the overall system that has been described above. It shows that the Hive assembles a running system (the Hive is symbolized as a hexagon) out of container-based services. Included with the diagram is an enumeration of the application development frameworks already integrated with the system.
The diagram in Figure 2 is much more complex. It is a bird's-eye view of the Hive platform architecture. Moving from the top down, at the base of the system is volatile and persistent storage. All data moving through the system eventually ends up here. It is integrated with MongoDB for persistent storage of principal application data. Time series data, like device telemetry, is retained in InfluxDB. Git is used to maintain versioning history of application logic. Influx or volatile data is kept in Redis.
The next layer is a set of infrastructural microservices that enforce the key features of the platform. The storage service provides object modeling capabilities (much like a traditional ORM) and enforces our very strict data partitioning scheme that provides separation of data on a per-tenant, per-application, and per-user basis. This layer also provides services for authentication (who are you?), authorization (what would you like to do?), and user management.
Following on from the Infrastructure layer is the Application Logic layer. This is the most complicated layer in the system. The microservices in this layer are arrayed in a constellation of cells surrounding a specific core cell. Between these services, there exists a network of message queues (RabbitMQ) that traffic data to and from outer cells and the core cell. This traffic contains a type of message called a behavior. Behaviors are the most basic atom in the orchestration scheme. They represent a single piece of application logic (create or update data, send an e-mail, send an sms, etc.). These behaviors are composed together into a second type of message called an action. Actions are essentially macros of behaviors chained together in serial or parallel. They can be triggered by a front-end application via a Public API as shown in Figure 2. A third type of message, a reaction, occurs when the state changes in the application logic. These messages are emitted from cells back to the core or to front-end applications via WebSockets.
The final layer is a Public API. User-facing application UIs will connect to this layer in order to authenticate, query data, trigger actions and receive notifications of changes in application state. This platform is optimized in two directions: scalability and composability.
The microservices architecture that dominates the layers allows the addition of processing capacity by simply deploying new instances of a taxed service. The reliance on a container system substantially decreases the pain of new service deployment. The use of an event-based model allows it to be statefully clean within those microservices. New applications can be composed simply by instantiating only the services that a particular application would require. The cell model ensures that only the logic required by the specific application is running. The Infrastructure layer ensures that critical services required by any application are reusable.
This design represents a novel and significant concept that fully exercises modern cloud-native patterns. This design also represents significant time-to-market improvements for customer applications. As explained previously, the platform implements the common parts of typical applications, leaving teams to only implement customer-specific front-facing elements.
To demonstrate the potential to leverage Hive in a real-world connected health application, Macadamian developed a solution to help youth with type 2 diabetes better manage their care (see Figure 3). Components of this solution now represent reusable building blocks that can be leveraged by customers to accelerate their time to market.
For solutions leveraging voice, this provides a back end that can synchronize data between an Alexa Skill and a mobile companion application and provide data integration from third-party sources, as well as allow solutions to be deployed across other popular virtual assistants, like Google Home.
Microservices Drive Digital
As a business grows and the number of users on a system increases, microservices are designed to scale as the system needs change and are particularly well adapted to modern cloud infrastructure where the majority of these solutions will be hosted. Not all data or processing needs to happen in the cloud though, and the containers associated with microservices can be run on servers within a healthcare facility or even in a medical device itself, lending flexibility in the manner and location in which they are deployed. These are capabilities that are nearly impossible to achieve in traditional development approaches.
Maintenance and Support
As solutions become more complex, maintenance and support considerations crop up. How do you add functionality or fix bugs in a system that has thousands of users running on it? Microservices enable continuous deployment processes to be leveraged in the operation of a solution once deployed. This allows new services to be added to the solution or code fixes to be introduced without affecting existing users. It also allows new functionality to be deployed on a specific subset of users before a wider rollout to test new capabilities or support A/B testing across different user groups as part of a product management strategy. Fault tolerance is also improved as one service can go down without affecting all of the other services.
Conclusion
With new approaches come new challenges. A microservice architecture does add some complexity to the system that must be managed by the team. Communications between the different microservices can introduce latencies that need to be considered. Deployment of these microservices requires coordination between the services that can add additional complexities. These can be managed by a modern DevOps team, though, with the right automation tools.
In summary, the benefits of microservices are well positioned to address the challenges in delivering modern digital and connected health solutions in a way that “future proofs” a solution so that it can grow and be built upon over many years without impacting its overall security or stability.
This article was written by Timon LeDain, Director, Emerging Technologies for Macadamian Technologies, Gatineau, Quebec, Canada. For more information, Click Here .