- Home
- Industry
- Products
- Services
- Cloud Platform
Enquire Now
Compliance is about being compliant with specification, policy, standard or law. Also, regulatory compliance for an
organization describes the goal to achieve in their efforts to display that they are in conformity with the established
regulations, guidelines or specification and government legislation.
Quality, on the other hand, is defined as products and services that deliver intended performance consistently
based on the customer requirement. In fact, compliance and quality as they complement each other.
For regulated industries, the regulations and guidelines for Quality System are set forth by the governing bodies such
as but not limited to:
Most of the organization develops their own in-house procedures, work instruction, training, etc.,
based on the regulations that govern their business. That is why having a procedure up to date and
following it helps the organization in solidifying the compliance in their respective fields.
Having a well-integrated quality management system in place helps an organization in the compliance arena.
Additionally, a well-defined document management system helps to keep track of all the procedures and efficiently
control the revision as the regulation changes.
Implementing a well defined internal audit management system to pulse check your compliance with procedures,
work instructions, standards. Similarly, with nonconformance management
system, documenting and trending quality incidents for early signals of major issues.
CAPA management to perform effective root cause analysis and put in the action plans to resolve major issues.
Sound training management to keep track of training requirements and to ensure that personnel are trained
competently to their role.
Oasis solutions are designed over years of experience in industry best practices and offer an out-of-the-box
functionality to meet requirements defined by regulatory bodies such as FDA, ISO and suport your in-house procedues.
21 CFR Part 11 is a US FDA Code of Federal Regulations (CFR) guideline for a computer system that is used to
manage and store electronic records and electronic signatures. It helps companies to define the rules under which
electronic signatures and records are considered to be original, accurate, trustworthy, confidential, reliable and
equivalent to paper records and handwritten signature.
21 CFR Part 11 is a US FDA Code of Federal Regulations (CFR) guideline for a computer system that is used to manage and store electronic records and electronic signatures. It helps companies to define the rules under which electronic signatures and records are considered to be original, accurate, trustworthy, confidential, reliable and equivalent to paper records and handwritten signature.
21 CFR Part 11 Requirement |
---|
The system must be capable to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying. |
Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. |
Limiting system access to authorized individuals. |
Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available |
Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. |
Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand. |
Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:
|
S No. |
Clause |
Description |
---|---|---|
1. | Risk Assessment | Risk management should be applied throughout the lifecycle of the computerized system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerized system. |
2. | Personnel | There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT. All personnel should have appropriate qualifications, level of access and defined responsibilities to carry out their assigned duties. |
3. | Suppliers and service provider | 3.1 .When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerized system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. IT-departments should be considered analogous. |
3.2. The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment. | ||
3.3. Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled. | ||
3.4. Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request. | ||
4. | Project Phase Validation | 4.1 The validation documentation and reports should cover the relevant steps of the life cycle. Manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment. |
4.2 Validation documentation should include change control records (if applicable) and Reports on any deviations observed during the validation process. | ||
4.3. An up to date listing of all relevant systems and their GMP functionality (inventory) should be available. For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available. | ||
4.4. User Requirements Specifications should describe the required functions of the computerized system and be based on documented risk assessment and GMP impact. User requirements should be traceable throughout the life-cycle. | ||
4.5 The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately. | ||
4.6 For the validation of bespoke or customized computerized systems there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system. | ||
4.7 Evidence of appropriate test methods and test scenarios should be demonstrated. Particularly, system (process) parameter limits, data limits and error handling should be considered. Automated testing tools and test environments should have documented assessments for their adequacy. | ||
4.8. If data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process. | ||
5. | Operational Phase Data | Computerized systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimize the risks. |
6. | Accuracy Checks | For critical data entered manually, there should be an additional check on the accuracy of the data. This check may be done by a second operator or by validated electronic means. The criticality and the potential consequences of erroneous or incorrectly entered data to a system should be covered by risk management. |
7. | Data Storage | 7.1 Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period. |
7.2. Regular back-ups of all relevant data should be done. Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically. | ||
8. | Printout | 8.1 It should be possible to obtain clear printed copies of electronically stored data. |
8.2. For records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry. | ||
9. | Audit Trails | Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail"). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed |
10. | Change and configuration Management | Any changes to a computerized system including system configurations should only be made in a controlled manner in accordance with a defined procedure. |
11. | Periodic Evaluation | Computerized systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports. |
12. | Security | 12.1. Physical and/or logical controls should be in place to restrict access to computerized system to authorized persons. Suitable methods of preventing unauthorized entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to computer equipment and data storage areas. |
12.2. The extent of security controls depends on the criticality of the computerized system. | ||
12.3. Creation, change, and cancellation of access authorizations should be recorded. | ||
12.4. Management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time. | ||
13. | Incident Management | All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions. |
14. | Electronic Signature | Electronic records may be signed electronically. Electronic signatures are expected to: a). have the same impact as hand-written signatures within the boundaries of the company, b). be permanently linked to their respective record, c). include the time and date that they were applied. |
15. | Batch Release | When a computerized system is used for recording certification and batch release, the system should allow only Qualified Persons to certify the release of the batches and it should clearly identify and record the person releasing or certifying the batches. This should be performed using an electronic signature |
16. | Business Continuity | For the availability of computerized systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. These arrangements should be adequately documented and tested. |
17. | Archiving | Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested. |
Oasis Solution Information Matrix for ISO 9001
It helps businesses and organizations to be more efficient and improve customer satisfaction (www.iso.org).Requirements Section |
Description |
---|---|
Section 4: General Requirements: Quality Management System | Provides requirements for the overall Quality Management System from quality manual documentation to the control of documents and records. |
Section 5: Management Responsibility | Provides requirements for Management’s role and commitment in the QMS. |
Section 6: Resource Management. | Provides the guidelines for resources to perform the job competently and in safety. |
Section 7: Product Realization | Provides the guidelines for customer related processes, design and development and purchasing |
Section 8: Measurement, Analysis and Improvement | Gives ISO requirements on monitoring processes and improving those processes such as customer satisfaction, internal audit, control of Non-Conforming Product, Corrective and Preventive Action (CAPA) and continual improvement |
Documented Information;
As a LIMS is used to store documented information, be sure that the access, storage, retrieval, control of changes, retention and disposition of data within the system is aligned with the requirements of your quality management system.
Control of externally provided processes, products and services; Where your LIMS is a hosted solution, be sure to have a documented contract or SLA in place that details your requirements for their service and their responsibilities. As good practice, you should define criteria for evaluation, selection, monitoring of performance and re-evaluation of your suppliers.
Document Control; There are specific requirements regarding changes to documentation. You should have procedures that detail how changes in documentation that is maintained within a computerized system such as a LIMS are created and controlled.
Control of Records;
Laboratories should maintain a procedure for identification, collections, indexing, access, filing, storage, maintenance
and disposal of quality and technical records. As a LIMS is used to record and store records, you should ensure your procedures
cover the use of your LIMS. It would be beneficial to describe where and how records are held secure and in confidence, and also
how records stored electronically are backed-up and data integrity is maintained. Furtherrequirements are specified for
technical records. These requirements would also apply to the functionality with your LIMS.
For example, observations, data and calculation shall be recorded at the time they are made and identifiable
to a specific task. This could be translated to the recording of test results via equipment integration for a
sample against a particular test method in your LIMS. In addition, where mistakes occur, the original
record should not be erased or deleted. This should be key functionality in your LIMS to ensure edits do
not overwrite original data entries.
It is important that the specification requirements meet the demands on the system and operating environment, and also incorporate the technical elements to satisfy part 11.
The documentation of plans procedures, and reports and appropriate review, approval, and management
O-link user administration comprises of the setting of rights group and assignment of rights to users, it enables easy setting of user access rights as well as rights group matched to each user’s required task. Functions such as these achieve effective user administration matched to laboratory operations from managerial tasks to data acquisition operations.
Features functions for setting an audit trail to ensure data reliability and security features include various settings, such as setting the length, expiration date and complexity of passwords for user accounts, setting the lockout function to prevent illegal access, and registering settings for the deletion and alteration of registered users, to enable highly secure system operation.
The changes history of method files is managed by the audit trail, application of audit trail to all methods can also be set in security policy settings. This prevents inconsistencies in compliance with regulations.