One product, two regimes: architecting software that lives as RUO and IVD

The same laboratory instrument often ships in two versions: one is labeled research use only and carries no regulatory obligations, the other is an in vitro diagnostic, under the full weight of the IVDR.

A PCR analyzer sold as a research variant and as a diagnostic variant is a familiar case: technically close, sometimes near-identical, yet living under two different regimes.

Whoever writes the software inside inherits that double life as an architecture problem, not a labeling one. The regulatory regime is not the subject of the design; it is a constraint the design has to hold.

Intended use draws the regulatory line

Research-use-only products sit outside the IVDR; an in vitro diagnostic sits inside it.

MDCG 2024-11 states that the IVDR does not apply to research-use-only products, which cannot carry a medical purpose, and MDCG 2019-11 makes the qualification of software depend on the manufacturer's intended purpose.

The line is intended use, not the label: a "research only" sticker does not protect a product whose real use is clinical.

The distinction is legal, but its consequence is architectural: the same functionality answers to two different evidence requirements. And the boundary that separates the two regimes does not separate the two products. Most of the code is, or should be, the same.

Forking the codebase multiplies the cost

The apparently simple route is a fork: one branch for research, one for diagnostics. It is the most expensive one.

The two products drift apart, every fix has to be made twice, and the diagnostic version falls behind a little more each time the research version runs ahead.

The fork is tempting because it looks like isolation: keep the regulated product away from experimental change. In practice it delivers the opposite: two moving targets instead of one controlled boundary.

What began as a shortcut becomes two products that merely share a history.

Variant management designs the split

The engineering path is a single codebase with explicit variant management. Product line engineering has a name for the underlying move: model what is common and what varies as first-class features, then encapsulate each optional feature so it can be included or excluded by construction rather than by convention.

In our view, this is the right frame for the RUO/IVD split: what falls under IVD rigor is segregated at design time, not patched apart afterward.

In practice this means module-level configuration (feature flags, if you prefer the term) separating what is active in the research build from what is active in the diagnostic build, with the shared core untouched by either.

A research-only visualization, say, is present in the research artifact and absent from the diagnostic one. Not disabled at runtime, but excluded from the build.

A single source then feeds a bifurcated pipeline that produces two distinct artifacts, each carrying its own level of evidence.

The idea that a delivery pipeline can generate regulatory evidence as it builds is not new; applied here, it lets one codebase produce a research artifact and a diagnostic artifact without either contaminating the other.

‍

Flag governance keeps the boundary intact

Variant management is only as safe as its discipline. Mismanaged flags become debt: dead code, untested paths, and - the failure that matters most here - a research-only feature leaking into a diagnostic build.

Product line engineering already warns that excluding a component has to leave a well-formed configuration behind, and every unmanaged flag is a chance to break that rule silently.

So flag governance (lifecycle, cleanup, and testing each variant as a product in its own right) is part of the architecture, not an afterthought.

Common practice is to treat every configuration as something to test end to end, because a build that is never exercised is a build no one can trust. This is where dual-use is done well or done badly.

Architecture decides which markets you can serve

A product that lives as both RUO and IVD is not two products with a shared past. It is one product with a designed boundary.

Get that boundary right and a company can move a research tool into diagnostics without rebuilding it, and keep both versions current from a single source.

That boundary is where we work: product architecture under regulatory constraint, variant management, and a bifurcated CI/CD pipeline that holds the two regimes apart by design.

Ship the code and leave the boundary to chance, and you are back to two products; design it, and one source can serve both markets. That is what making adoption work looks like in regulated software.