Which standards do the risk, usability, software and security files rest on, and how is the answer kept current?

Introduction#

A medical device, or an in vitro diagnostic medical device (IVD), meaning a test run on samples taken from the body, is placed on the European Union (EU) market with technical documentation. That documentation shows the product meets the general safety and performance requirements, the duties set out in Annex I of each regulation. Four files within it answer the requirements on risk, use error, software and security. Each file is usually built to a standard, a published technical specification from a body such as ISO or IEC. Whether that standard gives a presumption of conformity, meaning the law treats a device that follows it as meeting the requirements it covers, decides how much the file has to prove by its own argument.

The rules are in the Medical Device Regulation, Regulation (EU) 2017/745 (MDR), and the In Vitro Diagnostic Medical Device Regulation, Regulation (EU) 2017/746 (IVDR). The four files rest on four control standards, one from ISO and three from IEC. On the check date only one of them, the risk management standard, was cited in the EU's Official Journal and so gave the presumption. For the other three files, the company has to show conformity through its own demonstration.

Four illustrative products recur in the book. The monitor is a wearable cardiac monitor from a US company, and the triage tool is software enabled by artificial intelligence (AI) from a European company. The implant is a spinal implant system certified under the former directive, and the near-patient test is a cardiac troponin test from a Swiss company.

The chapter reads each text in its consolidated version, meaning the text with later amendments merged in. The MDR is stated as consolidated on 19 July 2026, the IVDR on 10 January 2025, and the EU lists of cited standards on 17 June 2026. All were checked on 29 September 2026, and every finding on which standards are cited holds as of that date.

1. Which requirements do the four files answer?#

Annex I of each regulation sets the general safety and performance requirements. Devices have to achieve their intended performance and be safe and effective, provided any risks are acceptable against the benefits to the patient. The generally acknowledged state of the art is taken into account. (MDR Annex I s. 1; IVDR Annex I s. 1)

Risk management. Manufacturers establish, document, implement and maintain a risk management system. Section 3 describes it as a continuous iterative process throughout the device's lifecycle, requiring regular systematic updating. (MDR Art. 10(2); Annex I s. 3; IVDR Art. 10(2); Annex I s. 3)

Among the activities Section 3 lists, point (c) covers risks during intended use and reasonably foreseeable misuse. Point (e) evaluates information from production and, in particular, from post-market surveillance. (MDR Annex I s. 3)

Section 4 sets the order in which risk controls are chosen. Safe design and manufacture come first, then protection measures, including alarms if necessary, and last information for safety and, where appropriate, training. Users are told of any residual risks. (MDR Annex I s. 4; IVDR Annex I s. 4)

Usability. Section 5 addresses risks related to use error. The manufacturer reduces as far as possible the risks from the device's ergonomic features and its intended use environment. It gives consideration to the users' technical knowledge, experience, education, training and use environment, where applicable, and to their medical and physical conditions. Article 2 of the MDR has no definition of use error. (MDR Annex I s. 5; IVDR Annex I s. 5)

Software. Software is designed for repeatability, reliability and performance in line with its intended use. It is developed and manufactured in accordance with the state of the art. That takes into account the principles of development life cycle and of risk management, including information security, and verification and validation. Section 17.2 names no standard. (MDR Annex I s. 17.1, 17.2; IVDR Annex I s. 16.1, 16.2)

Software for mobile platforms takes into account the platform's features, such as screen size, and external factors, such as varying light or noise. (MDR Annex I s. 17.3; IVDR Annex I s. 16.3)

Security. Manufacturers set out minimum requirements for hardware, information technology (IT) network characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. The instructions for use contain the same minimum requirements. Devices also reduce the risks of negative interaction between software and its IT environment. (MDR Annex I s. 14.2(d), 17.4, 23.4(ab); IVDR Annex I s. 13.2(d), 16.4, 20.4.1(ah))

For active devices and devices connected to them, the MDR adds protection, as far as possible, against unauthorised access that could hamper intended functioning. The MDR deems software to be an active device, so Section 18.8 also reaches software that is itself a device. The IVDR has no equivalent provision. (MDR Art. 2(4); Annex I s. 18.8)

(MDR Annex I; IVDR Annex I)

What guidance is worth#

The MDCG endorses the documents that carry its name. Its members represent the competent authorities of the Member States, and it is chaired by a representative of the Commission. (MDR Art. 103(2), (5))

Each MDCG document cited here says it cannot be regarded as reflecting the official position of the European Commission, and that any views in it are not legally binding. The Blue Guide describes itself as purely a guidance document in the same way. (MDCG 2019-16 rev.1, p. 1; Blue Guide, introduction)

2. How do the four files connect?#

The regulations do not require four separate files. Annex II sets what the technical documentation contains, including the solutions adopted and the results of risk management, and chapter 7 covers it. (MDR Annex II s. 5; IVDR Annex II s. 5)

Use error and the risk file. Section 3 covers reasonably foreseeable misuse, and Section 5 covers use error. The human factors guidance of the US Food and Drug Administration (FDA) defines two terms needed to link the usability file to the risk file. It is US guidance, and it binds neither FDA nor the public. (MDR Annex I s. 3, 5; FDA human factors guidance, preface)

(FDA human factors guidance, s. 3)

Our reading is that a use error found in usability testing belongs in the risk file as the start of a sequence. The sequence runs to the hazardous situation it could reach, the harm, and the control that answers it.

Security and safety. MDCG 2019-16 rev.1 places security risks inside the device's risk management process, to avoid the misunderstanding that a separate process is needed. Security risks use their own methods, with the same elements as safety: analysis, evaluation, control, residual risk and reporting. A security risk management plan documents them. (MDCG 2019-16 rev.1, s. 3.2)

A security control that could affect safety belongs in the safety risk assessment, and a safety control that could affect security belongs in the security analysis. The guidance's example is a blanked screen, which may protect personal data but is a safety concern on a device displaying vital signs. (MDCG 2019-16 rev.1, s. 2.4, 3.2)

After launch. Point (e) of Section 3 feeds post-market information back into the hazards and the risk estimates. MDCG 2019-16 rev.1 expects a process to gather post-market security information, such as new vulnerabilities in the manufacturer's own and third-party components. (MDR Annex I s. 3; MDCG 2019-16 rev.1, s. 3.8)

3. When does a standard give a presumption of conformity?#

A standard is a technical specification adopted by a recognised standardisation body, with which compliance is not compulsory. A harmonised standard is a European standard adopted on a request from the Commission for the application of Union harmonisation legislation. That definition says nothing about publication in the Official Journal. (Regulation (EU) No 1025/2012, Art. 2(1))

The MDR and the IVDR add that condition. Devices in conformity with relevant harmonised standards, or parts of them, whose references are published in the Official Journal are presumed to conform with the requirements those standards cover. The same applies to process requirements, and risk management is named among them. (MDR Art. 8(1); IVDR Art. 8(1))

The Blue Guide adds that, as long as the reference is unpublished, the standard gives no presumption. It says harmonised standards never replace legally binding essential requirements. (Blue Guide, s. 4.1.2.2)

What limits the presumption?#

Chapter 4 sets out the limits on the presumption for the quality system standard, and three of them apply here in the same way.

(Blue Guide, s. 4.1.2.3; MDCG 2021-5 rev.1, s. 2.3)

Where a manufacturer does not apply a harmonised standard, the Blue Guide says it has to demonstrate conformity by other means of its own choice. (Blue Guide, s. 4.1.2.3)

Is the use of a standard compulsory?#

MDCG 2021-5 rev.1 says use of any standard, cited or not, is and remains voluntary, as chapter 4 also sets out. A manufacturer may use its own solutions, provided it can demonstrate they are adequate to comply with the legal requirements. The demonstration "can be given" through a more in-depth risk assessment, gap analysis and similar work, reflected in the technical documentation. (MDCG 2021-5 rev.1, s. 2.2, pp. 7 and 9)

In the guidance's reading, neither national authorities nor notified bodies can impose a specific standard, harmonised or "state-of-the-art", apart from the exceptions it names. (MDCG 2021-5 rev.1, s. 2.2, p. 9)

A notified body is a conformity assessment body designated in accordance with the regulations. Annex VII still places a duty on it. Where relevant, it takes into consideration available common specifications, guidance and best practice documents and harmonised standards, even if the manufacturer does not claim compliance. (MDR Art. 2(42); Annex VII s. 4.5.1; IVDR Art. 2(34); Annex VII s. 4.5.1)

Our reading is that a notified body can take an uncited standard into consideration as a best practice document, although Annex VII does not say so expressly.

One of the exceptions the guidance names is symbols and identification colours, where a harmonised standard cited in the Official Journal contains indications on symbols or colour coding. Any symbol or identification colour used has to conform to the harmonised standards or common specifications. Where neither exists, the symbols and colours are described in the documentation supplied with the device. (MDR Annex I s. 23.1(h); IVDR Annex I s. 20.1(h); MDCG 2021-5 rev.1, s. 2.2, p. 8)

4. What does "state of the art" ask for?#

Annex I asks manufacturers to take the generally acknowledged state of the art into account, and to develop software in accordance with it. MDCG 2021-5 rev.1 says "state of the art" is not a legally defined concept, and that "taking into account" differs from "compliance". For software, Section 17.2 uses different words, "in accordance with". (MDR Annex I s. 1, 4, 17.2; MDCG 2021-5 rev.1, s. 3.5, p. 16)

Our reading is that the software file shows how the edition of the standard to which the software was developed meets the state of the art.

The guidance quotes a Commission statement from the minutes of its Subgroup on Standards of 20 May 2019. The most recent editions of standards should be considered as reflecting the state of the art, regardless of Official Journal referencing. (MDCG 2021-5 rev.1, s. 3.5, pp. 16 and 17)

Without further evidence in the technical documentation, compliance with the most recent version of an uncited standard does not automatically imply compliance with the legislation. "State-of-the-art" standards as such confer no presumption unless their references are cited. (MDCG 2021-5 rev.1, s. 3.5, pp. 17 and 18)

5. Which of the four control standards were cited on the check date?#

The Official Journal lists are Commission implementing decisions. Implementing Decision (EU) 2021/1182 publishes the references of harmonised standards drafted in support of the MDR, and Implementing Decision (EU) 2021/1195 does the same for the IVDR. (Implementing Decision (EU) 2021/1182, Art. 1; Implementing Decision (EU) 2021/1195, Art. 1)

Each list is read in a consolidated text, which names the amending decisions it takes in. A consolidation is a documentation tool with no legal effect, and the authentic texts are the acts published in the Official Journal. (Implementing Decision (EU) 2021/1182, consolidated text, p. 1)

The values below are a dated example, as read on 29 September 2026. Later publications are listed on the Commission's harmonised standards page. (Commission harmonised standards page)

In the consolidated MDR list of 17 June 2026, entry 16 is EN ISO 14971:2019 with its amendment EN ISO 14971:2019/A11:2021. The citation is of the European adoption with its A11 amendment, and not of ISO 14971:2019 alone. The IVDR list carries the same reference as entry 10. (Implementing Decision (EU) 2021/1182, Annex, entry 16; Implementing Decision (EU) 2021/1195, Annex, entry 10)

Implementing Decision (EU) 2022/757 of 11 May 2022 added that reference to the MDR list, and Implementing Decision (EU) 2022/729 of the same date to the IVDR list. Their recitals record that the European Committee for Standardization (CEN) and the European Committee for Electrotechnical Standardization (Cenelec) revised EN ISO 14971:2019 to adapt it to each regulation, which resulted in A11:2021. (Implementing Decision (EU) 2022/757, recital (4), Annex; Implementing Decision (EU) 2022/729, recital (4), Annex)

Neither list, as consolidated on 17 June 2026, refers to IEC 62304, IEC 62366-1 or IEC 81001-5-1, in any edition or European adoption. That finding is bounded to those consolidations and to a check on 29 September 2026 that found no later amending decision. On that date, EN ISO 14971 with A11 was the one control standard of the four that gave a presumption of conformity. (Implementing Decision (EU) 2021/1182, Annex; Implementing Decision (EU) 2021/1195, Annex)

(ISO 14971 catalogue page; IEC 62304 consolidated version record; IEC 62304 record; IEC 62366-1 consolidated version record; IEC 81001-5-1 record; M/575, Annex I Table 1 items 97, 203, 204; Table 2 item 50)

Does a standardisation request deadline give a presumption?#

Standardisation request M/575, adopted on 14 April 2021 and amended in 2023 and 2024, asks CEN and Cenelec to revise existing harmonised standards and draft new ones. Table 1 of each Annex lists standards to revise, and Table 2 new standards to draft, for the MDR in Annex I and the IVDR in Annex II. On the Commission's page, the consolidated request is provided for information purposes only. (M/575, Art. 1; Commission harmonised standards page)

For IEC 81001-5-1, the entry is a request to draft a new standard in support of the MDR, and the standard does not appear in Annex II, which covers the IVDR. A request deadline is the date by which the standards bodies are to deliver. Publication of a reference in the Official Journal is a separate act, and the presumption of conformity runs from that publication. (M/575, Annex I Table 2 item 50; Implementing Decision (EU) 2026/1231, recital (13))

6. What do the catalogues show for each standard?#

Because the clause text is in the licensed standards, this section draws on the catalogue pages, which give each standard's status and a summary of its scope.

Risk. iso.org lists ISO 14971:2019 as edition 3, confirmed in 2025, and says this version remains current. It marks the guidance companion, the technical report (TR) ISO/TR 24971:2020, as a standard to be revised. (ISO 14971 catalogue page; ISO/TR 24971 catalogue page)

ISO/TS 24971-2:2026, a technical specification (TS) published in June 2026, gives guidance on applying the ISO 14971 process to machine-learning-enabled devices. Its abstract says it does not apply to devices employing large language models or generative AI. Projects at earlier stages are listed on iso.org and in ISO Open Data. (ISO/TS 24971-2 catalogue page; ISO Open Data)

Software. The IEC Webstore describes IEC 62304 as applying to the development and maintenance of medical device software. That covers software that is itself a device and software embedded in or integral to the device, and excludes validation and final release of the device. The iso.org catalogue lists the 2006 edition as confirmed in 2023 and current, with one amendment. (IEC 62304 consolidated version record; IEC 62304 catalogue page, iso.org)

The IEC record lists an edition 2.0 at status PREPARING, with a forecast publication date of 26 October 2028. Edition 1 and its 2015 amendment show status PUBLISHED and are not withdrawn. Our reading is that the published edition is the one a file is built to, and the forecast is a watch item until a new edition is published. (IEC 62304 record)

Usability. iso.org summarises IEC 62366-1 as a process to analyse, specify, develop and evaluate a device's usability as it relates to safety. The process addresses risks of correct use and use errors, which it calls normal use. It can identify, but does not assess or mitigate, risks of abnormal use. (IEC 62366-1 catalogue page, iso.org)

IEC/TR 62366-2:2016 gives guidance on applying the standard, and its abstract says the report contains no requirements and is not intended to be used for regulatory purposes. Its planned replacement is listed on iso.org. (IEC/TR 62366-2 catalogue page)

7. What applies to security when no standard is cited?#

The security requirements in Annex I apply whether or not a harmonised standard exists for them. MDCG 2019-16 rev.1, of July 2020, guides manufacturers on meeting them. It maps the MDR sections to the IVDR ones. (MDR Annex I s. 17.2, 17.4; MDCG 2019-16 rev.1, s. 1.1 to 1.3)

The guidance says weak security can compromise patient safety. So can measures so restrictive that staff cannot reach an implanted cardiac device in an emergency. It concludes that security issues belong in the Annex I risk assessment even where the regulations do not mention security. (MDCG 2019-16 rev.1, s. 2.2)

It proposes an order of priority for security like the one Section 4 sets for safety: secure design first, then protection measures, then security information. It wants the device as autonomous as possible in IT security, with the manufacturer's assumptions about the operating environment in the instructions for use. (MDCG 2019-16 rev.1, s. 3.3, 3.6)

Team-NB, the European association of medical device notified bodies, published a position paper in October 2022. It is one association's position, and neither law nor MDCG guidance, and it says it reflects the state of the art only as at its creation. (Team-NB position paper, p. 1)

(MDCG 2019-16 rev.1, s. 3.4, 3.7; Annex III; Team-NB position paper, pp. 1 and 2; IEC 81001-5-1 record)

The IEC Webstore lists Interpretation Sheet 1 (ISH1) to IEC 81001-5-1, published on 4 December 2025, and the standard's own record lists a second edition in preparation. (IEC 81001-5-1 ISH1 record; IEC 81001-5-1 record)

FDA's cybersecurity guidance of 3 February 2026 has the same status as its human factors guidance, which binds neither FDA nor the public. Under section 524B of the Federal Food, Drug, and Cosmetic Act, premarket submissions for a cyber device must include cybersecurity information. A cyber device includes software, can connect to the internet, and could be vulnerable to cybersecurity threats. (FDA cybersecurity guidance, preface, s. III)

8. Where do the Cyber Resilience Act and the AI Act reach?#

The Cyber Resilience Act applies to "products with digital elements made available on the market". Their intended purpose or reasonably foreseeable use has to include "a direct or indirect logical or physical data connection to a device or network". It does not apply to products with digital elements to which the MDR or the IVDR applies. Recital 25 gives the reason: both regulations already address cybersecurity risks. (Cyber Resilience Act, Art. 2(1), 2(2); recital 25)

Whether the exclusion applies depends on whether the MDR or IVDR applies to the product, which is the qualification question that chapter 1 answers. Our reading is that a companion product with no medical purpose has to be assessed against Article 2(1) on its own, and the exclusion does not extend to it merely because it is supplied with a device. (Cyber Resilience Act, Art. 2)

Our reading is also that the Act's dates of application do not apply to a device to which the MDR or IVDR applies. (Cyber Resilience Act, Art. 71(2))

The AI Act lets providers of high-risk AI systems already subject to risk management requirements under other Union law make its risk management aspects part of, or combine them with, those procedures. MDCG 2025-6 says manufacturers of high-risk medical device AI may integrate the Article 9(1) to (9) requirements into their MDR or IVDR documentation. Chapter 10, on AI and cybersecurity obligations, sets out which devices this covers and from when. (AI Act, Art. 9(10); MDCG 2025-6, question 7)

9. How does a citation status go out of date?#

As consolidated on 17 June 2026, the MDR list names ten amending decisions, the last being Implementing Decision (EU) 2026/1231. The consolidation of 30 January 2026, now superseded, numbered its entries up to 48. The consolidation of 17 June 2026 numbers them up to 65, and the IVDR list runs to 23. (Implementing Decision (EU) 2021/1182, consolidated text, p. 1; Annex, entries 12, 12a and 65; consolidated text of 30 January 2026; Implementing Decision (EU) 2021/1195, Annex, entry 23)

Entries 49 to 65 were added later in 2026. Implementing Decision (EU) 2026/760, published on 7 April 2026, added entries 49, 50 and 51. A count of entries, or a finding that a standard was not cited, taken from the January text was therefore out of date by April. (Implementing Decision (EU) 2026/760, Annex)

Implementing Decision (EU) 2026/1231 shows how an amended standard comes to replace the earlier reference in the list, using EN ISO 15223-1:2021, the symbols standard, which A1:2025 amended. The amendment adds a defined term for authorised representative. It also makes the authorised representative's symbol, marked "EC REP", neither country nor region specific, and the guidance calls the new symbol "EU REP". (Implementing Decision (EU) 2026/1231, recitals (4), (10); MDCG 2021-5 rev.1 appendix, p. 5)

The Decision entered into force on publication, 17 June 2026. Point (6) of its Annex inserts entry 12a, the amended standard, with no deferred date. Point (5) deletes entry 12, the standard without the amendment, from a later date, so the two entries coexist until then. (Implementing Decision (EU) 2026/1231, Art. 2; Annex)

As published, Article 2 applied point (5) from 15 June 2031. A corrigendum is a published correction to an act, and one published on 22 June 2026 changed that date to 17 June 2031. (Corrigendum to Implementing Decision (EU) 2026/1231)

Implementing Decision (EU) 2026/1313 deletes the matching IVDR entry 8 from 17 June 2031. (Implementing Decision (EU) 2026/1313, Art. 2)

This sequence, in which the amended reference is added at once and the earlier one is deleted later, is the one the Blue Guide describes. The Commission usually allows a coexistence period, during which the superseded and revised standards both give a presumption, and after it the revised one alone does. (Blue Guide, s. 4.1.2.5)

An appendix to MDCG 2021-5 rev.1, of June 2026, applies this to the symbol. Until 17 June 2031, manufacturers may use either version, and one or both symbols on different levels of packaging, provided that the information on the authorised representative remains clear and intelligible. (MDCG 2021-5 rev.1 appendix, pp. 5 and 6)

From 17 June 2031, the appendix says, the amended standard alone gives compliance, and devices already on the market with the old symbol may continue to be made available. It calls the change purely editorial, needing no prior notified body approval. (MDCG 2021-5 rev.1 appendix, pp. 3, 4 and 6)

The Commission's harmonised standards page listed, on 29 September 2026, Decision (EU) 2026/1231 "and Corrigendum" as the latest MDR publication. The page is one of two places to check for a later amendment, and the Publications Office record of amending acts is the other. (Commission harmonised standards page)

10. How the answer is reached#

The answers depend on one another, in this order:

1. The product and its class come first, from chapter 1, on scope. Several Annex I sections apply only to certain types of device, so what matters is whether each component is software, active or connected to an active device. (MDR Art. 2(4); Annex I s. 17.1, 18.8)
2. Each Annex I section is either answered or set aside with a reason, because the manufacturer remains responsible for deciding which requirements are relevant. Our observation, meaning what the authors have seen in practice and not a sourced finding, is that a reasoned statement of non-applicability answers the question before an assessor asks it. (Blue Guide, s. 4.1.2.2)
3. A standard is chosen for each section and identified in full. A cited standard is identified as the European adoption with each amendment, such as EN ISO 14971:2019 with A11:2021. Our reading is that an uncited standard is identified by the edition the file was built to, together with the newest edition in the catalogue and the reason the file's edition was chosen. The reason matters because the guidance treats the newest edition as reflecting the state of the art. (Implementing Decision (EU) 2021/1182, Annex, entry 16; MDCG 2021-5 rev.1, s. 3.5)
4. Citation status is read from the current consolidation and what came after it: the whole annex, later amending decisions, and each amending act's application dates and corrigenda, as figure 5.2 shows. The result is recorded with the date of the check. (Implementing Decision (EU) 2021/1182, consolidated text; Implementing Decision (EU) 2026/1231, Art. 2; Commission harmonised standards page)
5. Where the reference is published, the presumption reaches the sections the standard covers. Its Annex Z shows which, and where only part of the standard is applied, the presumption reaches only that part. (MDCG 2021-5 rev.1, s. 2.3; Blue Guide, s. 4.1.2.3)
6. Where the reference is unpublished, the manufacturer answers each Annex I section with its own demonstration, with the evidence in the technical documentation. In the guidance's reading, compliance with an uncited standard does not by itself show compliance with the regulation. The triage tool in section 11 shows such a demonstration for Section 17.2. (MDCG 2021-5 rev.1, s. 2.2, 3.5)
7. The files connect through the risk file. Each use error from usability testing, each security risk that could affect safety and each post-market finding enters it. Our observation is that each file usually has an owner and the links between them often have none. (MDR Annex I s. 3, 5; MDCG 2019-16 rev.1, s. 3.2, 3.8)
8. The edges of the scope follow from qualification. Whether the MDR or IVDR applies to each product shipped decides the Cyber Resilience Act exclusion, and a product with AI raises the risk management question that chapter 10 answers. (Cyber Resilience Act, Art. 2(1), (2); AI Act, Art. 9(10))
9. The answer is reviewed when its inputs move: a new amending decision or corrigendum, a change to the device, or a new edition of an uncited standard in use. Annex I refers to the state of the art, and the guidance treats the newest edition as reflecting it. (MDR Art. 10(9); Annex I s. 1, 17.2; IVDR Art. 10(8); MDCG 2021-5 rev.1, s. 3.5)

11. The four running cases#

Each citation status below rests on the check of 29 September 2026 in section 5.

The monitor: a wearable cardiac monitor from a US company#

The monitor records heart rhythm continuously for later review by a clinician, and a companion application displays the recording. Its maker is a US company with no Union establishment. Chapter 1 reads the hardware as an active device in class IIa under Rule 10. The application is classified separately: class IIa if it only records for later review, class IIb if it analyses the rhythm and its output is intended to guide a physician's diagnosis. The planning assumption is that it records only.

As illustrative assumptions of this book, the monitor is already cleared and selling in the United States, and the application runs on the patient's phone. Suppose further that the monitor runs firmware and that its US submission treated it as a cyber device.

A wearable with a companion application has two interfaces. Our reading is that a usability study run on the wearable alone has not evaluated the application's interface, so the risk file has no use errors from it.

The triage tool: AI-enabled software from a European company#

The triage tool suggests how soon each patient should be seen in adult urgent care centres. Triage nurses use it for patients they have already assessed as having no life-threatening condition, and the nurse confirms or changes the suggestion. Classes IIa to III are all arguable under Rule 11, and chapter 1 plans the tool as class IIb, which stays a planning assumption.

As illustrative assumptions of this book, the maker's home Member State is Germany, and it sells the tool directly to hospitals and through an online app platform. Suppose further that its model uses machine learning and is not a large language model, and that the team releases often. If the platform version runs on mobile platforms, Section 17.3 applies to it as well. (MDR Annex I s. 17.3)

Our reading is that accepting a wrong suggestion is a use error. The nurse's confirmation stands between the suggestion and the result, which is then not caused solely by device failure. The action also differs from what the manufacturer expects, provided the instructions tell the nurse to check each suggestion against the assessment. (FDA human factors guidance, s. 3)

IEC 62304 is uncited, so the tool's conformity with Section 17.2 rests on a demonstration. The demonstration is built on the elements Section 17.2 names, with no clause of the standard quoted. The evidence below is an illustrative assumption.

(MDR Annex I s. 17.2; IEC 62304 consolidated version record; MDCG 2019-16 rev.1, s. 3.2, 3.7)

Section 17.2 also asks for development in accordance with the state of the art, so the demonstration ends by identifying the edition of the standard used. The tool is built to IEC 62304:2006 with amendment 1:2015, edition 1.1, the published edition, because edition 2.0 has only a forecast publication date. That edition was in neither list in the consolidations of 17 June 2026, checked on 29 September 2026.

The implant: a spinal implant from a European company with a directive certificate#

The implant is a spinal implant system, an interbody cage with screws, plates, hooks and rods, from a Union manufacturer seeking its first MDR certificate. Chapter 1 classes it by component. The cage is class III, and screws and plates are class IIb. Hooks are class IIb on MDCG 2021-24 rev.1's reading, and rods, wires and pins are open, because Rule 8 does not name them. The answers below are for the cage.

As an illustrative assumption of this book, the system is CE marked as a non-active implant under one directive, Directive 93/42/EEC, the Medical Devices Directive. Suppose further that it incorporates no software.

Recital (10) of Decision (EU) 2026/1231 lists standards that have been amended, among them EN ISO 10993-12:2021 and EN ISO 10993-17:2023 on biological evaluation. The entries for the previous biological evaluation references come out of the MDR list from 15 December 2027. That date sits in the amending act and not in the consolidation's Annex. (Implementing Decision (EU) 2026/1231, recital (10); Art. 2)

Once deleted, a reference is no longer published, so it gives no presumption, as section 3 explains. Our reading is that a biological evaluation relying on one of them for the presumption moves to the amended reference before then.

The near-patient test: a cardiac troponin test from a Swiss company#

The near-patient test measures cardiac troponin in blood near the patient in hospital emergency departments. Its maker is a Swiss company with no Union entity, acting through a sole authorised representative in the Union. Chapter 1 sets out two intended purposes, serial and single measurement, and plans both as class C until a notified body confirms otherwise. The answers below are for the serial purpose.

As illustrative assumptions of this book, the company also supplies the point-of-care analyser that reads the test. The test was placed on the Union market under a declaration of conformity drawn up under Directive 98/79/EC before 26 May 2022, with no notified body. The company already sells it through distributors in Germany, the Netherlands, Belgium and Austria. Chapter 2 covers how long Article 110 lets it stay on the market.

Our reading is that the change of the representative's symbol can be made at the next planned label revision, provided it falls before 17 June 2031. Labelling itself is in chapter 7, on technical documentation. (MDCG 2021-5 rev.1 appendix, pp. 5 and 6)

12. When specialist help is worth paying for#

• The presumption is relied on for particular sections. Establishing which sections the Annex Z of the cited standard covers needs the European text and someone able to read it. (MDCG 2021-5 rev.1, s. 2.3)
• The security file rests on an uncited standard. The demonstration has to show conformity with Sections 17.2 and 17.4 without a presumption to rely on. (MDR Annex I s. 17.2, 17.4; MDCG 2021-5 rev.1, s. 3.5)
• The product uses machine learning, or ships with a companion product that is not a device. Whether ISO/TS 24971-2 or the Cyber Resilience Act applies depends on facts about the product. (ISO/TS 24971-2 catalogue page; Cyber Resilience Act, Art. 2)
• One security programme serves the Union and the United States. The FDA and EU texts are separate, and the mapping between them falls to the manufacturer. (FDA cybersecurity guidance, s. III; MDCG 2019-16 rev.1, s. 1.1, 1.2)

Conclusion#

The product and its class decide which Annex I requirements, the EU's general safety and performance requirements, the files must answer. On our reading, the risk management file answers Sections 1 to 4 and 8, and the usability file answers Section 5.

When a device follows a harmonised standard, the law presumes that it meets the MDR or IVDR requirements that standard covers. The presumption applies only once the standard's reference has been published in the EU's Official Journal, and only when the company follows the European (EN) edition. It also reaches only the requirements that the standard's Annex Z, a table linking its clauses to the regulation, shows as covered. A company that uses an uncited standard, or none, may still show conformity in its own way, as the Commission's Blue Guide confirms, but the proof then rests on its own argument.

The risk, usability, software, and security files feed one another. Use errors found in usability work, security risks that could harm patients, and problems reported after launch all go into the risk file. The authors observe that each file usually has an owner while the links, where the files have to agree, often have none.

A finding on whether a standard is cited holds from the date of the check until a later amending decision or a corrigendum, a published correction, changes the EU list, so each check is recorded with its date.

Assuming the wearable heart monitor from a US company runs firmware, the firmware and the companion application fall under the software and security Sections 17.1, 17.2, 17.4 and 18.8. On our reading, the security documents prepared for the US Food and Drug Administration (FDA) do not by themselves show conformity with Sections 17.2 and 17.4. Each has to be mapped to an EU section and to the EU cybersecurity guidance.

The AI triage software is built to the software standard IEC 62304, which is cited in neither EU list. Its conformity with Section 17.2, on how software is developed, therefore rests on the manufacturer's own demonstration. Validation of the finished device needs its own evidence, because that standard excludes it.

For the spinal implant, on the assumption that it has no software, no software section applies on our reading, and the file states that reason. From 15 December 2027 the MDR list drops the earlier versions of the amended standards for biological evaluation, the work showing the materials are compatible with the body. On our reading, an evaluation relying on them for the presumption moves to the amended references before then.

The risk file of the Swiss company's near-patient troponin test rests on the cited risk management standard, entry 10 of the IVDR list. The presumption is therefore available to that file, within the limits above. Its usability file, built to an uncited standard, carries its own demonstration. In the guidance's reading, its labels may carry either the old or the new symbol for its authorised representative, the EU-based party it appoints, until 17 June 2031, provided the information stays clear. On our reading, the change can be made at the next planned label revision, if that falls before then.

Chapter 6 covers clinical and performance evidence, and chapter 7 the technical documentation and labelling. Current citations are on the Commission's harmonised standards page, and the catalogue status of each standard is on iso.org and the IEC Webstore.