Medical diagnostic laboratory. Samples of the material for testing in test tubes.

Case: Import af en dokumentleverance (en TMF)

En leverandør afleverer en større dokumentationsmængde, og nu skal det ind i modtagerens dokumenthåndteringssystem. Hvordan? Denne case er fra life science.

·

Baggrund

Inden ny medicin godkendes, afprøves den på mennesker i såkaldt kliniske forsøg. Ofte gennemføres denne afprøvning af CROer – clinical research organisations – på vegne af den farmaceutiske virksomhed. Leverancen fra CROen indeholder en frygteligt masse dokumentation for det gennemførte forsøg. Det kaldes en TMF.

Vi har altså en leverandør, hvis leverance blandt andet består en stor dokumentationspakke. Det genkender en dokumentationsansvarlig på tværs af brancher.

I denne konkrete case modtager vores kunde med et antal af sådanne leverancer årligt. Processen er, at CROen laver en eksport fra eget system, som overdrages i sin helhed til vores kunde. Det overdrages på et ftp-site, der er egnet og dedikeret til formålet.

Det er der vi kommer ind i billedet. Opgaven vi løser er, at løfte dokumentationen ind i kundens dokumenthåndteringssystem.

Udfordringen

Der var et par særlige forhold. Det ene væsentlige er, at der er forskellige CROer, der leverer i forskellige formater med forskellige kvaliteter af data. Det betyder at vi kan ikke tage en struktur eller et format som givet – vi skal kunne tilpasse os den konkrete leverance. Desuden skal kundens specialister skal kunne tilføje ekstra metadata – helst hvor muligt i form af regler.

Det andet særlige forhold er at det er en farmaceutisk virksomhed. Det stiller særlige krav til at vores måde at arbejde og dokumentere på. Men bortset fra afsnittet nedenfor med overskrift GxP ville vi nu nok have valgt at gøre præcis det sammen i en anden branche, hvor udfordringen var den samme.

Løsningen

Det er egentlig enkelt. Vi valgte et værktøj, der kan hjælpe os og etablerede en proces, som vi dokumenterede som en håndbog, vi nu følger. Så gennemprøvede vi vores process og værktøj – i dette tilfælde naturligvis efter de krav, der stilles til den slags i den farmaceutiske sektor – og frigav det. (Se afsnittet om GxP nedenfor). Nu bruger vi det så hver gang en ny TMF skal importeres. Kunden har valgt at vi udfører hver enkelt import af ressourcemæssige årsager, men de kunne godt have valgt at træne en par folk i at gøre det og sige tak for hjælpen og pænt farvel til os. 

Vi valgte et migreringsværktøj, der er specialiseret i dokumentmigrering. Migrering af struktureret data og dokumenter er ikke den samme udfordring – se fx artiklen Hvorfor er dokumentmigrering komplekst? – og et datamigreringsværktøj er derfor ikke opgaven voksen. 

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 en migrering er der jo en kilde og en destination og man kan derfor tilkøbe såkaldte migration paths, som er stien hvorfra og hvortil man migrerer. En migration-path består af en scanner, som kan forstå kildesystemet, og en importer, som kan forstå modtagesystemet. Rigtigt mange af markedets standardsystemer er dækket out-of-the-box . I dette tilfælde var det fra et filsystem til Documentum, så det var den path vi tilkøbte. 

Processen

Således fungerer værktøjet og processen – meget kort fortalt.

Datakilden skannes for dokumenter – i dette tilfælde de udpegede foldere på et fildrev. Al tilgængelig metadata for dokumenterne hentes ind fra kilden – i dette tilfælde kan det fx være et regneark med metadata eksporteret fra CROens system eller et XML dump eller blot den information, der ligger i en foldersti – hvad CROen nu engang kan levere.

Nu er dokumenter og metadata inde i migration-center, som i øvrigt er installeret indenfor vores kundes netværk.

Bearbejdningen af de skannede dokumenter går ud på at de metadata, som vi har skaffet ved skanningen bearbejdes, så vi får de metadata, som kundens system kræver.

Der er vi afhængige af, at kunne etablere nogle regler. I et konkret eksempel skal vi fx finde Country et sted i en folderstien til filen. Andre gange leveres fx metadata fra kundens system med Country angivet, men da måske efter en anden standard, end den kunden bruger. Der er altid noget at gøre for en husmor…

I alt fald sættes reglerne op, og så simulerer vi migreringen. Det tager ikke så lang tid, for det er kun metadata, der gennemregnes – dokumenter skal ikke flyttes. Så kan vi kigge på resultatet, og se om vi er glade.

Men vi kan også få lidt mere hjælp af værktøjet. De centrale metadatasregler i sponsors system, kan importeres / sættes op i migration-center, og i så fald kan migration-center udpege de værdier som forbryder sig mod de regler. Det er en stor hjælp.

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.

Test - GxP

Vi kom lidt let om ved test ovenfor. Hvordan testen her skal foregå, er stærkt afhængig af situationen. Her arbejder vi i et life science miljø hvor kravene er høje. 

Afslutningen på bearbejdningen er en konfiguration af og i migration-center som passer til datasættet. Den konfiguration kan i sin helhed flyttes mellem miljøer, den kan gemmes til senere brug osv. Det gøres via cockpittet i migration-center. 

Vi starter i testmiljøet med en kopi af en repræsentativ delmængde af (eller alle) dokumenterne i datakilden. Vi laver en migrerings-specifikation, som beskriver de mapninger mm, som vi vil konfigurere. Vi kommer til at iterere over specifikation og konfiguration, men når begge dele er færdige, stater vi importen. Den import vi nu laver i testmiljøet, kan vi validere. Når vi har valideret importen ved vi, at værktøjet tager dokumenter og data fra kilden og afleverer dem i modtagesystemet præcis, som vi ønsker det.

Konfigurationen i migration-center kan eksporteres som én fil igennem en standardfunktion i migration-center og derfra importeres i produktionsmiljøet.

I opstartsprojektet kvalificerede vi migration-center – vi lavede en IQ og en OQ og kunden en UAT.

Nu for hver TMF laver vi en OQ og kunden en UAT i valideringsmiljøet og igen i produktionsmiljøet. Det foregår efter samme skabelon hver gang og er derfor ikke noget stort arbejde.