When writing programming codes for either validating the software or for validation checks, we often have to write comments to explain why we did something.
Since the FDA regulates computerized systems used in clinical trials under the authority of Title 21 the Code of Federal Regulations Part 11 (21 CFR Part 11) – see my other article about 21 CFR Part 11 here, we need to make sure our codes and programs are documented. As you have heard before, if it is not documented, it never happened. Nevertheless, there is no mandatory regulatory agency mandating to have to do this.
GDP is an expected practice”
So how much documentation is needed? We could get into endless discussions of when we should comment, what we should comment, and how much we should comment. I have had plenty of discussions about comments with people with various opinions on the subject.
Here’s a good documentation practice for a SAS code:
The program header was written to validate Clintrial (Oracle).
- Program name, version, programmer and purpose.
- Risk Assessments
The second section contains information about the
- quality testing, user testing
- Macros, global variables and any other code that is reusable.
The document must tell the entire story about your program and must be readable by internal or external staff. Two other important things to remember, your program must be accurate “error free” and each section of your program must be traceable, such as who updated it, what and why.
Most companies have SOPs that requires you to record certain information. But do we understand what it is we are recording? or when it was recorded?
Standardized Documentation is KEY”
Do you have a preference? Tell me about it in the comments!
Anayansi has an extensive background in clinical data management as well as experience with different EDC systems including Medidata Rave, Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.