Digitale batchregistreringer, der overlever inspektion

Hvidbogsserien

eBMR/eDHR

Opdateret feb. 2026 • eBMR/eBR, eDHR, gennemgang efter undtagelse, hårde gates, genealogi, revisionsspor, e-signaturer, CSV, eksport, integrationsgrænser
Disclaimer: Dette dokument indeholder generel driftsvejledning. Det er ikke juridisk rådgivning og erstatter ikke dit interne kvalitetssystem, din lovgivningsmæssige rådgivning eller din specifikke risikovurdering for den pågældende virksomhed.

Executive summary

Digitale batchregistre mislykkes ved inspektioner af én grund: de opfører sig ikke som bevismateriale under pres. Registret ser komplet ud, indtil en inspektør stiller et simpelt spørgsmål - "vis mig, hvordan du ved, at dette tal er korrekt", "hvem ændrede det", "hvad skete der før frigivelse", "hvilke partier blev forbrugt", "hvilket udstyr blev brugt", "hvilke undtagelser opstod" eller "hvor hurtigt kan du hente hele historikken". Hvis disse svar kræver regneark, e-mailarkæologi eller narrativ rekonstruktion, er batchregistret ikke længere registreringen. Driftsmodellen bliver skrøbelig, og inspektionerne udvides i overensstemmelse hermed.

Dette whitepaper beskriver en praktisk, leverandørneutral model for elektroniske batchproduktionsregistre og elektroniske enhedshistorikregistre: elektroniske batchregistre (eBR/eBMR) og elektroniske enhedshistorikregistre (eDHR) . Modellen fokuserer på de kontrolflader, som inspektører og revisorer faktisk tester: identitet og partisikkerhed, trinvis udførelsesbevis, udstyrsberettigelse, kontrollerede redigeringer, undtagelsesstyring, gennemgang for undtagelse, revisionsspor, signaturbetydning og -binding samt hurtig hentning af komplette, kontekstualiserede registreringer.

Hvor elektroniske optegnelser og signaturer er omfattet, diskuteres inspektionsforventninger ofte gennem 21 CFR del 11 og relaterede dataintegritetskoncepter såsom dataintegritet og ALCOA+ . Artiklen beskriver også, hvordan man validerer de vigtige kontroller ved hjælp af CSV og vejledning såsom GAMP 5 , uden at glide hen i funktionsklik eller "valideringsteater".

Målet er enkelt: en elektronisk batchregistrering, der kan afleveres til en inspektør og stå alene – ensartet, rekonstruktionsresistent og hurtig at hente.


Abstrakt

Elektroniske batchproduktionsregistre (eBMR) og elektroniske enhedshistorikregistre (eDHR) bedømmes ud fra, om de producerer troværdig dokumentation under inspektionsforhold. Denne artikel foreslår en praktisk driftsmodel for digitale batchregistre ved hjælp af et firedelt bevissprog - identitet, status, udførelseshændelse og beskyttet registrering - understøttet af hard-gated udførelseskontroller, styrede undtagelser, gennemgang-for-undtagelse og hurtig hentning. Modellen adresserer almindelige fejltilstande såsom identitetsdrift, ukontrollerede redigeringer, fragmenterede revisionsspor, svage integrationsgrænser og registreringer, der kræver narrativ rekonstruktion.

Artiklen indeholder også inspektionsøvelser, der simulerer, hvordan inspektører tester tillid til registre: demonstration af revisionssporets adfærd, signaturbetydning, bevis for partiforbrug, udstyrsberettigelse, undtagelseskobling og hentning af komplette registre med kontekst. Hvor der anvendes elektroniske registre, stemmer modellen overens med risikobaserede CSV- og dataintegritetsforventninger, der typisk diskuteres under del 11 og ALCOA+.


1) Omfang: Hvad kvalificerer som eBMR/eDHR-bevis

"Digital batch-post" kan betyde alt fra en PDF-skabelon til en fuldt håndhævet, hændelsesdrevet udførelsespost. Inspektører er optaget af én ting: hvad organisationen behandler som den officielle post, der understøtter regulerede beslutninger. Hvis den digitale post bruges til bortskaffelse, frigivelse, undersøgelser eller kunde-/myndighedsresponser, skal den opføre sig som et bevissystem – komplet, henførbar, konsistent og hentbar.

Hvad angår terminologi, indrammer mange organisationer batchudførelsesposter som eBR/eBMR (produktion) og enhedsposter som eDHR . Det underliggende krav er det samme: rekonstruer, hvad der skete, uden at forlade sig på uformel fortælling.

Et praktisk spørgsmål om afgrænsning

Hvis der opstod en afvigelse, klage eller inspektion i morgen, ville du så bruge denne elektroniske batchregistrering som dit primære bevis? Hvis ja, skal den være udformet som revisionsklar dokumentation, ikke som en praktisk brugergrænseflade.


2) Hvad inspektører rent faktisk tester

Inspektører "læser sjældent hele batchregistreringen" først. De vælger en tråd og trækker i den: et kritisk trin, en vejnings-/dispenseringspost, en afvigelse, en justering, en brug af udstyr, en underskrift eller en frigivelsesbeslutning. Derefter beder de om bevis for, at registreringen kan stoles på: hvem gjorde det, hvornår, hvad der blev ændret, hvilke undtagelser opstod, og hvad forhindrede forbudte handlinger.

Inspektørsonde Hvad de beder om at se Hvad der må være sandt
Lot sandhed Hvilke partier der blev brugt, hvor de kom fra, og bevis for forbrug på tidspunktet for processen. Partiidentitet håndhæves (ofte via scanning); forbruget "tastes ikke ind senere".
Trin sandhed Hvilke trin blev udført, hvornår, af hvem og med hvilke resultater. Trin udføres som hændelser; nødvendige kontroller kan ikke springes over.
Udstyrsberettigelse Hvilket udstyr blev brugt, og om det var berettiget (kalibrering/ren status). Brug af udstyr, der ikke er i status, forhindres eller styres via undtagelsesveje.
Ændringshistorik Hvad blev ændret, hvem ændrede det, hvorfor, og om godkendelser blev anvendt. Revisionsspor er sikre og meningsfulde; redigeringer bevarer originale poster.
Undtagelsesstyring Afvigelser, tilsidesættelser, omarbejdning og hvordan de linker til batchposten. Undtagelser er synlige tidligt, strukturerede og knyttet til de berørte registreringselementer.
Beslutning om frigivelse Hvordan frigivelsen var berettiget, og hvem der godkendte den. Gennemgang er effektiv, men ikke blind; gennemgang efter undtagelse er målbar og forsvarlig.
Hentningshastighed Hvor hurtigt du kan hente den fulde batchhistorik med kontekst. Optegnelserne er komplette og kan eksporteres uden at miste mening.

Resten af ​​denne artikel beskriver, hvordan man kan konfigurere journalen, så disse spørgsmål kan besvares hurtigt og ensartet.


3) Bevismodellen: identitet, status, begivenhed, journal

Digitale batchregistreringer forbedres, når kontroller kan udtrykkes i et lille antal primitiver, der kan omsættes til det daglige arbejde. Den anvendte model er bevidst enkel: identitet (hvem/hvad), status (er det tilladt), udførelseshændelse (hvad skete, hvornår) og beskyttet registrering (manipulationssikret bevis).

Bevissproget

Hvis du ikke kan udtrykke en kontrol i sproget identitet + status + udførelseshændelse + beskyttet post , vil den i sidste ende degradere til "politik" og drive under produktionspres.

Primitive Operationel betydning Inspektionens betydning
Identity Utvetydig "hvem/hvad" på handlingstidspunktet (parti, operatør, udstyr, placering, etiket, batch). Uden identitetssikkerhed bliver alting sandsynlighedsbaseret. Inspektører afviser "vi tror".
Status Berettigelse på brugstidspunktet (hold/frigivelse, udløb, kalibrering, træningsberettigelse). Status er måden, hvorpå du beviser forebyggelse. Hvis status kan omgås, er kontrol rådgivende.
Udførelseshændelse Samtidig registrering af arbejde (dispensering, blanding, IPC-kontrol, pakning, test, frigivelse). Revisioner straffer rekonstruktion. Begivenheder erstatter senere fortælling med tidsbunden sandhed.
Beskyttet post Henførbar, reviderbar og manipulationssikret dokumentation med ændringshistorik. Troværdigheden af ​​elektroniske registre afhænger af revisionsspor adfærd og kontrollerede redigeringer.

Hvor der anvendes elektroniske registre, understøtter denne model forventninger, der typisk er formuleret gennem del 11 og dataintegritetsprincipper som ALCOA+ . Den operationelle test forbliver den samme: kan registret stoles på uden forklaring?


4) Kontrol af masterregistrering: MMR/DMR, opskrifter, versioner

Batchposter fejler, når "mastersandheden" er uklar. Inden for produktion er dette typisk Master Manufacturing Record (MMR) . Inden for enheder er det analoge anker ofte Device Master Record/specifikationssættet (navngivningen af ​​steder varierer). Inspektører vil spørge: hvilken version der blev udført, hvad der blev ændret, hvem der godkendte ændringen, og hvilke batcher der blev påvirket.

Et forsvarligt digitalt program behandler masterposter som kontrollerede objekter: versionsstyrede, godkendte og linkede til hver udført batch. Hvis masterparametre kan ændre sig uformelt – "vi justerer det på vagt" – bliver batchposten en historie snarere end en kontrolleret udførelse.

Master kontroladfærd, der overlever revisioner

  • Versionsbinding: Hver udført post angiver den udførte masterversion.
  • Skift kontrol: Ændringer i hovedsagen kræver formel ændre kontrol og godkendelser.
  • Parameterstyring: Kritiske parametre er begrænsede, og undtagelser registreres som styrede hændelser.
  • Logik for ikrafttrædelsesdato: Hvornår en version bliver aktiv, er eksplicit og sporbar.

5) Udførelseskontroller: trinvis arbejde, hårde porte, IPC

En digital batchregistrering er ikke "en formular". Det er et udførelsessystem, der skaber beviser, mens arbejdet udføres. Inspektører ser efter forebyggende kontroller: om systemet blokerer forbudte handlinger, håndhæver nødvendige kontroller og registrerer den sande rækkefølge af begivenheder. "Advarsler" er svagere end "blokeringer". Politikker er svagere end håndhævelse.

Processtryd er en fælles tråd i inspektioner, fordi den demonstrerer kontrol under udførelsen snarere end efterfølgende gennemgang. Se processtryd (IPC) og relaterede gating-koncepter såsom hard-gated bestået/ikke bestået-kontroller for reference.

Kontroltype Sådan ser det ud i praksis Hvorfor det betyder noget
Trinhåndhævelse Nødvendige trin kan ikke springes over; sekvensen styres; tidsstempler registreres ved udførelse. Forhindrer "udfyld senere"-adfærd og understøtter tidslinjer, der er resistente over for rekonstruktion.
Bestå/fejl-porte Kritiske IPC-resultater blokerer progression, når de er uden for området, medmindre en reguleret undtagelse anvendes. Viser forebyggelse, ikke kun detektion efter udslipsrisiko er skabt.
Identitetsporte Parti-/udstyrs-/operatøridentitet verificeres i hvert trin, ofte via stregkodevalidering. Stopper identitetsdrift og brug af forkerte partier, et inspektionsemne med høje konsekvenser.
Undtagelsesstier Tilsidesættelser kræver begrundelse og godkendelse, registreret som strukturerede hændelser knyttet til trinnet. Forhindrer uformelle løsninger, der ødelægger tilliden til registreringer.

6) Materialer og vejebevis: partier, vægte, udbytte

Materialeforbrug er ofte et punkt, hvor batchregistreringer bryder, fordi det er hyppigt og tidspresset. Inspektører vil teste, om du kan bevise: (1) hvilket parti der blev brugt, (2) om det var berettiget på brugstidspunktet, (3) om den registrerede mængde er troværdig, og (4) hvordan afvigelser (over-/undervægt, substitutioner, opdelte partier) blev håndteret.

Stærke programmer håndhæver lotspecifikt forbrug og registrerer vejehændelser som udførelsesbevis i stedet for senere typning. Hvor der findes vægtintegration, bør den behandles som en bevisgrænse og valideres i overensstemmelse hermed; se vægtintegration . Hvor beholderidentitet og tara er vigtige, reducerer kontroller som tarastyring tvetydighed.

Sandheden om udbyttet er også vigtig, fordi den afslører skjult omarbejdning, udokumenteret kassering eller afstemningsproblemer. En forsvarlig basislinje inkluderer struktureret udbyttegennemgang og synlighed af varians; se koncepter for udbyttevarians og forventninger til afstemning.


7) Udstyr, kalibrering og beredskabsstatus

Udstyrsbeviser er ikke blot en liste over et maskinnavn. Inspektører vil gerne vide, om udstyret var berettiget på brugstidspunktet, og om registreringen beviser det. Almindelige undersøgelser omfatter kalibreringsstatus, vedligeholdelsesstatus, rengøringsstatus (hvor det er relevant), og om operatører blev forhindret i at bruge aktiver, der ikke var i brug.

Stærke systemer implementerer berettigelse som statuslogik. For eksempel kan kalibrering håndhæves ved hjælp af regler såsom kalibreringslogik på grund af spærring eller lignende begrænsninger. Dette handler ikke om perfektion; det handler om, hvorvidt systemet blokerer forbudt udførelse eller indfanger regulerede undtagelser, når virkeligheden tvinger afvigelse.

Hvad overlever inspektion

  • Aktividentitet: Det anvendte udstyr er utvetydigt og knyttet til de udførte trin.
  • Bevis for berettigelse: Kalibrerings-/parathedsstatus på brugstidspunktet registreres eller kan håndhæves.
  • Undtagelsesregistrering: Brug uden for status, hvis det nogensinde er tilladt, dokumenteres med kontrollerede godkendelser.
  • Sporbar forbindelse: Udstyrshændelser er knyttet til batchregistreringshændelser og gemmes ikke separat uden forbindelse.

8) Afvigelser, undtagelser og kontrollerede redigeringer

Digitale batchregistreringer fejler, når undtagelser håndteres "off-system". Inspektører forventer ikke nul afvigelser. De forventer, at afvigelser er synlige, strukturerede og knyttet til de berørte registreringselementer. Hvis der findes en afvigelse i et QMS, men ikke kan knyttes til det batchtrin og de dataelementer, den påvirker, bliver din dokumentation narrativ.

Håndtering af undtagelser bør omfatte triage, tildeling og kobling til udførelseshændelser; se afvigelsestriage og tildeling og bredere håndtering af kvalitetshændelser . Effektiviteten af ​​korrigerende og forebyggende handlinger testes også i modne inspektioner; se CAPA-effektivitetskontrol.

Kontrollerede redigeringer er en hyppig udløser af eskalering. Inspektører ønsker at se, at rettelser bevarer originale poster og producerer meningsfuld ændringshistorik via revisionsspor , inklusive årsag til ændring, hvor det er relevant. Stille overskrivninger, sletning af regulerede poster eller privilegerede redigeringer uden styring er strukturelle svagheder.


9) Beslutninger om gennemgang pr. undtagelse og frigivelse

Gennemgang pr. undtagelse er attraktiv, fordi fuld manuel gennemgang ikke skaleres. Inspektører protesterer ikke mod gennemgang pr. undtagelse; de ​​protesterer mod gennemgang pr. håb. Spørgsmålet er, om undtagelserne er veldefinerede, om systemet pålideligt markerer dem, og om beslutningen om frigivelse er understøttet af beviser snarere end "vi bemærkede ikke noget".

Et praktisk anker er batch review by exception (BRBE) . Et forsvarligt BRBE-program definerer: hvad der udgør en undtagelse, hvordan undtagelser opdages, hvem der gennemgår dem, og hvordan en frigivelsesbeslutning dokumenteres og underskrives. Hvis frigivelsen er baseret på laboratorieresultater, skal forbindelsen til LIMS-beviser være eksplicit (se senere afsnit om vedhæftede filer og integrationsgrænser).

BRBE-element Driftskrav Inspektionsfejltilstand
Definition af undtagelse Tydelige udløsere: OOS/OOT, tilsidesættelser, manglende data, IPC uden for område, forsinkede indtastninger, redigeringer i revisionsspor. "Undtagelse" er vag eller ufuldstændig; korrekturlæsere kan ikke forklare, hvorfor batchen var "ren".
Detektionspålidelighed Systemet markerer pålideligt undtagelser; korrekturlæsere er ikke afhængige af hukommelse. Der findes undtagelser, men de markeres ikke konsekvent eller er lette at undertrykke.
Anmelderarbejdsgang Gennemgangen fokuserer på undtagelseskø og sammenkædet bevismateriale med sporbare dispositioner. Gennemgangen er uformel; der er intet bevis for, hvad der blev gennemgået, eller hvorfor det blev accepteret.
Udgivelsesrekord Frigivelse er en kontrolleret beslutning med e-signaturbetydning og tilknyttet bevismateriale. Frigivelse er en statusskifte uden dokumentation eller signaturbetydning.

10) Revisionsspor, e-signaturer og dataintegritetsstatus

Digitale batchregistre overlever kun inspektioner, hvis registreringen kan stoles på. Denne tillid skabes af identitet, adgangskontrol, revisionshistorik, kontrollerede redigeringer og opbevaringsdisciplin – ofte diskuteret under dataintegritet og principper som ALCOA+ . Hvor elektroniske registreringer og signaturer erstatter papir, formulerer organisationer ofte forventninger gennem 21 CFR del 11.

Inspektører tester revisionssporets adfærd ved demonstration: ændrer en beskyttet værdi, viser revisionssporets post (bruger, tidsstempel, gamle/nye værdier, hvor det er relevant, årsag til ændringen), viser, hvordan den hentes senere, og viser, at den ikke kan ændres lydløst. Se revisionsspor (GxP) . De tester også signaturbetydning og binding, hvor elektroniske signaturer anvendes: hvad betyder signaturen, hvordan godkendes underskriveren, og hvad sker der, hvis posten ændres efter underskrift?

Validering bør være risikobaseret og fokuseret på kontrolfladen. Formålet med CSV er ikke at teste alle skærmbilleder; det er at teste de kontroller, der forhindrer skade eller kvalitetsudslip: identitetshåndhævelse, statushåndhævelse, gatelogik, undtagelseshåndtering, revisionssporadfærd og opbevaringskontroller. Vejledning som GAMP 5 hjælper med at skalere indsatsen i forhold til risiko.


11) Vedhæftede filer og ekstern dokumentation: CoA, LIMS, logfiler

Batchregistreringer er sjældent selvstændige. De afhænger af ekstern dokumentation: leverandør-COA'er, laboratorieresultater, miljøovervågning, udstyrslogfiler, temperaturlogfiler, emballageafstemning og mere. Inspektionsrisikoen er ikke "vedhæftede filer findes"; den er, om vedhæftede filer er kontrollerede, kan tilskrives, er sammenkædede og kan hentes med kontekst.

Et almindeligt svagt punkt er, at ekstern dokumentation gemmes et andet sted (fælles drev, e-mail, LIMS) uden robust forbindelse. Når inspektører spørger "vis mig det laboratorieresultat, der understøttede frigivelsen", skal organisationen hurtigt fremlægge det med en tydelig forbindelse til batchen. Hvis forbindelsen er afhængig af filnavngivning eller manuel søgning, bliver registreringen skrøbelig.

Eksterne beviskontroller, der holder

  • Eksplicit kobling: Vedhæftede filer er knyttet til den præcise batch/det trin/den beslutning, de understøtter.
  • Versionskontrol: Den gennemgåede/godkendte version er identificerbar; ændringer kan revideres.
  • Fuldstændig hentning: Eksport af poster inkluderer referencer, der bevarer betydningen, ikke kun filnavne.
  • Bevisgrænser: Hvis et LIMS er et system til registrering af resultater, defineres og testes denne grænse.

12) Integrationsgrænser: ERP/LIMS/WMS-fejltilstande

Integrationer kan styrke eller underminere batchbeviser. Inspektører finder ofte huller ved grænser: to systemer er uenige om frigivelsesstatus; partiidentiteten er forskellig; tidsstempler stemmer ikke overens; eller "registreringen" er opdelt på tværs af værktøjer uden en klar definition af registreringssystemet. Når dette sker, er organisationen tvunget til afstemning – og afstemning er ikke beviser.

En forsvarlig integrationsposition definerer ejerskab pr. dataelement, hændelseskontrakter (hvad "problem", "forbrug", "frigivelse", "hold" betyder), latenstolerance og afstemningsmekanismer, når virkeligheden afviger. Masterdatajustering er grundlæggende; se masterdatasynkronisering.

Hvis lagerbevægelser kan omgå kvalitetsstatus, kompromitteres batchbeviser. Statushåndhævelseskoncepter som karantæne-/holdstatus skal være ensartede på tværs af operationens bevægelsesflader, ikke kun i ét system.


13) Inspektionsøvelser: 10 tests, du kan udføre internt

Den hurtigste måde at vide, om din eBMR/eDHR vil overleve inspektion, er at udføre øvelser, der efterligner, hvordan inspektører tester tillid til journaler. Hver øvelse skal kunne udføres hurtigt, og beviserne skal stå alene uden forklaring.

10 praktiske eBMR/eDHR-øvelser

  1. Bevis for partiforbrug: vælg en batch; bevis hvert forbrugt parti og vis trin-tid-registrering (ikke senere indtastning).
  2. Forebyggelse af forkert parti: forsøg en scanning/indtastning af forkert parti; vis forebyggelse og logføring.
  3. Udstyrsberettigelse: vælg et aktiv; bevis kalibrering/parathed på brugstidspunktet; forsøg brug uden for status.
  4. IPC-gatetest: opret et IPC-resultat uden for området; vis blokerings-/undtagelsesvej og -forbindelse.
  5. Udbytteafstemning: Forklar udbyttevariansen med beviser, ikke narrativer; vis håndtering af kassering/omarbejdning.
  6. Afvigelseskobling: vælg en afvigelse; bevis forbindelsen til det berørte trin og registrer elementerne.
  7. Demo af revisionsspor: ændre et beskyttet felt; vis gammelt/nyt, bruger, tidsstempel, årsag til ændring.
  8. Signaturbinding: underskrive en frigivelse/anmeldelse; vise hvad det betyder, og hvordan ændringer efter underskrift håndteres.
  9. Eksport af post: eksporter batchposten; bekræft, at den bevarer kontekst (godkendelser, referencer til revisionshistorik, vedhæftede filer).
  10. BRBE-boremaskine: vis undtagelseskø, korrekturlæserdispositioner og bevis for frigivelsesbeslutningen.

14) Implementeringsplan

Den hurtigste måde at fejle på er at starte med at "digitalisere papiret". Den hurtigste måde at vinde på er at starte med at identificere, hvor beviserne bryder igennem i dag, og at indføre hårde begrænsninger på de undslippepunkter med den højeste risiko. Behandl inspektioners overlevelsesevne som ingeniørarbejde: definer bevismodellen, håndhæv begrænsninger, mål resultater og skaler ved replikation.

En praktisk køreplan (faset)

  1. Definer den officielle registrering: afklare, hvilke systemer der udgør batchregistreringen og frigivelsesdokumentationen.
  2. Bind master-versioner: versionsstyret MMR/DMR og kontrolleret ændringsstyring.
  3. Sluk flugtvejene hårdt: forkert parti, udstyr i forkert status, manglende IPC, ukontrollerede tilsidesættelser, forsendelse/frigivelse uden bevis.
  4. Undtagelser fra instrumenter: afvigelser og tilsidesættelser er strukturerede, sammenkædede og kan gennemgås.
  5. Implementer BRBE: definere undtagelsesudløsere og arbejdsgange for korrekturlæsere; måle kvaliteten af ​​korrekturlæserne.
  6. Valider kontrolflader: CSV fokuserede på identitet, status, gates, revisionsspor, signaturer og opbevaring.
  7. Kør inspektionsøvelser: månedlige bevisøvelser for at forhindre afdrift og afdække svage grænser tidligt.
Virkelighedstjek: Hvis din "digitale batchregistrering" kræver et regneark til at forklare, hvad der skete, vil den ikke overleve inspektionen. Dit mål er en registrering, der forklarer sig selv gennem tvungen udførelse og sporbar historik.

Lukningsnotat

Overlevelsesevne i eBMR/eDHR er ikke et formateringsprojekt. Det er en driftsmodel: identiteter håndhæves, statusser er reelle, udførelse registreres som hændelser, undtagelser styres, gennemgang for undtagelse er målbar, og registreringen er beskyttet af design. Når disse elementer er på plads, bliver inspektioner hurtigere og mere præcise, undersøgelser bliver mere præcise, og batchbeviser bliver modstandsdygtige over for rekonstruktion.

For understøttende definitioner, se ordlistesiderne, der er linket til i hele dette dokument, herunder eBR/eBMR , eDHR , batchproduktionsrapport (BMR) , MMR , BRBE , revisionsspor , 21 CFR del 11 , dataintegritet og CSV . Disse referencer er valgfrie; kontrolmodellen i dette dokument er bevidst leverandørneutral.


TILBAGE TIL NYHEDER