"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.
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.
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.