Software in Medical Devices, by MD101 Consulting

What is the Device History Record (DHR)?

The DHR is a term defined by the US regulations. Like the DHF and the DMR, you can find it in the online copy of 21 CFR on the FDA website.

Definition

The section 21 CFR 820.3(i), gives the definition of DHR:

• Device history record (DHR) means a compilation of records containing the production history of a finished device.

Like the DHF and the DMR, the DHR applies to a finished device.
Like the DMR, the DHR is used during the production phase. But contrary to the DMR, which is an input of the production phase, the DHR is an output of the production phase. It's a log file of what's produced.

Device History Record

Let's have a look at 21 CFR part 820, subpart M - Records (sections 180 to 198). This is where we find more data about the DHR.
21 CFR 820.184 says (some text stripped):

• Each manufacturer shall maintain device history records (...) maintain procedures to ensure that DHR’s for each batch, lot, or unit are maintained to demonstrate that the device is manufactured in accordance with the DMR and the requirements of this part.
• The DHR shall include, or refer to the location of, the following information:
  • (a) The dates of manufacture;
  • (b) The quantity manufactured;
  • (c) The quantity released for distribution;
  • (d) The acceptance records which demonstrate the device is manufactured in accordance with the DMR;
  • (e) The primary identification label and labeling used for each production unit; and
  • (f) Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used.

The DHR is the log file of what was produced and the proofs that it was produced respecting plans/procedures/instructions found in the DMR.
How to translate that for software?

Device History Record for software

Let's see how to interpret each bullet of the DHR content.
I don't take them in their order in the regulations, hence some are not relevant for standalone software.

Dates of manufacture, quantity manufactured, quantity released for distribution

These requirements are most of times not relevant for software. Though it is mandatory to keep track of this set of data in the DHR for installation media, covers and boxes, they are not relevant for software itself.
The closest concept is to record how many copies of a software version where distributed, and to whom. But this is outside the DHR content, which stops at the end of production.
Thus, for conservative reasons, the DHR should contain records where it is possible to find who has what: which customer has which version. But this is not always possible, especially for software downloadable on the internet or distributed to the general public (letting people freely install a medical device software is another debate).

The acceptance records which demonstrate the device is manufactured in accordance with the DMR

This is mandatory for media, boxes and so on. But this is not the most interesting part of the discussion.
What it interesting, is to know whether a software version was installed the right way or not, if a technician encountered problems when installing software on the customer platform, whether things went well or not, and what correction actions were implemented.
Installation and maintenance is more relevant for software than production. Thus, for conservative reasons, considering that installing software is a service, which replaces the production, the DMR should keep track of installation and commissioning of software.
To be consistent with the DMR, where we said that it should contain installation tests and acceptance criteria, the DHR should contain installation tests results and acceptance records.

The primary identification label and labeling used

Once again, this bullet is not relevant for software itself. Media, boxes and so on should have their own identification label. But, once again, this is not the most interesting part of the discussion.
To identify a software copy, we have the software version (ok, already seen in the DMR) and, not systematically, the license number or a serial number or a serial number from the hardware it is installed on (eg: motherboard).
Thus, the combination of software version plus license number or serial number (or any unique identifier) should be a good solution.

Any unique device identifier (UDI)

This bullet was added in 2013 to DHR definition. UDI is a subject of its own. Have a look at the page about UDI on FDA website.
To make the link with the primary identification label, the solution proposed (software version + unique identifier) matches the requirements found in UDI.

Evolution of the DHR with multiple software versions

Like the DMR, a DHR can group data about a major software version and minor, sub-minor versions, and patches.
The good policy is to have the DMR and the DHR consistent. If there is one DMR per minor version, there should be one DHR per minor version.

To sum-up the DHR content

Following the example of batches and lots for physical products, the content of a DHR for standalone software should based on licenses or serial numbers of software copies, and the records, which prove that installation and servicing were performed according to established procedures and acceptance criteria.
Want to know which versions are installed in Dr Smith's offices? Have a look at the DHR.