Clinical Research Emergency Response Guidepdf

The core function of this guideline is to cover four types of high-risk emergencies throughout the clinical research cycle (subject safety incidents, major protocol deviations, sensitive data leaks, regulatory sudden inspections), and clarify the general disposal logic of "stop losses first to ensure safety, then trace the source to determine responsibilities, and then report and prepare traces." All operations comply with the relevant requirements of my country's GCP, "Drug Registration Management Measures" and ICH-GCP, and are accompanied by directly reusable disposal ledgers, reporting techniques and grading judgment toolkits.

To be honest, many people who are new to the industry always feel that emergencies are far away from them. If they really run into trouble, they will only cause trouble for the entire project. Last year, I was stationed at a phase III clinical center for lung cancer, and I happened to encounter a subject who developed laryngeal edema 12 minutes after the drug was administered. The first reaction of the newly-reformed CRC was to take out her mobile phone to make a voice report to the PI. I held her down and called the nurse to inject epinephrine. After the subject's blood oxygen returned to above 95% and the physical signs were stable, the follow-up reporting and recording process was carried out. This red line is not controversial. No matter what the situation, the subject's safety always comes first, and no matter how standardized the process is, it can't save human life.

After the most urgent security incident has been solved, the easiest thing left to deal with is the handling of plan deviations (PD). Until now, there is no completely unified implementation standard in the industry. If you ask different people, you will get completely opposite answers: Most of the experienced teachers who have been in institutional quality control for 12 years will emphasize to you that as long as there is a deviation, whether it is a visit that exceeds the window by 1 day or a non-core blood test indicator is missed, an ethics report must be reported within 24 hours. Even if you go a few times more, you can't leave any concealment. However, senior CRAs who spend time in various centers every day will most likely advise you to classify them first. Mild PDs that do not affect the safety of the subjects and do not interfere with the scientific nature of the trial data can be saved and submitted in the monthly safety report. Otherwise, if you send materials to ethics every three days, the energy of the already busy teacher will be occupied, and if a major incident occurs, it will delay the approval. My general approach is to finalize the grading list with the organization and ethics in advance at the project kick-off meeting, which ones should go through the emergency reporting channel, and which ones can be summarized on a monthly basis, so as not to have to argue with each other if something goes wrong.

The risk of data leakage that many people tend to ignore is no less lethal than an SAE (serious adverse event). Last year, a CRC center in Shanghai brought 29 original follow-up records of subjects to the institution to submit materials. She squeezed into the subway during the morning rush hour and put the document bag on her seat. Her first reaction was to go back along the subway line to look for it. The PM scolded her and woke her up on the spot: First, call all involved subjects one by one, report to the institution's confidentiality office and ethics, and then contact the subway operator for monitoring. Later, the document bag was delivered to the service station by a kind person. There was no misuse of information, and the entire process was compliant and was not punished by supervision. To put it bluntly, if the information is really resold, your responsibility for concealing it is ten times greater than the leak itself. Don't take any chances on this point.

As for the occasional unannounced inspection by the drug regulatory department, don’t hide the documents in a panic. Just notify the PI, project leader and company QA to arrive as soon as possible. If you are unsure about the question before QA arrives, just say "I need to confirm this content with the project team before giving you an answer." No one will blame you. If you say something wrong, it will be a big trouble.

There are now two different ways of dealing with the traceability process: many companies still adopt the traditional "whoever makes the mistake bears responsibility". If they fail to report SUSAR (suspicious and unexpected serious adverse reactions), they will be punished by CRC, and if they enroll subjects who do not meet the standards, they will be punished. To put it bluntly, But now more and more teams are beginning to take the route of system optimization. When something goes wrong, they first check whether there are loopholes in the SOP and whether the training is not in place. For example, the nurse gives the wrong medicine. Don't just blame the person. Change the medication process to a double check to plug the loopholes at the root. I have been using the latter for the past few years when leading my team. After all, frontline staff are already under a lot of pressure and no one wants to get into trouble. Punishment alone cannot solve the fundamental problem.

The toolkit attached at the end of this guide is actually the most practical, and is filled out of the pitfalls our team has traversed in the past seven or eight years: the SUSAR reporting time table is clearly marked, which situations should be reported within 7 days, and which situations should be reported within 15 days; speech templates for different scenarios, which can be explained to subjects and reported to regulatory authorities, and can be used by changing the project name; there is also an emergency event traceability ledger, which information needs to be recorded and who needs to sign. It is clearly listed. Of course, don’t be rigid. The emergency focus of oncology drug projects and medical aesthetic device projects are definitely different. Just adjust according to the situation of your own project. Ease of use is more important than compliance - oh no, compliance is the bottom line. How to be efficient on this basis.