HIPAA, GDPR eller HDS? Efterlevnadsguide för vårdappar

"HIPAA-certifierad" existerar inte

Många byråer marknadsför sig som "HIPAA-certifierade" eller "HDS-certifierade". Ingen av dem innehar faktiskt en sådan certifiering, eftersom det inte finns något certifieringsprogram för mjukvarubyråer, varken i USA eller Frankrike. HIPAA är en lag, inte en utmärkelse. Det finns inget prov att klara, inget certifikat att rama in, ingen myndighet som stämplar en app som "HIPAA-kompatibel".

Det som istället finns är juridiska skyldigheter enligt HIPAA Security Rule, som tillämpas i efterhand av den amerikanska myndigheten HHS Office for Civil Rights, oftast utlöst av en anmäld dataintrång. Efterlevnad visas genom signerade avtal, tekniska kontroller och dokumentation, inte genom ett certifikat.

Vem HIPAA faktiskt berör

HIPAA gäller direkt för "covered entities" (vårdgivare, försäkringsbolag, clearinghus i USA) och deras "business associates", varje leverantör som skapar, tar emot, lagrar eller överför skyddad hälsoinformation (PHI) för deras räkning. En utvecklingsbyrå blir en business associate i det ögonblick den hanterar riktig patientdata, till exempel i en staging-miljö med produktionsdata eller genom fortsatt hosting-åtkomst efter lansering.

Byggs appen enbart med syntetisk testdata under utvecklingen, och kliniken tar emot riktig PHI först efter att ha tagit över sin egen hosting, kan byrån i praktiken aldrig bli en business associate. Det är ett verkligt arkitekturbeslut värt att fatta tidigt, färre parter som rör riktig PHI ger en mindre efterlevnadsyta.

De tekniska skyddsåtgärder som HIPAA faktiskt kräver

HIPAA Security Rule (45 CFR §164.312) listar de konkreta tekniska skyddsåtgärder en applikation som hanterar PHI måste implementera. Det här är delen som leverantörer sällan förklarar konkret, så här är den:

Åtkomstkontroll: varje användare behöver en unik identifierare, inga delade inloggningar, systemet måste stödja rutiner för nödåtkomst, och sessioner bör loggas ut automatiskt efter inaktivitet. Rollbaserad åtkomstkontroll, så att en receptionist inte kan se kliniska anteckningar som en sjuksköterska kan, är den praktiska implementeringen.

Granskningskontroller: systemet måste registrera och kunna granska aktivitet i system som innehåller PHI, vem som såg vilken post, när, och vad som ändrades. Det här är inte valfri loggning, det är ett uttalat krav, och ett av de första sakerna OCR-utredare frågar efter vid en anmäld dataintrång.

Integritetskontroller: mekanismer som bekräftar att PHI inte har ändrats eller förstörts otillbörligt, oftast checksummor, versionshantering eller databasbegränsningar i kombination med granskningsloggen ovan.

Överföringssäkerhet: PHI måste skyddas mot obehörig åtkomst under överföring över ett nätverk, vilket betyder TLS 1.2 eller högre på varje anslutning, utan undantag för intern trafik mellan tjänster.

Kryptering i vila är formellt en "adresserbar" snarare än strikt "obligatorisk" specifikation, men i praktiken behandlar OCR en okrypterad databas med PHI som i princip oförsvarbar efter en dataintrång. Vi behandlar AES-256-kryptering i vila som icke förhandlingsbart på varje hälsodataprojekt oavsett formell klassificering.

Business Associate Agreements, den verkliga grindvakten

Business Associate Agreement (BAA) är den egentliga juridiska mekanismen som reglerar en leverantörsrelation enligt HIPAA, och i praktiken betydligt viktigare än något marknadsföringspåstående om "efterlevnad". Ett BAA är ett avtal som förpliktar leverantören att skydda PHI, anmäla dataintrång inom en fastställd tidsram och bara använda datan för tillåtna ändamål.

Varje leverantör i kedjan som rör riktig PHI behöver ett: hosting-leverantören, utvecklingsbyrån om den behåller åtkomst efter lansering, e-post- eller SMS-leverantören om den skickar något som innehåller PHI, analysverktyget om det inte är noggrant avgränsat för att utesluta PHI-fält. En enda leverantör i den kedjan utan signerat BAA är en verklig efterlevnadslucka, oavsett hur compliant resten av stacken är.

I praktiken innebär det att ordningen för ett nytt hälsodataprojekt bör vara: arkitektera systemet så att så få parter som möjligt behöver riktig PHI-åtkomst, identifiera varje kvarvarande leverantör som kommer att röra den, och se till att BAA signeras med var och en innan riktig patientdata når systemet, inte efteråt.

GDPR för hälsodata

GDPR klassar hälsodata som en "särskild kategori" enligt artikel 9, vars behandling i grunden är förbjuden utom vid uttryckligt undantag: explicit samtycke, nödvändighet av skäl som rör allmänt intresse på folkhälsoområdet, eller nödvändighet för hälso- och sjukvård. Det går längre än den enklare rättsliga grunden "berättigat intresse" som räcker för vanliga personuppgifter.

I praktiken innebär det för en GDPR-kompatibel vårdapp: dokumenterad, explicit rättslig grund för varje behandling av hälsodata, hosting inom EU, signerat personuppgiftsbiträdesavtal med varje leverantör, kryptering i vila och under överföring. Tillsynen är verklig: europeiska myndigheter har utfärdat kumulativa böter på 7,1 miljarder euro sedan 2018, varav 1,2 miljarder euro enbart 2025 över mer än 330 ärenden, alltmer riktade mot vanliga SaaS-bolag snarare än enbart Big Tech. Källor: Kiteworks GDPR Enforcement 2026, CMS GDPR Enforcement Tracker.

HDS: relevant vid patienter i Frankrike

HDS (Hébergement de Données de Santé) är en fransk certifiering enligt artikel L.1111-8 i Code de la santé publique, som gäller hosting-infrastrukturen så snart hälsodata från patienter som behandlas i Frankrike hostas eller behandlas. Leverantörer som OVHcloud, AWS, Microsoft Azure och Google Cloud har HDS-certifierade regioner eller erbjudanden. En svensk eller europeisk byrå som bygger åt en fransk kund måste bygga på denna certifierade infrastruktur, men blir inte själv "HDS-certifierad" genom det.

Utan franska patienter eller en fransk vårdgivare som kund är HDS inte relevant, GDPR-kompatibel EU-hosting räcker.

HIPAA vs GDPR vs HDS, en jämförelse

Har man användare i USA, EU och specifikt Frankrike hanterar man sannolikt alla tre regelverk samtidigt. De delar ett säkerhetsgrundverk, kryptering, åtkomstloggning, anmälan av dataintrång, men skiljer sig kraftigt i omfattning och mekanism.

Det återkommande misstaget i alla tre är detsamma: att anta att certifieringen gäller byrån som skriver koden. Det gör den inte. HIPAA certifierar ingenting, GDPR certifierar heller ingenting på byrånivå (även om ett personuppgiftsbiträdesavtal krävs), och HDS certifierar specifikt hosting-infrastrukturen. I samtliga fall är byråns egentliga uppgift att välja infrastruktur med rätt status och bygga applikationen korrekt ovanpå den.

Var Supabase passar in

Supabase, Postgres-backenden vi använder för de flesta projekt, erbjuder ett HIPAA-tillägg med signerat BAA från Team-planen och uppåt. Det täcker infrastrukturnivån, krypterad lagring och nätverkssäkerhet. Det som inte sker automatiskt: Row-Level-Security-policyer måste skrivas korrekt, granskningsloggning måste byggas som en explicit tabell och trigger, automatisk sessionsutloggning och rollbaserad synlighet är applikationsarbete, inte inställningar man slår på i Supabases dashboard.

Hur vi arkitekterar vårdappar

App Studio hävdar aldrig att vi är "HIPAA-certifierade" eller "HDS-certifierade", eftersom inget av påståendena skulle stämma. Det vi gör på varje projekt med hälsodata: väljer hosting som är HIPAA-kvalificerad eller HDS-certifierad beroende på var patienterna behandlas, ser till att BAA eller hosting-avtal signeras innan riktig data når systemet, och bygger Row-Level Security, granskningsloggning och rollbaserad åtkomstkontroll som standard, inte som tillval.

Vår erfarenhet av känslig personlig data utanför en klinisk HIPAA-kontext är verklig: vi byggde CRM:et för skadereglering och tvistehantering åt Nostrum Care, techdotterbolaget till en fransk ömsesidig försäkringskoncern, som behandlar känslig person- och finansdata under GDPR med WeWeb, Supabase och n8n. Det är försäkringsdata i backoffice, inte kliniska patientjournaler, och vi beskriver det medvetet så, det visar verklig GDPR-erfarenhet utan att framställa det som en klinisk HIPAA- eller HDS-lösning det inte är.

Checklista före lansering

Avtal: BAA signerat med hosting-leverantören; BAA signerat med utvecklingsbyrån om den behåller åtkomst efter lansering; personuppgiftsbiträdesavtal med varje tredjepartstjänst som kan röra PHI.

Åtkomstkontroll: unikt inloggningsuppgifter per användare, aldrig delade konton; rollbaserad synlighet på databasnivå via Row-Level Security, inte bara dold i gränssnittet; automatisk utloggning efter inaktivitet.

Granskning och integritet: en granskningslogg som registrerar vem som såg eller ändrade vilken post och när; loggen själv skyddad mot manipulation.

Kryptering: AES-256 i vila för varje databas och säkerhetskopia; TLS 1.2 eller högre för varje anslutning, intern som extern.

Riskanalys: en dokumenterad riskanalys som täcker var PHI finns, vem som kan komma åt den och vad som kan gå fel, den vanligaste bristen i verkliga HHS OCR-tillsynsärenden.