Driving Compliance: Translating EU MDR into Actionable Requirements
Business Analyst role on a healthcare project
Being a Business Analyst on a healthcare project requires more than just expertise in requirement management; it demands a deep understanding of the regulatory landscape in the target market for medical device release. Compliance with industry standards, such as FDA regulations in the U.S. or MDR in Europe, is critical to ensuring the device meets safety, quality, and legal requirements. A Business Analyst must bridge the gap between technical teams, stakeholders, and regulatory bodies, ensuring that every requirement aligns with market-specific guidelines. This dual responsibility makes their role essential in navigating the complexities of healthcare projects and driving successful product launches.
This article will cover European Union (EU) Medical Device Regulation (MDR) Regulation 2017/745 (referred to as ‘ EU MDR’ hereafter).
What is EU MDR
The EU MDR is a set of regulations that apply to all medical devices intended for the EU market, including those that come into direct contact with humans, administer medicines, or are used for in vitro diagnostics. The primary goal is to enhance patient safety and ensure the quality and efficacy of medical devices. As of May 26, 2020 the MDR replaced the previous Medical Device Directive (MDD) and Active Implantable Medical Devices Directive (AIMDD).
The MDR imposes stricter requirements for the design, manufacturing, and marketing of devices, including more in-depth clinical data to demonstrate safety and performance claims. A medical device in the EU must have a CE marking, which is obtained through conformity assessment process that determines whether the device complies with the MDR requirements. Also, a manufacturer needs to place a Unique Device Identifier (UDI) on all devices marketed in the EU that includes UDI device identifier (UDI-DI) and UDI production identifier (UDI-PI). UDI information must be uploaded to the new European Database on Medical Devices (EUDAMED) that provides traceability and transparency of marketed devices.
Besides, manufacturers must implement a Quality Management System (QMS) that complies with MDR requirements (ISO 13485), as well as perform a clinical evaluation to all medical devices, regardless of their risk class, and establish a post-market surveillance system to collect and analyze data on the quality, performance and safety throughout a product life cycle.
Why Classification Matters
As soon as on the business level the Manufacturer considers and decides the intended purpose of the product, product claims, as well as the list of targeted countries, they should check whether the device fulfills the definition of a medical device according to Article 2(1), and decide the classification in accordance with Article 51 and the rules in Annex VIII of the MDR. The EU MDR classifies medical software into four categories based on patient risk.
Class I medical software is typically low-risk, generally used to only display readings from a medical device without processing, analyzing, or interpreting the data, does not contain diagnostic or therapeutic functions, and does not influence critical clinical decisions. Examples include Lifestyle and Wellness Apps, Patient Self-Assessment Tools, Digital Logbooks, Electronic Medical Records (EMR), Hospital Information Systems (HIS), PACS (Picture Archiving and Communication Systems), Appointment Scheduling and Telemedicine Platforms.
Class IIa medical software is considered moderate-risk and typically supports clinical decisions without making critical diagnoses or directly controlling medical treatments. It often assists healthcare professionals but does not replace their judgment. Examples include software that suggests possible diagnoses based on patient symptoms but does not make final decisions, drug interaction checkers that alert healthcare professionals about potential contraindications, software that enhances or measures medical images, adjusting contrast, measuring lesion size, but does not provide automated diagnosis, image segmentation tools that assist in defining anatomical structures for doctors to review, software that detects abnormal trends in vital signs but requires a healthcare professional to confirm, software used to transmit and display medical images like, X-rays and MRIs, for remote consultation without automated diagnostic function,and many-many more… You get the idea, right?
Under MDR, most standalone medical software is classified as at least Class IIa unless it meets strict criteria for remaining Class I. If the software performs calculations, interprets medical data, or influences treatment decisions, it is Class IIa or higher under Rule 11 of the MDR.
Class IIb medical software provides information that is used to make decisions that may result in serious health deterioration or a surgical intervention. Examples include medical imaging analysis software for detecting cancers, strokes or fractures, clinical decision support software assisting doctors in diagnosing serious conditions, remote patient monitoring software, where incorrect failures could lead to severe consequences, AI-based triage systems that determine emergency treatment urgency.
Class III medical software refers to software that presents the highest level of risk, typically performs critical functions that could lead to serious harm or death if it fails, and is subject to the most stringent regulatory requirements. Examples include software controlling life-supporting medical devices, such as ventilators, or heart-lung machines, AI-driven diagnostic software that determines critical treatment paths, like stroke detection and cancer treatment, real-time monitoring software that directly affects treatment in critical conditions.
Unlike Class I and some class IIa devices, for medical software of Class IIb and ClassIII a Notified Body must review and approve the software before market release. This Conformity Assessment includes technical documentation, clinical evaluation and Risk Management process. The Manufacturer must be able to demonstrate compliance with Quality Management System for medical devices (ISO 13485), Medical Device Software Lifecycle Process (IEC 62304), Risk Management for Medical Devices (ISO 14971), Cybersecurity Standard for Health Software (ISO 81001-5-1), as well as follow GDPR, where applicable.
Therefore, the initial business decisions and requirements will influence many of the subsequent steps to be followed. It is essential to be precise, especially if the product is likely to have a borderline medical purpose or could have a different classification depending on an interpretation of the rules.
From Regulation to Requirement
The Business Analyst (BA) and Person Responsible for Regulatory Compliance (PRRC) must work hand-in-hand to ensure that medical software meets both business objectives and MDR compliance. The BA translates business needs into requirements, while the PRRC ensures that regulatory and risk aspects are embedded in the development process.
To demonstrate compliance in practice, let’s translate selected paragraphs of Annex I of EU MDR - General Safety and Performance Requirements into requirements using an Automated Insulin Pump as an example, classified as a Class IIb medical device:
- Chapter III, Section 23.1(d):
“Instructions for use shall be provided together with devices. By way of exception, instructions for use shall not be required for class I and class IIa devices if such devices can be used safely without any such instructio/ns and unless otherwise provided for elsewhere in this Section”
- Chapter III, Section 23.4 (a) and (b):
“The instruction for use shall contain the following particulars:
the device’s intended purpose, including indications, contra-indications, the patient target group or groups, and intended users, as appropriate
the information needed to identify the device and its contents, such as the description of the device's intended purpose, intended patient population, and operating principles”
Regulatory Requirement A. Instructions for Use (IFU) must be supplied together with the device on EU market
Description and acceptance criteria: IFU must be written in clear, user-friendly language and available in all relevant EU languages. The IFU will be released in a digital format (e-IFU). Key elements to be included:
- Device name & model
- Manufacturer details
- Intended purpose
- Patient target group
- Operating principles
- Contraindications
Further decomposition includes details about each element of Regulatory Requirement 1.
Solution Requirement A.1. IFU: Device name & Model
Description:
Device Name: Automated Insulin Pump
Model: InsuCare X5
Solution Requirement A.2. IFU: Manufacturer Details
Description:
Manufacturer Name: DiabeTech Solutions S.A.
Registered Address:
DiabeTech Solutions S.A.
123 Rue de la Santé,
75008 Paris, France
Authorized Representative:
MedReg Compliance Ltd.
456 Medical Park,
Berlin, Germany
Solution Requirement A.3. IFU: Intended Purpose
Description:
The InsuCare X5 Automated Insulin Pump is a wearable, electronic medical device intended for the continuous subcutaneous delivery of insulin in individuals diagnosed with diabetes mellitus.
The device is designed to:
- Provide precise and controlled insulin infusion based on pre-programmed basal and bolus settings.
- Assist in the management of Type 1 and insulin-dependent Type 2 diabetes by maintaining blood glucose levels within a target range.
- Integrate with continuous glucose monitoring (CGM) systems for adaptive insulin delivery (when used with compatible sensors).
- Enable manual bolus administration by the patient or healthcare professional when required.
Solution Requirement A.4. IFU: Patient Target Group
Description:
This device is intended for use in adults and children aged 6 years and older who require continuous insulin therapy and are capable of managing their diabetes with medical guidance.
Solution Requirement A.5. IFU: Operating Principles
Description:
The InsuCare X5 is intended for home and clinical use under the supervision of a healthcare professional.
Solution Requirement A.6. IFU: Contraindications
Description:
Contraindications of The InsuCare X5 Automated Insulin Pump:
- Not suitable for non-insulin-dependent diabetics.
- Not recommended for use in individuals with severe cognitive impairment who cannot operate the device independently or with caregiver assistance.
- Not intended for intravenous insulin delivery.
- Not to be used in environments with strong electromagnetic interference (MRI, diathermy, etc.).
As the next step, a technical writer designs the IFU by organizing the information provided in the requirements into a human-readable and user-friendly document. The implementation phase includes publishing the IFU either online (as an eIFU) or as a printed copy, to be distributed alongside the product.
Conclusion
In a healthcare project, the Business Analyst plays a crucial role in ensuring alignment between business goals, regulatory compliance, and product development. By translating complex regulatory language into actionable, testable requirements, the BA guides the development process from concept to market. With a solid understanding of MDR requirements and strong cross-functional collaboration, the BA is not merely a contributor—but a key driver in delivering safe, compliant, and effective healthcare solutions.
Author: Iryna Sizikova
My name is Iryna Sizikova.
For the past 17 years I have been working in the healthcare industry, at Dentsply Sirona, US dental equipment and software product manufacturer that markets its products in over 120 countries.
My current role is the Chapter Lead of the System Analysis and Documentation team. I am promoting the role of Business Analyst in a regulated environment.
I am an IIBA member, podcast guest, speaker, presenter and author of scientific publications.
I am passionate about business analysis and regulatory compliance and enjoy sharing best practices and techniques with the BA community worldwide.