I en hälsotjänst är datasäkerhet inte en funktion som läggs till på slutet, utan en utgångspunkt som strukturen byggs kring. I det här inlägget beskriver jag för den tekniskt nyfikna läsaren hur Treat är byggt: var uppgifterna finns, hur de är krypterade, vem som kommer åt dem och vad som händer om något går fel. Jag räknar inte upp certifikat; jag beskriver det som är byggt. Den bindande beskrivningen finns i vår dataskyddsbeskrivning.
Jag anslöt mig till Treat i augusti 2026, samma månad som läkaren Antti Mauno. Onni Hakala och Sami Marttinen hade börjat bygga Treat i april, och Henri Heliö kom med i juni. I augusti blev Treat också ett patientdatasystem i klass B i ASTORI-registret. Det här inlägget beskriver arkitekturen i det skedet av utvecklingen.
Var uppgifterna finns
Treat-applikationen körs i Google Cloud i Finland, i regionen europe-north1, och projektet är avgränsat med Assured Workloads EU Data Boundary. Vi använder Cloud Run, Cloud SQL (PostgreSQL), Cloud Storage, Secret Manager, KMS och Vertex AI. Alla patientsamtal, ärendeuppgifter och användarkonton finns här.
Cloudflare betjänar enbart marknadsföringssidan treat.health. Den hanterar aldrig patientsamtal, ärendeuppgifter eller användarkontonas uppgifter. Personuppgifterna stannar inom EES.
Kryptering i vila och under överföring
Databasen, objektlagringen och hemligheterna krypteras med kundhanterade KMS-nycklar i regionen europe-north1. Skillnaden mot molntjänstens standardkryptering ligger i kontrollen: nycklarnas livscykel, rotation och åtkomsträttigheter definieras och loggas av oss, i stället för att vara plattformens förval.
Under överföring kräver varje ändpunkt TLS 1.2 eller nyare, och databasen accepterar för närvarande bara krypterade anslutningar.
Minsta möjliga behörighet, inga delade inloggningar
Åtkomsträttigheterna till produktionsmiljön är begränsade med Googles IAM per tjänstekonto. Varje tjänst har sin egen identitet och bara de rättigheter som dess uppgift kräver. Det finns inga delade inloggningsuppgifter, och användningen loggas.
I praktiken betyder det tre saker:
- Varje tjänst har bara de rättigheter som dess uppgift kräver, vilket begränsar följderna om en enskild komponent komprometteras.
- Varje åtkomst kan spåras till en viss identitet, inte till "administrationen".
- Att utöka rättigheter är en medveten, loggad ändring.
Identifiering
Patienterna identifierar sig starkt via den nordiska identifieringsförmedlaren Idura: med finländska nätbankskoder och Mobilcertifikat, svenskt BankID och Freja ID, norskt BankID och Vipps eller danskt MitID. Vi kräver FTN:s tillitsnivå väsentlig (substantial). Treat får aldrig dina nätbankskoder, din PIN-kod eller dina biometriska uppgifter, bara namn, nationell identifieringskod och en bestående identifierare.
I applikationen stöds nyckelbaserad inloggning (passkey), och lösenord skyddas med hashalgoritmen Argon2.
Loggar utan känsligt innehåll
Tjänsteloggar är nödvändiga för felsökning och säkerhetsövervakning, men patientuppgifter får inte läcka in i dem. Därför tas personbeteckningen och de kliniska fritextfälten bort ur applikationsloggarna redan innan de skrivs. Kvar i loggarna finns IP-adress, tidsstämplar för förfrågningar och webbläsarens uppgifter.
Loggarna sparas som standard i 90 dygn; längre bara för en namngiven säkerhetsutredning.
Säkerhetskopior
Databasen säkerhetskopieras med återställning till en viss tidpunkt (point-in-time recovery), det vill säga tillståndet kan återställas till ett givet ögonblick och inte bara till den senaste fullständiga kopian. Säkerhetskopiorna krypteras med samma KMS-nycklar som produktionsdata och sparas upp till de lagstadgade gränserna. En säkerhetskopia som vore sämre skyddad än originalet skulle vara systemets svagaste punkt.
AI inom samma avgränsning
AI:n i symtomkartläggningen är Googles Vertex AI (Gemini) i EU (eu.rep.googleapis.com), inte den Gemini-tjänst som riktar sig till konsumenter. Cachning av prompter är avstängd, och anropen autentiseras med ett tjänstekonto. Dina uppgifter används aldrig för att träna AI-modeller; för att utveckla tjänsten används bara anonymiserade uppgifter. Vi har ansökt om undantag från Googles loggning för missbruksövervakning; tills det beviljats utgår vi inte från full nollagring för anropen och markerar detta tydligt i våra interna loggar.
AI:n ställer bara strukturerade följdfrågor och sammanställer en sammanfattning. Den ställer inga diagnoser, fattar inga vårdbeslut och bedömer inte brådska. Varje kliniskt beslut fattas av en legitimerad läkare.
Människor och avtal
Tekniken räcker inte om människornas skyldigheter saknas. Varje anställnings- och underleverantörsavtal innehåller ett sekretessåtagande, och yrkesutbildade personer inom hälso- och sjukvården är dessutom bundna av lagen om yrkesutbildade personer inom hälso- och sjukvården (559/1994, 17 §). När vi lägger till eller byter ett personuppgiftsbiträde uppdaterar vi förteckningen i dataskyddsbeskrivningen innan det nya biträdet börjar.
Om något händer
Ingen kan lova att en personuppgiftsincident aldrig inträffar. Därför är också processen definierad: vi anmäler en incident till dataombudsmannen inom 72 timmar och underrättar berörda användare utan onödigt dröjsmål när GDPR:s anmälningströskel överskrids.
Varför jag berättar det här
Du behöver inte förstå KMS-nycklar för att använda Treat. Men om du vill veta hur dina uppgifter skyddas ska svaret vara konkret, inte svävande. Det här inlägget är en översikt; de exakta åtagandena finns i dataskyddsbeskrivningen: https://treat.health/sv/dataskyddsbeskrivning/