I helseprosjekter er kravene til sikkerhet og sporbarhet ikke noe du legger på til slutt. De bestemmer arkitekturen.

Et integrasjonsprosjekt i en vanlig bedrift starter ofte med at to systemer skal snakke sammen, og så finner man ut av detaljene underveis. Det er en rimelig arbeidsform når verste utfall er en feil faktura. Når dataene er helseopplysninger, endres regnestykket: verste utfall er at opplysninger om en pasient havner hos noen som ikke skulle ha dem, og det er ikke en feil du retter i neste sprint.

Avklar behandlingsgrunnlaget først

Før noe teknisk arbeid begynner, må det være avklart hvem som er behandlingsansvarlig, hvem som er databehandler, hva det rettslige grunnlaget for behandlingen er, og hvor lenge opplysningene skal lagres. Dette er ikke en formalitet du kan hente inn senere — svarene avgjør hvilke data du har lov til å hente, hvor de kan ligge, og hva som må slettes når.

Konkret betyr det at databehandleravtalen og risikovurderingen bør være på plass, eller i det minste under arbeid med kjent retning, før du designer datamodellen. Får du beskjed halvveis om at fødselsnummer ikke kan lagres i løsningen, er det en arkitekturendring, ikke en liten justering.

Hent minst mulig

Prinsippet om dataminimering er både et juridisk krav og god teknisk praksis. Spør konkret: hvilke felter trenger denne funksjonen faktisk? Kan pasienten identifiseres med en intern nøkkel i stedet for fødselsnummer? Kan du lagre et beregnet svar i stedet for rådataene det ble regnet ut fra?

Hver kolonne du ikke henter, er en kolonne du ikke må sikre, revidere, slette og forklare i en risikovurdering. Det er den billigste sikkerhetsjobben som finnes.

Bygg sporbarhet inn fra start

Kravet er at det skal være mulig å svare på hvem som har sett hvilke opplysninger, når. Det betyr logging av oppslag, ikke bare av endringer — et vanlig applikasjonslogg-oppsett fanger ofte det siste og ikke det første.

Praktiske konsekvenser: loggen må inneholde identiteten til den som leste, ikke bare tjenestekontoen integrasjonen bruker. Den må være lagret slik at den ikke kan endres i etterkant. Og den må selv være tilgangsstyrt, for den er en oversikt over hvem som har vært i kontakt med helseapparatet — altså like sensitiv som det den beskytter. Å ettermontere dette i en løsning som er i drift er dyrt; å ta det med i første design koster nesten ingenting.

Tilgangsstyring er en modelleringsoppgave

I de fleste systemer er tilgang et spørsmål om rolle: en saksbehandler ser saker, en leder ser rapporter. I helse er tilgang knyttet til relasjon. Har denne behandleren et tjenstlig behov for opplysninger om denne pasienten, nå? Svaret endrer seg gjennom et døgn, og det kan ikke uttrykkes med en statisk rolleliste.

Konsekvensen for arkitekturen er at tilgangsbeslutningen må tas per oppslag, med kontekst, og at den må kunne begrunnes i etterkant. Det betyr at du ikke kan filtrere i grensesnittet og stole på det. Filteret må ligge så nær dataene som mulig, slik at et API-kall utenfor grensesnittet ikke omgår det. Dette er en av få steder der jeg konsekvent anbefaler å legge regelen i databaselaget i tillegg til i applikasjonen, selv om det betyr at den vedlikeholdes på to steder.

Idempotens og gjenkjøring

Meldingsbaserte integrasjoner leverer av og til samme melding to ganger. Nettverket falt, mottakeren kvitterte ikke, avsenderen prøvde igjen. I et fakturasystem er dobbel behandling irriterende. I et pasientforløp kan det bety en dublett i journalen, og det er en avvikssak.

Løsningen er at hver melding har en identifikator fra avsender, og at mottakeren husker hvilke identifikatorer den har behandlet:

-- Tabellen som gjør gjenkjøring trygg
CREATE TABLE mottatt_melding (
    melding_id   uniqueidentifier NOT NULL PRIMARY KEY,
    mottatt      datetime2        NOT NULL,
    resultat     varchar(20)      NOT NULL
);

-- Ved mottak: avvis duplikat før behandling,
-- i samme transaksjon som selve behandlingen.

Det avgjørende er at innsettingen i denne tabellen og selve behandlingen skjer i én transaksjon. Gjør du det i to steg, finnes det et tidsvindu der meldingen er behandlet men ikke registrert, og da er du tilbake til utgangspunktet. Dette er billig å bygge inn fra start og ubehagelig å ettermontere i en løsning som allerede har dubletter i produksjon.

Feilhåndtering som noen faktisk ser

En integrasjon som feiler stille, er verre enn en som ikke finnes, fordi organisasjonen begynner å stole på den. Regn derfor med å bygge tre ting utover selve dataflyten: en kø for meldinger som ikke kunne behandles, en måte å se hva som ligger i den, og en måte å kjøre dem om igjen etter at årsaken er rettet.

Og noe som ofte glemmes: feilmeldinger og køinnhold kan inneholde helseopplysninger. Da kan de ikke sendes til en ekstern feilrapporteringstjeneste, ikke stå i en logg alle utviklere leser, og ikke ligge i en e-postvarsling. Varselet må si at melding nummer så og så feilet med en gitt feilkode — ikke hva den inneholdt.

Regn med at testdata er et prosjekt i seg selv

Du får ikke kopiere produksjonsdata ned i testmiljøet. Det betyr at noen må lage syntetiske pasienter, syntetiske forløp og syntetiske avvik som er realistiske nok til å avdekke feil. Dette undervurderes nesten alltid i estimatet, og det er ofte det som avgjør om integrasjonen faktisk er testet eller bare kompilert.

Standarder sparer deg for arbeid senere

Norsk helsesektor har etablerte standarder og felleskomponenter for meldingsutveksling og identitet. Å bruke dem er tregere i starten enn å definere et eget JSON-format, og raskere i alt som kommer etterpå: neste integrasjon, neste leverandør, neste revisjon. Sjekk hva mottakersystemet faktisk støtter, i den versjonen som er i drift hos dem — ikke hva dokumentasjonen beskriver som mulig.

Sletting er en funksjon, ikke en opprydding

Lagringstiden følger av behandlingsgrunnlaget, og den gjelder også kopiene: mellomlagre, køer, backup, logger og eventuelle rapportdatabaser. Dersom løsningen ikke har en mekanisme for å slette, har du i praksis bestemt at oppbevaringstiden er evig, uansett hva avtalen sier.

Praktisk råd: skriv ned for hver datatype hvor den havner, og hvor lenge den skal ligge der, før du bygger. Listen blir lengre enn du tror — den samme opplysningen finnes ofte i fem systemer etter at en integrasjon er satt i drift. Det er mye enklere å bygge sletting inn i en flyt som er designet for det, enn å finne igjen kopiene etterpå.

Arbeidsformen er annerledes

Leveransetempoet settes ikke bare av utvikling. Det settes av tilgangsbestillinger, risikovurderinger, testmiljøer som deles med andre prosjekter, og klinikere som har pasienter å behandle og derfor ikke kan stille på et møte førstkommende tirsdag. Planlegg for det, så blir prosjektet forutsigbart. Planlegg som om det var et vanlig systemprosjekt, og du bruker halve tiden på å forklare forsinkelser.

Hva dette betyr for estimatet

Summen av det over er at et integrasjonsprosjekt i helse har en betydelig andel arbeid som ikke er funksjonalitet: tilgangsmodell, sporbarhet, idempotens, feilkø, testdata, sletting og dokumentasjon. Erfaringsmessig er det en stor nok andel at et estimat basert på funksjonaliteten alene blir feil med god margin.

Det er heller ikke sløsing. Det er de samme egenskapene som gjør at løsningen kan revideres, overtas av noen andre og stå i drift i ti år. Men det må være med i planen fra begynnelsen, ikke oppdages i uke seks.