Source: https://matthewrupert.net/2011/06/24/continuous-integration-on-software-medical-device-projects-part-4/
Timestamp: 2017-07-28 19:02:19
Document Index: 119524554

Matched Legal Cases: ['art 4', 'art 4', 'art 820', 'arts 11', 'art 820', 'art 3', 'art 5', 'art 4', 'art 9']

Continuous Integration on Software Medical Device Projects, Part 4 – MTR
Continuous Integration on Software Medical Device Projects, Part 4	June 24, 2011June 13, 2013	Posted in Medical Device Software, Project Management, Writing Software	21 CFR Part 820 – DHF Requirements
820.30(e) Design History File (DHF) means a compilation of records which describes the design history of a finished device.
–Device Advice: Regulation and Guidance, Software Validation Guidelines, http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance
Medical device software is audited and controlled by standards defined by FDA, specifically 21 CFR parts 11 and 820. Many of the requirements laid out in this somewhat difficult-to-understand guidance can be made very easy, second nature even, when we use a continuous integration environment throughout the course of project design and development. Looking specifically at the quality system requirements laid out by 21 CFR Part 820.30, Subpart C – Design Controls, it becomes apparent that a good continuous integration environment can help us to address each. A major consideration, perhaps the major consideration, is the completeness of the Design History File.
820.30(j) Design History File. 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.
–CFR – Code of Federal Regulations Title 21. Subpart C – Design Controls, Section 820.30 Design Controls
The “or reference” part of this statement stands out. Traditionally, medical device manufacturers have though of the DHF as a physical, self-contained item. But with a project of any complexity, it isn’t difficult to imagine how quickly a DHF may grow into an unruly mess of difficult-to-wade-through “stuff.” Why not simply leverage software tools to make the process seamless? Using a continuous integration build environment, development teams can pull together a baseline of all the elements of a DHF as frequently as they wish to; Furthermore, they can do so with a degree of accuracy that cannot be achieved through the diligent (yet distractible) legwork of a pre-occupied team.
I propose that the DHF need not be a single physical or soft folder with duplicate copies of items. Leveraging the CI environment along with the version control system, it is a much better idea to think of the DHF as a snapshot of all relevant design outputs at a given point in time. To that end, the development team can have many snapshots of the DHF throughout the project lifecycle. To achieve this, they need simply define this process in their standard operating procedures and work instructions.
Previous: Previous post: Continuous Integration on Software Medical Device Projects, Part 3Next: Next post: Continuous Integration on Software Medical Device Projects, Part 5	One thought on “Continuous Integration on Software Medical Device Projects, Part 4”	Pingback: Continuous Integration on Software Medical Device Projects, Part 9 | MTR Comments are closed.