På jeres egen server, med jeres egne nøgler

Det spørgsmål, ingen leverandør svarer klart på

«Kan I læse mine journaler?» De fleste kliniksystemer svarer med en politik: at de ikke gør det, at der er adgangskontrol, at medarbejdere er underlagt tavshedspligt. Det er sandsynligvis rigtigt. Det er også et løfte, og et løfte er noget andet end en umulighed.

Kører Anotera hos jer, er svaret et andet: nej, og det er ikke noget, vi har besluttet. Journalerne er krypteret med en nøgle pr. behandler, som bliver til på jeres maskine i det sekund, opsætningen kører. Den forlader den ikke. Vi kan ikke hente den, og vi kan ikke tvinges til at udlevere den.

Den anden halvdel af sætningen står med samme skriftstørrelse i opsætningen: mister I en nøgle, kan den behandlers journaler ikke læses igen. Heller ikke af os. Det er prisen, og den skal siges højt, før nogen siger ja — ikke i en fodnote bagefter.

Ét script, tolv minutter

I skal have en server med Docker, et domæne der peger på den, og port 80 og 443 åbne. Resten er ét script, der kan køres af en, der ikke arbejder med servere til daglig:

bash anotera-opsaet.sh --tjek     # er maskinen klar?
bash anotera-opsaet.sh            # sæt op

Det spørger om klinikkens navn, jeres domæne og hvem der skal have adgang. Så laver det nøglerne, skriver opsætningen, henter certifikatet og starter journal, booking og video. Til sidst står der én ting på skærmen, som I skal gøre inden I lukker vinduet: skrive nøglerne ned og dele dem ud personligt.

Scriptet tjekker DNS før det gør noget andet. Et certifikat, der ikke kan hentes, fejler nemlig på en måde, der ligner alt muligt andet — og så leder man det forkerte sted i en time.

Hele systemet, ikke en let udgave

Journal med kryptering pr. behandler. Kalender med træk-og-slip, konflikter og flere deltagere pr. aftale. Booking med identifikation, så den samme klient ikke bliver til to journaler. Venteliste, der laver en aflysning om til en samtale. Videomøde med optagelse, klienten selv skal sige ja til. Patientside, hvor klienten ser sine egne tider. Eksport af det hele, uden at spørge os om lov.

Det sidste er værd at læse to gange. En klinik, der ikke kan få sit journalmateriale med ud, kan ikke opsige sin leverandør uden at bryde sin egen opbevaringspligt. Eksporten ligger derfor bag samme knap som alt andet, og den virker uden at nogen skal godkende noget.

Fire ting, der ikke er selvbetjening

De her kræver noget, kun I kan skaffe, fordi de er aftaler i jeres navn — ikke i vores:

• Sikkerhedskopier. Scriptet sætter dem op, men I vælger, hvor kopien uden for maskinen skal ligge. En kopi på den samme disk beskytter mod en fejltagelse, ikke mod at serveren dør.
• SMS. Egen konto hos en gateway. Indtil da tæller systemet beskederne i stedet for at sende dem — og siger det på skærmen, så ingen tror, en påmindelse er på vej.
• Notatudkast. Egen aftale med en sprogmodel-leverandør. Vi slår det ikke til som standard: så ville udskrifter blive sendt et sted hen, uden at nogen havde sagt ja.
• Indberetning til «danmark». Jeres eget behandlernummer og jeres egen adgang. Systemet bygger indberetningerne færdige og lægger dem som kladder, indtil det er på plads.

Det er ikke mangler, vi har glemt at nævne. Det er forskellen på et system, der kører hos jer, og et der kører hos os: I ejer også aftalerne.

Hvad der endnu ikke er godt nok

Opsætningen er testet på en ren maskine og virker. Den er ikke testet på tyve forskellige serverudbydere, og den har ikke en opgraderingsvej, der kan køres uden at læse en vejledning. Skal I køre det selv i dag, skal I have nogen, der tør åbne en terminal.

Kører I hos os i stedet, tager vi den del. Forskellen i fortrolighed er reel: så har vi nøglerne, og så er svaret på spørgsmålet ovenfor igen et løfte i stedet for en umulighed. Begge dele er forsvarlige. De er bare ikke det samme, og vi vil hellere sige det end lade være.