Your software is used in healthcare. Does that make it a medical device?

The place of use is not the deciding factor

Scheduling software and a module intended to inform treatment decisions may run on the same computer in the same department. They do not automatically share a regulatory status. Starting with the healthcare sector or a brand name can lead a team to assess the wrong scope.

Begin with function: what information goes into the software, what comes out and what decision is the output intended to support? Describe the product actually offered, rather than only the technology or an ambition in a presentation.

Start with the manufacturer's intended purpose

Regulation (EU) 2017/745 defines medical devices and intended purpose. Instructions, product information and promotional claims contribute to this assessment. Broad language cannot substitute for a consistent description of functions and the claimed medical use.

The June 2025 revision of MDCG 2019-11 offers guidance on software qualification, modules and interfaces. It is guidance, not an individual device-status ruling or a replacement for the regulation. Software with an in vitro diagnostic purpose also requires consideration of the appropriate IVDR framework.

Rule 11 follows the device-status assessment

Once medical-device status is established, assess the relevant classification rules. Annex VIII Rule 11 distinguishes software providing information for diagnostic or therapeutic decisions, monitoring physiological processes and other software within its scope.

The potential consequences of decisions and the nature of monitored parameters can change the class. Other rules may apply as well: consider the relevant set rather than choosing a favourable phrase. MDCG guidance explains these distinctions; an AI label alone does not determine classification.

The assessment must also coordinate CE-marking requirements with GDPR obligations where personal data is processed. If the software meets the definition of an AI system, assess the AI Act against its use, the parties' roles and the applicable timeline. Medical-device class and AI high-risk classification have distinct criteria: both assessments must be conducted and connected.

Six inputs for a regulatory review

A scoping file should bring the following information together. This prepares the analysis; it is not the complete technical documentation that may be required.

• The precise intended purpose, users and target population.
• Functions, input data, outputs and the decisions they influence.
• Medical and non-medical modules, including dependencies and interfaces.
• Potential consequences of an incorrect or unavailable output.
• The reasoning for device status and classification, including unresolved issues.
• Product and document versions, with changes that require a renewed review.

Keep the assessment connected to product changes

Adding clinical recommendations to a document tool can change the assessment. A new population, indication or function may also undermine earlier assumptions. Review needs to follow relevant product changes.

For a NELSPACE demonstration, start with your intended purpose and ask how to organise facts, supporting documents, responsibilities and open questions. The supported scope must be explicit. Regulatory organisation software does not itself confer CE marking or replace participants required in the conformity-assessment process.