Software in Medical Devices, by MD101 Consulting

What is the Device Master Record (DMR)?

The DMR is a term defined by the US regulations. You can find it in the online copy of 21 CFR on the FDA website.

Definition

The section 21 CFR 820.3(j), gives the definition of DMR:

• Device master record means a compilation of records containing the procedures and specifications for a finished device.

Like the DHF, the DMR applies to a finished device.
But the DMR is the Device master record. Can you see the difference with the Design history file?
The difference resides in the phase of the product lifecycle covered by these concepts. The DHF, this is in its name, covers the design phase. The DMR is used during the production phase.
The DHF contains all the design history, the DMR contains the snapshot of the device specifications validated at the end of the design phase.

Production controls

Production controls apply to (almost) all medical devices of any classes. Especially for medical device software (standalone or embedded) production controls always apply.
This is one practical reason that DMR is required for all medical device software, whichever their class.

Design transfer

The DMR contains the output of the design transfer. 21 CFR 820.30(h) says:

• Design transfer. Each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications.

So a design transfer phase or review (or any other provision in your QMS) shall exist to prove that this design transfer actually happens. It shall be based on the snapshot of the validated design.
The scope of the design transfer should contain, depending of your software:

• the software itself, binaires, scripts, configuration files and so on,
• the technical documentation (software requirements, design and tests, risks analysis...), output of the design process,
• any other document useful to the end-users, administrators, technical personnel, support personnel...

But the DMR is more than that.

Device Master Record

There is a section in the 21 CFR, which lists mandatory records for medical devices: 21 CFR part 820, subpart M - Records (sections 180 to 198). This is where we find more data about the DMR.
21 CFR 820.181 says (some text stripped):

• Each manufacturer shall maintain device master records (...) The DMR for each type of device shall include, or refer to the location of, the following information:
  • Device specifications,
  • Production process specifications,
  • Quality assurance procedures,
  • Packaging and labeling specifications,
  • Installation, maintenance, and servicing procedures and methods.

In other words, a DMR is a comprehensive record of all the procedures, instructions and specifications required to manufacture a device. It contains the documents or locations of documents for manufacturing and servicing a device.
Though easily understandable for physical devices, this regulation needs a bit of interpretation for standalone software.

Device Master Record content for software

Let's see how to interpret each bullet of the DMR content.

Device specifications

For software, device specifications could be translated to Software Requirement Specifications at a minimum. But it lacks the architectural and detailed specifications. Thus, device specifications can be extended to the output of the software development process when a device is validated.
But it is possible to take the device specifications in its narrow meaning and only refer to software requirements specifications.
For practical reasons, it may be more handy to make a reference to the set of documents related to a software version in the design history file.
Another practical solution is to have a Version Delivery Description document, which contains the reference to all documents about a software version, including the software requirements specifications.

Production process specifications

Production process specifications are the output of the design transfer phase.
A production process is usually minimal for standalone software. But, depending on the type of delivery, some procedures or work instructions may be part of the DMR:

• location of the binaries and configuration files of the version,
• media labels, like CD/DVD cover,
• instructions to burn CD, to print instructions, to put them in a box...
• instructions to publish software on the web (if downloadable)...
• instructions to generate licenses...

Scratch you head, but no too much. There shouldn't be lots of documents!

Packaging and labeling specifications

If the software is delivered on a physical media, labeling instructions on each type of media, on the box, or on anything that should contain this media, shall be in the DMR.
Software itself shall also contain labeling in the help/about window, or the splash screen, or anything the like. Labeling specifications for these widgets are usually directly written in the software specifications.

Quality assurance procedures

Here we find a reference to procedures related to software support and maintenance process:

• support process: how support is organized and how escalation is triggered (eg: 1st level support to 2nd level),
• maintenance process: how software maintenance is controlled (eg: problem resolution process and software maintenance process of IEC 62304).

We can also add a reference to other procedures like: software design, change control, non-conformities, CAPA, and so on.

Installation, maintenance, and servicing procedures and methods

This is the interesting part of the DMR for software. It shall contain any document regarding the processes around software delivered to the end-user:

• installation and configuration instructions (either for internal use, or for customer administrators, or for end-users),
• installation tests cases and acceptance criteria,
• uninstallation instructions,
• training workshops: training for users, for technicians, for administrators, training for trainers...
• support instructions for manufacturer personnel, customer administrators instructions...
• a knowledge base...
• any other instructions for manufacturer personnel, for distributors, for customer personnel, for any 3rd party mandated by the manufacturer or the customer to manage software.

Evolution of the DMR with multiple software versions

The evolution of the DMR depends on the type of changes in a software version:

• Patches or minor changes: just add the reference to the new minor version to the DMR,
• Major changes: create a new DMR.

It is possible to modify a DMR when minor versions or patches are released, provided that the changes are logged somewhere in the DMR. The idea is to be able to answer this kind of question: When was that patch released? What has changed between service pack 1 and service pack 2? Did we update the user manual in V1.2.4?.

To sum-up the DMR content

The DMR contains all about a software version: set binaries or files used at runtime, set of documents, instructions, procedures to install, use, maintain, support, service it.
Contrary to the DHF, the DMR is a snapshot of a software version. Want to know what's inside V2.1? Have a look at the DMR of V2.1.


Next time, we'll see the Device History Record.