The research-to-product boundary

The same code can appear in two very different situations. In one, a research group runs a segmentation pipeline on retrospective data and records measurements for an analysis. In another, a service presents those measurements to clinicians as part of care or treatment planning. The algorithm and model weights may be identical, but the claim, users, workflow, responsibilities, and evidence burden are not. The first question at this boundary is therefore not “what kind of model is this?” It is “what is this software intended to do, for whom, and in which jurisdictional context?”

This section uses an EU-first example because its terminology makes the distinction visible. It is educational orientation, not legal advice. Other jurisdictions can use different definitions and routes, and a real project needs current official sources, privacy and regulatory expertise, and a fact-specific assessment. Nothing below classifies a real product.

Two contexts, identical code

Consider a constructed research-to-product scenario. Version A of a pipeline extracts total tumour volume from follow-up CT examinations in a retrospective research cohort; the values are analysed in a notebook and are not presented as instructions for a patient’s care. Version B uses the same code and weights but displays “tumour volume: 43.2 cm3, +18% since last scan” beside the images while clinicians plan therapy. The numbers and interface in this example are illustrative, not a real product claim.

The difference is not established by the file format, programming language, model architecture, or repository name. It is established by the intended use and the context in which people rely on the output. A research label cannot, by itself, answer what happens when a third party presents the output as a basis for a clinical decision. Conversely, a clinical-looking interface does not by itself establish a particular legal status. It identifies the facts that a product, privacy, ethics, and regulatory review must examine.

Qualification and classification follow the claim

Within the European Union, the Medical Device Regulation (MDR, Regulation (EU) 2017/745) is a relevant legal framework for medical devices, including software, when the applicable facts and intended medical purposes bring the software within its scope. The manufacturer’s intended purpose is central: claims in labelling, instructions for use, promotional or sales material, and the clinical evaluation can all be relevant to what the device is presented as doing. The same binary can therefore be used in a research setting and in a product setting while the surrounding claim is different.

Two questions must be kept separate. Qualification asks whether the software falls within the device framework for the intended purpose and facts at issue. Classification asks which risk category and conformity-assessment consequences follow if it does. The answer is not determined by model size, an AUROC, a segmentation score, or the fact that the software is called “research”. Nor can this chapter determine the classification of a real system. Current legal text and guidance, including the applicable software-classification reasoning, can change and must be checked in the maintained companion reference with jurisdictional expertise.

Crossing from research into a product context also changes the bundle of questions. The project may need evidence proportionate to the intended claims, risk management, quality and change control, post-market or incident processes, and a conformity route. Research use is not thereby free of ethics, privacy, security, or data-governance obligations. These are distinct obligations with distinct decision owners; none can be replaced by a model metric or by a DICOM conformance statement.

The AI Act relationship is conditional

The EU AI Act (Regulation (EU) 2024/1689) overlays other applicable frameworks; it does not make the MDR disappear. Its treatment of a system depends on facts such as intended use, the relationship to a product or safety component, the legislation in scope, and whether a relevant third-party conformity-assessment condition applies. Other routes and exemptions may also matter. It is therefore not a sound stable rule to say that every medical AI system is automatically high-risk.

For this dated, EU-scoped orientation, the source material also names MDCG 2019-11 rev.1 on software qualification and classification (June 2025). Exact guidance editions, transition dates, classification tables, and implementation practice are volatile. They belong in the companion Web and must be rechecked against current official material before a real decision. This chapter retains only the durable reasoning pattern: one intended-purpose analysis can inform several legal questions, but the questions remain separate and the answer depends on the facts.

The distinction from Chapter 10 is important here. Technical DICOM confidentiality, pseudonymisation, object identity, transport, and storage describe technical or governance properties. They do not establish that a release is legally anonymous, that software has a particular intended purpose, or that it has a particular regulatory classification. A DICOM-derived conclusion cannot substitute for jurisdiction-specific legal analysis.

When use changes the question

Return to the constructed example with three users. A university lab runs the pipeline on retrospective data. A hospital research team runs it in a hidden shadow workflow, with outputs withheld from clinicians. A clinician then begins using the same tool to prepare contours or measurements that inform treatment. These scenarios raise different questions about intended purpose, oversight, data handling, and accountability. They are teaching scenarios, not legal classifications of a real product or a claim that one fact alone decides the result.

The important engineering response is to notice the change rather than let the software’s research label hide it. If the planned use has become clinical, the team should stop treating the research description as a complete product specification and seek the appropriate regulatory, privacy, clinical, and governance review. If the intention remains research-only, the boundaries and limitations should be explicit in the workflow, access controls, documentation, and communication. Neither choice is created by deleting a DICOM tag or by keeping a repository private.

The purchaser faces the same boundary from the other side. A claim such as “validated” or “CE-marked”, when made about a real product, has to be compared with the labelled intended purpose, population, workflow, evidence, and local use. A mark or certificate is not a universal guarantee of reader benefit, local interoperability, patient safety, or clinical utility. The hospital must still ask who acts on the output, how updates are controlled, what evidence was generated with the relevant readers, and who owns monitoring and incidents. Those are the adoption questions assembled in the preceding section.

This boundary is deliberately recognition rather than determination. It teaches the reader to identify an intended-purpose change, separate technical from legal claims, and escalate a real case to the people qualified to decide it. It does not give a product a class, declare a research use lawful, or turn an illustrative EU discussion into advice for another jurisdiction.