Document Control

Document Control

A fundamental requirement for any controlled process is to have the documentation associated with the process to be “controlled.”  What do we mean by controlled?  Document control implies that one can distinguish one revision of a document from another revision.  It also implies that a particular revision is retrievable and unblemished – that is, five or ten years later, any controlled revision is available for reference or use.  Documentation used during design and manufacturing must be controlled in order to ensure quality and predictable processes.

Obviously documentation control makes sense even if not required by the US regulations and ISO 13485.  One should desire documentation control simply because of concern for safety and efficacy of designed and built products.  So what exactly is required?

21 CFR Sec. 820.40 Document controls

Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall provide for the following:

Document Control: Approvals and Distribution

(a) Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to issuance all documents established to meet the requirements of this part. The approval, including the date and signature of the individual(s) approving the document, shall be documented. Documents established to meet the requirements of this part shall be available at all locations for which they are designated, used, or otherwise necessary, and all obsolete documents shall be promptly removed from all points of use or otherwise prevented from unintended use.

At a minimum, document approval is a second set of eyes – a second person that acknowledges that a new revision is to be released.  However the regulation states, “review of adequacy.”  This implies that the approver has some level of skill and knowledge that justifies them serving in the role of approver.  One might justify the approver based on title or position within the organization or define explicitly in the procedure.  ISO 13485 § 4.2.4 points out explicitly that approval must occur “prior to use.”  One should understand the intent of both the US regulation and ISO 13485 in this case – clearly information that will be controlled in a document will go through “thinking,” “beginning to document,” and finally to “final” phases.  Often a process includes periods of time when multiple documents may be in early phases and not final, and in these defined periods preliminary information may be used as part of the activities of that period of time.  So be clear in defining process and when documentation will be finalized.

Note also that the document revisions must be accessible and all users for the documentation must be aware of release status.  Consider how the documents will be maintained long term.  If using electronic records, the 21 CFR Part 11 rule must be considered.

Document Control: Changes

(b) Document changes. Changes to documents shall be reviewed and approved by an individual(s) in the same function or organization that performed the original review and approval, unless specifically designated otherwise. Approved changes shall be communicated to the appropriate personnel in a timely manner. Each manufacturer shall maintain records of changes to documents. Change records shall include a description of the change, identification of the affected documents, the signature of the approving individual(s), the approval date, and when the change becomes effective.

Just as one exercises control for the initial release of a document, the same care and control must be applied when making changes/revisions to a document.  Be sure to describe all changes to the document in the revision history for the document.  Often it is difficult for a reviewer or approver to know everything that changed so they rely on the revision history.  Also, if the document being changed affects another document, this should be noted.

Records

What is the difference between a document and a record?  One simple view is that a document may go through revisions over its life and multiple revisions may be in use at any given time.  Documents are meant to be updated for variety of reasons.

Our General Manager often says, records are like “photographs,” that is, they are meant to capture a moment in time.  Consider the scenario where one runs a test case and captures test results – the test results would be a record.  The test case would likely be part of a test protocol or suite that is a document.  And the test case would likely trace to a software requirements document.  Records are generally created when performing reviews, audits, testing, inspections, etc.

Document Control Tools

Document and records management tools can improve efficiency and effectiveness when tailored to particular product types and product teams.  However tools may have “guardrails” that can be constraining and limit flexibility.  Or they may work well for many types of documents but not for all.

Other Resources

US FDA Quality System Inspection Technique: https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/quality-systems

Foreign Inspections:  https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-references/what-expect-during-foreign-supplier-verification-programs-inspection

About the author

Joel is a quality systems associate and researcher for SoftwareCPR. After working for 7 years in the medical field with the United States Army, he now spends his time exploring tech development and programming. He is the father to two wonderful children and avid fisherman.

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email training@softwarecpr.com to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:

TBD

 


 

Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now

 


 

Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
USA
+1-781-721-2921
Partners located in the US (CA, FL, MA, MN, TX) and Canada.