SaMD risk categorization and the IMDRF framework

Does the IMDRF framework decide your class?

Nothing in the binding text sends you to it. Across the regulatory records this site keeps behind its standard pages, IMDRF appears in a classification context once, and it appears there as an influence on a legislature. MDCG 2019-11 Rev.1 explains that Rules 9, 10 and 12 of the MDR address risks from the exchange of energy or substances, that software "relates to the consequences of indirect harm from failure to provide correct information", and that "in line with Recital 5 of the Medical Device Regulation and international guidance from the IMDRF ..., Rule 11 was introduced into the MDR and is intended to address the risks related to the information provided by an active device, such as MDSW."

That is a sentence about why Rule 11 exists. It routes no product anywhere. Article 51(1) of Regulation (EU) 2017/745 states the operative scheme: "Devices shall be divided into classes I, IIa, IIb and III, taking into account the intended purpose of the devices and their inherent risks. Classification shall be carried out in accordance with Annex VIII." Annex VIII holds twenty-two rules, numbered 1 to 22 with no gaps, and none of them incorporates an international category set.

Guidance carries the weight guidance carries, and MDCG says so about its own work: the document "is not a European Commission document", and its views "are not legally binding and only the Court of Justice of the European Union can give binding interpretations of Union law." A harmonisation document one step further out from the Regulation sits further out again.

Which categorization is each person actually asking about?

Four schemes reach the same piece of software, and they answer to different inputs. Whether the software is a medical device at all is the prior question, worked through at is my health app a medical device; everything below runs after that answer is yes.

Four classification schemes for medical device software under EU MDR, EU IVDR, FDA premarket guidance and IEC 62304, with each outcome and what it decides.

The question	The instrument	The outcome	What the outcome decides
Which EU device class?	MDR Annex VIII Rule 11, with implementing rules 3.3 and 3.5, under Article 51(1)	I, IIa, IIb or III	Whether a notified body enters your development records, under Article 52
Which EU IVD class?	IVDR Annex VIII Rules 1 to 7, with implementing rule 1.4, under Article 47(1)	A, B, C or D	The conformity route under Article 48, and how often a PSUR is due
Which FDA documentation level?	"Content of Premarket Submissions for Device Software Functions", June 2023	Basic or Enhanced	How much of the software file is written into the submission
Which IEC 62304 safety class?	clause 4.3, assigned per software item	A, B or C	Which clauses of the standard bind, through the class marker on each requirement

Two of these four schemes are driven by what the product claims to do, and two by what happens when it does that wrong, which is why one letter never satisfies all four questions at once.

What does each EU class cost you?

The class decides who reads your file and how often you have to write to them again. Article 52(7) keeps a class I file inside the company: the manufacturer draws up the technical documentation set out in Annexes II and III and issues the EU declaration of conformity itself. Three exceptions bring an assessor back into a class I product, and they are sterility, a measuring function and a reusable surgical instrument. Article 52(6) sends class IIa through Chapters I and III of Annex IX, including a Section 4 technical documentation assessment "of at least one representative device for each category of devices". Article 52(4) does the same for class IIb, with the representative device taken "per generic device group". Article 52(3) sends class III through Annex IX, or through Annex X coupled with Annex XI.

The recurring cost is set by the same letter. Article 85 gives class I manufacturers a post-market surveillance report. Article 86 gives class IIa, IIb and III a periodic safety update report and sets its interval by class: IIb and III update the PSUR at least annually, IIa at least every two years. A class settled in one afternoon therefore fixes a reporting rhythm for as long as the product stays on the market.

Rule 11 itself, its paragraphs and the class each one produces, is quoted in full on EU MDR software requirements. One implementing rule is worth carrying into the budget conversation before you get there. Implementing rule 3.5 says that where several rules or sub-rules apply, "the strictest rule and sub-rule resulting in the higher classification shall apply", and MDCG names seven Annex VIII rules to weigh for software: 9, 10, 11, 12, 13, 15 and 22. A product placed by reading Rule 11 alone has been placed on one rule out of seven.

Why does the IVDR answer come out differently?

Because there is no software rule to read. The IVDR's entire software mechanism is Annex VIII implementing rule 1.4: "Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right." Independent software is then run against the same seven rules a reagent is run against, and Article 47(1) divides devices into classes A, B, C and D.

Three of those rules move a health software product a long way from where its founders expect to land.

• Rule 3 is the class C list, thirteen points lettered (a) to (m). Point (f) covers devices "to be used as companion diagnostics", which puts every companion diagnostic at class C or above, software included. Point (h) covers screening, diagnosis or staging of cancer, and point (i) human genetic testing.
• Rule 4(a) classifies devices intended for self-testing as class C, with a named list of exceptions at class B: pregnancy detection, fertility testing, cholesterol level, and detection of glucose, erythrocytes, leucocytes and bacteria in urine. A lay-facing self-test product outside that list is class C by default.
• Rule 6 is the residual rule and reads in full: "Devices not covered by the above-mentioned classification rules are classified as class B." Independent software has no class A landing place, so the IVD equivalent of the MDR's quiet class I outcome does not exist.

The consequence for the calendar arrives immediately. Article 48(10) lets class A manufacturers declare conformity themselves, and class B, C and D all take Annex IX Chapters I and III with a technical documentation assessment. A team that called its product low risk because Rule 11 did not seem to catch it has usually been reading the wrong regulation, and the residual answer under the right one is class B with an assessor attached. The rules, the implementing rules and the routes are set out on IVDR software testing requirements.

Two implementing rules close the door on a narrower reading. Rule 1.7 requires the manufacturer to take all classification and implementing rules into account, and rule 1.8 says that where a manufacturer states multiple intended purposes and the device consequently falls into more than one class, it is classified in the higher class. Adding a second claim to a marketing page is a classification event.

What does the FDA decide instead of a category?

Two things, and neither of them is a category. The first is the route. 21 CFR 807.81 requires a premarket notification at least 90 days before a device is introduced into interstate commercial distribution, and section 513(i) of the Federal Food, Drug, and Cosmetic Act defines the substantial equivalence that route runs on: the same intended use as the predicate, plus either the same technological characteristics or information showing the device is as safe and effective as a legally marketed device and raises no different questions of safety and effectiveness. Where no predicate exists, 21 CFR Part 860 Subpart D runs the De Novo request. 21 CFR 860.240(a) gives FDA 120 days from acceptance to grant or decline, and 21 CFR 860.260(a)(2) requires a Federal Register notice of the classification order within 30 days of a grant, so the output of a granted De Novo is a classification order placing the device in class I or class II together with any special controls. Premarket approval sits in 21 CFR Part 814.

The second decision is the documentation level, and it governs how much of your testing evidence leaves the building. The guidance that sets it is "Content of Premarket Submissions for Device Software Functions", issue date June 2023, docket FDA-2021-D-0775, which replaced the 2005 guidance on software contained in medical devices. Enhanced Documentation applies where a failure or flaw of a device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are applied. Basic Documentation applies where Enhanced does not.

The phrase "before risk control measures are applied" is where two of these schemes part company. IEC 62304 assigns class A where the hazardous situation "does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM". One test is applied before the mitigations and the other after them, so an argument that lowers the safety class does not lower the documentation level with it. Enhanced adds a complete software design specification with traceability, and unit and integration level test records, on top of the Basic set. What a submission then reads is covered in FDA 510(k) software documentation.

Which class does IEC 62304 give you, and who writes the threshold?

Clause 4.3 assigns the class per software item, from the harm that stays possible in a worst case. Class A covers a software system that cannot contribute to a hazardous situation, or contributes to one that leaves no unacceptable risk once external risk control measures are counted. Class B is where unacceptable risk remains and the possible harm is non-serious injury. Class C is where the possible harm is death or serious injury. A group of software items takes the class of its highest-classified member, so an item nobody classified does not sit at class A by default. The clause set each letter binds is on IEC 62304 software testing requirements.

The load-bearing word in that clause is "unacceptable", and IEC 62304 does not define it. ISO 14971 supplies no threshold either. Its scope says the document "requires manufacturers to establish objective criteria for risk acceptability but does not specify acceptable risk levels", and subclause 4.4 puts those criteria inside the risk management plan, next to the method for evaluating overall residual risk and the criteria for accepting it. Your safety class therefore rests on a document your own team wrote and your own top management approved. Where those criteria are vague the class is vague with them, and the argument comes apart at the first assessor question. Where those criteria come from, and which of them a test run can actually evidence, is covered on ISO 14971 risk management and software testing.

In what order do you settle it?

Step 6 is the one teams postpone, and postponing it is expensive in a specific way. The class decides the depth of unit and integration evidence, and that evidence has to be produced while the code is being written. Rebuilding it after a release means running work a second time without the context that made it cheap the first time. If you are pricing that decision now, the validation scope estimate walks the same inputs.

What does the finished categorization hand over?

Four documents. Each one answers a question an assessor asks in a fixed order.

• A classification justification. It names the rule applied and the class it produced. Annex II Section 1.1(f) requires it.
• A software safety classification record, one entry per software item. Each entry names the external risk control measures the class depends on.
• A documentation level evaluation for the US route, with the rationale for Basic or Enhanced.
• A test plan scoped to the class. The plan states which clauses bind and which records each run must leave.

Which categorization mistakes cost the most money?

• The class is answered with an international category, so the reader derives the binding class again and asks a second round of questions.
• Only Rule 11 is checked, where MDCG names rules 9, 10, 11, 12, 13, 15 and 22 and implementing rule 3.5 takes the strictest of them.
• IVD software is treated as unclassified because the IVDR has no software rule, when Rule 6 makes independent software class B and Article 48(10) reserves self-declaration for class A.
• A companion diagnostic feature is added to a classified product without reopening the class, although Rule 3(f) puts companion diagnostics at class C.
• Class A is recorded for a software item and the external risk control measures holding that assignment up are named nowhere, which leaves the second limb of clause 4.3 unevidenced.
• The FDA documentation level is derived from the safety class, although the Enhanced criterion is assessed before risk control measures are applied and the safety class after them.
• The class is settled at kickoff and the intended purpose statement moves afterwards, on a pricing page nobody routed past regulatory affairs.

Sources for this page. Article 51(1), Article 52(3), (4), (6) and (7), Articles 85 and 86, Annex II Section 1.1(f), the Annex VIII structure and implementing rules 3.3 and 3.5 are read in the official consolidated text 02017R0745 as at 1 January 2026. Article 47(1), Article 48(10), Annex VIII implementing rules 1.4, 1.7 and 1.8, and Rules 3, 4, 5 and 6 are read in consolidated text 02017R0746. The MDCG passages, including the IMDRF sentence and the guidance's own disclaimer, are read in MDCG 2019-11 Rev.1, published 17 June 2025. The clause 4.3 wording and the class criteria are read in IEC 62304 Edition 1.1, and the acceptability wording in ISO 14971, the 2019 third edition. The 510(k), De Novo and PMA citations are taken from the eCFR issue of 31 August 2026. The Enhanced Documentation criterion and the Table 1 contents are read in FDA's guidance issued on 14 June 2023, Section V, on 10 September 2026.

What can a testing supplier settle here, and what can it not?

No supplier assigns your class. Annex II Section 1.1(f) asks the manufacturer for the risk class and the justification of the classification rule applied, and that justification is signed by whoever owns the technical documentation. An outside team cannot sign it and cannot stand behind it.

Testing settles the evidence a class argument leans on. Where a class A assignment under IEC 62304 clause 4.3 names external risk control measures, each of those measures owes proof that it works, and clause 4.3 gives a health care procedure as one example of such a measure. Where a class under Rule 11 or IVDR Rule 3 rests on a stated intended purpose, the evidence that the software stays inside that statement is a set of test results carrying the build they ran on. Both are producible before an assessor asks, and both take longer to reconstruct afterwards than to record at the time.

Classification work touches your documents far more often than it touches patient records. We do not need production PHI to test. Environments run on synthetic and de-identified data, and we sign a Business Associate Agreement before any engagement that touches PHI. Where an argument for a lower class leans on evidence drawn from live use, the handling terms are agreed before the environment exists, and our answers on protected health information set out what those terms are.