Quality Assurance
Quality assurance is one of the key ingredients of creating good software. While our full QA process, which is described below, is used when we develop high integrity software for the medical industry, we use a reasonable subset for all our non medical projects.
Our full QA process conforms to FDA guideline 21 CFR 820 – Quality System Regulations which addresses how to develop and validate software for FDA-regulated environments like medical devices, clinical trials and software governed by 21 CFR Part 11 for electronic signatures. HIPAA has also adopted Part 820 as its quality standard for software that contains patient data. Part 820 requires that a disciplined, controlled and fully documented methodology be used to develop and validate software.
While a software vendor may have an excellent piece of software, for a FDA-regulated environment, an assumption is made that if a particular aspect of the development process has not been documented it did not happen and the software’s integrity cannot be proven. The FDA does not accept that observing the software’s error free behavior in the past is proof that the software will behave in an error free manner in the future. The FDA will only accept a software development methodology that clearly manages and documents the quality of the entire development process as proof that the software is error free.
SageKey uses a disciplined, controlled and fully documented methodology to design, build and test regulated software. Our quality assurance methodology uses a nine-step process:
Need a Digital Partner?
Contact us today. We love solving problems through custom software development projects.
Product Requirements
- The Product Requirements document defines the project. It includes the list of requirements and information about the environment in which the application will be run.
Software Development Project Plan
- This document lists the project’s resources and deliverables, defines the schedule of tasks to be completed and identifies the source of project funding.Design Specifications
- The Design Specifications document contains detailed information about the specific functionality of the software. Each feature or function is given an identifier that is used to trace between the specifications and their test cases.
Technical Specifications
- This document describes the project’s system architecture and development tools. It outlines how the Design Specifications will be developed into software and includes a design risk assessment and a developer testing plan.
Unit Testing & Code Review
- Unit testing is conducted on each functional element of the application by the developer and the results documented. Code reviews are performed as a means of improving code maintainability by ensuring adherence to coding standards. Results of the reviews are included in the Code Review Report.
Build Notes
- The Build Notes document describes the software build environment and lists any specific settings or configurations that must be made to create a build of the software.
Software Quality Assurance Testing Protocol
- This document identifies the testing environment and includes a description of the testers and their approach for testing each component of the software. The document describes each test case and assigns it an identifier that traces it to a design specification.
Software Quality Assurance Testing Report
- This document describes the results of the execution of the test cases. It includes a description of the software configuration tested and the results of each test case execution. The results of failed tests are entered into a Validation Error Reporting log in preparation for re-testing.
Release Notes
- The Release Notes document includes a list of all files that will be deployed with the application and lists any outstanding issues, workarounds or helpful notes that will assist in the deployment, installation and use of the application.
Company’s Supporting Infrastructure
In addition to the above, companies that build high integrity software are required to have a set of written, approved and enacted policies called Standard Operating Procedures (SOPs) for all the core business activities that affect the software development process. These SOPs act as the foundation of the software development activity and ensure that this activity is not compromised. SageKey maintains the following SOPs to run its core business activities:
Evaluation Results from Computer System Validation
SageKey Software was recently evaluated by David Nettleton, founder of Computer System Validation. David is an FDA and HIPAA computer system validation specialist who is considered to be one of the nation’s foremost experts in the field. He is the author of three books on the subject and was on the team that developed the 21 CFR Part 11 regulations.
During the past two weeks I evaluated SageKey Software, Inc. for compliance with 21 CFR Part 11, the FDA’s Electronic Records and Signature regulation that affects all GxP data (laboratory, clinical, manufacturing). Part 11 has three primary areas for compliance; Standard Operating Procedures (SOPs), product features, and validation documentation.
SOPs: I reviewed infrastructure SOPs related to document management, training, facility security, computer and network security, data backup, and disaster recovery. All SOPs show mature processes and commitment to quality standards.
I reviewed software development and validation SOPs related to coding standards, source code control, issue tracking, software development and validation, and software change control. All SOPs show a comprehensive and mature process for developing state of the art software applications that meet industry standards for FDA compliance.
I reviewed the training records of two members chosen at random, a senior software developer and a system administrator. Both sets of records show appropriate training of 21 CFR Part 11 and applicable SOPs.
Product Features: SageKey is a contract software vendor and as such does not market software applications themselves. Therefore no specific product was included in this evaluation. However, I was presented with a demonstration of a medical records application, an EMR for the dialysis industry, that demonstrated compliance with the current industry standard feature set for security, data transfer, audit trails, and electronic signatures related to 21 CFR Part 11, and 45 CFR Part 164, the HIPAA electronic records security standards rule.
Validation Documentation: SageKey has a comprehensive software development and system validation lifecycle with detailed validation documentation. I reviewed all of the validation documents for one project that included: Product Requirements, Software Development and Validation Project Plan, Design Specifications, Technical Specifications, Code Review Report, Build Notes, Software Quality Assurance (SQA) Testing Protocol, SQA Testing Report, and Release Notes. All of these documents follow SageKey SOPs, meet industry standards, and clearly show a commitment to quality and regulatory compliance.
In summary, SageKey shows an excellent level of compliance related to FDA and HIPAA regulations and is a mature contract software development vendor.
We invite you to visit us and audit our example projects, processes and SOPs. SageKey is located in a beautiful part of Western Canada, well known for its wine, vacation spots and low impact industries.
SOP and Document Management
- Describes how the company manages its standard operating procedures and related documents
Staff Training
- Contains records that show that the staff are qualified to do the work
Building Security
- Defines how the physical security of the organization is protected and managed
Computer and Network Security
- Defines how the electronic security of the organization is protected and managed
Electronic Data Backup and Recovery
- Defines how the electronic data of the organization is backed up and protected
Disaster Recovery
- Describes the company’s disaster recovery process
Coding Standards
- Describes the coding standards adhered to by the organization and how code reviews are conducted
Source Code Control
- Describes how source code versions are managed
Issue Tracking
- The organization’s policies for tracking software issues from their discovery through to their resolution and testing
Software Development and Validation
- A detailed description of the nine-document software development process adhered to by the organization (as described in the section above)
Software Change Control
- Defines how changes are introduced into released software that maintains the integrity of the software