Microservices vs monolithic architecture for EHR development: which fits your platform?
Healthcare adds constraints that generic architecture advice skips: one audit trail for every access to patient data, PHI that spreads with every service that stores it, order and medication workflows that cannot half-commit, and certification and export duties that cross every component.
Should an EHR or clinical platform use microservices or a monolith?
Quick answer
Microservices vs monolithic architecture for EHR development usually resolves to a modular monolith first: one deployable with strict internal modules, one audit log and one transaction boundary for orders. Split a module into a service when a team or scaling need demands it. Agnotic Technologies designs both and decides module by module.
| Criterion | Modular monolith | Microservices |
|---|---|---|
| Team size and release cadence | One to a few teams releasing together | Many teams that must release independently |
| Audit log consistency | One log, written in the same transaction as the change | Every service logs; you must correlate entries and protect a central store |
| PHI scope | One runtime and one database to safeguard | Every service, queue and cache that holds PHI is in scope |
| Orders and medication administration | One database transaction | Outbox or saga patterns with compensating steps when a service fails |
| Certification retesting | One build to regression test after a change | Each release of a service in the certified scope needs its own regression evidence |
| EHI export | One schema to export from | A fan-out job across every service that holds patient data |
| Observability | Stack traces and one log | Distributed tracing to follow one request across services |
| Security surface | One perimeter and in-process calls | Service identity, mutual authentication and an API gateway between services |
| Where AI agent tools sit | Tools call module APIs in-process, under the user's permissions | Tools call service APIs, each call with its own identity and audit entry |
What they are
What is Modular monolith
A monolith ships as one deployable with one database. A modular monolith keeps that single deployable but enforces boundaries inside it: each module owns its tables and exposes an internal API, so a module can later become a service without a rewrite.
What is Microservices
Microservices split the system into independently deployed services that talk over APIs or events, each with its own data store. Each service scales and releases on its own, at the cost of distributed data, network failure modes and more security surface to run.
Key differences
Why is the audit trail the first thing to design?
45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that contain or use ePHI. The ONC (ASTP) certification criterion 170.315(d)(2) requires certified technology to record actions on electronic health information and to detect whether the audit log has been altered. In a monolith, the audit entry commits with the change. With microservices, each service writes its own entries, so you need one append-only store and a shared request ID, or one patient's access history becomes a search across many logs.
How does PHI scope grow with each service?
The HIPAA Security Rule covers all ePHI an organization creates, receives, maintains or transmits (45 CFR 164.306(a)). Every service that stores PHI, and every queue or cache that carries it, needs access control, encryption and logging. Keep PHI in as few services as you can: pass identifiers and fetch details from the owning service instead of copying patient records into each service's database.
What happens to orders and medication workflows?
A medication order touches the order, pharmacy verification, the administration record and often billing. In one database that is one transaction. Split across services, you need an outbox or saga with compensating actions, and you must decide what a nurse sees while a step is pending. Keep the order and administration core in one module until there is a clear reason to split it.
How do certification and EHI export cross service boundaries?
Criterion 170.315(b)(10) requires certified technology to export all of a single patient's electronic health information, and to export a patient population, in a computable format with a link to the format's documentation. With microservices, export becomes a job that gathers data from every service holding patient data, and any new service with patient data must join that job before it ships.
Where should AI agent components sit?
Treat the agent as a client of the domain, never a back door into the database. Its tools should call the same module or service APIs the user interface uses, under the user's permissions or a narrow system identity, so business rules and audit entries apply to every tool call. The agent runtime and model hosting can be a separate service for scaling; the PHI it reads stays in the modules that own it.
What security work does a microservices design add?
NIST SP 800-204 lists the core features microservices need: authentication and access management, service discovery, secure communication protocols, security monitoring, resiliency techniques such as circuit breakers, and load balancing and throttling, often packaged in an API gateway or service mesh. Each is a component you build, run and test. A modular monolith needs most of them only at its outer edge.
When to use each
When to use Monolith or modular monolith
- One or two product teams building a new EHR, clinical platform or practice system.
- Order entry, medication administration and results that must commit together.
- A first certification cycle, where one audit log and one export path keep testing contained.
- An AI agent whose tools call the same module APIs as the user interface.
When to use Microservices
- Several teams that must release independently, such as scheduling, billing and patient messaging.
- Workloads with very different scaling needs, such as imaging ingestion next to a scheduling screen.
- Integration edges, such as an HL7 v2 or FHIR gateway, that change on their own cadence.
- AI agent runtimes and model hosting that need their own scaling, kept outside the PHI core.
Where do healthcare microservice designs fail?
1. Split audit logs. Each service logs in its own format and store, and nobody can reconstruct who viewed a chart. Fix: one append-only audit store, with one request ID carried across every call.
2. Distributed transactions on orders. An order is saved, but the pharmacy service never receives it. Fix: keep the order core in one module, or use an outbox with a pending state the user can see.
3. PHI copied into every service. Each service caches demographics for convenience, and the number of stores in scope multiplies. Fix: pass identifiers and look details up from the owning service.
4. Agent tool calls that bypass the domain. An AI agent writes straight to a table and skips validation and audit. Fix: agent tools call domain APIs only, never the database.
5. Export that misses a service. A new service holds patient data but is not part of the EHI export job. Fix: make export coverage a release check for every service.
6. Splitting before the boundaries are known. Services follow screens instead of domains and then call each other on every request. Fix: start modular, watch which modules change and scale on their own, then extract those.
Which sources does this comparison rely on?
- 45 CFR 164.312: technical safeguards, including audit controls (eCFR)
- 45 CFR 164.306: Security Rule general requirements (eCFR)
- 45 CFR 170.315: ONC certification criteria, (b)(10) EHI export and (d)(2) auditable events (eCFR)
- NIST SP 800-204: Security Strategies for Microservices-based Application Systems (csrc.nist.gov)