Our cases
Clients about us
Software as a Medical Device: Qualification, Classification, and Development
When is software a medical device? Intended purpose, MDR Rule 11, risk classes, IEC 62304 and CE marking, with practical examples.
When software becomes a medical device
Software becomes a medical device when the manufacturer gives it a medical intended purpose. Article 2 of Regulation (EU) 2017/745 names purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation. MDCG 2019-11 helps with qualification. It does not replace the regulation. A system that only books appointments, beds, and invoices does not have that purpose. A wellness diary with no diagnostic claim does not either. The classification changes once the software suggests a finding, calculates a score for a clinical decision, or raises an alarm from a vital sign. In English this is often called SaMD. The measure on this page is the MDR.
Medical device software development then follows one frame: intended purpose, Rule 11, the IEC 62304 lifecycle, risk management under ISO 14971, and the technical documentation for CE marking. We do not copy the regulation. It is published on EUR-Lex as MDR (EU) 2017/745. Qualification of software is summarised in MDCG 2019-11. The standard itself is at the IEC webstore under 62304. WTT writes the software and the development evidence. The manufacturer affixes the mark. We do not promise a certificate.
The intended purpose as the starting point
An intended-purpose example: The software calculates a score from vital signs and lab values and flags patients the ward team should review first for sepsis. Users are physicians and nurses on a general ward, not lay people. The software does not diagnose and does not start treatment. It supplies information that feeds a diagnostic decision.
User, setting, and limit
The intended purpose names who uses the software, in which setting, and what it explicitly does not do. If the limit is missing, a notified body reads the widest sensible purpose. A display tool then becomes decision software. The sentence belongs in the technical documentation, not in a brochure.
The score is already Rule 11
The sepsis example supplies information for a diagnostic decision. Under MDR Rule 11 the floor is then class IIa. Whether IIb is closer depends on whether an error can cause a serious deterioration. The manufacturer states the class. We do not assign it.
A narrow sentence does not hide a function
Leaving the function in the code and omitting it from the intended purpose does not change the real purpose. Class I is not a design goal. It remains only when the software neither feeds decisions nor monitors physiological processes. Otherwise the function sets the class.
No document without a manufacturer
The manufacturer signs the intended purpose, not the development supplier. Without that person there is no honest risk class and no technical documentation. We stop the regulatory write-up until the manufacturer is named. We can still design the software. We cannot prepare the marking.
A project from our work
Connect with students for live 1-on-1 college insights and tours
EXPERTISE
Education
TECHNOLOGIES
What this means for your project
Qualification first
Before production code, we write the intended purpose so Rule 11 can be tested against it. If the work sits inside a broader clinical system, the overview is custom healthcare software. The class follows the sentence, not the wish to avoid a notified body.
Qualification first
Before production code, we write the intended purpose so Rule 11 can be tested against it. If the work sits inside a broader clinical system, the overview is custom healthcare software. The class follows the sentence, not the wish to avoid a notified body.
An IEC 62304 lifecycle
Plan, requirements, architecture, verification, and release are evidence, not slides added later. Software safety class A, B, or C sets the depth. SOUP items are named and checked for known anomalies. The ISO 13485 quality system belongs to the manufacturer. We deliver into that system.
Evidence, not a mark
We write the development parts of the technical documentation: requirements, architecture, tests, traceability, and SOUP. The manufacturer affixes the CE marking, signs the declaration of conformity, and adds the notified-body number when one was involved. We do not promise an authority decision or a directory entry.
Telematics infrastructure is separate
Connecting the software to the German telematics infrastructure is its own scope, with its own interfaces and deadlines. Qualification as a medical device does not replace that connection. The German page for that scope is planned as Telematikinfrastruktur-Anbindung.
Keep interoperability separate
Profiles and interfaces do not automatically change the intended purpose, but they can sharpen it. Software that only transports data is often not a device. Software that prepares data for a decision falls under Rule 11. The German cluster page for that scope is Interoperabilität im Gesundheitswesen.
What remains after release
Post-market surveillance stays with the manufacturer. Software changes, known anomalies, and SOUP updates have to enter that process. We can document the change and repeat the test. Reports to the authority and to the notified body stay with the manufacturer. A maintenance contract is not a marking.
IEC 62304: the software development lifecycle
IEC 62304 describes processes, not an MDR risk class. Software safety class A, B, or C decides which activities may be reduced. Class A is the narrowest, class C the strictest. Maintenance is a separate process beside these eight development steps. SOUP is software that was not created under this process for the device.
Software development plan
The plan names the lifecycle, software safety class A, B, or C, the tools, and the SOUP list. Without a class, the later evidence is a guess. The result is the plan, not the code.
OutputPlan and safety class
Software development plan
The plan names the lifecycle, software safety class A, B, or C, the tools, and the SOUP list. Without a class, the later evidence is a guess. The result is the plan, not the code.
OutputPlan and safety class
Software requirements
Each requirement traces to the intended purpose and to a risk under ISO 14971. What the software must not do is written beside that. The wish list ends here.
OutputRequirements and acceptance
Software architecture
The architecture separates units, interfaces, and SOUP. A unit that prepares a clinical decision stays visible. It does not disappear into an unnamed library.
OutputArchitecture and SOUP
Software detailed design
For safety class B and C the detailed design describes units so someone else can review them. Class A may narrow this step. The standard allows the cut. The risk does not.
OutputUnit design
Implementation and verification
Units are built and checked against their design. Known anomalies in SOUP are evaluated, not only listed. A passing unit test is not yet a system test.
OutputUnits and records
Integration and integration test
The units run together, including SOUP. The integration test covers interfaces and failures a single unit does not show. The record names the version.
OutputIntegrated version
Software system test
The system test checks the software against the requirements and the intended purpose. A green build with no link to a requirement does not count. Traceability ends in this record.
OutputSystem test
Software release
Release lists the version, residual anomalies, SOUP, and open points. It is the handover to the manufacturer, not the CE marking. The declaration of conformity stays with the manufacturer.
OutputRelease record
MDR Rule 11 and the risk classes
Rule 11 in Annex VIII of the MDR classifies software. The left column is the class, the middle an example, the right what a notified body usually reviews on that path. The final class sits in the intended purpose. This table is a reading aid, not a decision.
- Notified body reviews the device
- Only one aspect, or a second procedure
- No body for the device
Technical documentation and CE marking
The months are planning corridors from conformity-assessment practice, not deadlines in the MDR and not a date from WTT. The technical documentation describes the intended purpose, the design, evidence against the general safety and performance requirements, risk management, and the clinical evaluation. The manufacturer affixes the CE marking after the assessment. We do not issue it.
Class I
Declaration
6–12 months
- Manufacturer’s declaration of conformity
- Technical documentation still complete
- Quality system, often via ISO 13485
- Usability under IEC 62366
- Post-market surveillance as a report
Class IIa
Sample
12–18 months
- Notified body in the procedure
- A sample of the technical documentation
- Lifecycle under IEC 62304
- Risk management under ISO 14971
- A PSUR, not only a report
Class IIb and III
Full review
18–30 months
- Review of the technical documentation
- Clinical evaluation in focus
- Software safety class often C
- Changes go through the body
- No promise of a finish date
What clients say
INDUSTRY RECOGNITION
Luklabs
Acting CEO
The team is smart, creative, nice, calm, and professional, and they are problem solvers.
WTT Solutions paid attention to details. Most of their first iterations were very close to our intended designs. Consequentially, we didn’t have to do a ton of revisions in the QA phase.
I greatly enjoyed working with them.
Where the MDR stops and the IVDR starts
The same codebase can be two products. What matters is whether the intended purpose acts on a person or on a specimen outside the body. The IVDR (EU) 2017/746 has its own classes. The text is on EUR-Lex. One product does not carry both regulations for the same purpose.
A specimen outside the body
Software that interprets a lab result or a self-test to support a diagnosis usually falls under the IVDR. MDR Rule 11 is the wrong key. The notified body needs the IVDR scope.
An effect on a person
Software that prepares vital signs, images, or a clinical score for a decision about a patient stays under the MDR. The sepsis example above is that path. The IVDR does not apply on top.
Two purposes, two products
If the same software once scores a ward and once diagnoses from a blood specimen, those are two intended purposes. Each needs its own class, its own file, and its own conformity procedure.
Different classes, same discipline
The IVDR does not use I, IIa, IIb, and III. Its software often lands in class B or C once it supplies information for a decision. IEC 62304, ISO 14971, and ISO 13485 remain the working standards.
Transport is not yet a device
An interface that only forwards a lab value and does not interpret it is often neither a medical device nor an in vitro diagnostic. Once it alerts, filters, or suggests an action, qualification starts again.
The DiGA special case
01
CE marking is not the directory
A DiGA needs a CE marking and a separate listing at the BfArM. The marking alone does not open the directory. The frame is described by the BfArM. We do not file the application.
02
Class I, IIa, or IIb
Since the DigiG, an application in risk class I, IIa, or IIb can be a DiGA. Class III does not meet the basic requirement. For IIb the conformity assessment is already finished, and the medical benefit is part of the application. The intended purpose decides that first.
03
A positive healthcare effect
Permanent listing requires the manufacturer to show a positive healthcare effect. Provisional listing on a study plan exists for class I and IIa, and it is time-limited. For class IIb the medical benefit is already part of the application. A software test does not replace it.
04
Data protection and interoperability
The DiGAV asks for evidence on data protection, information security, and interoperability, in addition to the MDR. Those records sit beside the technical documentation. The BfArM publishes the criteria. We do not invent them.
05
What we build on this path
We build the software, the IEC 62304 lifecycle, and the development evidence. Usability work under IEC 62366 can be prepared. The positive healthcare effect, the directory entry, and the marking stay with the manufacturer and the competent body.
06
No promise of a listing
A finished system test is not a BfArM decision. We promise neither provisional nor permanent listing. If the intended purpose sits in class III, we say so before anyone plans a directory application.
Risk management under ISO 14971
ISO 14971 is the process the manufacturer uses to find, evaluate, and control hazards. The standard is not the MDR risk class and not software safety class A, B, or C in IEC 62304. Three scales, three questions. We do not reproduce the standard. It is published by ISO. We deliver the software inputs into the manufacturer’s risk-management file.
Risk-management plan
The plan names acceptability criteria, roles, and the link to the intended purpose.
Risk analysis
Hazards come from the intended use and from reasonably foreseeable misuse.
Risk evaluation
Each risk is judged against the plan before anyone calls it acceptable.
Risk control
Controls change the software, the instructions for use, or both. A control without evidence is still an intention.
Residual risk
What remains after control is evaluated. It does not vanish because a test is green.
Benefit and risk
The manufacturer weighs clinical benefit against residual risk. We do not sign that judgement.
Production and SOUP
Information from the build and from known SOUP anomalies goes back into the file.
Post-market surveillance
Findings after placing on the market reopen the file. The manufacturer runs that surveillance.
AI software: the MDR and the AI Act
AI software that is itself a medical device, or a safety component of one, and that needs a notified body is a high-risk system under Article 6(1) of Regulation (EU) 2024/1689. The MDR and the IVDR are listed for that route in Annex I. Under Article 113 as it stands, that path applies from 2 August 2028. Class I with no notified body does not automatically fall into the same bucket. MDR duties continue either way: intended purpose, Rule 11, IEC 62304, ISO 14971, and the technical documentation. The regulation is on EUR-Lex. This is a reading aid, not legal advice, and not a promise that a marking will exist on that date.
OpenAI
Google Gemini
Anthropic Claude
LangChain
LlamaIndex
Perplexity API
RAG / Pinecone / Qdrant
PostgreSQL
MySQL
MongoDB
Redis
Docker
Kubernetes
Terraform
GitHub Actions
Hi, I’m Serge!
CEO & Co-founder at WTT Solutions
Do you have a new project? Or want to say "Hello"...
