Riskanalys och agil systemutveckling

• Beslut i projekt skall vara medvetna
• Beslut i projekt tas dagligen
• Beslut skall bygga på bästa möjliga underlag

Beslut tas för att nå ett mål. Vägen till målet kan vara omgiven av risker som kan störa möjligheten att uppnå förväntade mål. För att kunna göra en realistisk bedömning av hur svårt det är att nå målet används riskanalys som ett verktyg. Riskanalys bygger på att använda den kunskap man har till förfogande till att bedöma sannolikheten för störningar och ev. konsekvenser av dessa störningar.

I projekt är det oftast ett krav att man gör en riskanalys innan man påbörjar arbetet. Skulle riskerna bedömmas som stora kan det resultera i att projektet stoppas eller att målformuleringen ändras. Även delprojekt eller specifika egenskaper kan bli föremål för riskanalyser. Men ...oftast sker riskanalyser enbart vid projektstart, tyvärr, för under ett projekt ökar kunskapen kontinuerligt om dess risker och hur dessa kan förebyggas. En riskanalys som görs en tid efter projektstart kan peka åt ett helt annat håll än den ursprungliga och kvaliteten på förutsägelserna är troligen högre.

Agil systemutveckling bygger på en medvetenhet om att allt i en systemutvecklingsprocess inte kan förutses och därmed inte fullt specificeras inför genomförande. Det mesta, utom de övergripande målen, kan behöva förändras i arbetet. Besluten inom projekten kommer därmed att bli större och viktigare varför det också är viktigt att man har bästa och färskaste underlag för dessa beslut, inklusive en riskanalys som stöd.

Kontentan av ovanstående är att inför en beslutspunkt skall finnans en aktuell riskanalys som underlag för ett bra beslut. Att sammakalla till en riskanalysseans inför varje beslut är förmodligen ogörligt. Finns det däremot verktyg för att för att kontinuerligt samla in och värdera risker i form av sannolikhet och konsekvens skulle kvaliteten på del löpande besluten kunna öka.

Mitt mål är alltså att hitta eller skapa en process för löpande analys av risk så att man vid varje beslutstillfälle har bästa möjliga underlag.

Testdata för vård-IT

Jag har de senaste veckorna stött på frågeställningar om hur man skapar och arbetar med testdata för IT inom vården och sammanfattar här mina spaningar.

För tester av IT-system inom vården krävs, som för all test, relevanta testdata. Det enklaste sättet att få tillgång testdata är att använda produktionsdata från likvärdig miljö men det är något som sällan låter sig göras. Så fort det rör sig om någon form av känsligt data som t.ex. personuppgifter, patientdata eller annan information som omfattas av sekretess är det oftast olämpligt och i många fall olagligt att hantera data på det sätt som tester kräver. Personuppgiftslagen (PUL) och Patientdatalagen reglerar tydligt hur uppgifter får hanteras.

Hur löser man då lämpligen behovet av testdata. För lågnivåtester som enhetstester och liknande fungerar det ganska bra med att generera testdata för varje “enhet”. Antalet variabler och ”states” är oftast begränsade.

Vid större systemtester och integrationstester blir det hela mer komplext. Större mängder testdata med stor variation behövs. Dessutom behövs också testdata från olika system vid integrationstester, data som behöver gemensamma nycklar över systemgränser, ofta personnummer. Vid sådana tester används ofta “anonymiserade” produktionsdata där personnummer, kontonummer o.d. ersatts med ett fiktiva, namn och adressuppgifter tagits bort eller ersatts av slumpmässaga uppgifter. Övrigt information lämnas sedan orörd för att kunna fungera som testdata. Fiktiva person- eller kontonummer måste ha föreskriven struktur men om möjligt inte kollidera med verkliga nummer. Specifika personnummer bör bytas ut mot samma fiktiva i de system som skall integrationstestas.

Men...
Ovanstående hantering av testdata är inte oproblematiskt, hittills har anonymiseringen oftast ansetts som ett tillräckligt skydd av persondata men det kan vi inte räkna med i framtiden. Samkörning av läckta testdata mot publik information, Facebook eller Google kan framöver förmodligen koppla väldigt stor del av den anonymiserade informationen mot fysiska personer. Nämnda aktörer har i stor utsträckning kännedom när du varit på olika platser, t.ex. ett sjukhus, hur gammal du är, kanske har du sökt på symptom som stämmer med din sjukjournal m.m.

Anonymisering av personnummer och kontonummer är inte heller oproblematiskt, använder man en metod som inte är fullt slumpmässig utan att resultatet vid bytet av ett personnummer blir det samma vid upprepning är det troligt att man med begränsade datorresurser faktiskt kan spåra ursprungligt nummer.

För ett seriöst arbete med testdata inom vården bör följande finnas med:

1. Ett kryptografiskt “säkert” sätt att anonymisera nyckeldata t.ex. personnummer från de produktionsdata som kommer att användas. Detta gör att den personal som kommer i kontakt med testdata inte enkelt kan göra sökningar på fysiska personer.
2. Säkra processer för generering, distribution och lagring av testdata som inte riskerar att läcka produktionsdata.
3. Säkring av testmiljöer både logiskt och fysiskt så att testdata inte riskerar att lämna den avgränsade testmiljön.
4. Rutiner för att förstöra testdata på ett kontrollerat sätt efter genomförda tester.