20 terms you will hear on a Healthcare — Life Sciences project, each with what it means, where it shows up in the business, and what QA should test.
GxP · 21 CFR Part 11 · ALCOA+ · CSV and CSA · EDC · CRF · CTMS · IRT · Blinding · Database lock · SDTM · CSR · eCTD · E2B(R3) · MedDRA · CAPA · Batch record · CDMO · Serialisation and EPCIS · Pharmacovigilance
The family of "good practice" rules for regulated work: GLP in the lab, GCP in clinical trials, GMP in manufacturing, GDP in distribution and GVP in safety.
Where it shows up: Every stage from discovery to pharmacovigilance.
What QA should test: Knowing which GxP applies, because it decides how much validation and evidence a system needs.
The US FDA rule for electronic records and electronic signatures in regulated work.
Where it shows up: Any system holding GxP records: EDC, LIMS, QMS, MES, safety databases.
What QA should test: Audit trails, unique logins, e-signature meaning and linking, and record protection.
The data integrity principles: Attributable, Legible, Contemporaneous, Original and Accurate, plus Complete, Consistent, Enduring and Available.
Where it shows up: Every regulated record.
What QA should test: Who changed what and when, no silent overwrites, and data retrievable for the full retention period.
Proving a regulated system does what it should. CSV is the traditional documented approach (IQ, OQ, PQ); CSA is the FDA's risk-based approach that focuses effort on what affects patients and product quality.
Where it shows up: Before go-live and after every change.
What QA should test: Risk assessment, traceable test evidence, and a validation summary that signs the system off.
The system trial sites use to enter patient data into electronic case report forms.
Where it shows up: Clinical trials, from first patient in to database lock.
What QA should test: Edit checks, visit schedules, query workflows and audit trails.
The form, usually electronic (eCRF), that defines exactly what data is collected for each patient at each visit.
Where it shows up: Designed from the protocol before the trial starts.
What QA should test: Every protocol data point has a field, with the right ranges and derivations.
Runs the operational side of trials: sites, monitoring visits, enrolment tracking and site payments.
Where it shows up: Trial set-up and conduct.
What QA should test: Enrolment counts against EDC, milestone tracking and site payment triggers.
The system that randomises patients and manages trial drug supply to sites, while keeping the study blind.
Where it shows up: Randomisation and drug supply during the trial.
What QA should test: Randomisation lists, kit assignment, emergency unblinding, and that blinded users never see treatment arms.
Keeping patients and investigators (and sometimes the sponsor) unaware of who receives which treatment, so results are not biased.
Where it shows up: Throughout a controlled trial.
What QA should test: Reports, exports and screens never exposing kit-to-treatment links to blinded roles.
The point where trial data is final: all queries resolved, no further changes, ready for analysis.
Where it shows up: End of the trial.
What QA should test: Lock and unlock permissions, and that nothing can change after lock.
The CDISC standard structure for submitting trial data to regulators such as the FDA.
Where it shows up: Data management and submission preparation.
What QA should test: Mapping from EDC to SDTM domains, controlled terminology and validation reports.
The full scientific report of a trial's design, conduct and results, structured to ICH E3.
Where it shows up: After database lock and analysis, into the submission.
What QA should test: Tables, listings and figures traceable to locked data.
The standard electronic format for submitting a drug application, organised in five modules.
Where it shows up: Regulatory submission to the FDA, EMA, CDSCO and others.
What QA should test: Publishing and validation rules, hyperlinks, and lifecycle operations on documents.
The ICH standard for electronic individual case safety reports (ICSRs), the format for sending adverse event cases to regulators.
Where it shows up: Pharmacovigilance, after an adverse event is reported.
What QA should test: XML validation, acknowledgements, and reporting clocks such as 15-day expedited reports.
The standard medical terminology for coding adverse events and medical history.
Where it shows up: Trial data and safety case processing.
What QA should test: Coding to the right term, and dictionary version upgrades.
The quality process for fixing the cause of a problem and stopping it happening again.
Where it shows up: After deviations, audit findings and complaints.
What QA should test: CAPA workflow states, effectiveness checks and links to the original deviation.
The record of how one batch of a medicine was made, step by step, reviewed by QA before the batch can be released.
Where it shows up: GMP manufacturing, often electronic in an MES.
What QA should test: Step enforcement, limits and alarms, e-signatures and review-by-exception.
A company that develops and manufactures medicines for other pharma companies.
Where it shows up: Outsourced development and manufacturing.
What QA should test: Data exchange with the sponsor, and quality agreements reflected in the systems.
Giving every saleable pack a unique serial number and recording its movements as GS1 EPCIS events, so medicines can be traced through the supply chain.
Where it shows up: Packaging and distribution, for example under the US DSCSA.
What QA should test: Serial generation, aggregation of packs into cases and pallets, and event exchange with partners.
Monitoring the safety of medicines once they are in use: collecting, assessing and reporting adverse events.
Where it shows up: From the first trial patient to the end of a product's life.
What QA should test: Case intake to submission, duplicate detection, and regulatory clock tracking.
The Healthcare — Life Sciences track walks through the whole business end to end, and Session 01 is free in English and Telugu.
