Version: [enter content] Date: [enter content]
[Placeholder Company Address] Email: [enter content] Website: [enter content]
[Placeholder CE Sign] [Placeholder UDI]
[enter Product Name] is a class [enter content] medical device in accordance with 93/42/EEC (for MDD) // Regulation (EU) 2017/745 (for MDR). UMDNS Code: [enter content]
Safety Information: [Placeholder Symbol] This symbol indicates important safety-related information.
Additional Information: [Placeholder Symbol] This symbol indicates supplementary information.
On your introductory pages, explain the symbols that you use in the following sections. Take into account standards like ISO 15223.
General Provisions: Instructions for use are regulated in Section 13 of the Essential Requirements (MDD) and Chapter 3, Section 23 of the General Safety and Performance Requirements (MDR). You may be able to make a case for why your users must not be provided with instructions for use, based on the exception stated in Section 13.1 (MDD) or Section 23.1.d (MDR):
“By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions.”
Language Requirements: Language requirements are regulated on the national level. German Medical Device Law (Medizinprodukte-Durchführungsgesetz (MPDG), Art. 8) typically requires German, but also gives leeway to argue that English may be a language that is easily understood by your users if those are trained professionals. If you follow this route, as a minimum requirement, all safety-related information has to be provided in German nevertheless:
“In begründeten Fällen dürfen die Informationen auch in englischer Sprache oder einer anderen für den Anwender des Medizinproduktes leicht verständlichen Sprache zur Verfügung gestellt werden, wenn diese Informationen ausschließlich für professionelle Anwender bestimmt sind und die sicherheitsbezogenen Informationen auch in deutscher Sprache oder in der Sprache des Anwenders zur Verfügung gestellt werden.”
You can basically copy/paste your intended use document here and in the sections below. This paragraph should include high-level information required to get an idea of how your product works. Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software. Take into account: clinical benefits to be expected, types of processed data, types of data processing (or machine learning based devices: information about algorithm accuracy).
Describe your users: what level of education can be assumed for your users group? Any pre-existing knowledge of the field that your device is used in? What technical proficiency can be assumed, how much time is typically spent using the software?
If you plan on providing user training prior to product use, make sure to also add a description of that here.
Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile above, but not necessarily. Your software could be used by physicians to diagnose diseases in patients, so in that case, they don’t overlap. Some ideas for characteristics to describe: Age group, weight range, health, condition(s).
Describe the typical use environment. What sort of devices is this running on? Does the software only run on one device or on multiple devices? Is it loud and chaotic like in an emergency ward? How’s the lighting? Also, add other software or hardware which is required by your device. Most commonly, apps require users to have a smartphone with a compatible operating system (iOS / Android).
This is an important section for your company liability: make clear the environment your device should NOT be used in, by whom should your device NOT be used?
More exclusions, more specific to safety risks and clinical implications. For example, does your device automate medical diagnoses? If not, you may want to point out that all results must be checked thoroughly by a qualified physician.
You can use this section to point out user information as required for risk mitigation measures. For example, specific information that must be checked for accuracy or completeness to operate the device.
Self-explanatory: what languages, what language settings are offered for your product?
What hardware configuration is required to run your device (e.g. minimum requirements for processor, display, network bandwidth)?
What software configuration is required (e.g. latest browser version)?
What is required to prevent unauthorized access? How do users prevent data loss? Describe for example firewall settings, VPN setup, etc.
Describe: Is any IT integration required prior to use? How is a successful installation verified? How are login credentials dealt with?
Consider multiple sub-sections here: how do you plan to deploy frontend / backend updates? How can users report malfunctions, clinical incidents, lost passwords or a potential security breach?
Other aspects you may want to consider for the section as part of your instructions for use:
Template Copyright openregulatory.com. See template license.
Please don’t remove this notice even if you’ve modified contents of this template.