Valideret dataoverførsel
Inspireret af den nye EMA ”Notice to sponsors on validation and qualification of computerized systems used in clinical trials” udgivet april 2020, vil jeg gerne give et kort indblik i en af de mere oversete detaljer indenfor laboratorie- eller produktionsmiljøer: Valideret overførsel af data mellem systemer. I denne artikel vil jeg forsøge at dække det regulatoriske grundlag for valideret dataoverførsel, beskrive hvilke problematikker og udfordringer man kan komme ud for, samt lidt om hvordan man kan inspicere overførsel af data mellem systemer.
Hele pointen ved en valideret dataoverførsel er naturligvis at man skal kunne stole på sine data. Data man ikke stoler på, har ingen værdi. I tillæg hertil er det et af myndighedernes nyeste fokusområder, både fordi der er kommet mange nyere guidelines på området og fordi det er et noget forsømt emne i industrien.
Udfordringerne ligger typisk i, at man skal vide noget om hvordan data bevæger sig rundt mellem forskellige systemer, samtidig med man skal have en forståelse for IT og datasikkerhed. Det betyder i realiteten at det skal være en QA-person med indgående kendskab til datamønstre i virksomheden, og IT-forståelse, for at man kan gennemskue hvilke udfordringer man har i virksomheden.
Men hvad er det nu egentlig myndighederne kræver? Her er et par eksempler:
| Regulatory reference | Regulatory requirement text |
| EudraLex, vol. 4, annex 11 European Good Manufacturing Practice (GMP) guidelines, IT Version 2011.06.30 Section 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. |
| PIC/S GUIDANCE PI 011-3 GOOD PRACTICES FOR COMPUTERISED SYSTEMS IN REGULATED “GXP” ENVIRONMENTS Version 2007.09.25 Section 19.3 | The examination of the procedures and records should assure that the following basic requirements are satisfied: Measures are needed to ensure the validated recovery of original information and data following back up, media transfer, transcription, archiving, or system failure. |
| PIC/S PI 041 1 Draft 3 Good practices for data management and integrity in regulated GMP/GDP environments Version 2018.11.30 Section 5.5.1 | Data risk assessment should consider the vulnerability of data to involuntary alteration, deletion, loss or re-creation or deliberate falsification, and the likelihood of detection of such actions. … Control measures which prevent unauthorised activity, and increase visibility / detectability can be used as risk mitigating actions. |
| PIC/S PI 041 1 Draft 3 Good practices for data management and integrity in regulated GMP/GDP environments Version 2018.11.30 Page 32, Item 1 | Interfaces should be assessed and addressed during validation to ensure the correct and complete transfer of data. Interfaces should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimise data integrity risks. Verification methods may include the use of: Secure transferEncryptionCheck sums Where applicable, interfaces between systems should be designed and qualified to include an automated transfer of GxP data. |
| Medicines & Healthcare products Regulatory Agency (MHRA) ‘GXP’ Data Integrity Guidance and Definitions Version 2018.03 Section 6.8 | Data transfer should be validated. The data should not be altered during or after it is transferred to the worksheet or other application. There should be an audit trail for this process. Appropriate Quality procedures should be followed if the data transfer during the operation has not occurred correctly. |
Som det fremgår af ovenstående myndighedskrav, er det som altid en forventning at man sikrer dataintegritet, herunder at dataoverførsler er valide.
Den store udfordring er så at der findes ufatteligt mange dataoverførsler i et moderne system. Mange af overførslerne er automatiserede, men udfordringerne med at implementere en validerbar overførsel er store. Bl.a, er etablering af en fuldstændig og tilstrækkelig audit trail på filoverførsler
Eksempel
En virksomhed ønsker at flytte sine data fra en maskine (det være sig et stykke laboratorieudstyr eller en produktionsmaskine) der befinder sig på et dedikeret netværk (der hvor laboratorie eller produktionsudstyr er tilknyttet), op til et ERP-system der befinder sig på det korporale netværk (der hvor alle kontor PC’erne med Word og Excel befinder sig).
Dataoverførslen består af flere operationer. Først og fremmest skal data overføres fra det dedikerede netværk over på det korporale netværk. I reglen har der været IT folk inde over sammenhængen imellem de 2 netværk, og de har for at beskytte det dedikerede netværk mod hackere, virus og andre ondsindede sager, sørget for et teknologiskift mellem de 2 netværk. Det betyder de 2 netværk ikke hænger sammen på en måde så man kan kopiere en fil direkte, men skal typisk skrive filen til en server der har 2 netværkskort, som ikke kan snakke sammen (dette kaldes en DMZ). Herfra skal så en anden mekanisme kopiere filen videre over på et passende sted hvor ERP-systemet kan læse den.
Det kan være vores fil hedder log20200412143503. Da man gerne vil have filen liggende på et bestemt sted i ERP-systemet, skal man nu omdøbe filen til noget mere passende for at ERP-systemet kan ”gætte” hvor filen skal placeres. Nu omdøber vi derfor filen til et mere passende filnavn, som f.eks. TAG510A_LOG_20200412_143503. Herefter griber et program filen og lægger den ind i ERP-systemet under logfiler tilknyttet tag nummer 510A.
Hvis man ser på den moderne tids cloudløsninger, kan man hurtigt tænke sig denne situation garneret med en ekstern ERP-leverandør der ligger i skyen, en ekstern IT virksomhed til at levere netværksydelsen samt et antal eksterne leverandører af IT/automatikløsningen til at starte dataoverførslen, ændre filnavn, flytte data videre i systemet osv…
ret så kompliceret at implementere.
Som det fremgår af dette eksempel, findes der både flere dataoverførsler og endda en omdøbning af data. Først og fremmest er det værd at overveje følgende paradigme: Hvis man omdøber en fil uden at kontrollere om indholdet er det samme, er det så en valid dataoverførsel?
Et af de vigtigste formål med myndighedernes krav til dataintegritet er at man ikke u-opdaget kan manipulere data. Et indlysende sted at manipulere data (f.eks. ved at udskifte en fil med en anden) ville være under en omdøbning. Det giver således særdeles god mening at kontrollere at dataoverførslen fra log20200412143503 til TAG510A_LOG_20200412_143503 er sket korrekt, og at indholdet er kontrolleret til at være identisk. Denne kontrol skal naturligvis også ende i en valideret audit trail.
Dataoverførsel
Et andet ”smart sted” at ændre i sine data ville være i teknologiskiftet mellem det dedikerede netværk og det korporale netværk, og eftersom denne dataoverførsel typisk består af mere end én kopimekanisme, hvilket betyder at audit trail for denne dataoverførsel også er særdeles vigtig.
Det er naturligvis ikke alene frygt for manipulation af data der driver dette. Det er i realiteten mere væsentligt at man kan stole på sine data, og at man ved at data er læsbare. Selv med en marginal risiko for at data ikke kan læses, mister data en væsentlig andel af sin brugsværdi.
Man skal ligeledes huske at en dataoverførsel betyder at ”originalen” fjernes fra der hvor den lå tidligere. Hvis man laver en dataoverførsel, er det derfor vigtigt at kontrollere filen på den nye placering, op imod den originale fil, før man sletter den originale fil.
Backup
Genetablering af data er et andet sted hvor snyd vil være indlysende, og derfor under myndighedernes lup. Hvis man forestiller sig at man gerne ville have nogle data til at ”gå væk” og erstatte dem med andre data, vil en backup man manipulerer være næsten ”usynlig”, hvis man ikke har en metode til at validere overførslen fra maskine til backup og fra backup til maskine. Vigtigst er dog nok sammenligningen mellem den backup der er de oprindelige data, og de data man vil genetablere fra sin backup. Dette kan gøres f.eks. via audit trail dokumentation af at indholdet på backupmediet/drevet ikke er ændret, eller ved sammenligning af de 2 datasæt med et entydigt positivt resultat.
Cloud
”Cloud løsninger” betyder i realiteten blot at det ikke er ens egen organisations server dataserver, men en anden organisations. Både egne servere og ”cloud servere” kan stå i Indien eller Kina, og i princippet drives af de samme folk. Men taler man pludselig om eksterne leverandører, kommer der et nyt lag af kompleksitet ovenpå.
Hvis man forestiller sig at ens labdata stilles til rådighed fra et kontraktlaboratorie via en filoverførsels service (f.eks. en gammel svend af slagsen ”FTP” – som i øvrigt findes i en anbefalelsesværdig version af slagsen, kaldet SFTP – S som i ”Safe”), er det måske en god idé at undersøge hvem der kan læse data og at der er audit trail på hvem der tilgår disse (så der ikke er falske og manipulerbare data i omløb), samt at der ikke er mulighed for at lægge data tilbage.
Data ligger hos et kontaktlaboratorie. De vigtige resultater af de udførte klinikforsøg der afgør virksomhedens fremtid, ligger i disse data. Data bliver hentet fra laboratoriet, og er resultaterne rigtigt gode, på nær et enkelt sæt forsøgs data, der potentielt kunne så tvivl om ens produkt.
”Heldigvis” har ingen undersøgt den dataoverførsels service der bliver benyttet, hvorved data kan ”forbedres” og uploades til kontraktlaboratoriets server igen.
En ny download af de forbedrede data kan nu downloades dagen efter, endda med audit trail for den udførte download, og investor kan nu gøres glad (i det mindste til den rette sammenhæng bliver afsløret).
Her kan jeg lige give et ”real life” eksempel på risikoen man skal forholde sig til:
Konklusion
Implementering af valid dataoverførsel er ikke svært, blot man tænker sig om, og overvejer hvor risikoen (eller muligheden) for manipulation er til stede. Det vil være disse steder myndighederne interesserer sig for, og det bør vi som ansvarlige virksomheder også gøre. Dokumenterbar valid dataoverførsel øger desuden sandsynligheden for at data er læsbare betragteligt.
Utroværdige, ulæselige eller blot usikre data er værdiløse !
