Pas på ikke at blive fanget i skyen

/i /af

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
… 
63It must be possible in the system unambiguously to distinguish my data from other companies’ data.
64It must be possible to bulk extract all my data in a validated manner, including metadata and audit trail, into a reusable structure.
65The data format must be readable by commercially available application, or a reader must be delivered along with extract data.
66It 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.

OH NO!! Grumpy cat in Covid Mask

Karen Ginsbury’s Quality Blog #3

/i /af

This is 2020 Blog #3.  I made it my business to reread the previous one (ok the truth – I am overwriting – the mother of all bad practices) #2.  Written in June, I suppose I was Covid punch drunk and focused on business continuity / disaster recovery plans and shortages.  By now we have sort of settled into life with Covid – I don’t leave the house without a face mask… unless I forget.  I have a CAPA on that too – masks in every bag, briefcase, pocket…

In earlier blogs I had said we need to define the purpose of a quality system.  GMPs are NOT a quality system and never were intended to be one.  They are a series of requirements.  If quality is “Meeting all the requirements all the time” we need to do a better job of defining requirements.

I have done a little better on defining what a foundational quality system is – with the help of ISO9001:2015…another of my grumpy cats.

The ISO standard makes the crucial point under the section Risk Based Thinking:
“One of the key purposes of a quality management system is to act as a preventive tool”

and this is where the GMPs, industry and regulators have colluded over the years to ensure failure.
What is this collusion?  It is that nasty little part of the GMPS which accepts deviations as an essential part of what we do.

It is true the EU GMPs advise us to avoid deviations as much as possible, unlike 21CFR part 100 which with no such qualifying statement says “Any deviation from the written procedures shall be recorded and justified” or in other words “there will always be deviations, let’s accept that as an unavoidable fact of life and just document them and JUSTIFY them!!!!

The GMPs MUST be revised and must remove / replace this statement.  #PREVENT is my new movement to switch pharma from reactive to proactive mode.  Deviations should not be accepted as an unavoidable fact of life.  Risk based thinking and control strategies are about analyzing and MANAGING PROCESSES.  Any process is amenable to this – as long as we map it out and spend time on # PLAN – developing a robust process where we didn’t say “ah it’ll be ok – and if there are deviations – well the GMP allow us to mop up.”  Then with the wisdom of King Solomon, those incredibly smart QA Directors write a “risk assessment” and release the DEVIATING product.  Human error, so let it happen again… and again… and again…

Once a deviation has happened and you are trying to justify releasing NON-CONFORMING product, this is NOT RISK BASED THINKING.  It is RISK-TAKING which is a completely different kettle of fish (in this case stinking fish)!  At the very least can regulators (calling out PIC/s here as I believe it started with them) STOP asking for a risk assessment which should be proactive and #PREVENT and call it what it is – a product impact assessment.  Gosh – even for me… what a RANT!  (Karen stop shouting – all those capital letters).  Of course that’s the beauty of a blog – you can run with it and let it do whatever it wants.

Some conclusions then:

One of the primary purposes of a QMS is to #PREVENT bad things from happening, by using risk based thinking, by #PLAN, DO, CHECK, ACT = control strategy per process.

A MATURE quality system #PREVENTs!

GMP conformance CAN be integrated and the system still be effective but we should be aware that releasing ANY batch with an associated deviation is a sad and essentially bad thing to do.  Sometimes, in order to avoid a genuine shortage which is a greater evil for the patient, we may HAVE to release a non-conforming batch.  That may on rare occasions be the right thing to do (they are not currently rare).  NEVER should we deceive ourselves into believing that this is the preferred or default state.  We do it only after the system failed to #PREVENT.

What other stumbling blocks have industry AND regulator placed in the way of an effective and foundational quality system?

In the previous blog I included two updates:

  • ICH Q12: Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management
  • PIC/s draft guidance: How to Evaluate / Demonstrate the Effectiveness of a Pharmaceutical Quality System in relation to Risk-based Change Management

These documents, which apparently are much needed, are nevertheless new and additional hurdles and therefore stumbling blocks for industry.  FDA has been talking of a vision of an agile manufacturing organization – can we ever be agile if implementing changes requires ICHQ12 and the PIC/s draft guidance?  I mean how many changes have you had to make in your QMS as a result of Covid.  Plexiglass barriers to enforce distancing in offices and manufacturing and laboratory areas is just one part of it?  Masks, staggered working hours, other?  Did that go through the change control process and how long did it take and how well was it documented and controlled?  I hope it was fast!

My vision for 2020 was to implement P-D-C-A for myself.

Every action that is taken during 2020 and thereafter, will be considered and planned.  (P-D-C-A) Implementation will be according to what was planned OR, if what was planned turns out not to be the requirements, then the requirements will be officially changed, people who need to know will be notified and the action will be planned all over again prior to implementation.

As of August, we (my husband and I and my mother) had to move out of our homes (Plan: we sold them and bought in another city), and as our new places weren’t ready, we had to rent a furnished place.  We are all together for now, because we are a “Covid Bubble group” – so all the careful planning which left several spare months for completion of our project – failed!  We did move, but are rather stuck living out of suitcases with 95% of our belongings in storage.  But we are ok and well as I hope all of you reading this are too.  I couldn’t come to Denmark now, when I was supposed to be there – more Covid fallout.  I pray that by March this will be behind us – I suspect it won’t be totally.  I also pray that the people I know and those each of you know who are currently battling Covid, will make it through.  Those of us who are healthy are blessed – whatever the restrictions.  Let us acknowledge it and in appreciation do a kind deed for a neighbour or friend, or phone someone who lives alone.  People are soooo lonely.

I hope to see you all very soon and send you my very best wishes.

# PREVENT – WEAR YOUR MASK WHENEVER YOU GO OUT – please… and stay safe.

Karen