Språk
EnglishTürkçeSuomiEspañolItalianoDeutschFrançaisNederlandsSvenska
Raznameh Clinics
Guider›Säkerhet & regelefterlevnad

Säkerhet och dataskyddsrätt · USA, Europeiska unionen, Storbritannien

Lagen först, sedan programvaran som genomför den.

En journal inom psykisk hälsa är en av de mest skyddade sorterna av uppgifter som finns. En felaktig titt i en enda fil kan bli en anmälningspliktig incident. Den här sidan börjar med de tre lagar som avgör vad du måste göra – HIPAA i USA, GDPR i Europeiska unionen och UK GDPR i Storbritannien. Sedan visar den exakt vilken del av plattformen som utför varje skyldighet. Därefter går den igenom hur själva programvaran är byggd, hur Odoo Community styr vem som ser vad, hur servern är härdad och, till sist, de delar som stannar hos din organisation.

Den är skriven på vardagsspråk med avsikt. Du ska kunna ge den till ett dataskyddsombud, en säkerhetsgranskare eller en chef som aldrig läst en förordning, och alla tre ska kunna följa den.

Dataskyddsombud Granskare av informationssäkerhet Verksamhetschefer Köpare som gör en due diligence
3rättsordningar som täcks 5egenskaper hos varje uppgift 0sätt att kringgå åtkomsten AES-256-GCMkryptering av varje fil 20 årlängsta lagringstid som modellerats
Välj ditt land Vad lagen kräver USA · EU · Storbritannien sida vid sida Vad som skyddas De fem egenskaperna Vem som kan öppna en uppgift Odoo: åtkomst, inloggning, roller Härdning av servern Skydd i flera lager Praxis i vårdbranschen Om något går fel Plattformens kontroller Vad du kan bevisa Där programvaran slutar
Börja här

Välj landet där ni verkar

Det mesta av det som följer är detsamma överallt – krypteringen, åtkomstkontrollen, granskningsloggen, härdningen av servern. Det som skiljer sig mellan länder är maskineriet för rättigheter och styrning ovanpå, och det har en egen sida. Gör du en due diligence, börja med ditt eget land och kom tillbaka till det gemensamma materialet efteråt.

USA USA HIPAA · HITECH · 42 CFR Part 2 · delstatlig rätt Den största av de tre. Varje regel i USA som når en verksamhet inom psykisk hälsa, vad som har byggts för var och en, och – sist – sju genomgångar steg för steg av vad som faktiskt händer inuti programvaran.
  • Privacy Rule: varje patienträttighet, även de delar de flesta system hoppar över
  • Security Rule: alla åtta tekniska skyddsåtgärder, plus de administrativa och fysiska registren
  • Anmälan av incidenter: fyra faktorer, 60 dagar, trösklar per delstat, båda leverantörsklockorna
  • 42 CFR Part 2, inklusive 2024 års regel
  • Sju flöden – en begäran om journalkopia, en nekad rättelse, ett utlämnande, en incident, en ny patient, en inaktiv skärm och regelefterlevnadens år
 Europeiska unionen GDPR Förordning (EU) 2016/679 Rättslig grund enligt artikel 9.2 h i stället för samtycke, radering genom att krypteringsnyckeln förstörs, dataportabilitet som en loggad export, och de två fristerna vid incidenter med det undantag du måste förtjäna.
  • Varför journaler inte får vila på samtycke
  • Radering som respekterar rättigheten utan att förstöra bevisen
  • 72-timmarsklockan och frågan om nycklarna röjts
  • Registerförteckning och konsekvensbedömning som levande poster
 Deutschland Tyskland § 203 StGB · § 630f BGB · NIS2 · SGB V De europeiska reglerna gäller här oförändrade – och sedan lägger Tyskland till ett eget lager, varav en del är straffrätt och avgör om en mottagning över huvud taget lagligen får köpa av oss.
  • § 203 StGB: varför valet av leverantör är terapeutens rättsliga risk
  • Vad ett åtagande enligt § 203 säger, klausul för klausul
  • Tio år från behandlingens slut, inte från filens datum
  • NIS2 för mottagningsgrupper, och programmet som redan är byggt
  • En ärlig redogörelse för den lagstadgade infrastruktur vi inte har
 Storbritannien UK GDPR DPA 2018 · NHS Code of Practice 2021 Vad Storbritannien lägger till ovanpå GDPR: prövningen av allvarlig skada byggd som ett arbetsflöde som löper ut av sig självt, NHS:s lagringsschema som medföljande data, och en rättighet till journaler för personer som har avlidit.
  • Undanhållande som kräver en namngiven yrkesperson och upphör efter sex månader
  • Tjugo år efter senaste kontakt för journaler inom psykisk hälsa
  • Access to Health Records Act 1990
  • Caldicott-princip 7 och varför nödåtkomst är en funktion
 Australia Privacy Act 13 APP · NDB-systemet · delstatlig lagring En federal lag utan undantag för småföretag när det gäller vårdgivare, åtta uppsättningar delstatliga regler om lagring, och – sedan juni 2025 – en patient som kan stämma utan att vänta på en tillsynsmyndighet.
  • Alla tretton Australian Privacy Principles, en i taget
  • APP 8: varför inget behöver lämna landet
  • Sju år från senaste anteckningen, och till 25 års ålder för ett barn
  • Incidentflödet, steg för steg, plus rapportering av ransomware inom 72 timmar
  • Essential Eight, ISO 27001, RACGP C6.4 – och varför SOCI inte gäller
 Kanada PIPEDA & PHIPA 10 principer · provinsiella lagar · yrkesorganens lagringstider Ingen HIPAA, ingen enskild lag: en federal lag, en vårdlag som skiljer sig mellan provinserna, och ett yrkesorgan ovanpå båda som bestämmer hur länge du sparar en journal.
  • Vilken lag och vilken kommissionär, provins för provins
  • PIPEDA:s tio principer, och PHIPA för varje slags informationsansvarig
  • Lockbox – det enda kanadensiska begreppet vi ännu inte har
  • Två incidentklockor, och den årliga statistikrapporten varje mars
  • Den provinsiella faktureringsinfrastrukturen vi inte är ansluten till, sagt i avsnitt 09
 Gemensamt för alla sex Säkra dokument Maskineriet som varje landssida bygger på Hur en journal krypteras, vem som kan öppna en, ett dokuments hela liv från inlämning till gallring – och, sist, sju risker som inte har någon teknisk lösning.
  • Kuvertkryptering, och varför det finns två nycklar och inte en
  • Åtkomst som följer behandlingsrelationen
  • Gallring genom att förstöra en nyckel i stället för att radera en rad
  • Sju risker sagda rakt ut, med det som stannar hos dig
01 — Börja med lagen

Vad HIPAA, GDPR och UK GDPR faktiskt kräver av dig

De flesta säkerhetsdokument börjar med tekniken och lämnar lagen till slutet. Det här gör tvärtom, eftersom det är lagen du bedöms mot. Nedan är varje regelverk på vardagsspråk: vad det är, vem det gäller och vilka skyldigheter det lägger på en mottagning. Under vart och ett står den del av plattformen som utför den skyldigheten.

USA

HIPAA

HIPAA är Health Insurance Portability and Accountability Act. Den gäller vårdgivare i USA och de företag som hanterar hälsouppgifter för deras räkning. Den består av två huvuddelar. Privacy Rule säger vem som får se hälsoinformation och vad en patient kan begära. Security Rule säger hur elektronisk hälsoinformation måste skyddas.

  • Minsta nödvändiga. Personalen får bara se den information de behöver för uppgiften framför sig. I plattformen upprätthålls det genom vårdrelationer: en terapeut når klienterna på sin egen lista, inte hela mottagningen.
  • The designated record set. En patient kan begära en kopia av sin journal, men inte av allt mottagningen har. Varje dokumenttyp är markerad som innanför eller utanför den mängden, och en begäran kan inte returnera det som ligger utanför.
  • Psychotherapy notes hålls separat. HIPAA behandlar en terapeuts egna processanteckningar annorlunda än journalen. I plattformen krypteras de under en annan nyckel, så nyckeln som öppnar den vanliga journalen öppnar inte dem.
  • Redovisning av utlämnanden. En patient kan fråga vem deras uppgifter lämnats ut till under de senaste sex åren. Registret över utlämnanden besvarar det från sparade poster.
  • Anmälan av incidenter. Om skyddad hälsoinformation röjs måste personerna informeras – om inte uppgifterna var korrekt krypterade. Det undantaget kallas safe harbour, och det är skälet till att krypteringen är byggd som den är.
  • 42 CFR Part 2 är en separat amerikansk regel för journaler från behandling av substansbrukssyndrom. Den är strängare än HIPAA och kräver en varning mot vidareutlämnande på allt som delas. Plattformen genererar den texten i stället för att be personalen skriva den.
Europeiska unionen

GDPR

GDPR är dataskyddsförordningen. Den gäller varje organisation som behandlar personuppgifter om personer i Europeiska unionen. Hälsouppgifter är det GDPR kallar särskilda kategorier av personuppgifter, vilket betyder att det är förbjudet att behandla dem om inte ett särskilt villkor är uppfyllt. Där HIPAA mest handlar om skydd handlar GDPR också om individens rättigheter till sina egna uppgifter.

  • En rättslig grund för varje dokumenttyp. För journaler är det rätta villkoret artikel 9.2 h, tillhandahållande av hälso- och sjukvård – inte samtycke. Ett samtycke som en person inte fritt kan vägra är inget giltigt samtycke, och i en vårdsituation kan de oftast inte vägra. Plattformen registrerar grunden på dokumenttypen, så det blir aldrig en gissning senare.
  • Rätten till tillgång (art. 15). En person kan begära en kopia av sina uppgifter, och det finns en lagstadgad frist för att svara. Begäran körs som ett spårat arbetsflöde med den klockan på sig.
  • Rätten till radering (art. 17). Kallas ofta rätten att bli bortglömd. Plattformen respekterar den genom att förstöra krypteringsnyckeln i stället för databasraden, så innehållet är borta men beviset för att en uppgift fanns och gallrades finns kvar.
  • Rätten till dataportabilitet (art. 20). En person kan begära sina uppgifter i en form de kan ta med sig någon annanstans. Plattformen bygger en zip-fil i minnet och strömmar den, och loggar varje dokument i den för sig.
  • Anmälan av incidenter (art. 33 och 34). Tillsynsmyndigheten måste informeras inom 72 timmar från att du fått kännedom. De berörda måste också informeras, om inte uppgifterna var krypterade.
  • Styrningsdokumentation (art. 30 och 35). Du måste föra en förteckning över dina behandlingar och göra en konsekvensbedömning avseende dataskydd för behandlingar med hög risk. Båda finns i systemet som levande poster, inte som en Word-fil som blir inaktuell.
Storbritannien

UK GDPR och DPA 2018

När Storbritannien lämnade Europeiska unionen behöll landet GDPR nästan oförändrad och kallar den UK GDPR. Data Protection Act 2018 står bredvid och lägger till brittiska regler, flera av dem mycket viktiga inom vården. Tillsynsmyndigheten är Information Commissioner's Office, ICO.

  • Allt GDPR kräver gäller fortfarande. Tillgång, radering, portabilitet, anmälan av incidenter och styrningsposterna är samma skyldigheter som i EU.
  • Prövningen av allvarlig skada. Hälsouppgifter får undanhållas från en persons egen begäran om tillgång där ett utlämnande sannolikt skulle orsaka dem allvarlig skada. För en verksamhet inom psykisk hälsa motsvarar det det amerikanska undantaget för psychotherapy notes, och processen runt det är sträng.
  • NHS lagringstider. NHS Records Management Code of Practice 2021 bestämmer hur länge journaler sparas – för psykisk hälsa 20 år efter senaste kontakt. Det schemat levereras som startdata.
  • Access to Health Records Act 1990. Anhöriga till en person som har avlidit kan i vissa fall begära ut deras journaler. GDPR omfattar inte avlidna alls, så det här är en rättighet som bara finns i Storbritannien, med egna regler om vem som har rätt att fråga.
  • Caldicott-princip 7. Brittisk vägledning för vården säger att skyldigheten att dela information kan vara lika viktig som skyldigheten att skydda den. Att blockera allt är ett eget slags misslyckande, och det är därför nödåtkomst finns och registreras i stället för att förbjudas.
Vad alla fyra är överens om

Under skillnaderna vill de fyra regelverken samma fem saker. Skydda uppgifterna så att en stulen kopia är oanvändbar. Låt bara rätt personer se dem. För en förteckning över vem som såg dem. Spara dem bara så länge du behöver, och gallra dem sedan på rätt sätt. Kunna bevisa alla fyra i efterhand. Den gemensamma listan är vad plattformen bygger in i lagringslagret en gång, för varje driftsättning. Maskineriet för rättigheter ovanpå är det som skiljer sig mellan länder, och det levereras som en separat modul som du installerar för din jurisdiktion.

Ingen är certifierad för detta, och den som påstår något annat säljer något

Det finns ingen HIPAA-certifierad eller GDPR-certifierad produkt. Ingen myndighet utfärdar ett sådant certifikat. Det som finns är en lista med tekniska och organisatoriska åtgärder. Programvara kan genomföra de tekniska och göra de organisatoriska lätta att sköta och lätta att visa. Den kan inte på egen hand göra en organisation regelefterlevande. Sidans sista avsnitt anger exakt vilka delar som stannar hos dig.

02 — Sida vid sida

Samma tekniska kärna överallt. Olika maskineri för rättigheter ovanpå

Kryptering, åtkomstkontroll, granskningsloggen och lagring är identiska i varje land. De byggs en gång, i den gemensamma kärnan, och varje driftsättning får dem. Det som skiljer sig mellan USA, Europeiska unionen, Storbritannien, Australien och Kanada är arbetet med rättigheter och styrning som ligger ovanpå den kärnan. Det är därför ett system byggt efter en amerikansk standard inte automatiskt uppfyller EU:s krav, och därför varje land kommer som en egen installerbar modul.

De två sista kolumnerna har de ärligaste markeringarna. Australian Privacy Principles kräver mindre än Europa på två ställen, och det finns ännu ingen australisk modul – maskineriet för rättigheter som en australisk driftsättning använder i dag är den gemensamma kärnan plus delar av de europeiska och brittiska modulerna. Australiensidan namnger varje skarv.

Kanada är nyast, och den enda kolumnen där regelboken ändras inom landet. Det finns ingen kanadensisk modul heller, och en skyldighet har ingen motsvarighet någon annanstans i den här tabellen – det så kallade lockbox, en instruktion från patienten som stänger av en del av den egna journalen inom vårdkretsen. Kanadasidan beskriver vad det innebär att bygga det, och vilken provinsiell lag som gäller var.

Vad som krävs USA
HIPAA · 42 CFR Part 2		 Europeiska unionen
GDPR		 Storbritannien
UK GDPR · DPA 2018		 Australia
Privacy Act 1988 · APP		 Kanada
PIPEDA · PHIPA och provinsiella lagar
Kryptering, åtkomstkontroll, granskningslogg, lagring ✓ gemensam kärna ✓ gemensam kärna ✓ gemensam kärna ✓ gemensam kärna ✓ gemensam kärna
Ett registrerat rättsligt skäl för att ha varje dokumenttyp — inte så HIPAA fungerar ✓ Art. 9.2 h för journaler, inte samtycke ✓ samma sak, enligt UK GDPR ✓ APP 3.3 och s16B, registrerat per dokumenttyp § ändamål och samtycke, inte en uppräknad rättslig grund
En person kan begära en kopia av sin journal ✓ 45 CFR 164.524, begränsat till designated record set ✓ Art. 15, med en lagstadgad frist ✓ Art. 15, plus prövningen av allvarlig skada ✓ APP 12, inom rimlig tid, och ingen avgift för att fråga ✓ PIPEDA princip 9 och PHIPA s. 52 – 30 dagar, kan förlängas
En del material kan hållas inne ✓ psychotherapy notes ligger utanför record set § snävt, och beror på medlemsstaten ✓ prövning av allvarlig skada, körd som ett arbetsflöde som löper ut ◐ grunder i APP 12.3 finns; arbetsflödet levereras med den brittiska listan ◐ grunder i PHIPA finns; arbetsflödet levereras med den brittiska listan
En person kan begära att deras uppgifter raderas § HIPAA ger ingen allmän rätt; lagringstiden avgör ✓ Art. 17, genom att nyckeln förstörs ✓ samma sak, med brittiska undantag § ingen allmän rätt till radering; destruktion enligt APP 11.2 gör jobbet § ingen allmän rätt; lagring och gallring gör jobbet
En person kan ta med sina uppgifter någon annanstans § via rätten till tillgång; HIPAA har ingen separat rätt ✓ Art. 20, strömmad zip, varje fil loggad ✓ samma sak § ingen rätt till portabilitet; rätten till tillgång bär den ✓ Québecs Law 25-rättighet landar på GDPR-exporten; ingen federal motsvarighet
Ett register över vad som delats, och med vem ✓ sex år, på begäran ✓ vad som lämnades ut, till vem, på vilken grund ✓ samma sak ✓ APP 6, vad som lämnades ut och på vilken grund ✓ vad som lämnades ut, till vem, på vilken grund och varför
Att informera tillsynsmyndigheten och de berörda efter en incident ✓ bedömning i fyra faktorer, avisering inom 60 dagar, trösklar för medier och HHS ✓ Art. 33 och 34, 72 timmar, två klockor, frågan om nycklarna registrerad ✓ samma sak, anmält till ICO ✓ NDB-systemet: 30 dagar att bedöma, sedan anmälan så snart det är möjligt ◐ posten är fullständig; de två anmälningarna och räkningen i mars tas inte fram
Skriftliga styrningsposter som hålls aktuella ✓ policyregister, versionshanterat, sex år per version ✓ konsekvensbedömning (art. 35) och registerförteckning (art. 30) ✓ samma sak ✓ APP 1: policyregister, riskregister, klagomål som poster ✓ policyregister, riskregister, klagomål som poster
Ett lagringsschema som levereras färdigt att använda ⚙ varierar mellan delstater, så du anger tiderna ⚙ varierar mellan medlemsstater, så du anger tiderna ✓ NHS Records Management Code of Practice 2021 ◐ tiderna är kända nationellt, och inget är förifyllt ⚙ bestäms av ditt yrkesorgan, så det finns inget nationellt schema att fylla i
Journaler för personer som har avlidit ⚙ HIPAA skyddar dem i 50 år; regeln är inte förifylld — GDPR gäller inte avlidna ✓ Access to Health Records Act 1990 § den federala lagen upphör vid dödsfallet; NSW skyddar i 30 år efter ⚙ lagarna fortsätter att gälla efter döden; tiden bestäms av ditt yrkesorgan
Extra skydd för journaler om substansbruk ✓ 42 CFR Part 2, med varningen mot vidareutlämnande — ingen motsvarande regel — ingen motsvarande regel — ingen motsvarande regel — ingen motsvarande regel
✓ByggtI jurisdiktionsmodulen nu, och går att visa. ⚙Byggt — du väljer värdetMekanismen finns och siffran är din, eftersom lagen överlåter den åt dig eller din delstat. Ingen brist. §Det regelverket kräver mindreInget saknas. Det här landets lag ger en snävare rättighet, eller når samma mål på en annan väg. ◐Delvis byggtNågot saknas verkligen. Landssidan namnger exakt vad. —Finns inte alls i det regelverketLagen innehåller helt enkelt inte den här rättigheten.

De två mittersta markeringarna var en enda markering tills nyligen, vilket lästes som ett och samma slags brist när bara ◐ är en. En lagringstid du anger för att din delstat anger den är ingen saknad funktion, och det är inte heller att HIPAA avstår från att ge en rättighet som GDPR ger.

03 — Vad som skyddas

Tre sorters uppgifter, och bara en av dem är vanlig

Inte allt i en mottagning behöver samma skydd. Behandlar du varje fält som maximalt känsligt blir systemet långsamt och krångligt, och personalen börjar föra anteckningar i ett kalkylark i stället. Det är den verkliga risken för incidenter på de flesta mottagningar. Behandlar du inget som känsligt är systemet helt enkelt osäkert. Därför sorterar plattformen uppgifterna i tre sorter och lägger det tunga maskineriet bara på den sort som behöver det.

Sort av uppgifterExempelHur de lagrasVem som kan nå dem
Vanliga affärsuppgifter Kontaktuppgifter, ordrar, fakturor, bokningar, chattmeddelanden I databasen, skyddade av Odoos egna åtkomstregler Personal vars arbete kräver det. Klienten själv, via portalen
Kliniska och yrkesmässiga uppgifter Samtalsrapporter, incident- och skyddsärenden, identitetshandlingar Som säkra dokument: krypterade en version i taget, lagrade utanför det vanliga filområdet Bara klientens vårdteam, genom en uttrycklig regel. Ingen yrkestitel ger åtkomst
Ekonomiska uppgifter Fakturor, utbetalningar till behandlare, avtalsversioner, bokföringsposter I huvudboken, som inte kan ändras när en post väl är utfärdad Ekonomi och ledning. En rättelse lämnar ett spår i stället för att skriva över
Varför gränsen dras vid uppgiften, inte vid fältet

Att kryptera varje enskilt fält skulle göra sökning omöjlig. Personalen skulle då ha sina arbetsanteckningar någonstans utanför systemet, där inget loggas och inget skyddas. Därför drar plattformen gränsen vid sorten av uppgift i stället för vid det enskilda fältet. Känsligt material stannar i systemet, där varje läsning av det kan registreras.

04 — Uppgiftsmodellen

Fem saker som gäller för varje skyddad uppgift

De här fem är egenskaper hos hur uppgifterna lagras. De är inga riktlinjer som personalen ombeds följa. Den skillnaden är hela argumentet på den här sidan. En kontroll som beror på att folk beter sig rätt är en kontroll du inte kan visa för en granskare. En kontroll som är inbyggd i lagringen är en du kan visa.

Egenskap ett

Varje version krypteras för sig

Plattformen använder kuvertkryptering med AES-256-GCM. Det betyder att varje dokumentversion får en egen slumpmässig nyckel, och den nyckeln låses sedan med en andra nyckel som tillhör hela driftsättningen. Den andra nyckeln sparas aldrig i databasen.

  • Den som stjäl en kopia av bara databasen har inget läsbart
  • De krypterade filerna ligger utanför Odoos vanliga fillagring och serveras aldrig via den vanliga nedladdningsvägen
  • Att rotera driftsättningsnyckeln låser om de små nycklarna utan att skriva om en enda krypterad fil
  • Programvaran vägrar att starta om nyckeln saknas, är läsbar för alla, ägs av fel konto eller förvaras någonstans där den skulle kopieras tillsammans med de uppgifter den skyddar
Egenskap två

Stängt om inte en regel öppnar det

Varje läsning måste hitta en regel som tillåter den och ingen regel som förbjuder den. Det kontrolleras varje gång, inte en gång vid inloggningen. Att vara administratör, chef eller den som skrev dokumentet ger i sig ingenting.

  • Det finns ingen huvudöverstyrning och ingen superanvändarväg in till kliniskt innehåll
  • Åtkomsten följer klientens vårdteam, inte organisationsschemat
  • När personalen lämnar in ett dokument säger dialogen med enkla ord vem som kommer att kunna öppna det, innan det sparas
Egenskap tre

Varje läsning skrivs ner

Öppningar loggas, inte bara ändringar. Loggen är endast tillägg och hashkedjad, vilket betyder att varje post är matematiskt knuten till den före. Att ta bort eller ändra en post bryter kedjan och blir synligt.

  • Posten skrivs innan innehållet lämnas ut, inte efteråt
  • Ingen kan ändra eller radera den, inte heller de som administrerar systemet
  • En fullständig lista över vem som öppnat en uppgift kan tas fram för en klient, en tillsynsmyndighet eller era egna jurister
  • Läsningar i portalen är hastighetsbegränsade per användare, räknat från samma logg, så gränsen håller även över flera serverprocesser
Egenskap fyra

Rättelser lägger till, de skriver aldrig över

När något rättas lämnas en ny version in. Den tidigare finns kvar exakt som den var, inklusive dess metadata. En uppgift som kan ändras i tysthet är värdelös som bevis, och en dag kan era behöva vara värda något.

  • En begäran om rättelse läggs till uppgiften i stället för att ersätta den
  • Varje version har en egen nyckel, så gallring kan göras version för version
  • En ändring syns därför i historiken i stället för att vara något du måste sluta dig till
Egenskap fem

Gallring förstör nyckeln

När en lagringstid löper ut förstör plattformen krypteringsnyckeln i stället för att radera raden. Innehållet blir permanent oläsbart. Det tomma skalet och granskningskedjan finns kvar. Tekniken kallas kryptografisk radering.

  • Gallringen går att bevisa i stället för att bara påstås
  • Beviset för att en uppgift en gång fanns, och gallrades i tid, finns kvar
  • Lagringstiden räknas från ett verkligt ankardatum: senaste kontakt, födelsedatum eller dödsdatum
Den avsiktliga luckan

Det den inte gör, sagt öppet

Plattformen kan inte söka inuti krypterade dokument. Det är en direkt följd av krypteringen, inte en saknad funktion. Dokument hittas efter vem de gäller, vilken typ de är och när de lämnades in.

  • Det sägs här eftersom en leverantör som lovar både stark kryptering och fritextsökning i samma innehåll lovar det ena falskt
  • Det är en tjänst för säkra dokument, inte en elektronisk patientjournal: ingen journalföring, ingen HL7- eller FHIR-kommunikation, ingen e-förskrivning
  • Kärnan vet ingenting om hälso- och sjukvårdsjuridik. Varje lands regler kommer som en separat modul ovanpå
05 — Vem som kan öppna en uppgift

Åtkomst följer vårdrelationen, inte yrkestiteln

Det här är den enskilt viktigaste idén på sidan, och det är det enda en vanlig dokumenthanterare inte kan uttrycka. En vårdrelation är en registrerad koppling mellan en behandlare och en klient, med en typ, ett startdatum och ett slutdatum. En terapeut når uppgifterna om personerna på sin egen lista. Inte mottagningens lista. Sin egen. När relationen upphör upphör också åtkomsten, efter en kort frist som räcker för att göra klart utestående anteckningar.

Det är det här som gör ”minsta nödvändiga” från en riktlinje i en handbok till något programvaran faktiskt upprätthåller, och något du kan visa vid en revision.

Vad som händer vid varje enskild läsning

Fem steg, varje gång, för varje dokument

  1. Vem frågar?En inloggad användare, kopplad till en bestämd person. Inte en roll och inte en grupp.
  2. Finns det en regel som tillåter det?För att de är den registrerade, för att de ingår i vårdteamet, eller för att någon gett dem namngiven åtkomst. Ingen regel, ingen åtkomst.
  3. Finns det en regel som förbjuder det?Ett nej vinner alltid över ett ja. Psychotherapy notes, förseglade dokument och undanhållna uppgifter nekas på varje väg in.
  4. Skriv loggpostenLäggs till i loggen med endast tillägg innan något innehåll skickas tillbaka.
  5. Dekryptera i minnet och strömmaInget skrivs till disken på vägen ut och inget serveras från det vanliga filområdet.

Vad som inte ger dig åtkomst

Uppräknat uttryckligen, eftersom köpare alltid frågar

  1. Att vara administratörEtt administratörskonto öppnar i sig inget kliniskt innehåll. Det finns ingen bakdörr för support eller underhåll.
  2. Att ha skrivit det självIncident- och skyddsärenden är stängda även för den som lämnade in dem, eftersom de lämnas in till mottagningens verksamhetschef.
  3. Att ha hög befattningKliniska roller avgör vilka vyer i applikationen någon når. De avgör aldrig vad någon kan öppna.
  4. Att vara klientenEn klient ser en uppgift om sig själv bara när en regel uttryckligen beviljar det. Det är ett kliniskt och juridiskt beslut, fattat med avsikt och registrerat med skälet och namnet på den som fattade det.
  5. Att gissa en dokumentreferensEtt dokument du inte får se ger ”hittades inte”, aldrig ”förbjudet”. Annars blir gissade referenser ett sätt att ta reda på vem som har uppgifter.
Nödåtkomst finns, och den sker aldrig i det tysta

Ibland behöver en behandlare verkligen en uppgift de inte har någon relation till – en kris, ett samtal utanför kontorstid, en kollega som blivit sjuk. Om er organisation tillåter det finns en väg för nödåtkomst. Att använda den registreras som en händelse och granskas i efterhand av dataskyddsansvarig.

Det är designen i en mening: åtkomst finns när någon verkligen behöver den, och sker aldrig i det tysta. Det är avsiktligt. Ett system som bara blockerar misslyckas på sitt eget sätt. Brittisk vägledning (Caldicott-princip 7) säger att skyldigheten att dela kan vara lika viktig som skyldigheten att skydda, och det är därför nödåtkomst är en avsiktlig funktion i kärnan snarare än ett hål som lämnats i den.

06 — Affärskärnan

Hur Odoo Community avgör vem du är, och vad du ser

Det kliniska maskineriet ovan ligger ovanpå Odoo 19 Community, som är affärskärnan med öppen källkod. Odoo har en egen modell för åtkomstkontroll, och den är värd att förstå, eftersom det är den som skyddar de vanliga affärsuppgifterna – bokningarna, fakturorna, kontakterna och meddelandena som utgör det mesta av systemet.

Det här avsnittet har sex delar: de fyra lagren av åtkomstkontroll som avgör vad en inloggad person får nå; inloggning – lösenord, tvåfaktorsautentisering, passkeys och reglerna runt dem; vad ”rollbaserad” faktiskt betyder här, eftersom uttrycket används slarvigt överallt; isolering av databaser; OWASP Top Ten med Odoos svar på var och en; och vad öppen källkod faktiskt är värd.

Allt nedan levereras med Odoo 19 Community. Inget av det är ett betalt tillägg, och allt är läsbar källkod som ert eget säkerhetsteam kan granska.

Odoos åtkomstmodell har fyra lager. Vart och ett besvarar en egen fråga, och en begäran måste passera alla fyra. De kontrolleras inuti själva datalagret, vilket är det viktiga: samma kontroller gäller oavsett om en post nås via webbgränssnittet, via mobilappens gateway eller via Odoos fjärr-API. Det finns ingen väg som går runt dem.

Lager ett

Grupper – vilken del av systemet du når

En grupp är en roll. Medlemskapet avgör vilka menyer, vyer och knappar en person över huvud taget ser. Grupper kan innefatta andra grupper, så en handledare automatiskt har allt en behandlare har, utan att behörigheterna skrivs två gånger.

  • Rollerna i den här driftsättningen omfattar behandlande kliniker, handledare, verksamhetschef, journalansvarig, reception och dataskyddsansvarig
  • Receptionen har bara personuppgifter: inget kliniskt innehåll och ingen dokumentåtkomst av något slag
  • En grupp ger räckvidd, aldrig innehåll. Att ha behandlarrollen öppnar i sig ingen klients journal – det gör vårdrelationen
Lager två

Åtkomsträttigheter per modell – vad du får göra med en sorts post

För varje typ av post och varje grupp sparar Odoo fyra separata behörigheter: läsa, skapa, ändra och radera. De deklareras i vanliga textfiler som följer med varje modul, så att de kan läsas och granskas utan att något körs.

  • Den här driftsättningen deklarerar 660 åtkomstposter i 35 moduler
  • Allt som inte står med nekas. Åtkomst ges genom att den namnges, aldrig genom att man glömmer att blockera den
  • Läsa utan att ändra är vanligt med avsikt: många roller kan se en post de inte får ändra
Lager tre

Postregler – vilka enskilda poster du får röra

En postregel är ett filter som läggs på varje fråga. Det är den som gör ”dina egna klienter” och ”ditt eget företag” verkliga, i stället för en fråga om vilken vy någon råkar öppna. Globala regler gäller alltid. Regler kopplade till en grupp vidgar åtkomsten bara för den gruppen.

  • Den här driftsättningen definierar 117 postregler i modulerna för journaler, bokning, avtal, e-signatur och rapporter
  • Typiska exempel: en behandlare ser vårdrelationer där de är behandlaren; en portalanvändare ser bara bokningar som hör till deras egen kontaktpost
  • Regeln tillämpas av datalagret, så den gäller lika för listvyer, rapporter, exporter och fjärr-API:t
Lager fyra

Fältregler och separat portal

Enskilda fält kan begränsas till vissa grupper, så två personer kan öppna samma post och se olika mycket av den. Därutöver håller Odoo portalanvändare i en helt annan klass än personalen.

  • En portalanvändare – en klient eller en extern kontakt – har ingen åtkomst alls till backoffice, bara till de sidor som uttryckligen publicerats för dem
  • Öppna webbsidor körs som en anonym användare med nästan inget beviljat, så ett misstag på en öppen sida kan inte röja personaluppgifter
  • Varje controllerväg i den här driftsättningen anger om den kräver en inloggad användare eller är avsiktligt öppen: 174 vägar kräver inloggning, 57 är öppna med avsikt
Skydd i ramverketVad Odoo görVad det förhindrar
FrågebyggeAlla databasfrågor byggs av ramverket från strukturerade filter. Applikationskoden skriver inte rå SQL för vanliga läsningar och skrivningarSQL-injektion via sökfält, filter och URL-parametrar
Escaping i mallarOdoos mallmotor escapar som standard värden den renderar i en sida. Rå utmatning måste begäras uttryckligenCross-site scripting, där text som sparats av en användare körs som kod i en annan användares webbläsare
FormulärtokenWebbformulär som ändrar data har en token knuten till användarens session, och servern avvisar ett inskick utan denCross-site request forgery, där en annan webbplats i tysthet skickar ett formulär som din inloggade användare
SessionerSessionens tillstånd hålls på servern. Webbläsaren har bara en identifierare, i en cookie markerad så att sidans skript inte kan läsa denStöld av sessioner via ett skript som körs i sidan
LösenordSparas bara som en envägshash, aldrig i en form som kan vändas tillbaka. Hashschemat kan uppgraderas utan att alla behöver byta lösenordAtt en stulen användartabell blir en lista med användbara lösenord
DatabashanterarenVyerna som skapar, kopierar, återställer och raderar hela databaser är stängda i produktion, och ett värdnamn är bundet till exakt en databasAtt någon som når servern hittar, kopierar eller skriver över en databas
Upphöjda operationerKod kan kringgå åtkomstregler bara där en utvecklare skrivit det avsiktligt, för en definierad operation, på ett namngivet ställe. Kliniskt innehåll är inte ett av de ställenaBred, oavsiktlig behörighetsupptrappning begravd i applikationskoden
Öppen källkodOdoo Community publiceras under en öppen licens och tilläggen i den här plattformen går att läsa i sin helhet. Säkerhetsrättelser publiceras av Odoo och tillämpas på er egen installationAtt behöva lita helt på en leverantörs påståenden om säkerhet

Inloggning: lösenord, andra faktorer och reglerna runt dem

De fyra lagren ovan avgör vad en inloggad person får nå. Det här är delen före det – hur Odoo fastställer att någon är den de säger sig vara, och vad den gör när de inte är det. Allt levereras med Odoo 19 Community; inget av det är ett betalt tillägg.

KontrollStatusVad den gör, och vad du bestämmer
Lösenord hashas, de sparas aldrig ✓ Sparas som en PBKDF2-SHA512-hash med ett salt per lösenord och en inställbar arbetsfaktor. En hash kan inte göras om till ett lösenord, så en stulen användartabell är ingen lista med inloggningar. Arbetsfaktorn kan höjas i takt med att hårdvaran blir snabbare, och lösenord hashas om till den starkare inställningen nästa gång var och en loggar in – ingen behöver byta lösenord.

Ingen kan läsa tillbaka ett lösenord, inte era egna administratörer och inte vi: fältet är alltid tomt, vem som än frågar. Tappar någon sitt lösenord är den enda vägen en återställning, och det är det rätta svaret snarare än en saknad funktion.
Tvåfaktorsautentisering ⚙ Byggd och levererad i varje installation, med de vanliga koderna från autentiseringsappar (TOTP) som fungerar med Google Authenticator, Authy, 1Password och de andra. En person kan själv registrera en enhet, och betrodda enheter kan kommas ihåg under en period.

Du anger: om den är valfri eller obligatorisk. En inställning slår på den för alla, en annan för alla personalkonton – och den som saknar en autentiseringsapp får i stället en engångskod via e-post, så att ett krav inte lämnar någon utestängd. I en amerikansk driftsättning bör det vara påslaget: det förväntas enligt Security Rule och blir i praktiken obligatoriskt om den föreslagna uppdateringen fastställs.
Tvåfaktor stänger också API-dörren ✓ Detaljen som gör det värt att ha. När en person har en andra faktor slutar deras lösenord att fungera för maskin-till-maskin-åtkomst helt och hållet – en integration måste i stället använda en namngiven API-nyckel. Utan den regeln skyddar tvåfaktorsautentisering inloggningsskärmen och lämnar bakdörren öppen, och det är så den besegras i praktiken.
Passkeys ⚙ Odoo 19 stöder passkeys – inloggning med ett fingeravtryck, ett ansikte eller en hårdvarunyckel i stället för ett lösenord. Inget som kan nätfiskas skrivs in, så det tar bort hela den sortens attack där någon övertalas att skriva sitt lösenord på en övertygande kopia av er inloggningssida. Du avgör om du vill erbjuda det.
API-nycklar i stället för lösenord för integrationer ✓ Varje integration får en egen namngiven nyckel med eget omfång, listad under personen som skapade den, och som kan återkallas en i taget. En nyckel som läcker stängs av utan att någons lösenord ändras och utan att de andra integrationerna går sönder.
Lösenordspolicy ⚙ En minsta längd som upprätthålls när ett lösenord anges, med en styrkemätare som visas medan det skrivs. Du anger minimivärdet. Det är noll från start, vilket betyder att beslutet hör till driftstarten snarare än är något man upptäcker senare.

Det finns avsiktligt ingen inställning för tvingade teckenklasser – en versal, en siffra, en symbol. Det är inget förbiseende. Både forskning och aktuell vägledning från NIST har funnit att sådana regler är kontraproduktiva: de driver folk mot förutsägbara utbyten och mot att skriva ner lösenord, och de ger mindre än längd gör. Längd plus en andra faktor är kombinationen som fungerar.
Skydd mot lösenordsgissning ✓ Påslaget som standard. Efter tio misslyckade försök nekas varje ytterligare försök i sextio sekunder räknat från det senaste misslyckandet – så en gissningsattack stryps till ett försök i minuten i stället för tusentals. Båda talen är inställningar som en databasadministratör kan ändra (eller stänga av, genom att sätta det första till noll). Det fungerar utan att någon behöver märka att attacken pågår.
Ny autentisering för känsliga åtgärder ✓ Att ändra säkerhetsinställningar, registrera en andra faktor eller skapa en API-nyckel kräver att personen bevisar vem de är igen, även mitt i en session. En obevakad skärm kan inte användas för att försvaga kontot den är inloggad på.
Att byta lösenord avslutar varje session ✓ Sessionens giltighet härleds från själva kontot, så att byta lösenord eller inaktivera ett konto ogiltigförklarar varje befintlig session överallt på en gång – varje webbläsare, varje enhet, omedelbart. Det är det som gör ”någon har slutat, stäng ute dem” till en enda åtgärd i stället för en förhoppning.
Företagsinloggning, där ni använder det ⚙ Odoo kan autentisera mot er befintliga katalog (LDAP eller Active Directory) eller en OAuth2-identitetsleverantör, så att nyanställda och avgående hanteras en gång, på det ställe där organisationen redan hanterar dem. Valfritt, och bara värt att göra om ni redan har en.
Portaldokument bakom en andra faktor ⚙ Den här är vår snarare än Odoos, och den finns eftersom en klients inloggning är den svagaste punkten i varje kliniskt system. Slå på den, så kan en portalanvändare som inte registrerat en andra faktor fortfarande logga in och se att dokument finns – men inte öppna något förrän de gör det. Den påverkar personer som redan använder portalen, så berätta för dem innan du slår på den.
✓Påslaget som standardFungerar från det ögonblick systemet installeras. ⚙Byggt – du slår på detFinns och stöds. Om det ska användas, och hur strikt, är ditt beslut.

Vad ”rollbaserad” faktiskt betyder här

Nästan varje system påstår sig vara rollbaserat. Uttrycket är värt att packa upp, eftersom det i de flesta produkter betyder att menyn ändras och i Odoo betyder att datan ändras.

En roll i Odoo är en grupp. Grupper kan innehålla andra grupper, så en handledare automatiskt har allt en behandlare har utan att någon skriver behörigheterna två gånger – och när en behörighet rättas rättas den en gång för alla som ärver den. Det en grupp ger är inte en vy. Det är fyra separata behörigheter (läsa, skapa, ändra, radera) på varje sorts post, plus filter som avgör vilka poster av den sorten, plus möjligheten att dölja enskilda fält.

Den viktiga följden: att dölja en meny är ingen behörighet. I ett system där roller bara ändrar menyn når den som lär sig en webbadress datan bakom den. I Odoo ligger kontrollerna i datalagret, så samma nej kommer oavsett om posten nås via en vy, en rapport, en export, en sökning eller fjärr-API:t. Det finns ingen väg som hoppar över dem.

01Roller är namngivna efter jobbet

Behandlande kliniker, handledare, verksamhetschef, journalansvarig, reception, dataskyddsansvarig, ekonom, avtalsansvarig. Receptionen har bara personuppgifter – inget kliniskt innehåll och ingen dokumentåtkomst av något slag.

Besvarar”Visa mig vad en receptionist kan se”
02Roller ger räckvidd, aldrig innehåll

Att ha behandlarrollen öppnar i sig ingen klients journal. Det gör vårdrelationen. Det är den enskilt viktigaste meningen om åtkomst på den här webbplatsen.

Besvarar”Kan en terapeut läsa hela mottagningens journaler?”
03Fyra behörigheter, inte en

Läsa, skapa, ändra och radera är separata för varje sorts post. Läsa utan att ändra är vanligt med avsikt: många roller måste se något de inte får ändra.

Besvarar”Vem kan ändra en faktura efter att den utfärdats?”
04Radfilter avgör vilka poster

”Dina egna klienter”, ”ditt eget företag”, ”bokningar som hör till dig”. Tillämpas på varje fråga, så de gäller lika för listor, rapporter, exporter och API:t.

Besvarar”Vad hindrar en export från att dra ut allt?”
05Globala regler kan inte vidgas

En regel som inte är kopplad till någon grupp gäller alla och kombineras med varje annan regel, så den smalnar av åtkomsten och kan aldrig kringgås genom att lägga till en roll. Separationen mellan företag är byggd på det sättet.

Besvarar”Kan en mottagning se en annan mottagnings data?”
06Enskilda fält kan döljas

Två personer kan öppna samma post och se olika mycket av den. Används här för kostnads- och marginalsiffror, och för de fält bara en journalansvarig ska läsa.

Besvarar”Ser alla som ser ett avtal också dess marginal?”
07Klienter är en annan klass av användare

En portalanvändare har ingen som helst åtkomst till backoffice – inte en begränsad vy av det, ingenting. De når bara sidorna som publicerats för dem. Öppna webbsidor körs som en anonym användare med nästan inget beviljat.

Besvarar”Vad är det värsta som kan hända om en klients inloggning stjäls?”
08Varje väg anger sin egen åtkomst

Varje webbadress i den här driftsättningen anger om den kräver en inloggad användare eller är avsiktligt öppen: 174 kräver inloggning, 57 är öppna med avsikt. Inget är öppet av misstag.

Besvarar”Vilka av era URL:er fungerar utan inloggning?”
09Allt är läsbar konfiguration

Behörigheter levereras som vanliga textfiler i varje modul. Ert eget säkerhetsteam kan läsa vem som får vad utan att köra systemet, och jämföra det mellan versioner.

Besvarar”Kan vi granska behörigheterna själva?”

En databas per mottagning, och ingen väg över

Era data finns i en egen databas. Det är inte en delad tabell med en kundkolumn i, vilket är upplägget där en felaktig fråga returnerar någon annans uppgifter.

Odoo upprätthåller den separationen vid anslutningen: en begäran har ett värdnamn, värdnamnet väljer exakt en databas, och det finns ingen väg från insidan av en databas till en annan som körs på samma server. Inget i applikationen kan adressera en databas den inte är ansluten till. Därtill är vyerna som skapar, kopierar, återställer och raderar hela databaser stängda i produktion, så ingen som surfar till servern kan räkna upp vad som finns där.

Inuti er egen databas gör ett andra lager samma jobb mellan företag: driver ni mer än en mottagning i en installation skrivs separationen mellan företag som globala regler – den sort som gäller alla och aldrig kan vidgas genom att lägga till en roll.

OWASP Top Ten, och var Odoo står i varje punkt

Open Web Application Security Project publicerar listan över de vanligaste sätten webbapplikationer bryts in i. Det är listan en säkerhetsgranskare går igenom, så här är den med Odoos svar på varje punkt. Mönstret värt att lägga märke till är att de flesta förhindras av ramverkets design snarare än av att utvecklare kommer ihåg att vara försiktiga – vilket är den enda sortens förebyggande som överlever mötet med en deadline.

AttackenStatusVarför den inte fungerar här
Injektion, särskilt SQL-injektionfientlig indata som behandlas som ett kommando ✓ Applikationskoden skriver inte databasfrågor för hand. De byggs av ramverket från strukturerade filter, med varje värde skickat separat från själva frågan, så text som någon skrivit kan aldrig bli en del av kommandot. En utvecklare skulle behöva anstränga sig för att skriva en rå fråga, och de kliniska modulerna gör det inte.
Cross-site scriptingtext som sparats av en person körs som kod för en annan ✓ Allt som renderas i en sida escapas som standard. Att lägga rått innehåll i en sida måste begäras uttryckligen och syns i koden när det görs. Standardläget är säkert, så att glömma ger något fult snarare än något farligt.
Cross-site request forgeryen annan webbplats skickar ett formulär som din inloggade användare ✓ Varje formulär som ändrar data måste ha en token knuten till personens session, och servern avvisar ett inskick utan den. Token finns bara för att personen verkligen laddade er sida, och en angripares webbplats kan inte få tag i den.
Körning av skadliga fileratt få servern att köra kod du skickat ✓ Det finns ingen funktion som inkluderar en fjärrfil. Där privilegierade användare kan skriva små uttryck för att anpassa beteendet körs de i en sandlåda som blockerar åtkomst till filsystemet, till nätverket och till allt vars namn börjar med ett dubbelt understreck – en medvetet kort lista över tillåtna operationer snarare än en lista över förbjudna.
Osäker direkt objektreferensatt ändra ett nummer i en URL för att nå någon annans post ✓ Det här är den som fångar de flesta system, och Odoos svar är strukturellt: åtkomstkontrollen är inte implementerad i vyerna. Att ändra ett postnummer i en webbadress når samma kontroll i datalagret som allt annat och nekas där. Det finns ingen risk i att en referens syns, eftersom det inte är referensen som ger åtkomst.
Bristande begränsning av URL-åtkomstatt nå en sida genom att känna till dess adress ✓ Samma svar, och värt att säga två gånger eftersom det är skillnaden mellan verklig åtkomstkontroll och en prydlig meny. Säkerheten här bygger inte på att en länk är dold. Där en sida verkligen måste fungera utan inloggning – en klient som bekräftar en tid från ett mejl – har adressen en signerad token som är unik för den posten och den personen.
Osäker kryptografisk lagringinloggningsuppgifter som skyddas svagt eller inte alls ✓ Lösenord hashas med PBKDF2-SHA512 och nyckelsträckning, som beskrivs ovan, och kan helt undvikas lokalt genom att autentisera mot er egen katalog eller identitetsleverantör. Kliniska dokument går ännu längre: krypterade per version under nycklar som förvaras utanför databasen.
Osäker kommunikationtrafik som skickas i klartext ✓ Krypterade anslutningar hela vägen, med okrypterade förfrågningar omdirigerade i stället för besvarade, och webbläsarhuvuden som vägrar en nedgradering. Eftersom plattformen driftas av er själva är det här en kontroll i driftsättningen snarare än en egenskap hos programvaran – den sätts upp som en del av en standardinstallation och beskrivs i avsnitt 07.
Att nå interna funktioner via API:tatt anropa något som aldrig var tänkt att anropas ✓ Finns inte på OWASP-listan men är värd att lägga till, eftersom det är den folk antar är en lucka. Fjärr-API:t vägrar att anropa någon intern metod – allt vars namn börjar med ett understreck, plus en namngiven lista med farliga metoder. Bara metoder som avsiktligt publicerats kan nås utifrån, vilket kraftigt begränsar vad ett misstag i applikationskoden kan röja.

Öppen källkod, och vad det faktiskt är värt

”Öppen källkod” sägs ofta som om det vore en säkerhetsfunktion i sig. Det är det inte. Det det ger dig är konkret och värt att namnge exakt.

Du kan kontrollera i stället för att tro

Varje rad i Odoo Community och varje rad i de kliniska modulerna kan läsas av ert eget säkerhetsteam eller av testare ni anlitar. Behörigheter levereras som vanliga textfiler. Inget på den här sidan behöver tas på förtroende, vilket är ett annat läge än en sluten produkt där samma påståenden bara kan hävdas.

Det är en inbjudan att granska, inte en ersättning för granskning.

Många fler tittar på den

Odoo granskas löpande av användare, bidragsgivare och oberoende säkerhetsforskare världen över, och felrapporter från gemenskapen är en verklig källa till återkoppling om säkerhet. Odoo har ett program för ansvarsfullt avslöjande och publicerar rättelser som säkerhetsmeddelanden.

Den egna utvecklingsprocessen omfattar kodgranskning där säkerhet är en av de saker som granskas, för ny kod och bidragen kod lika.

Ni styr när rättelser landar

Egen drift innebär att säkerhetsrättelser tillämpas på er installation enligt er tidsplan i stället för att dyka upp över natten. Det är en fördel för en klinisk verksamhet som måste validera ändringar – och det är också en skyldighet, eftersom en rättelse som ingen tillämpar inte skyddar någon.

Att hålla systemet uppdaterat står på driftansvarigas lista i avsnitt 07, och det är det enskilt vanligaste sättet som en i övrigt välbyggd installation till slut blir komprometterad.

En skillnad värd att vara noggrann med

Odoo publicerar en egen säkerhetssida, och delar av den beskriver Odoos molntjänst – deras härdade serveravbilder, deras uppdateringar, det lilla antal av deras tekniker som kan nå en maskin och bara via en krypterad nyckel från en krypterad bärbar dator. De är verkliga, och de är inte dina, eftersom den här plattformen är egen driftad på er egen infrastruktur.

Allt på den här sidan ovanför linjen är en egenskap hos programvaran och gäller er exakt som det står. Motsvarigheterna på serversidan – härdat operativsystem, uppdateringar, vem som har SSH-åtkomst, fullständig diskkryptering på maskinerna som administrerar den – är era att sköta, och de redovisas ärligt i avsnitt 07, inklusive de delar som hör till den som driver servrarna. Att läsa Odoos sida om molnet och anta att den beskriver er driftsättning är det vanligaste misstaget om egen driftad Odoo, och det är den sortens sak som rasar vid en due diligence-granskning.

Där Odoos modell slutar och den kliniska börjar

Odoos fyra lager är starka, vältestade och räcker för vanliga affärsuppgifter. De räcker inte ensamma för en journal, av ett skäl: de är konfiguration, och konfiguration kan ändras av någon med rätt roll. Det är därför kliniska dokument dessutom krypteras under nycklar som förvaras utanför databasen, och därför psychotherapy notes använder ännu en annan nyckel. Om varje Odoo-regel i systemet vore fel i morgon skulle det krypterade innehållet ändå inte öppnas.

07 — Servern

Hur själva maskinen härdas

Applikationssäkerhet räknas bara om servern under den är ordentligt stängd. Plattformen driftas av er själva, vilket betyder att den körs på infrastruktur ni kontrollerar snarare än i en leverantörs moln. Det är en verklig fördel för en vårdverksamhet, och den kommer med en verklig skyldighet: härdningen nedan är en del av installationen, och den måste hållas sann efteråt.

Allt i den första tabellen sätts upp som en del av en standardinstallation och är dokumenterat i installationsguiderna. Den andra tabellen är delen som hör till den som driver servrarna.

OmrådeHur det är konfigureratVarför det görs så
Inget exponeras direkt Applikationstjänsterna lyssnar bara på själva maskinen. All trafik utifrån kommer via en omvänd proxy i nginx, som är det enda som finns på en öppen port En ytterdörr i stället för flera. Certifikat, huvuden, begränsningar och loggning tillämpas alla på ett ställe
Kryptering under överföring TLS-certifikat från Let's Encrypt, utfärdade och förnyade automatiskt. Vanlig HTTP omdirigeras till HTTPS i stället för att besvaras Det finns ingen okrypterad väg in, inte ens av misstag, och förnyelsen är inget en person måste komma ihåg
Säkerhetshuvuden i webbläsaren Strict-Transport-Security i ett år, X-Frame-Options satt till same-origin, X-Content-Type-Options satt till nosniff Webbläsaren vägrar att nedgradera till HTTP, vägrar att låta webbplatsen ramas in av en annan webbplats och vägrar att gissa filtyper
Brandvägg Bara portarna 80 och 443 är öppna mot världen. Applikationsportar, databasen och Redis kan inte nås utanför maskinen Databasen kan aldrig adresseras från internet. En telefon är minst två steg från varje rad
Hastighetsbegränsning Begränsningar i proxyn för inkommande förfrågningar, plus token buckets i Redis inuti gatewayen för öppna vägar och läsningar av dokument i portalen Proxyn stoppar flodvågor. Räknarna i Redis gäller över flera serverprocesser, så en gräns per användare betyder vad den säger
Ett värdnamn, en databas Odoo är konfigurerat så att värdnamnet i begäran väljer exakt en databas, och vyerna för databashantering är stängda Ingen som surfar till servern kan lista, kopiera, återställa eller radera en databas
Tjänster, inte skal Gatewayen och Odoo körs som hanterade systemtjänster under egna konton, startas automatiskt och startas om vid fel Inget körs som ett administratörskonto, och en omstart beror inte på att någon är inloggad
Hemligheter bara på servern Signeringsnycklar och tredjepartsuppgifter finns i en miljöfil som bara tjänstekontot kan läsa. Mobilappen levereras utan någon av dem Appen kan plockas isär utan att något avslöjas. En roterad inloggningsuppgift börjar gälla för alla på en gång, utan en ny appversion
Krypterade dokument förvaras separat Chiffertext skrivs till en egen katalog med egna behörigheter, utanför Odoos vanliga fillagring, och serveras aldrig via den vanliga nedladdningsvägen En felkonfigurerad webbserver kan inte av misstag publicera kliniska filer
Huvudnyckeln kontrolleras vid start Krypteringsmodulen läser nyckeln från en egen sökväg och vägrar att starta om filen saknas, är läsbar för alla, ägs av fel konto eller ligger i en katalog som säkerhetskopieras tillsammans med data Det vanligaste verkliga nyckelfelet är att nyckeln hamnar i samma säkerhetskopia som de data den skyddar. Programvaran kontrollerar det i stället för att lita på en rutin
WebSocket i samma kanal Chatt, närvaro och signalering för samtal uppgraderas genom samma proxy och samma certifikat som allt annat En anslutning, en policy, ingen andra lyssnare att säkra för sig
Spårning av förfrågningar Varje förfrågan har en identifierare genom gatewayen och tillbaka ut i svarshuvudena, tillsammans med hur lång tid den tog En incident kan rekonstrueras över tjänster i stället för att gissas fram ur separata loggfiler

Härdningen som hör till den som driver servrarna

Det här är inga luckor i programvaran. Det är beslut och rutiner som bara driftansvariga kan fatta, och ingen leverantör kan fatta dem åt dig. De listas rakt ut så att ingen antar att de är täckta.

  • Uppdatering av operativsystemet. Ett schema för säkerhetsuppdateringar på värden, och någon vars uppgift det är att bekräfta att de tillämpades.
  • Diskkryptering på värden. Dokument krypteras var för sig av plattformen, men fullständig diskkryptering skyddar allt annat på maskinen, inklusive loggar och temporära filer.
  • Säkerhetskopior, och deras kryptering. Vart säkerhetskopiorna går, hur de krypteras, vem som kan återställa dem och hur länge de sparas. En säkerhetskopia är en fullständig kopia av era data utan någon av era åtkomstregler kopplad till sig.
  • Huvudnyckeln säkerhetskopieras separat. Går nyckeln förlorad är varje krypterat dokument förlorat för alltid – det är poängen med designen. Den måste säkerhetskopieras, och den får inte säkerhetskopieras tillsammans med data.
  • Administrativ åtkomst till servern. SSH-nycklar i stället för lösenord, ingen direkt root-inloggning, en förteckning över vem som har åtkomst, och att ta bort den samma dag någon slutar.
  • Test av återställning. En säkerhetskopia som ingen någonsin återställt är en förhoppning, inte en kontroll. Testa den enligt ett schema och skriv ner att ni gjorde det.
  • Övervakning och larm. Någon måste få veta när en tjänst stannar, en disk blir full, ett certifikat snart går ut eller ett schemalagt lagringsjobb slutar köras.
  • Flerfaktorsautentisering för personalkonton. Starkt rekommenderat för alla som når kliniskt innehåll, och i praktiken ett krav om den föreslagna uppdateringen av HIPAA Security Rule fastställs. Kontrollera med er administratör om det är påslaget i er driftsättning.
  • Placering i nätverket. Om databasen ligger på samma maskin eller en separat, vad som kan nå den, och om administrationen sker över ett privat nätverk eller ett VPN.
  • Penetrationstester. Systemet är öppen källkod och driftas av er själva just för att era egna testare ska kunna granska det ordentligt. Det är en inbjudan, inte en ersättning för att göra det.
08 — Skydd i flera lager

Fyra lager, och vart och ett nekar något som nästa aldrig ser

Skydd i flera lager betyder att inte förlita sig på något enskilt skydd. En begäran måste ta sig förbi alla fyra lagren nedan. Värdet är inte att något av dem är omöjligt att bryta. Det är att de misslyckas på olika sätt, så ett misstag i ett av dem är mycket osannolikt ett misstag i alla fyra.

1 · Enhet och yta Det en person håller i handen Obetrott
Inga hemligheter på enhetenAppen har bara publika nycklar. Den kan plockas isär utan att något avslöjas.
Biometrisk inloggning och applåsOvanpå telefonens egen skärmlåsning, inte i stället för den.
Token i säker lagringFörvaras i plattformens nyckelring, inte i vanliga appfiler.
Databasen går inte att nåAppen kan inte adressera databasen alls, i något nätverk.
HTTPS · kortlivad token
2 · Gateway Den enda backend appen känner till Håller hemligheterna
Varje tredjepartsnyckel finns härInloggningsuppgifter för betalningar, AI, meddelanden och lagring lämnar aldrig servern.
Kortlivade signerade tokenVar och en anger vem den gäller, när den utfärdades, när den löper ut och ett unikt id. Förnyas i stället för att vara långlivade.
LösenordshashningEnvägs, med schemat uppgraderbart utan återställning.
HastighetsbegränsningRäknare i Redis, delade över varje serverprocess.
Validering av indataFelaktiga förfrågningar avvisas här, innan affärskärnan ens ser dem.
Signerade länkar som löper utMedia går via en proxy. Inget serveras från en adress du skulle kunna gissa.
tjänstekonto · minsta behörighet
3 · Affärskärna Där reglerna faktiskt finns Auktoritativ
Grupper, åtkomsträttigheter och postreglerOdoos fyra lager, tillämpade hur posten än nås.
Upplösning av vårdteametDet enda stället som avgör vem som får öppna en journal.
Kliniska rollerAvgör vilken del av applikationen någon når. Aldrig vad de kan öppna.
Huvudbok som inte kan ändrasEn utfärdad faktura är fast. En rättelse är en kreditnota.
Daterade avtalsversionerVillkor kan inte antedateras och historiken finns kvar.
krypterat i vila · nycklar förvarade separat
4 · Lagring och nycklar Det som överlever en stulen disk Kryptografi
Katalog för chiffertextUtanför fillagret, utanför databasen, med egna behörigheter.
HuvudnyckelnPå disk, ägd av tjänstekontot, aldrig i samma säkerhetskopia som data.
En andra nyckel för terapianteckningarDen vanliga nyckeln öppnar dem inte, vad reglerna än säger.
Hashkedjad granskningsloggEndast tillägg. Manipulering går att upptäcka, den är inte bara avrådd.
09 — Praxis i vårdbranschen

Kontrollerna en klinisk granskare frågar särskilt om

Brandväggar och kryptering förväntas av vilket system som helst. De nio nedan är de som dyker upp just vid en granskning inom psykisk hälsa, och som en allmän dokumenthanterare inte kan uttrycka alls. Var och en är skriven med den fråga den besvarar, eftersom det oftast är så den kommer.

01Vårdrelationer

En registrerad koppling mellan en behandlare och en klient, med en typ, en början och ett slut. När relationen upphör upphör också åtkomsten, efter en frist som räcker för att göra klart utestående anteckningar.

Besvarar”Hur upprätthåller ni minsta nödvändiga?”
02Inlämnat till ledningen

Incidenter, klagomål och skyddsanmälningar går till verksamhetschefen och är stängda för den som lämnade in dem, och för den som klagomålet gäller.

Besvarar”Kan en anställd läsa klagomålet mot sig själv?”
03Begäranden om rättigheter som arbetsflöden

Begäranden om tillgång har sin lagstadgade frist. Begäranden om rättelse lägger till en version i stället för att skriva över. Begäranden om begränsning förseglar de dokument de gäller.

Besvarar”Visa mig en begäran om registerutdrag från början till slut”
04Register över utlämnanden

Vad som lämnade verksamheten, till vem och på vilken rättslig grund. Det här är uppgiften en person i USA har rätt att begära sex år av.

Besvarar”Vem har ni delat den här personens uppgifter med?”
05Ankare för lagring

Senaste kontakt, födelsedatum och dödsdatum sparas som datum att räkna från, eftersom en regel skriven i år är meningslös utan en startpunkt.

Besvarar”Hur vet ni när det här ska gallras?”
06Påminna efter status, aldrig efter innehåll

Försenade samtalsrapporter hittas efter frist och läge. En chef kan se att en rapport saknas utan att öppna en som inte finns.

Besvarar”Läser chefer journalanteckningar för att driva mottagningen?”
07Identitets- och ålderskontroller

En automatisk ansiktskontroll först, sedan en kö för mänsklig granskning vid behov. Identitetshandlingarna krypteras medan de förvaras och raderas automatiskt när kontrollen är klar.

Besvarar”Vad händer med id-handlingen efteråt?”
08Klinisk e-signatur

Intygande av beslutsförmåga, underskrift för en klients räkning, handledarens medunderskrift och ett samtycke som kan återkallas senare i stället för att vara en engångsbock.

Besvarar”Hur samlas samtycke in, och kan det återkallas?”
09Signeringen stannar internt

Signaturtjänsten körs på era egna servrar med en egen hashkedjad logg. Inget dokument skickas till ett externt företag för att signeras, och det finns ingen leverantörsfaktura per signatur.

Besvarar”Vilka tredje parter ser våra signerade dokument?”
10 — Om något går fel

Två frister från ett ögonblick, och ett undantag du måste förtjäna

Krypteringen är utformad som den är till stor del på grund av det här avsnittet. Både GDPR och HIPAA godtar att korrekt krypterade uppgifter är oläsbara och därför egentligen inget röjande. Men det undantaget gäller bara om du kan visa att nycklarna inte också togs. Hela designen för nyckelförvaring finns för att du ska kunna visa det.

Att få kännedom

Båda fristerna nedan börjar i det ögonblick du får kännedom, inte i det ögonblick incidenten inträffade. Det gör att fastställa och registrera det ögonblicket till det första du gör, i stället för något som rekonstrueras senare.

Informera tillsynsmyndigheten

GDPR artikel 33 ger dig 72 timmar från att du fått kännedom att anmäla till tillsynsmyndigheten – ICO i Storbritannien, den berörda nationella myndigheten i Europeiska unionen. Den fristen gäller oavsett om uppgifterna var krypterade.

Informera de berörda

Artikel 34 kräver att du också informerar individerna, om inte uppgifterna var krypterade. Artikel 34.3 a behandlar korrekt krypterade uppgifter som oläsbara för den som tog dem. HIPAA har samma tanke och kallar den safe harbour.

Togs nycklarna också?

Undantaget hänger helt på den här enda frågan, så systemet ställer den uttryckligen och en obesvarad fråga räknas emot undantaget. Att stänga en incident som inte anmälningspliktig kräver underlag, eftersom ett undantag som åberopas utan underlag faller när det granskas.

En incidentpost, delad, med varje lands regler ovanpå

Själva incidentposten finns i den gemensamma kärnan: när du fick kännedom, vad som berördes, vilka som påverkades, om uppgifterna var krypterade och om nycklarna togs. Varje jurisdiktionsmodul lägger sedan till sina egna skyldigheter ovanpå den enda posten. Den europeiska modulen lägger till 72-timmarsfristen i artikel 33 och beslutet enligt artikel 34. Den amerikanska modulen lägger till riskbedömningen i fyra faktorer, 60-dagarsfristen mot individer, tröskeln för medier över 500 invånare i en delstat och rapporteringen till Department of Health and Human Services. En incident, bedömd en gång, mot de regler som gäller för dig.

Åtkomstloggen är utredningen

Eftersom varje läsning loggades innan något innehåll lämnades ut har frågan ”vad röjdes faktiskt, och för vem?” ett verkligt svar i stället för en uppskattning. Det är skillnaden mellan att informera elva personer och att informera alla i databasen.

11 — Plattformens kontroller

De vanliga frågorna, besvarade på ett ställe

Inget i den här tabellen är ovanligt. Det står här för att en granskare kommer att fråga, och för att en leverantör som inte snabbt kan svara på de här frågorna oftast inte kan svara på de svårare heller.

OmrådeVad som finns på platsVarför det görs så
InloggningLösenord sparas bara som envägshashar. Kortlivade signerade token som anger vem användaren är, när token utfärdades, när den löper ut och ett unikt idEn stulen token löper ut av sig själv, och hashningen kan uppgraderas utan att någon behöver byta lösenord
Förvaring av hemligheterVarje tredjepartsuppgift finns på servern. Mobilappen har bara publika nycklarAppen kan dekompileras utan att något går förlorat. Att rotera en nyckel börjar gälla för alla användare på en gång, utan en ny version i appbutiken
ÖverföringHTTPS överallt, inklusive den WebSocket som används för chatt, närvaro och signalering för samtalEn anslutning, en policy och ingen reserv i klartext
HastighetsbegränsningBegränsningar i proxyn, plus räknare i Redis på öppna vägar och på läsningar av dokument i portalenRäknas från delat tillstånd, så en gräns per användare gäller över varje serverprocess i stället för per process
MediaGår via gatewayen med signerade länkar som löper ut. Inget serveras från en sökväg som går att gissaLagringen adresseras aldrig direkt av en klients enhet
DatabasKan inte nås från någon klient. Gatewayen ansluter till kärnan via ett tjänstekonto med bara de rättigheter det behöverTvå separata steg mellan en telefon och en rad, vart och ett med en egen chans att neka
Öppna formulärreCAPTCHA på webbplatsens formulär, och telefonnummer normaliserade när de matas inSkräppost och felaktig indata avvisas innan de blir poster som någon måste städa upp
Att gissa referenserEtt dokument du inte får se ger ”hittades inte”, aldrig ”förbjudet”Annars berättar skillnaden mellan de två svaren för en angripare vilka poster som finns
KlientkontonPortalanvändare har ingen som helst åtkomst till backoffice. Tvåfaktorsautentisering levereras med plattformen och kan göras obligatorisk för all personal, eller för alla, med en inställning – och åtkomst till dokument i portalen kan placeras bakom denDet värsta som kan hända med en komprometterad klientinloggning är att den klientens egna uppgifter röjs, och med portalspärren påslagen inte ens det
Exponering mot tredje partBetalningar, artificiell intelligens, meddelanden och lagring sitter var för sig bakom ett gränssnitt med en attrapp på andra sidan av ett reglageLeverantörer kan bytas. Demonstrationer och tester körs utan något levande leverantörskonto och helt utan riktiga data
Licenser och driftOdoo 19 Community och komponenter med öppen källkod rakt igenom, körda på er egen infrastrukturErt eget säkerhetsteam kan läsa koden i stället för att ta en leverantörs ord för det
12 — Vad du kan bevisa

Skillnaden mellan en kontroll och ett löfte

Vid en revision, en upphandling eller ett klagomål är det inte vad du avsåg som räknas. Det är vad du kan visa. Nedan är de sex frågor som oftast dyker upp, och vad systemet tar fram som svar på var och en.

Vem läste den här uppgiften?Åtkomstlogg
En fullständig, hashkedjad lista som ingen kan ha ändrat – inte heller era egna administratörer
Ändrades den här uppgiften?Versionshistorik
Rättelser är nya versioner och den tidigare är intakt, så en ändring syns i stället för att vara något du sluter dig till
Förstördes utgångna uppgifter?Förstörelse av nyckeln
Nyckeln är borta, och det tomma skalet bevisar att filen fanns och gallrades enligt plan
Vem delade vi dem med?Register över utlämnanden
Vad som lämnade verksamheten, till vem och på vilken rättslig grund – sex år av det, på begäran
Kunde en administratör ha sett det?Behörighetsmodellen
Stängt som standard utan huvudöverstyrning. Ett administratörskonto ger ingenting, och nödåtkomst är en loggad, granskad händelse
Är huvudboken pålitlig?Ekonomiska kontroller
Utfärdade fakturor kan inte ändras, utbetalningsrader anger avtalsversionen som prissatte dem, och inget faktureras utan att en person bekräftar det
13 — Där programvaran slutar

Det ingen plattform kan göra åt dig

Programvara gör inte en organisation regelefterlevande. Den gör regelefterlevnad möjlig, och den gör det möjligt att bevisa den. Att vara rak om den gränsen är värt mer vid en granskning än en längre lista med påståenden, så här är gränsen i sin helhet.

Det här är ingen juridisk rådgivning, och ingen produkt är certifierad

Inget på den här sidan är juridisk rådgivning. Ingen programvara är HIPAA-certifierad eller GDPR-certifierad, eftersom ingen myndighet utfärdar sådana certifikat för produkter. Det som finns är en uppsättning tekniska och organisatoriska åtgärder. Den här plattformen genomför de tekniska och stöder de organisatoriska. Resten hör till er organisation, och en bra rådgivare säger exakt samma sak.

  • Avtalen är era att underteckna. Business associate agreements i USA, personuppgiftsbiträdesavtal och villkor för underbiträden i EU och Storbritannien. Plattformen modellerar dem. Den ingår dem inte åt er.
  • Era jurister bekräftar formuleringen. Varningen mot vidareutlämnande enligt 42 CFR Part 2 genereras i stället för att skrivas, just för att den inte ska kunna glida över tid. Men förordningen föreskriver innehållet, och det behöver granskas juridiskt innan ni går i drift.
  • Lokal lag går längre än grundnivån. Delstatliga lagar i USA – Kaliforniens CMIA, och regler i bland annat New York och Texas – går längre än HIPAA. I EU lägger medlemsstaternas lagstiftning till saker till GDPR: Tysklands §203 StGB och §630f BGB är exempel. Lagringstider i synnerhet måste bekräftas med juridiskt ombud för ert eget land.
  • Personalens beteende är ingen programvarukontroll. Utbildning, nyanställda och avgående, disciplinära förfaranden och vem som över huvud taget får en vårdrelation är beslut som systemet registrerar men inte fattar.
  • Fysisk säkerhet och infrastrukturens säkerhet hör till driftansvariga. Var servrarna står, vem som kan gå fram till dem, hur säkerhetskopior krypteras och förvaras utanför lokalerna, hur huvudnyckeln förvaras, och det katastrofåterställningstest ni faktiskt kör snarare än det som står i planen.
  • Penetrationstester och sårbarhetshantering är ett program, inte en funktion. Systemet är öppen källkod och driftas av er själva så att ert eget team eller era egna testare kan granska det ordentligt. Det är en inbjudan, inte en ersättning.
  • Organisationer som arbetar mot NHS fyller i Data Security and Protection Toolkit. Den bedömningen handlar om er organisation och dess människor, och ligger utanför vad någon programvara omfattar.
  • Någon måste hålla ögonen på lagringsmotorn. Lagring och gallring körs som schemalagda jobb. Ett schemalagt jobb som tyst slutar köras är ett regelefterlevnadsproblem som bara kommer fram vid en revision, och det är därför kontrollen av det ingår i månadsrutinen.
Hela sidan i ett stycke, för en granskare som har bråttom

Journaler krypteras en version i taget, under nycklar som förvaras utanför databasen. De öppnas bara när en uttrycklig regel tillåter det, och den regeln följer vårdrelationen snarare än befattningen. Varje läsning skrivs till en logg som ingen kan ändra. Rättelser läggs till som nya versioner i stället för att skriva över den gamla. När lagringstiden löper ut förstörs nyckeln, vilket gör innehållet oläsbart men lämnar bevis för att det fanns och gallrades. Ovanpå samma kärna lägger en jurisdiktionsmodul till maskineriet för rättigheter och styrning för USA, Europeiska unionen eller Storbritannien. Under den skyddar Odoo Communitys åtkomstmodell i fyra lager de vanliga affärsuppgifterna, och servern är stängd bakom en enda proxy med TLS, brandvägg och hastighetsbegränsning.

14 — Vart du går härnäst

Resten av bilden

Den här sidan är ståndpunkten om säkerhet och regelefterlevnad. Översikten visar hur delarna passar ihop, katalogen listar modulerna där de här kontrollerna faktiskt finns, och administratörens ritning täcker rutinen som håller allt det här underlaget sant månad efter månad.

MaskinenSystemöversiktFyra lager, och var hemligheterna och uppgifterna faktiskt finns. ReferensModulkatalogModulerna för säkra dokument, journaler och e-signatur i sin helhet. RitningAdministratörHandlingsakten, kontrollerna av lagring och den kvartalsvisa genomgången. RitningKlientVad en klient får veta om sina egna uppgifter, och vad de kan begära.