Automatiseret import af dokumentleverancer (TMF’er)

Vores kunder modtager større og større dokumentationsmængder fra diverse underleverandører. Sammen har vi sat en delvis automatiseret import op, som sikrer at dokumentationen lander i kundens dokumenthåndteringssystem. Denne case er fra Life Science.

Baggrund

De dokumenter, der er tale om her i casen, er forskningsdokumentation.

Det er nemlig dokumentation af kliniske forsøg (kontrolleret afprøvning af medicin på mennesker). Kliniske forsøg gennemføres ofte af CROer (Clinical Research Organisations) i rollen som underleverandør til den farmaceutiske virksomhed, der skal have afprøvet sit præparat.

Dokumentationen, som bl.a. er fra læger, opsamler CROen i eget dokumenthåndteringssystem, og når forsøget er afsluttet, eksporteres dokumentationen som en samlet pakke og leveres til den farmaceutiske virksomhed. Pakken kaldes en Trial Master File (TMF). Pakkernes størrelse kan variere helt utroligt meget, men for dog at indikere en størrelsesorden kan vi sige, at mange har haft i omegnen af 30.000 dokumenter.

Vores kunde modtager sådanne pakker jævnligt og vores opgave er så, at få importeret dokumenterne til kundens eget dokumenthåndteringssystem, så automatiseret og nemt som muligt i en farmaceutisk virkelighed.

Dette er en case historie om det fine samarbejde, vi har med pågældende kunde, og om hvordan vi etablerede en metode og over tid har forbedret den.

Mmodel eller ej

Det ensartede i de forskellige leverancer er, at de alle er TMFer, og der er ret klare forventninger til hvad en sådan pakke TMF indeholder. Det er velbeskrevet i en model (DIAs referencemodel), og hvert type dokumentation har en entydig plads i modellen givet ved et såkaldt artifact number, og det er også givet af modellen hvilke metadata, dokumentet derudover bør beriges med.

Nu ville det være bekvemt, hvis både CROerne og vores kunde for det første brugte den omtalte model, og for det andet var enige om fortolkningen af den. Men sådan skulle det selvfølgelig ikke være.

Vores kunde har lagt sig tæt op ad den omtalte model med nogle lokale tilpasninger. Det er altså meget velbeskrevet, hvordan dokumenterne skal være, når de er kommet ind i kundens system. Men det leverede er meget forskelligt. Nogle CROer benytter modellen og har formået at eksportere metadata fra deres system til os, så vi næsten får det hele forærende, og blot skal tilpasse efter lokale forhold. Andre leverer en bunke rod, for at være helt ærlig. Og vi får alt imellem de to ekstremer.

Opgaven med at få dokumenterne ind i kundens system består således i at importere de leverede dokumenter under fuld farmaceutisk kontrol, men også i at identificere de centrale metadata på de leverede dokumenter. Det kalder vi klassifikation. Udgangspunktet er vidt forskelligt hver gang – fra medfølgende regneark, fra filstier og filnavne, og hvad der ellers måtte være givet – men resultatet er ensartet fra gang til gang.

Etablering

Vi valgte et migreringsværktøj, der er specialiseret i dokumentmigrering. Værktøjet hedder migration-center og er fra tyske fme AG. Det har mange år på bagen, er velgennemprøvet og kan leve op til de særlige krav den farmaceutiske sektor opererer under.

Migration-center består af en migration-center motor og et cockpit, hvorfra migrering/import styres. I den ene ende forbindes til kilden med en filscanner og i den anden ende forbindes til destinationen med en importer. Rigtigt mange af markedets standardsystemer er dækket out-of-the-box.

I dette tilfælde valgte vi en importer til Documentum, som er vores kundes teknologi og to skannere. Dokumenterne ligger jo på et filsystem til en start, så begge skannere kan læse filer i filsystemet. Den ene (filesystem scanner) er specialiseret i at læse de metadata, der er til rådighed i selve filsystemet (det er jo især filstier og filnavne) om hver fil. Den anden (csv scanner) er specialiseret i at læse metadata om hver fil fra regneark.

Udover at installere og opsætte værktøjet (indenfor kundens firewall) udviklede og validerede (testede) vi den proces, som vi nu følger ved hver eneste leverance. Processen blev beskrevet i en håndbog, som vi følger hver gang en ny TMF skal importeres.

Kunden har valgt, at vi skal udføre hver enkelt import, fordi de vil spare interne ressourcer. Men de kunne godt have valgt at træne en par folk i at gøre det selv og sige pænt farvel til os.

Processen

Hvordan værktøjet og processen virker – meget kort fortalt:

Datakilden skannes for dokumenter. I dette tilfælde skannes de relevante foldere på fildrevet, hvor vores TMF-pakke ligger. Al tilgængelig metadata for dokumenterne hentes ind fra kilden. Nu er dokumenter og metadata inde i migration-center databasen.

Opgaven består nu i, at de metadata, som vi har skaffet ved skanningen bearbejdes, så vi får de metadata, som kundens system kræver af os. Altså klassifikationsarbejdet beskrevet ovenfor i afsnittet om modellen.
I de fleste tilfælde er de oplysninger, vi har brug for, der. Det er et spørgsmål om at identificere dem og få dem trukket ud. Skal vi fx bruge Country, og det ikke er høfligt leveret til os i et regneark fra CROen, så må vi kigge i folderstien. Sædvanligvis kan vi konstatere, at der er en fin logik, hvor dokumenter fra et land er lagt i en folder med navn efter landet. Oplysningen er der altså – i folderstien. Øvelsen for os består i at opdage dette og dernæst udtrække den information, vi har brug for.
I eksemplet her skal vi altså bruge filstien, som er læst af vores skanner og derfor er til rådighed i migration-center databasen, og ud fra den udlede en Country værdi pr dokument. Vi sætter derfor en regel op i værktøjet, som laver den udledning – her ville vi konkret lave noget strengegymnastik, som er en blandt mange, mange muligheder, vi har for at bygge regler i værktøjet

Når reglerne, som vi skal bruge, er sat op kan vi simulere migreringen. Det tager ikke så lang tid, for det er kun metadata, der gennemregnes – dokumenter flyttes ikke. Så kan vi kigge på resultatet, og se om vi er glade. Vi kan også trække resultatet af simuleringen ud i regneark og få det kontrolleret af interne folk med forretningsviden. Vi fortsætter med at rette til og simulere, til vi er tilfredse. Når vi er tilfredse, har vi en konfiguration i migration-center, som passer lige præcis til dette datasæt.

Importen startes, og dokumenterne importeres.

Validering under GxP

Vi kom lidt let om ved test ovenfor. Der skal altid testes uanset branche, men dette afsnit kigger på hvordan vi lever op til kravene i den farmaceutiske sektor om validering under GxP.

I opstartsprojektet, hvor vi etablerede processerne og teknologien, kvalificerede vi migration-center. Vi tog udgangspunkt i, at det er et etableret produkt og at leverandøren fremlagde deres proces for udvikling og vedligehold af produktet. Vi besluttede at kvalificere vores afgrænsede brug af værktøjet – defineret ved håndbogen – og etablerede dels IQ men også en grundig OQ, der kom rundt i hjørnerne af vores måde at bruge værktøjet på ifølge håndbogen. Det datasæt vi brugte som eksempel i kvalifikationen blev importeret og kundens UAT kunne så via det importerede data teste værktøjet op mod URSen for en TMF-import.

Med værktøjet kvalificeret en gang for alle, kan valideringen af hver enkelt import nu koncentrere sig om datanære test. Vi har en næsten helt genbrugbar OQ, som gentages for hvert datasæt, og ligeledes har kunden en UAT, som er meget standard. Hver TMF-import er et projekt for sig med egen valideringsplan.

Så hvordan foregår så rent praktisk den datanære validering? Når vi er færdige med at lave reglerne til at bearbejde et datasæt, skal bearbejdningen af data som helhed valideres. Vi har udviklet regler mv i et udviklingsmiljø, men det gode er, at alle de regler mv, vi har gjort klar, kan pakkes sammen og eksporteres via en standardfunktion i værktøjet. Derpå kan vi importere dem i et valideringsmiljø, og gennemføre importen fra ende til anden (evt. på en repræsentativ delmængde af dokumenterne).

Når valideringen er overstået, kan vi igen benytte standardfunktionalitet i værktøjet til at importere reglerne til produktionsmiljøet, og så er vi klare til at køre importen.

Afslutning

De leverede pakker er strukturelt forskellig hver gang. Det betyder, at vi ikke bare kan trykke på en knap, og så importerer det sig selv. Men vi har nu haft så mange forskellige varianter, at der er mere og mere at genbruge af. Vi har automatiseret, generaliseret, systematiseret i et væk, og nu kører det virkeligt effektivt og godt. Vi har fået viden nok til selv at kunne lave klassifikationen af dokumenterne blot med sparring nu og da med en intern specialist. Valideringen var et stort arbejde de første par gange, men nu kører det ret smertefrit.

Så selvom det ikke et tryk på en knap, så er importen automatiseret så langt det overhovedet lader sig gøre. Alternativet, som benyttedes før vi fik dette op at køre, var manuelle uploads.

Vores erfaringer og bedste råd til at komme godt igennem en kontrolleret migrering, er samlet i vores Guide til dokumentmigrering.