Breaking the Wall: Microservices, Segregation, and Compliance in Medical Devices

In this article, I will describe the advantages of the microservices architecture when writing code for medical devices and AI software, drawing on my event-driven and API background. After describing the efficiency brought by a domain-driven design approach to microservices, we will see the additional advantages of using this paradigm for regulated systems with segregation of risk classification within Medical Devices.

The Pitfalls of Monolithic Architecture within Medical Devices & Software

In a monolithic architecture, all components of a software application are interwoven and tightly coupled within a single codebase. This approach, while straightforward for small-scale applications, faces significant scalability and flexibility challenges as the application grows.

Separation of Concerns and Efficiency for Compliance

Microservices architecture, as summarized by Martin Fowler,  addresses these challenges by embracing the principle of 'Separation of Concerns.' It breaks down the application into smaller, independent services, each responsible for a specific functionality. This separation allows for more focused development and easier maintenance, leading to greater efficiency. Teams can work on different services simultaneously, reducing coordination overhead and accelerating development, ultimately delivering greater value to the end-user.

Loosely Coupled Systems and Two-Pizza Teams

One of the critical advantages of microservices is their loosely coupled nature. Each service functions independently, making the overall system more resilient and easier to manage. This architecture aligns well with the concept of 'Two-Pizza Teams', a term coined by Amazon, where small, autonomous teams can manage and develop services effectively, ensuring agility and innovation, and at the same time ensure individual happiness of each contributor.

Reusing Code and Ubiquitous Language

Microservices allow for the reusing of code across various parts of an application, enhancing consistency and reducing development time. Additionally, the adoption of a 'ubiquitous language' across services ensures clear communication within teams, particularly important in a distributed development environment.

HTTP and REST API: The Connective Tissue

Microservices often communicate with each other using HTTP and REST APIs. These technologies provide a standard way for services to interact over a network, ensuring lightweight, stateless, and scalable communication.

Jeff Bezos’ Mandate and Its Influence

Jeff Bezos' mandate at Amazon has been a guiding force in the adoption of microservices. It stipulates that all data and capabilities should be exposed through APIs, all team communications should occur via these APIs, without side channels or shortcuts. This mandate underscores the importance of APIs as a fundamental building block in microservices architecture. It also emphasizes that technology choices are secondary to the functionality exposed by the APIs, which must be designed with externalization in mind.

Domain-Driven Design towards Microservices and Compliance

Microservices complement Domain-Driven Design (DDD) as summarized by Greg Evans by allowing teams to focus on specific business domains, leading to more purposeful and aligned software solutions. To build a complex software system today, DDD towards microservices appears to be the most resilient, fast and fun method for teams.

Risk Classification and Segregation within Compliance & Medical Devices

When designing a regulated software system, for example a medical device but also an high-risk AI based system, you need to think early on about your Risk Classification, either as Medical Device or AI system (or both). If a piece of your device falls under Class III or High Risk, your entire system will be considered as Class III or High Risk. However, in ISO 62304 for Medical Devices, if a software component of your system can be controlled by an external risk control, it can keep its classification as being its own Software Requirement System (SRS). This principle is called segregation.

So if your system is made of components that each can be controlled externally hence keep a low risk class, and the risky elements stay in a separate system, typically hardware, each team can progress with light design control and the intense design control effort be focused on the high-risk component.

Segregation with Microservices within Compliance of Medical Devices 

Now, let’s apply the principle of segregation to microservices architecture for an SxMD (Software-as-Medical Device or Sowftare-in-Medical Device). In your (stand-alone or embedded) software plan, if you design your system as components with their own SRS running at its own microservices, you get two benefits at the same time: speed, resilience and fun from microservices, with optimized risk classification for each component leading to speed and control from segregation. You should ask yourself that question not only for a SiMD with software embedded in a hardware and an SaMD companion, but also for a pure SaMD or AI-based software. This could save you thousands of hours you can better spend innovating faster.

Build Patient and AI Journeys with Compose

To facilitate this highly controlled process, Matrix Requirements allows you to control the design of different product components as projects with separate SRS. And you can maintain traceability over your entire system thanks to Compose: items in a component re-used in another component will automatically update (or not, up to you!) so that each team can progress separately and their compliance data be traceable.

Sources:

https://en.wikipedia.org/wiki/Domain-driven_design

https://nordicapis.com/the-bezos-api-mandate-amazons-manifesto-for-externalization/

Domain-Driven Design: Tackling Complexity in
the Heart of Software by Eric Evans ISBN: 0-321-12521-5