Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


Content of DHF, DMR and DHR for medical device software - Part 1 DHF

After a temporary absence, I'm back on the waves with a new series of articles to talk about the files required by the 21 CFR 820 regulations:

  • DHF: Design History File,
  • DMR: Device Master Record,
  • DHR: Device History Record.

Let's begin with the DHF.

What is the Design History File (DHF)?

The DHF 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(e), gives the definition of DHF:

  • Design history file (DHF) means a compilation of records which describes the design history of a finished device.


Okay, the DHF applies to a finished device, not to a prototype or to a device still in the design phase.

Design Controls

The section 21 CFR 820.30 about Design Controls states the requirements about the DHF:

  • 21 CFR 820.30 (a): General
    • (1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.
    • (2) The following class I devices are subject to design controls:
      • (i) Devices automated with computer software
      • (...)

In other words, you shall maintain a DHF, whichever the class of your medical device software (even in class I).

  • 21 CFR 820.30 (j): Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.

In other words, the first sentence of this last section requires to: establish and maintain a DHF for each type of device. For standalone software, a "type of device" may be a software alone or a system made of software working together (eg a client and a server) or a software suite (with a well established list of software in the suite!).

The second sentence requires to gather all the records necessary to prove that the design controls requirements of 21 CFR 820.30 are met. These design controls requirements are described in the sections (b) to (i) of 21 CFR 820.30. They list the mandatory steps of a design process: Design and Development Planning, Design Input, Design Output, Design Review, Design Verification, Design Validation, Design Transfer.

Thus the DHF contains the records, which prove that these mandatory steps were actually followed.

Design Controls for software

The "translation" of these steps for software design can be found in two places: in the "General Principles of Software Validation" (GPSV) FDA guidance, or in the IEC 62304 FDA recognized standard.
We can draw the links between GPSV and IEC 62304 chapters, and designs steps listed in 21 CFR 830.30.

Note: these links are relevant for standalone software. When software is embedded in a hardware device, IEC 62304 requirements are not enough. Eg: Design input contains also requirement management at system level.

Design and Development Planning

GPSV 5.2.1. Quality Planning, and IEC 62304 5.1 Software development planning require to define procedures and/or plans to follow during design.

Design Input

GPSV 5.2.2 Requirements, and IEC 62304 5.2 Software requirements analysis.
For both documents, this is the input data of software requirement definition (the high-level requirements, the use-cases, the user requirement not formalized),

Design Output

GPSV 5.2.2 Requirements, and IEC 62304 5.2 Software requirements analysis. But now, this is the output data of software requirement definition (the actual software requirements written in a formal way, used to design software).
For GPSV, we have also 5.2.3. Design, 5.2.4. Construction or Coding, and for IEC 62304 we have 5.3 Software Architectural Design, 5.4 Software Detailed Design, 5.5 Software Unit implementation and verification, 5.6 Software integration and integration testing (for the integration part).

Design Review

GPSV 3.5 Design review section gives basic principles of design reviews for software, and requires design reviews in 5.2.2 Requirements and 5.2.3. Design.
IEC 62304 doesn't use the term design review but uses in place the word verify. Sections 5.2.6 Verify software requirements, 5.3.6 Verify software architecture, and 5.4.4 Verify detailed design are good landmarks to define the content of a design review.
There may be one or more design reviews, depending on the complexity and the length of the software development. But there shall be at least one design review, containing the review of the above elements in its agenda.

Design Verification

Verification is testing software. Provisions for tests are described in GPSV 5.2.5. Testing by the Software Developer, 5.2.6. User Site Testing (when user takes part to verification tests), and in IEC 62304 5.6 Software integration and integration testing (for the testing part), and 5.7 Software System testing.

Design Validation

21 CFR 820.3 Definition of design validation is establishing by objective evidence that device specifications conform with user needs and intended use.
The recommendations of GPSV document about validation are in fact the whole section 5.2.
Narrowing the scope to what happens after verification, validation is 5.2.6 User Site Testing (when user takes part to validation tests).
Here for IEC 62304 we don't have any relevant section, hence this standard ends at the verification phase. But for standalone software, requirements described in 5.7 Software System testing are quite convenient to formalize and record a user validation step.
Another way of appraising validation is to apply the recommendations of GPSV and from A to Z.

Design Transfer

In GPSV, we don't have a specific chapter. Hence it stops the list of recommendations at the end of validation.
In IEC 62304, section 5.8 Software release contains some requirements about design transfert. Design transfert can be seen as freezing a software configuration and its associated documentation (design docs, release notes ...). But design transfer is more than that because it aims to prepare the Device Master Record.
We'll see that in the next article of this series.

Content of the DHF for software

Based on the steps of design controls listed above, we can list the kind of documents that we need to prove that these steps were followed:

  • Planning: A design procedure and/or plans for design, i.e. project management plan, software development plan, software configuration management plan, and risk management plan,
  • Input: any input document relevant for software design (algorithms, scientific articles, user requirements, prototypes, mock-ups...), including preliminary risk assessment report and preliminary usability specifications,
  • Output: software requirements specifications, usability specification, risk assessment report, software architecture design, software detailed design, ... and the code (better in a software configuration management tool),
  • Review: review meeting reports (be it architectural, detailed design, code reviews, integration review or else), according to plans,
  • Verification: software test plan, software test description, software test reports, for each test phase,
  • Validation: software test plan, software test description, software test reports, for the validation test phase, if there is one, plus validation meeting review reports.
  • Transfer: version delivery description, release notes... (see next article)

You may find some documents templates on the templates repository for software development process page.

Evolution of the DHF with multiple software versions

Software versions are never frozen for long. Sooner or later, a new incremental version, a brand new version, or patches are released.
All these patches or evolutions of software have to be recorded in the DHF. To do so, the way they are released need to be planned, and they need to be documented.

Software maintenance plan

GPSV has the section 5.2.7. Maintenance and Software Changes, and IEC 62304 has the chapter 6 Software maintenance process. Both require to establish a maintenance process, to analyse user problems or requests, and to implement them using the development process (under the change control provisions of the quality management system).
The DHF may contain a software maintenance procedure and/or a software maintenance plan, to keep track of how design changes were planned.

Software maintenance documentation

Software maintenance activities are actually design activities for evolutions, and design flaws fixes for bugs. The documentation to add to the DHF is either the updates of all design documents listed in the design phases (especially updates of the risk assessment report), or documents describing patches (if bug fixes didn't change the design and the list of tests).
As its name suggests, the Design History file contains the history of design! Thus it shall contain all versions of software documents created for each software version, including patches and minor versions. If you use a bug tracking tool, its content can be seen as a piece of the DHF. Freezing or exporting the content of the bug tracking tool is a good way to keep track of the status of bugs for each released version or patch.

To sum-up the DHF content

The DHF contains the set of all documents and records related to software design, for every software version (major or minor) and for every patch.
Procedures and plans followed during design and maintenance can also be seen as a part of the DHF, hence they contain the description of the processes followed at the time software was designed.
The content of software development tools, mainly configuration management and bug tracking can also be seen as a important piece of the DHF. Thus they contain the history of source files and the history of bugs.

Next time we'll see the Device Master Record and how to build it with Design Transfer.



Comments

1. On Friday 2 October 2015, 12:39 by Giuseppe

I'm sorry, but as for the records to put into a DHF I'm not sure that it is as you mentioned. In fact, only the claims (e), (f) and (g) of 820.30 explicitly assert to put the results of their activities into the DHF.
As far as I've understood, since the aforementioned claims refer to, resp., design review, verification, and validation, in my opinion, by putting only these results into DHF should be in line with the objective asserted in (j) "...to demonstrate that the design...".

I'd like to ask you what do you think about.

Let me take advantage of this comment to thank you for this precious blog.

Giuseppe

2. On Sunday 4 October 2015, 22:14 by Mitch

Many thanks Giuseppe for your comment. 

The DHF is explicitly mentioned in design review, verification and validation. I agree. 

But I found that the only way to be compliant with 820.30 (j) and especially to "demonstrate that the design was developed in accordance with the approved design plan" is to kepp in the DHF all other records I mentioned. 

 

3. On Thursday 25 February 2016, 00:48 by Richman Manalili

I found this article really valuable for me to understand the regulatory requirements pertaining to DHF. I would like to clarify, if a software integrates with other third party software (e.g. scribing software for radiology systems), the artifacts you produce (requirements, plans, test cases, results) in realizing that integration, will they be part of the DHF?

Thanks in advance.

4. On Friday 26 February 2016, 17:15 by Mitch

Hi Richman,

Thanks for you feedback.

If you do the integration at design time, then, yes, it goes to the DHF.

If you have tests to run every time you install software to verify its correct integration on the target platform

  • the intallation test plan goes to the DMR,
  • the installation test reports of tets run on each target platform go to the DHR. 

Bye.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed