Software in Medical Devices, by MD101 Consulting

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.