This documentation should be retained as part of study records. Source documents should be retained to enable a reconstruction and evaluation of the trial.
When original observations are entered directly into a computerized system, the electronic record is the source document. The design of a computerized system should ensure that all applicable regulatory requirements for recordkeeping and record retention in clinical trials are met with the same degree of confidence as is provided with paper systems. Clinical investigators should retain either the original or a certified copy of all source documents sent to a sponsor or contract research organization, including query resolution correspondence.
Any change to a record required to be maintained should not obscure the original information. The record should clearly indicate that a change was made and clearly provide a means to locate and read the prior information. Changes to data that are stored on electronic media will always require an audit trail, in accordance with 21 CFR Documentation should include who made the changes, when, and why they were made.
The FDA may inspect all records that are intended to support submissions to the Agency, regardless of how they were created or maintained. Data should be retrievable in such a fashion that all information regarding each individual subject in a study is attributable to that subject. Computerized systems should be designed: 1 So that all requirements assigned to these systems in a study protocol are satisfied e.
SOPs should be established for, but not limited to:! The data entry system should also be designed to ensure attributability. Therefore, each entry to an electronic record, including any change, should be made under the electronic signature of the individual making that entry.
However, this does not necessarily mean a separate electronic signature for each entry or change. For example, a single electronic signature may cover multiple entries or changes.
The printed name of the individual who enters data should be displayed by the data entry screen throughout the data entry session. Individuals should only work under their own passwords or other access keys and should not share these with others. Individuals should not log on to the system in order to provide another person access to the system. Passwords or other access keys should be changed at established intervals. When someone leaves a workstation, the person should log off the system.
Failing this, an automatic log off may be appropriate for long idle periods. For short periods of inactivity, there should be some kind of automatic protection against unauthorized data entry. An example could be an automatic screen saver that prevents data entry until a password is entered. Persons must use 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.
A record is created when it is saved to durable media, as described under "commit" in Section II, Definitions. Audit trails must be retained for a period at least as long as that required for the subject electronic records e.
Personnel who create, modify, or delete electronic records should not be able to modify the audit trails. Clinical investigators should retain either the original or a certified copy of audit trails. FDA personnel should be able to read audit trails both at the study site and at any other location where associated electronic study records are maintained.
Systems used for direct entry of data should be designed to include features that will facilitate the inspection and review of data. Data tags e. Retrieval of Data Recognizing that computer products may be discontinued or supplanted by newer possibly incompatible systems, it is nonetheless vital that sponsors retain the ability to retrieve and review the data recorded by the older systems.
Reconstruction of Study FDA expects to be able to reconstruct a study. SECURITY Physical Security In addition to internal safeguards built into the system, external safeguards should be in place to ensure that access to the computerized system and to the data is restricted to authorized personnel. SOPs should be in place for handling and storing the system to prevent unauthorized access. Logical Security Access to the data at the clinical site should be restricted and monitored through the system's software with its required log-on, security procedures, and audit trail.
Systems documentation should be readily available at the site where clinical trials are conducted. Such documentation should provide an overall description of computerized systems and the relationship of hardware, software, and physical environment. FDA may inspect documentation, possessed by a regulated company, that demonstrates validation of software. The study sponsor is responsible, if requested, for making such documentation available at the time of inspection at the site where software is used.
Clinical investigators are not generally responsible for validation unless they originated or modified software. For software purchased off-the-shelf, most of the validation should have been done by the company that wrote the software. The sponsor or contract research organization should have documentation either original validation documents or on-site vendor audit documents of this design level validation by the vendor, and should have itself performed functional testing e. Documentation important to demonstrate software validation includes: Written design specification that describes what the software is intended to do and how it is intended to do it; A written test plan based on the design specification, including both structural and functional analysis; and, Test results and an evaluation of how these results demonstrate that the predetermined design specification has been met.
Change Control Written procedures should be in place to ensure that changes to the computerized system such as software upgrades, equipment or component replacement, or new instrumentation will maintain the integrity of the data or the integrity of protocols. All changes to the system should be documented. Contingency Plans Written procedures should describe contingency plans for continuing the study by alternate means in the event of failure of the computerized system.
Backup and Recovery of Electronic Records Backup and recovery procedures should be clearly outlined in the SOPs and be sufficient to protect against data loss. Training Training should be provided to individuals in the specific operations that they are to perform.
Thus, such a product is a Class IIa medical device as the device provides information to a relevant health professional to inform the diagnosis of a serious disease. This category also covers risk prediction software, as well as the tools that record data from a patient monitor or images directly from an MRI scanner provided that such software does not impact the operations of a scanner itself.
This category applies to medical devices associated with medium-high risk. For instance, such classification should be applied to a product that is intended to analyze a cardiac MRI in order to provide information used in making diagnoses of related diseases. As in the previous example, the software is intended to provide information to healthcare professionals only. As described in the guidance, Class IIb applies to medical software that is intended by the manufacturer the software developer to provide information to a relevant health professional to inform the diagnosis of a serious disease.
Other examples of Class IIb products include tools intended to be used to diagnose an acute arterial occlusion due to the severity of potential consequences of this disease if the necessary treatment is not applied. This category also covers software products that are intended to provide recommendations for treatment or intervention on the basis of input data e.
As in the previous cases, such software should be used only by healthcare professionals. Consequently, a Class IIb software-based medical device is the one that is intended to:. The same classification applies to wearable devices intended to collect and analyze data for screening for serious heart diseases, as well as questionnaire apps intended to analyze the information provided by a patient and provide a diagnostic output.
Another important aspect addressed in the guidance relates to coding or construction. In general, a new software product could be created in two ways:.
The particular approach to be used should be determined based on the intended purpose of the future product, availability of resources, and functionality needed. Coding itself, and additional processes associated thereto should be conducted under the respective written procedures to be developed and implemented by medical device manufacturers software developers engaged in the creation of such products.
When describing the processes associated with coding and construction, the guidance addresses the most important aspects associated thereto, such as debugging the code, compilation, source code evaluation, as well as documenting these processes. The guidance also pays special attention to a source code traceability analysis to be performed to ensure that software design specification has been duly implemented, and all the elements could be traced back to source code.
The typical tasks related to coding or construction include the following ones:. In summary, the present FDA guidance highlights the most important aspects associated with the particular actions to be undertaken by medical device manufacturers software developers concerning software design and coding processes.
The document describes in detail the typical tasks associated with each of the aforementioned processes and outlines the key points to be taken into consideration. RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally.
Our focus on enabling companies to reach true quality is coupled with our commitment to advancing industry best practices through our partnership with the FDA on their Case for Quality.
Significant regulatory burdens are removed for manufacturers by ensuring all documentation and records pertaining to eQMS validation are in alignment with regulations and current FDA expectations. Software assurance is about you demonstrating and having confidence that the system meets your intended use and the features and functions perform as expected without impacting patient safety and device quality.
FDA does not want to direct resources to inspect and review assurance activities. Instead, FDA expects the medical device company to be responsible for doing so. What does FDA care about? FDA is going to focus time and effort on direct impact to device quality, device safety, direct patient safety risks.
And this does not mean that if the areas listed above are impacted that FDA expects you to necessarily address via robust protocols, testing, etc. This does mean FDA cares about these areas and expects you to focus on critical thinking and assurance. Remember, you do not need to reinvent the wheel. Leverage existing activities. Leverage supplier data and information. Use CSV tools to automate assurance activities. You will determine the correct tools and assurance activities. When applicable, use agile testing methodologies.
Use electronic data capture and record creation. You can apply this new way of thinking and approaches today. Doing so will help you with better information, product performance knowledge, easier methods to track and trend, more timely responsiveness, process optimization, reducing in product risks, reducing operational expenses, and increasing business value.
Ultimately, embracing automation and technologies within your business has the great potential to improve your product quality and reduce patient risks. Looking for an all-in-one QMS solution to advance the success of your in-market devices and integrates your quality processes with product development efforts? See the Demo. Subscribe See the Demo. Search Results for:. In the final segment, Cisco Vicenty, CDRH Program Manager at FDA, offered his unique insight on the topic, The FDA supports and encourages the use of automation, information technology, and data solutions throughout the product lifecycle in the design, manufacturing, service, and support of medical devices.
Why is this a big deal? What is it that prevents use of technology? This was a wake-up call for FDA. Related Articles. Read More. Approval vs. Want more free medical device resources? Subscribe to our blog to receive updates.
Get in-depth weekly articles, right in your inbox. Jon knows the best medical device companies in the world use quality as an accelerator. That's why he created Greenlight Guru to help companies move beyond compliance to True Quality.
Back to blog listing page.
0コメント