One database or two? Architecture decisions for SaMD products

There is a moment in nearly every Software as a Medical Device project where someone asks the reasonable-sounding question: "Can't the clinician dashboard just read from the same database as the patient app?" It is reasonable. It is also the moment where a regulatory decision is quietly being made by an engineer who may not realise it is one.

This post is about that decision — one database or two — and why, for SaMD products, the answer is rarely a pure engineering call.

The setup

You have a patient-facing application that is cleared as a medical device. It collects clinical data and is governed by IEC 62304, a risk file under ISO 14971, and whatever clearance documentation got it to market. It works. It is in the field. Nobody wants to touch it.

Now the business needs a clinician-facing oversight layer: dashboards, population triage, compliance reporting. The data the clinicians need already exists, inside the cleared system. The temptation to point a new UI at the existing database is enormous, because it is the path of least immediate effort.

Why "just share the database" is a trap

The cleared device has a defined boundary. Its risk analysis, its verification and validation, its change-control process — all of it is scoped to a system that behaves in known ways. The instant another application has write access to that database, or even read access that influences clinical workflow, you have arguably extended the device. Now your change-control process for the new dashboard is entangled with the cleared product. A schema change for a dashboard feature becomes a question for your regulatory lead.

That coupling does not just slow you down. It raises the risk classification of work that did not need to be high-risk, and it makes the cleared product more fragile, because more things now depend on its internal shape.

The two-database pattern

The alternative is a clean separation:

• The patient app remains the system of record. Its database is its own. Nothing else writes to it. Its boundary, and therefore its risk file, stays intact.
• The oversight platform has its own database, populated by a one-way, read-derived pipeline from the system of record. It is a separate application with its own — typically lower — risk classification, because it does not control therapy; it observes it.

The pipeline between them is explicit, versioned, and itself the controlled interface. You can change the dashboard's schema freely. You change the contract with the cleared system rarely and deliberately.

"But now I have a data-sync problem"

Yes. This is the honest tradeoff. Two databases means a pipeline, eventual consistency, and the operational reality that the oversight view may lag the source by seconds or minutes. For a clinician triaging a population, that lag is clinically irrelevant. For the regulatory posture you keep, it is a bargain.

The mistake is to compare two databases against one database and conclude one is "simpler." The correct comparison is two databases against one database plus an expanded device boundary plus entangled change control plus a higher risk classification on dashboard work. Seen that way, the pipeline is the cheap part.

Where the boundary actually goes

A few principles we apply:

• Reads that inform clinical decisions still matter. Even a read-only dashboard influences care if a clinician acts on it. It does not need to be a Class C device, but it does need its own, honest risk analysis. "It's just read-only" is not a risk argument.
• Audit the reads, not just the writes. In a regulated context, who viewed which patient and when is part of the record. Design for that on day one; it is painful to retrofit.
• Make the pipeline the controlled interface. Version it. Document what flows, in which direction, with what guarantees. That document is worth more than the code.

The decision, restated

So: one database or two? For a standalone product, one, almost always. For an oversight layer on top of a cleared SaMD product, two — not because two databases are architecturally superior in the abstract, but because the second database is what keeps your cleared device's boundary, and your sanity, intact.

The general lesson generalises beyond healthcare. Any time you attach new software to a system that carries regulatory or contractual weight, the database boundary is where coupling hides. Decide it deliberately, with the people who own the risk file in the room — not incidentally, in a pull request.