Pas på ikke at blive fanget i skyen
Jeg arbejder som konsulent for en række medicinalvirksomheder, så det er på denne baggrund jeg her udtaler mig her.
Ud med data (i cloud)
Det virker som om trenden er, at store dele af virksomhedernes IT-systemer er ved at blive flyttet ud i skyen. Fordelene er mange, og heldigvis er langt de fleste virksomheder også opmærksomme på de udfordringer, der er i forhold til at lægge ting i skyen: Dataintegritet, procedurer for systemets brug, non-disclosure, backup, valideret status (eller ’validerbarhed’), Service Level Agreements, o.s.v..
Indrømmet, så er mange af opgaverne med at lægge ting ud i skyerne komplicerede, fordi udbuddet af de enkelte cloudydelser er stort og servicen og leverandørernes troværdighed er generelt lige så usammenlignelig som to mobilabonnementer. Samtidig er det at sætte krav til en cloud service et nyt område for mange medicinalvirksomheder, og man misser derfor let et krav eller to. Det kan endda være nogle af de vigtige krav, som enten går ud over compliance, eller ud over driften.
Jeg vil lige slå et slag for et par af de krav som ofte overses i forbindelse med cloudydelser.
Livscyklus
En af de emner der ofte omtales i nye guidelines, er livscyklus. Ethvert system fødes, valideres, gennemgår en lang række af vedligeholdende aktioner for at bibeholde den validerede status, hvorefter de til sidst nedlægges efter mange års tro tjeneste.
Denne livscyklus skal jo nødvendigvis også være gældende selvom et givent system befinder sig i skyen.
Etableringen af et system i skyen er typisk ret let, idet systemet som oftest eksisterer på forhånd. Leverandørerne har også typisk en brugermanual, eller vejledninger så det er let at etablere en procedure for systemet (tænk f.eks. på Microsoft, Google og Amazon). Fakta er at man – selv som stor medicinalvirksomhed – kan have svært ved at få indflydelse på leverandørens serviceaftale med deres underleverandører
Det bliver lidt mere kompliceret når man skal sikre dataintegriteten, og bl.a. diskutere backupløsning med leverandøren (vi har jo f.eks. Recovery Point Objective, Recovery Time Objective samt kravet om en dokumenteret test af re-store at skulle bede om). Leverandøren har som oftest enten en (typisk temmelig non-GxP) IT-afdeling der leverer denne service, eller IT-delen er måske baseret på ydelser de køber hos en underleverandør (f.eks. hosting, dataopbevaring, backup o.l.). Man ender under alle omstændigheder hurtigt ud i en diskussion om hvor ens data ligger, eller hvem der har adgang til dem, og om adgangen til systemer og data er dokumenteret på alle niveauer (både til systemet og i den applikation man benytter).
Det kan også være at man er nødsaget til selv at udføre en validering af systemet, eller at systemet (for at dække mere alment brugbare funktioner dedikeret andre brancher end netop medicinalvirksomhed) i praksis ikke helt kan opfylde en medicinalvirksomheds forventninger til dataintegritet.
Alle disse udfordringer er jo til at komme ud over, via velformulerede kravsspecifikationer, gode velskrevne procedurer, lidt manuelt valideringsarbejde og en god aftale om de serviceydelser der er inkluderet i leverancen.
Hvis ens cloud leverandør benytter en underleverandør til nogle af delydelserne, skal man lige være opmærksom på at nogle af disse underleverandører kan være ganske store. Det kan være særdeles svært at få lov til at udføre en audit hos en gigantvirksomhed af en underleverandør desuden være yderst sjældent at man kan få mulighed for at kontrollere om leverandørens hhv. om underleverandørens interne procedurer overholdes. Nogle gange er der mange niveauer af serviceaftaler ovenpå hinanden, og disse er endvidere skrevet i et juristsprog ingen forstår, så det kan være ganske komplekst. Denne risiko er stor, og derfor også værd at tage stilling til.
Leverandørerne har også gerne en stor opfindsomhed når det kommer til nye funktioner, som lægges på systemet uden at man ved det, og uden der er alt for skarp ændringskontrol. Dette gør vedligehold af det validerede stade, og her under ændringsstyring noget besværligt, men man kan dog som regel aktivt overvåge de versioner systemet har, og lure når der sker ændringer.
Så kommer vi til det sidste element i livscyklus, nemlig nedlæggelsen af systemet. Et cloudsystem ”nedlægges” måske ikke i praksis, fordi leverandøren havde tænkt sig at fortsætte med at levere systemet til andre virksomheder, men for den virksomhed som køber ydelsen, er behovet måske forsvundet, og man ønsker at ”nedlægge systemet” ved at stoppe samarbejdet.
Huskede vi det hele?
MEN så er det her man for alvor skal stå sin prøve. Jeg har netop været udsat for et cloudbaseret dokumentstyringssystem, hvor man godt kunne downloade sine dokumenter enkeltvis, men det var ikke muligt på en struktureret måde at downloade alle dokumenter med tilhørende metadata. Ydermere ville leverandøren med henvisning til at det kørte systemet som et GxP system ikke slette data, metadata og audit trail fra systemet, og give os dokumentation herfor. Leverandøren kunne tilbyde at data blev obsoleted (markeret som slettede) med tiden, men sletning kunne de ikke garantere.
Jeg gætter på at data i leverandørens database ikke var struktureret på en måde så man kunne relatere alle sine data til en specifik kunde. Dette vil gøre at hvis man sletter en specifik kundes data, risikerer man også at slette/påvirke andre kunders data.
Enden på historien blev i dette tilfælde at man skal bibeholde leverandøren og betale for et fortsat samarbejde, backup og service for sine data indtil dommedag, eller i det mindste det tidspunkt hvor man finder det sikkert at blot ignorere de findes. Man indgik en betalingsmæssig kompromisløsning med leverandøren, men kommer trods alt over de næste mange år til at betale et substantielt beløb.
| Req. # | Cloud requirements |
| … | |
| 63 | It must be possible in the system unambiguously to distinguish my data from other companies’ data. |
| 64 | It must be possible to bulk extract all my data in a validated manner, including metadata and audit trail, into a reusable structure. |
| 65 | The data format must be readable by commercially available application, or a reader must be delivered along with extract data. |
| 66 | It must be possible to delete my data entirely from the system, including a documented audit trail for the deletion of the data. |
| … |
Figur Eksempel på krav til et cloudsystem
Hvis vi lige holder fast i den ovenfor beskrevne situation, er det ikke kun ved nedlæggelse af data at sletning/udlevering kan have relevans. Det kunne være at man en dag ønskede at skifte til en anden cloudleverandør, at den cloudleverandør man benytter pludselig besluttede at ændre forretningsområde og derved nedlægge systemet, eller at ens cloudleverandør blev ramt af opkøb, konkurs eller lignende. I alle disse situationer ønsker man faktisk at få sine data udleveret på en struktureret måde, incl. metadata, samt dokumentation for den validerede dataoverførsel, til en server efter eget valg.
Mange af de data der bliver produceret indenfor medicinalbranchen, har en levetid på +10 år. En væsentlig del af de laboratoriedata der produceres, har en levetid på +20 år.
Prøv at huske 20 år tilbage, og tænk på de IT-systemer man brugte dengang – Windows 98 på en DOS platform eller Windows NT, WordPerfect, SAP i et grønt monokromt interface der emulerede de gamle amberskærme fra de første PC’eres tid, og IBM Dokumentum i sin mest rå form. Hvordan ser verdenen ud om 20 år, og kan man til den tid få udleveret sine 20 år gamle data, i et læsbart format?
Summa summarum! Man skal tænke hele livscyklus ind i sine krav, og ligesom med det meste andet i livet, sørge for at der er en ordentlig og pæn exitstrategi – Det gælder også for cloudsystemer.
