Sikkerhet & etterlevelse · Raznameh Clinics

Begynn her

Velg landet du driver i

Det meste av det som følger er det samme over alt — krypteringen, tilgangsstyringen, revisjonsloggen, herdingen av serveren. Det som varierer med landet, er rettighets- og styringsmaskineriet oppå, og det har en egen side. Gjør du en selskapsgjennomgang, begynn med ditt eget land og kom tilbake til det felles stoffet etterpå.

USA USA HIPAA · HITECH · 42 CFR Part 2 · delstatsrett Den største av de tre. Hver amerikanske regel som når en praksis innen psykisk helse, hva som er bygget for hver av dem, og — til slutt — sju gjennomganger steg for steg av hva som faktisk skjer inne i programvaren.

Personvernregelen: hver pasientrettighet, også de delene de fleste systemer hopper over
Sikkerhetsregelen: alle åtte tekniske tiltak, pluss de administrative og fysiske registrene
Varsling ved avvik: fire momenter, 60 dager, terskler per delstat, begge leverandørklokkene
42 CFR Part 2, inkludert regelen fra 2024
Sju forløp — en journalforespørsel, en avvist retting, en utlevering, et avvik, en ny pasient, en skjerm som står ubrukt, og etterlevelsesåret

Den europeiske union GDPR Forordning (EU) 2016/679 Behandlingsgrunnlag etter artikkel 9 nr. 2 bokstav h framfor samtykke, sletting gjennomført ved å ødelegge krypteringsnøkkelen, dataportabilitet som en logget eksport, og de to fristene ved avvik med unntaket du må gjøre deg fortjent til.

Hvorfor behandlingsjournaler ikke kan hvile på samtykke
Sletting som oppfyller retten uten å ødelegge sporet
72-timersklokken og spørsmålet om nøklene er kompromittert
Behandlingsprotokoll og vurdering av personvernkonsekvenser som levende poster

Deutschland Tyskland § 203 StGB · § 630f BGB · NIS2 · SGB V De europeiske reglene gjelder her uendret — og så legger Tyskland til sitt eget lag, der én bit er strafferett og avgjør om en praksis i det hele tatt lovlig kan kjøpe av oss.

§ 203 StGB: hvorfor valget av leverandør er terapeutens juridiske risiko
Hva en § 203-erklæring sier, punkt for punkt
Ti år fra behandlingens slutt, ikke fra journalens dato
NIS2 for praksisgrupper, og programmet som alt er bygget
En ærlig gjennomgang av det offentlige sporet vi ikke er på

Storbritannia UK GDPR DPA 2018 · NHS Code of Practice 2021 Hva Storbritannia legger oppå GDPR: testen for alvorlig skade bygget som en arbeidsflyt som utløper av seg selv, NHS' oppbevaringsplan som data vi leverer med, og en rett over journalene til mennesker som er døde.

Tilbakehold som krever en navngitt fagperson og bortfaller etter seks måneder
Tjue år etter siste kontakt for journaler innen psykisk helse
Access to Health Records Act 1990
Caldicott-prinsipp 7, og hvorfor nødtilgang er en funksjon

Australia Privacy Act 13 APP-er · NDB-ordningen · oppbevaringsregler per delstat Én føderal lov uten unntak for små virksomheter når de er helsetilbydere, åtte sett delstatsregler om oppbevaring, og — siden juni 2025 — en pasient som kan gå til sak uten å vente på et tilsyn.

Alle de tretten australske personvernprinsippene, ett for ett
APP 8: hvorfor ingenting må forlate landet
Sju år fra siste oppføring, og til fylte 25 for et barn
Avviksforløpet, steg for steg, pluss 72-timersrapportering ved løsepengevirus
Essential Eight, ISO 27001, RACGP C6.4 — og hvorfor SOCI ikke gjelder

Canada PIPEDA & PHIPA 10 prinsipper · provinslover · oppbevaring etter yrkesforbund Ingen HIPAA, ingen enkelt lov: en føderal lov, en helselov som varierer med provinsen, og et yrkesforbund oppå begge som setter hvor lenge du bevarer en journal.

Hvilken lov og hvilket tilsyn, provins for provins
PIPEDAs ti prinsipper, og PHIPA forvalter for forvalter
Lockbox — det ene kanadiske begrepet vi ennå ikke har
To avviksklokker, og den årlige statistikkrapporten hver mars
Det provinsielle faktureringssporet vi ikke er på, sagt i avsnitt 09

Norge Norge § 14 tilgangslogg · helsepersonelloven · § 1-8 EØS-reglene gjelder uendret, og det norske laget handler om mennesker mer enn om papirarbeid: hva pasienten får se, hvem som regnes som helsepersonell, hvem som kan opptre på vegne av en pasient, og hvordan du engasjerer behandlerne som holder timene.

Pasientens egen tilgangslogg, også for journaler som holdes tilbake fra dem
HPR-autorisasjon, og en beskyttet tittel som ikke kan publiseres ukontrollert
Samtykke ved 16, og fortrolighet overfor foreldre fra 12
Bevar så lenge det er behov: en oppbevaringstype uten noen slettedato i det hele tatt
Presumsjonen om ansettelse i § 1-8, håndhevet ved utbetalingen

Suomi Finland asiakastietolaki 703/2023 · valvontalaki 741/2023 · Kanta Den ene landsiden som åpner med hva vi ikke er. Vi er ikke et sertifisert finsk journalsystem — og sikkerhetsplanen hver tilbyder må ha, er laget av nøyaktig de registrene denne plattformen fører.

De fire leverandørportene i Kanta, og hvorfor det segmentet er stengt for oss
Autoriserte mot tittelbeskyttede — psykoterapeutti er det andre
Tjenesteenheten, den ansvarlige personen, og den offentlige planen
Loggopplysninger: to år, to måneder, og et registrert tilbakehold
En mindreårigs modenhet vurdert sak for sak, uten noen alder i det hele tatt

Felles for alle åtte Sikre dokumenter Maskineriet hver landside hviler på Hvordan en klinisk journal krypteres, hvem som kan åpne en, hele livsløpet til et dokument fra arkivering til sletting — og, til slutt, sju risikoer som ikke har noen teknisk løsning.

Konvoluttkryptering, og hvorfor det er to nøkler og ikke én
Tilgang som følger behandlingsrelasjonen
Sletting ved å ødelegge en nøkkel framfor å slette en rad
Sju risikoer sagt rett ut, med hva som blir hos deg

01 — Begynn med loven

Hva HIPAA, GDPR og UK GDPR faktisk krever av deg

De fleste sikkerhetsdokumenter begynner med teknologien og lar loven vente til slutten. Dette gjør det motsatte, fordi loven er det du måles mot. Under står hvert regelverk i vanlig språk: hva det er, hvem det gjelder for, og pliktene det legger på en klinikk. Under hvert av dem står den delen av plattformen som gjennomfører plikten.

USA

HIPAA

HIPAA er Health Insurance Portability and Accountability Act. Den gjelder for helsetilbydere i USA og for selskapene som håndterer helseopplysninger på deres vegne. Den er bygget av to hoveddeler. Personvernregelen sier hvem som kan se helseopplysninger og hva en pasient kan be om. Sikkerhetsregelen sier hvordan elektroniske helseopplysninger må vernes.

Minste nødvendige. Ansatte kan bare se de opplysningene de trenger for oppgaven foran seg. I plattformen håndheves dette av behandlingsrelasjoner: en terapeut når klientene på sin egen liste, ikke hele klinikkens.
Det utpekte journalsettet. En pasient kan be om en kopi av journalen sin, men ikke om alt klinikken har. Hver dokumenttype er merket som innenfor eller utenfor det settet, og en forespørsel kan ikke returnere det som er utenfor.
Psykoterapinotater holdes for seg. HIPAA behandler en terapeuts egne prosessnotater annerledes enn journalen. I plattformen krypteres de under en annen nøkkel, så nøkkelen som åpner den vanlige journalen åpner dem ikke.
Oversikt over utleveringer. En pasient kan spørre hvem opplysningene deres er delt med de siste seks årene. Utleveringsregisteret svarer på det ut fra lagrede poster.
Varsling ved avvik. Blir vernede helseopplysninger eksponert, må folk få beskjed — med mindre opplysningene var riktig krypterte. Det unntaket kalles trygg havn, og det er grunnen til at krypteringen er bygget som den er.
42 CFR Part 2 er en egen amerikansk regel for journaler innen rusbehandling. Den er strengere enn HIPAA og krever en advarsel om videreformidling på alt som deles. Plattformen lager den meldingen framfor å be ansatte skrive den.

Den europeiske union

GDPR

GDPR er personvernforordningen. Den gjelder for enhver virksomhet som håndterer personopplysninger om mennesker i Den europeiske union. Helseopplysninger er det GDPR kaller særlige kategorier, som betyr at de er forbudt å behandle med mindre et bestemt vilkår er oppfylt. Der HIPAA mest handler om vern, handler GDPR også om den enkeltes rettigheter over sine egne opplysninger.

Et behandlingsgrunnlag for hver dokumenttype. For behandlingsjournaler er det riktige vilkåret artikkel 9 nr. 2 bokstav h, ytelse av helsehjelp — ikke samtykke. Et samtykke en person ikke fritt kan nekte er ikke et gyldig samtykke, og i en behandlingssituasjon kan de vanligvis ikke nekte. Plattformen registrerer grunnlaget på dokumenttypen, så det er aldri en gjetning senere.
Retten til innsyn (art. 15). En person kan be om en kopi av opplysningene sine, og det er en lovbestemt frist for å svare. Anmodningen kjører som en sporet arbeidsflyt med den klokken på.
Retten til sletting (art. 17). Ofte kalt retten til å bli glemt. Plattformen oppfyller den ved å ødelegge krypteringsnøkkelen framfor databaseraden, så innholdet er borte mens beviset for at en journal fantes og ble slettet består.
Retten til dataportabilitet (art. 20). En person kan be om opplysningene sine i en form de kan ta med seg. Plattformen bygger en zip-fil i minnet og strømmer den, og logger hvert dokument inne i den for seg.
Varsling ved avvik (art. 33 og 34). Tilsynet må varsles innen 72 timer etter at du ble kjent med avviket. De berørte må også få beskjed, med mindre opplysningene var krypterte.
Styringsdokumenter (art. 30 og 35). Du må føre en protokoll over behandlingsaktivitetene dine, og gjennomføre en vurdering av personvernkonsekvenser for arbeid med høy risiko. Begge lever i systemet som levende poster, ikke som en Word-fil som blir foreldet.

Storbritannia

UK GDPR og DPA 2018

Etter at Storbritannia forlot Den europeiske union beholdt landet GDPR nesten uendret og kaller den UK GDPR. Data Protection Act 2018 ligger ved siden av og legger til britiske regler, flere av dem betyr mye i helse. Tilsynet er Information Commissioner's Office, ICO.

Alt GDPR krever, gjelder fortsatt. Innsyn, sletting, dataportabilitet, varsling ved avvik og styringsdokumentene er de samme pliktene som i EU.
Testen for alvorlig skade. Helseopplysninger kan holdes tilbake fra en persons eget innsynskrav der utlevering sannsynligvis vil føre til alvorlig skade for dem. For en tjeneste innen psykisk helse er dette motstykket til det amerikanske unntaket for psykoterapinotater, og prosessen rundt det er streng.
NHS' oppbevaringstider. NHS Records Management Code of Practice 2021 setter hvor lenge journaler bevares — for psykisk helse, 20 år etter siste kontakt. Den planen leveres som startdata.
Access to Health Records Act 1990. Pårørende til en person som er død kan i noen tilfeller be om journalene deres. GDPR dekker ikke avdøde i det hele tatt, så dette er en rett bare Storbritannia har, med egne regler om hvem som har rett til å spørre.
Caldicott-prinsipp 7. Britisk helseveiledning sier at plikten til å dele opplysninger kan være like viktig som plikten til å verne dem. Å blokkere alt er sin egen form for svikt, og det er derfor nødtilgang finnes og registreres framfor å være forbudt.

Hva alle fire er enige om

Under forskjellene vil de fire regelverkene det samme fem tingene. Vern opplysningene slik at en stjålet kopi er verdiløs. La bare de riktige menneskene se dem. Før en oppføring over hvem som så dem. Behold dem bare så lenge du trenger dem, og slett dem så ordentlig. Kunne vise alle fire i ettertid. Den felles listen er hva plattformen bygger inn i lagringslaget én gang, for hver installasjon. Rettighetsmaskineriet oppå er det som varierer med landet, og det leveres som en egen modul du installerer for din jurisdiksjon.

Ingen er sertifisert for disse, og den som sier noe annet selger noe

Det finnes ikke noe slikt som et HIPAA-sertifisert eller GDPR-sertifisert produkt. Ingen myndighet utsteder det sertifikatet. Det som finnes, er en liste over tekniske og organisatoriske kontroller. Programvare kan gjennomføre de tekniske og gjøre de organisatoriske lette å kjøre og lette å dokumentere. Den kan ikke gjøre en virksomhet etterlevende på egen hånd. Det siste avsnittet på denne siden sier nøyaktig hvilke deler som blir hos deg.

02 — Side ved side

Den samme tekniske kjernen over alt. Forskjellig rettighetsmaskineri oppå

Kryptering, tilgangsstyring, revisjonsloggen og oppbevaring er identiske i hvert land. De er bygget én gang, i den felles kjernen, og hver installasjon får dem. Det som varierer mellom USA, Den europeiske union, Storbritannia, Australia og Canada, er rettighets- og styringsarbeidet som ligger oppå den kjernen. Det er derfor et system bygget etter en amerikansk standard ikke automatisk oppfyller EU, og hvorfor hvert land kommer som sin egen installerbare modul.

De to siste kolonnene bærer de ærligste merkene. De australske personvernprinsippene krever mindre på to punkter enn Europa gjør, og det finnes ennå ingen australsk modul — rettighetsmaskineriet en australsk installasjon bruker i dag er den felles kjernen pluss deler av den europeiske og den britiske modulen. Australia-siden navngir hver søm.

Canada er den nyeste, og den eneste kolonnen der regelboken endrer seg inne i landet. Det finnes ingen kanadisk modul heller, og én plikt har ingen motsvarighet noe annet sted på denne tabellen — lockbox, en pasientinstruksjon som gjerder inn en del av deres egen journal inne i behandlingskretsen. Canada-siden sier hva det betyr å bygge den, og hvilken provinslov som gjelder hvor.

Hva som kreves	USA HIPAA · 42 CFR Part 2	Den europeiske union GDPR	Storbritannia UK GDPR · DPA 2018	Australia Privacy Act 1988 · APP-ene	Canada PIPEDA · PHIPA og provinsielt
Kryptering, tilgangsstyring, revisjonslogg, oppbevaring	✓ felles kjerne	✓ felles kjerne	✓ felles kjerne	✓ felles kjerne	✓ felles kjerne
En registrert rettslig grunn for å ha hver dokumenttype	— ikke slik HIPAA virker	✓ art. 9 nr. 2 bokstav h for behandlingsjournaler, ikke samtykke	✓ det samme, etter UK GDPR	✓ APP 3.3 og s16B, registrert per dokumenttype	§ formål og samtykke, ikke et opplistet rettslig grunnlag
En person kan be om en kopi av journalen sin	✓ 45 CFR 164.524, begrenset til det utpekte journalsettet	✓ art. 15, med en lovbestemt frist	✓ art. 15, pluss testen for alvorlig skade	✓ APP 12, en rimelig frist, og ingen gebyr for å spørre	✓ PIPEDA-prinsipp 9 og PHIPA § 52 — 30 dager, kan forlenges
Noe materiale kan holdes tilbake fra dem	✓ psykoterapinotater ligger utenfor journalsettet	§ smalt, og avhenger av medlemsstaten	✓ testen for alvorlig skade, kjørt som en arbeidsflyt som utløper	◐ grunnlag finnes i APP 12.3; arbeidsflyten leveres med den britiske listen	◐ grunnlag finnes i PHIPA; arbeidsflyten leveres med den britiske listen
En person kan be om at opplysningene deres slettes	§ HIPAA gir ingen alminnelig rett; oppbevaringen avgjør	✓ art. 17, gjort ved å ødelegge nøkkelen	✓ det samme, med britiske unntak	§ ingen alminnelig retting til sletting; destruksjon etter APP 11.2 gjør arbeidet	§ ingen alminnelig rett; oppbevaring og sletting gjør arbeidet
En person kan ta opplysningene sine et annet sted	§ gjennom innsynsretten; HIPAA har ingen egen	✓ art. 20, strømmet zip, hver fil logget	✓ det samme	§ ingen rett til dataportabilitet; innsynsretten bærer den	✓ retten i Québecs Law 25 lander på GDPR-eksporten; ingen føderal motsvarighet
En oversikt over hva som ble delt, og med hvem	✓ seks år, på forespørsel	✓ hva som gikk ut, til hvem, på hvilket grunnlag	✓ det samme	✓ APP 6, hva som gikk ut og på hvilket grunnlag	✓ hva som gikk ut, til hvem, på hvilket grunnlag og hvorfor
Å varsle tilsynet og de berørte etter et avvik	✓ vurdering av fire momenter, 60 dagers varsel, terskler for medier og HHS	✓ art. 33 og 34, 72 timer, to klokker, nøkkelspørsmålet registrert	✓ det samme, rapportert til ICO	✓ NDB-ordningen: 30 dager til å vurdere, så varsle så snart det er praktisk mulig	◐ posten er komplett; de to innsendingene og marsopptellingen lages ikke
Skriftlige styringsdokumenter holdt oppdatert	✓ policyregister, versjonert, seks år per versjon	✓ vurdering av personvernkonsekvenser (art. 35) og behandlingsprotokoll (art. 30)	✓ det samme	✓ APP 1: policyregister, risikoregister, klager som poster	✓ policyregister, risikoregister, klager som poster
En oppbevaringsplan levert klar til bruk	⚙ varierer med delstaten, så du setter periodene	⚙ varierer med medlemsstaten, så du setter periodene	✓ NHS Records Management Code of Practice 2021	◐ periodene er kjent nasjonalt, og ingenting legges inn	⚙ satt av yrkesforbundet ditt, så det finnes ingen nasjonal plan å legge inn
Journaler etter mennesker som er døde	⚙ HIPAA verner dem i 50 år; regelen er ikke lagt inn	— GDPR gjelder ikke for avdøde	✓ Access to Health Records Act 1990	§ den føderale loven stopper ved død; NSW verner i 30 år etter	⚙ lovene fortsetter etter død; perioden er yrkesforbundets
Ekstra vern for journaler innen rusbehandling	✓ 42 CFR Part 2, med meldingen om videreformidling	— ingen tilsvarende regel	— ingen tilsvarende regel	— ingen tilsvarende regel	— ingen tilsvarende regel

✓ByggetI jurisdiksjonsmodulen nå, og mulig å vise fram. ⚙Bygget — du velger verdienMekanismen er der og tallet er ditt, fordi loven overlater det til deg eller til delstaten din. Ikke en mangel. §Det regelverket krever mindreIngenting mangler. Dette landets rett gir en smalere rettighet, eller kommer til samme sted langs en annen vei. ◐Delvis byggetNoe mangler faktisk. Landsiden navngir nøyaktig hva. —Ikke i det regelverket i det hele tattLoven inneholder rett og slett ikke denne rettigheten.

De to midtre merkene var ett merke til nylig, som ble lest som én form for mangel når bare ◐ er én. En oppbevaringstid du setter fordi delstaten din setter den, er ikke en manglende funksjon, og det er ikke at HIPAA lar være å gi en rettighet GDPR gir, heller.

03 — Hva som vernes

Tre slags opplysninger, og bare én av dem er alminnelig

Ikke alt i en klinikk trenger det samme vernet. Behandler du hvert felt som maksimalt følsomt, blir systemet tregt og tungt, og ansatte begynner å føre notater i et regneark i stedet. Det er den reelle avviksrisikoen i de fleste klinikker. Behandler du ingenting som følsomt, er systemet rett og slett utrygt. Derfor sorterer plattformen opplysninger i tre slag og bruker det tunge maskineriet bare på det slaget som trenger det.

Slags opplysninger	Eksempler	Hvordan de lagres	Hvem som kan nå dem
Alminnelige forretningsopplysninger	Kontaktopplysninger, ordrer, fakturaer, bestillinger, chatmeldinger	I databasen, vernet av Odoos egne tilgangsregler	Ansatte som trenger det i jobben. Klienten selv, gjennom portalen
Kliniske og faglige journaler	Timerapporter, hendelses- og vernesaker, identitetsdokumenter	Som sikre dokumenter: kryptert én versjon om gangen, lagret utenfor det vanlige filområdet	Bare den klientens behandlingsteam, etter en uttrykkelig regel. Ingen stillingstittel gir det
Økonomiske poster	Fakturaer, utbetalinger til behandlere, kontraktsversjoner, regnskapsposteringer	I regnskapet, som ikke kan endres når en postering er utstedt	Økonomi og ledelse. En korreksjon etterlater et spor framfor å overskrive

Hvorfor streken går ved journalen, ikke ved feltet

Å kryptere hvert enkelt felt ville gjort søk umulig. Ansatte ville da holdt arbeidsnotatene sine et sted utenfor systemet, der ingenting logges og ingenting vernes. Derfor trekker plattformen streken ved typen journal framfor ved det enkelte feltet. Følsomt materiale blir inne i systemet, der hvert oppslag i det kan registreres.

04 — Journalmodellen

Fem ting som er sanne om hver vernet journal

Disse fem er egenskaper ved hvordan opplysningene lagres. De er ikke retningslinjer ansatte blir bedt om å følge. Den forskjellen er hele argumentet på denne siden. En kontroll som avhenger av at folk oppfører seg riktig, er en kontroll du ikke kan vise fram for en revisor. En kontroll bygget inn i lagringen er en du kan vise fram.

Egenskap én

Hver versjon krypteres for seg

Plattformen bruker konvoluttkryptering med AES-256-GCM. Det betyr at hver dokumentversjon får sin egen tilfeldige nøkkel, og at den nøkkelen så låses med en annen nøkkel som hører til hele installasjonen. Den andre nøkkelen lagres aldri i databasen.

Den som stjeler en kopi av databasen alene har ingenting lesbart
De krypterte filene ligger utenfor Odoos vanlige fillagring og leveres aldri gjennom den vanlige nedlastingsruten
Å rotere installasjonsnøkkelen låser de små nøklene på nytt uten å skrive om en eneste kryptert fil
Programvaren nekter å starte hvis den nøkkelen mangler, er lesbar for alle, er eid av feil konto, eller ligger et sted der den ville bli kopiert sammen med opplysningene den verner

Egenskap to

Lukket med mindre en regel åpner den

Hvert oppslag må finne en regel som tillater det og ingen regel som forbyr det. Dette kontrolleres hver gang, ikke én gang ved innlogging. Å være administrator, leder, eller den som skrev dokumentet, gir ingenting i seg selv.

Det finnes ingen hovedoverstyring og ingen superbrukervei inn i klinisk innhold
Tilgang følger klientens behandlingsteam, ikke organisasjonskartet
Når ansatte arkiverer et dokument, sier dialogen med vanlige ord hvem som vil kunne åpne det, før det lagres

Egenskap tre

Hvert oppslag skrives ned

Åpninger logges, ikke bare endringer. Loggen er bare-skriv og lenket med hashverdier, som betyr at hver oppføring er matematisk bundet til den før den. Å fjerne eller endre en oppføring bryter kjeden og blir synlig.

Oppføringen skrives før innholdet gis videre, ikke etterpå
Ingen kan endre eller slette den, inkludert de som administrerer systemet
En komplett liste over hvem som åpnet en journal kan lages for en klient, et tilsyn eller dine egne advokater
Portaloppslag er mengdebegrenset per bruker, talt fra den samme loggen, så grensen holder også på tvers av flere serverprosesser

Egenskap fire

Rettinger legger til, de overskriver aldri

Når noe rettes, arkiveres en ny versjon. Den tidligere står nøyaktig som den var, inkludert metadataene. En journal som kan endres i stillhet er verdiløs som bevis, og en dag kan din måtte være verdt noe.

En anmodning om å endre en journal legger til i den framfor å erstatte den
Hver versjon bærer sin egen nøkkel, så sletting kan gjøres versjon for versjon
En endring er derfor synlig i historikken framfor noe du må slutte deg til

Egenskap fem

Sletting ødelegger nøkkelen

Når en oppbevaringstid løper ut, ødelegger plattformen krypteringsnøkkelen i stedet for å slette raden. Innholdet blir permanent uleselig. Det tomme skallet og revisjonssporet blir. Denne teknikken kalles kryptomakulering.

Sletting kan vises fram framfor bare å bli påstått
Beviset for at en journal en gang fantes, og ble slettet i tid, består
Oppbevaring regnes fra en virkelig ankerdato: siste kontakt, fødselsdato eller dødsdato

Det bevisste hullet

Hva den ikke vil gjøre, sagt åpent

Plattformen kan ikke søke inne i krypterte dokumenter. Det er en direkte følge av krypteringen, ikke en manglende funksjon. Dokumenter finnes på hvem de handler om, hvilken type de er, og når de ble arkivert.

Det står her fordi en leverandør som lover både sterk kryptering og fritekstsøk i det samme innholdet, lover det ene usant
Den er en tjeneste for sikre dokumenter, ikke en elektronisk pasientjournal: ingen klinisk journalføring, ingen HL7 eller FHIR, ingen e-resepter
Kjernen vet ingenting om helserett. Hvert lands regler kommer som en egen modul oppå

05 — Hvem som kan åpne en journal

Tilgang følger behandlingsrelasjonen, ikke stillingstittelen

Dette er den enkeltvis viktigste ideen på siden, og den ene tingen et alminnelig dokumentsystem ikke kan uttrykke. En behandlingsrelasjon er en registrert forbindelse mellom én kliniker og én klient, med en type, en startdato og en sluttdato. En terapeut når journalene til menneskene på sin egen liste. Ikke klinikkens liste. Sin egen. Når relasjonen tar slutt, gjør tilgangen det også, etter en kort frist som er lang nok til å fullføre utestående notater.

Dette er hva som gjør «minste nødvendige» til noe programvaren faktisk håndhever framfor en retningslinje i en håndbok, og til noe du kan vise fram i en revisjon.

Hva som skjer ved hvert eneste oppslag

Fem steg, hver gang, for hvert dokument

Hvem spør?En innlogget bruker, løst opp til en bestemt person. Ikke en rolle og ikke en gruppe.
Finnes det en regel som tillater det?Fordi de er den registrerte, fordi de er på behandlingsteamet, eller fordi noen ga dem navngitt tilgang. Ingen regel, ingen tilgang.
Finnes det en regel som forbyr det?En avvisning vinner alltid over en tillatelse. Psykoterapinotater, forseglede dokumenter og tilbakeholdte journaler nekter på hver vei inn.
Skriv loggoppføringenLagt til den bare-skriv-loggen før noe innhold sendes tilbake.
Dekrypter i minnet og strøm detIngenting skrives til disk på vei ut, og ingenting leveres fra det vanlige filområdet.

Hva som ikke gir deg tilgang

Listet uttrykkelig, fordi kjøpere alltid spør

Å være administratorEn administratorkonto åpner ikke noe klinisk innhold av seg selv. Det finnes ingen bakdør for støtte eller vedlikehold.
Å ha skrevet det selvHendelses- og vernesaker er lukket også for den som arkiverte dem, fordi de arkiveres til klinikklederen.
Å være seniorKliniske roller avgjør hvilke skjermer i programmet noen kommer til. De avgjør aldri hva noen kan åpne.
Å være klientenEn klient ser en journal om seg selv bare når en regel uttrykkelig gir det. Det er en klinisk og juridisk beslutning, tatt med vilje og registrert med begrunnelsen og navnet på den som tok den.
Å gjette en dokumentreferanseEt dokument du ikke får se gir «ikke funnet», aldri «ikke tillatt». Ellers blir det å gjette referanser en måte å finne ut hvem det finnes journaler om.

Nødtilgang finnes, og den er aldri stille

Av og til trenger en kliniker reelt en journal de ikke har noen relasjon til — en krise, en vakttelefon, en kollega som er blitt syk. Tillater virksomheten din det, finnes en nødtilgangsvei. Å bruke den registreres som en hendelse og gjennomgås etterpå av personvernansvarlig.

Det er designet i én setning: tilgang er tilgjengelig når noen reelt trenger den, og aldri stille. Dette er med vilje. Et system som bare blokkerer svikter på sin egen måte. Britisk veiledning (Caldicott-prinsipp 7) sier at plikten til å dele kan være like viktig som plikten til å verne, og det er derfor nødtilgang er en utformet funksjon i kjernen framfor et hull etterlatt i den.

06 — Forretningskjernen

Hvordan Odoo Community avgjør hvem du er, og hva du ser

Det kliniske maskineriet beskrevet over ligger oppå Odoo 19 Community, som er den åpne forretningskjernen. Odoo kommer med sin egen modell for tilgangsstyring, og den er verdt å forstå, fordi den er det som verner de alminnelige forretningsopplysningene — bestillingene, fakturaene, kontaktene og meldingene som utgjør det meste av systemet.

Dette avsnittet har seks deler: fire lag med tilgangsstyring som avgjør hva en innlogget person kan nå; innlogging — passord, tofaktor, passnøkler og reglene rundt dem; hva «rollebasert» faktisk betyr her, fordi uttrykket brukes løselig over alt; isolering av databasen; OWASP Topp ti med Odoos svar på hver av dem; og hva det å være åpen kildekode faktisk er verdt.

Alt under leveres med Odoo 19 Community. Ingenting av det er et betalt tillegg, og alt er lesbar kildekode ditt eget sikkerhetsteam kan undersøke.

Odoos tilgangsmodell har fire lag. Hvert av dem svarer på et forskjellig spørsmål, og en forespørsel må gjennom alle fire. De kontrolleres inne i datalaget selv, som er den viktige delen: de samme kontrollene gjelder enten en post nås gjennom vevgrensesnittet, gjennom mobilappens gateway, eller gjennom Odoos eksterne API. Det finnes ingen vei som omgår dem.

Lag én

Grupper — hvilken del av systemet du når

En gruppe er en rolle. Medlemskap avgjør hvilke menyer, skjermer og knapper en person i det hele tatt ser. Grupper kan implisere andre grupper, så en veileder har automatisk alt en kliniker har, uten at rettighetene skrives to ganger.

Roller i denne installasjonen omfatter behandlende kliniker, veileder, klinikkleder, journalansvarlig, resepsjon og personvernansvarlig
Resepsjonen har bare demografi: ingen klinisk innhold og ingen dokumenttilgang av noe slag
En gruppe gir rekkevidde, aldri innhold. Å ha klinikerrollen åpner ingen klients journal av seg selv — behandlingsrelasjonen gjør det

Lag to

Modelltilgang — hva du kan gjøre med en type post

For hver type post og hver gruppe lagrer Odoo fire atskilte rettigheter: lese, opprette, endre og slette. De erklæres i rene tekstfiler som leveres med hver modul, så de kan leses og gjennomgås uten å kjøre noe.

Denne installasjonen erklærer 660 tilgangsoppføringer på tvers av 35 moduler
Alt som ikke er listet, nektes. Tilgang gis ved å navngi den, aldri ved å glemme å blokkere den
Lese uten å endre er vanlig med vilje: mange roller kan se en post de ikke må endre

Lag tre

Postregler — hvilke enkeltposter du kan berøre

En postregel er et filter som legges på hver spørring. Det er den som gjør «dine egne klienter» og «ditt eget selskap» virkelig framfor et spørsmål om hvilken skjerm noen tilfeldigvis åpner. Globale regler gjelder alltid. Regler knyttet til en gruppe utvider tilgangen bare for den gruppen.

Denne installasjonen definerer 117 postregler på tvers av modulene for klinikk, bestilling, kontrakt, e-signatur og rapportering
Typiske eksempler: en kliniker ser behandlingsrelasjoner der de er klinikeren; en portalbruker ser bare bestillinger som hører til deres egen kontaktpost
Regelen legges på av datalaget, så den holder for listevisninger, rapporter, eksporter og det eksterne API-et likt

Lag fire

Feltregler og skillet mot portalen

Enkeltfelt kan begrenses til bestemte grupper, så to personer kan åpne den samme posten og se forskjellig mye av den. I tillegg holder Odoo portalbrukere i en helt annen klasse enn ansatte.

En portalbruker — en klient eller en ekstern kontakt — har ingen tilgang til backoffice i det hele tatt, bare til sidene som uttrykkelig er publisert for dem
Offentlige nettsider kjører som en anonym bruker med nesten ingenting gitt, så en feil på en offentlig side kan ikke eksponere ansattopplysninger
Hver kontrollerrute i denne installasjonen erklærer om den krever en innlogget bruker eller er bevisst offentlig: 174 ruter krever innlogging, 57 er offentlige ved design

Vern i rammeverket	Hva Odoo gjør	Hva det hindrer
Bygging av spørringer	Alle databasespørringer bygges av rammeverket ut fra strukturerte filtre. Applikasjonskode skriver ikke rå SQL for alminnelige oppslag og skrivinger	SQL-injeksjon gjennom søkefelt, filtre og URL-parametere
Escaping i maler	Odoos malmotor escaper verdier den gjengir på en side som standard. Rå utdata må uttrykkelig bes om	Kryssted-skripting, der tekst lagret av én bruker kjører som kode i en annen brukers nettleser
Skjematokener	Vevskjemaer som endrer opplysninger bærer et token knyttet til brukerens økt, og tjeneren avviser en innsending uten det	Kryssted-forespørselsforfalskning, der et annet nettsted i stillhet sender inn et skjema som din innloggede bruker
Økter	Økttilstand holdes på tjeneren. Nettleseren holder bare en identifikator, i en informasjonskapsel merket slik at skript på siden ikke kan lese den	Økttyveri gjennom et skript som kjører på siden
Passord	Lagret bare som en enveis hash, aldri i en form som kan reverseres. Hashmetoden kan oppgraderes uten å be alle om å nullstille	At en stjålet brukertabell blir en liste over brukbare passord
Databasebehandler	Skjermene som oppretter, kopierer, gjenoppretter og sletter hele databaser er stengt i produksjon, og ett vertsnavn er bundet til nøyaktig én database	At noen som når tjeneren finner, kopierer eller overskriver en database
Operasjoner med forhøyede rettigheter	Kode kan omgå tilgangsregler bare der en utvikler skrev det med vilje, for en definert operasjon, på et navngitt sted. Klinisk innhold er ikke ett av de stedene	Bred, utilsiktet rettighetseskalering begravd i applikasjonskode
Åpen kildekode	Odoo Community er utgitt under en åpen lisens, og tilleggene i denne plattformen er lesbare i sin helhet. Sikkerhetsrettinger utgis av Odoo og legges inn i din egen installasjon	Å måtte ta en leverandørs sikkerhetspåstander helt på tro

Innlogging: passord, andre faktorer og reglene rundt dem

De fire lagene over avgjør hva en innlogget person kan nå. Dette er delen før det — hvordan Odoo slår fast at noen er den de hevder å være, og hva det gjør når de ikke er det. Alt av det leveres med Odoo 19 Community; ingenting av det er et betalt tillegg.

Kontroll	Status	Hva den gjør, og hva du bestemmer
Passord hashes, lagres aldri	✓	Lagret som en PBKDF2-SHA512-hash med salt per passord og en konfigurerbar arbeidsfaktor. En hash kan ikke gjøres tilbake til et passord, så en stjålet brukertabell er ikke en liste over innlogginger. Arbeidsfaktoren kan heves etter hvert som maskinvaren blir raskere, og passord hashes på nytt til den sterkere innstillingen neste gang hver person logger inn — ingen blir bedt om å nullstille. Ingen kan lese et passord tilbake, inkludert dine egne administratorer og inkludert oss: feltet leses alltid som tomt, uansett hvem som spør. Mister noen passordet sitt, er den eneste veien en nullstilling, og det er det riktige svaret framfor en manglende funksjon.
Tofaktorautentisering	⚙	Bygget og levert i hver installasjon, med standardkodene fra autentiseringsapper (TOTP) som virker med Google Authenticator, Authy, 1Password og resten. En person kan registrere en enhet selv, og betrodde enheter kan huskes en periode. Du setter: om det er valgfritt eller påkrevd. Én innstilling slår det på for alle, en annen for alle ansattkontoer — og den som ikke har en autentiseringsapp får en engangskode på e-post i stedet, så å håndheve det etterlater ingen på perrongen. I en amerikansk installasjon bør dette være på: det forventes etter sikkerhetsregelen og blir i praksis påkrevd hvis den foreslåtte oppdateringen vedtas.
Tofaktor lukker også API-døren	✓	Detaljen som gjør den verdt å ha. Når en person har en andre faktor, slutter passordet deres å virke for maskin-til-maskin-tilgang helt — en integrasjon må bruke en navngitt API-nøkkel i stedet. Uten den regelen verner tofaktor innloggingsskjermen og lar bakdøren stå åpen, som er slik den beseires i praksis.
Passnøkler	⚙	Odoo 19 støtter passnøkler — innlogging med et fingeravtrykk, et ansikt eller en maskinvarenøkkel i stedet for et passord. Ingenting som kan fiskes tastes inn, så det fjerner hele angrepsklassen der noen blir overtalt til å skrive passordet sitt på en overbevisende kopi av innloggingssiden din. Du bestemmer om du vil tilby det.
API-nøkler i stedet for passord for integrasjoner	✓	Hver integrasjon får sin egen navngitte nøkkel med sitt eget omfang, listet mot den som opprettet den, og kan trekkes tilbake én for én. En nøkkel som lekker slås av uten å endre noens passord og uten å ødelegge de andre integrasjonene.
Passordregler	⚙	En minste lengde håndhevet i det øyeblikket et passord settes, med en styrkemåler vist mens det tastes. Du setter minimumet. Det er null fra start, som betyr at å bestemme det er en del av driftsstarten framfor noe å oppdage senere. Det finnes med vilje ingen innstilling for påkrevde tegnklasser — én stor bokstav, ett siffer, ett symbol. Det er ikke en forglemmelse. Både forskning og gjeldende NIST-veiledning fant de reglene mot sin hensikt: de skyver folk mot forutsigbare erstatninger og mot å skrive passord ned, og de kjøper mindre enn lengde gjør. Lengde pluss en andre faktor er kombinasjonen som virker.
Vern mot rå kraft	✓	På som standard. Etter ti mislykkede forsøk avvises hvert videre forsøk i seksti sekunder regnet fra det siste feilforsøket — så et gjetteangrep strupes til ett forsøk i minuttet framfor tusenvis. Begge tallene er innstillinger en databaseadministrator kan endre (eller slå av, ved å sette det første til null). Det virker uten at noen må legge merke til at angrepet skjer.
Ny autentisering for følsomme handlinger	✓	Å endre sikkerhetsinnstillinger, registrere en andre faktor eller opprette en API-nøkkel ber personen bevise hvem de er igjen, også midt i en økt. En skjerm som står ubrukt kan ikke brukes til å svekke kontoen den er innlogget på.
Å endre et passord avslutter hver økt	✓	Øktens gyldighet utledes av kontoen selv, så å endre et passord eller deaktivere en konto gjør hver eksisterende økt ugyldig over alt på én gang — hver nettleser, hver enhet, umiddelbart. Det er dette som gjør «noen har sluttet, steng dem ute» til én handling framfor en håpefull en.
Felles pålogging, der du bruker det	⚙	Odoo kan autentisere mot katalogen du alt har (LDAP eller Active Directory) eller en OAuth2-identitetsleverandør, så nyansatte og avganger håndteres én gang der virksomheten din alt håndterer dem. Valgfritt, og bare verdt å gjøre om du alt driver en.
Portaldokumenter bak en andre faktor	⚙	Denne er vår og ikke Odoos, og den finnes fordi en klients innlogging er det svakeste punktet i et hvilket som helst klinisk system. Slå den på, og en portalbruker som ikke har registrert en andre faktor kan fortsatt logge inn og se at dokumenter finnes — men kan ikke åpne ett før de gjør det. Det påvirker folk som alt bruker portalen, så si det til dem før du slår det på.

✓På som standardVirker fra det øyeblikket systemet er installert. ⚙Bygget — du slår det påFinnes og støttes. Om du vil bruke det, og hvor strengt, er din beslutning.

Hva «rollebasert» faktisk betyr her

Nesten hvert system hevder å være rollebasert. Uttrykket er verdt å pakke opp, for i de fleste produkter betyr det at menyen endres, og i Odoo betyr det at opplysningene endres.

En rolle i Odoo er en gruppe. Grupper kan inneholde andre grupper, så en veileder har automatisk alt en kliniker har uten at noen skriver rettighetene to ganger — og når en rettighet rettes, rettes den én gang for alle som arver den. Hva en gruppe gir, er ikke en skjerm. Det er fire atskilte rettigheter (lese, opprette, endre, slette) på hver type post, pluss filtre som avgjør hvilke poster av den typen, pluss muligheten til å skjule enkeltfelt.

Den viktige følgen: å skjule en meny er ikke en rettighet. I et system der roller bare endrer menyen, når hvem som helst som lærer en nettadresse opplysningene bak den. I Odoo bor kontrollene i datalaget, så den samme avvisningen skjer enten posten nås gjennom en skjerm, en rapport, en eksport, et søk, eller det eksterne API-et. Det finnes ingen vei som hopper over dem.

01Roller er navngitt etter jobben

Behandlende kliniker, veileder, klinikkleder, journalansvarlig, resepsjon, personvernansvarlig, regnskapsfører, kontraktsansvarlig. Resepsjonen har bare demografi — ingen klinisk innhold og ingen dokumenttilgang av noe slag.

Svarer på«Vis meg hva en resepsjonist kan se»

02Roller gir rekkevidde, aldri innhold

Å ha klinikerrollen åpner ingen klients journal av seg selv. Behandlingsrelasjonen gjør det. Dette er den enkeltvis viktigste setningen om tilgang på dette nettstedet.

Svarer på«Kan en terapeut lese hele klinikkens journaler?»

03Fire rettigheter, ikke én

Lese, opprette, endre og slette er atskilte for hver type post. Lese uten å endre er vanlig med vilje: mange roller må se noe de ikke må endre.

Svarer på«Hvem kan endre en faktura etter at den er utstedt?»

04Radfiltre avgjør hvilke poster

«Dine egne klienter», «ditt eget selskap», «bestillinger som hører til deg». Lagt på hver spørring, så de holder for lister, rapporter, eksporter og API-et likt.

Svarer på«Hva hindrer en eksport fra å hente alt?»

05Globale regler kan ikke utvides

En regel som ikke er knyttet til noen gruppe gjelder for alle og kombineres med hver annen regel, så den innsnevrer tilgangen og kan aldri unnslippes ved å legge til en rolle. Selskapsskillet er bygget slik.

Svarer på«Kan én klinikk se en annen klinikks opplysninger?»

06Enkeltfelt kan skjules

To personer kan åpne den samme posten og se forskjellig mye av den. Brukt her for kostnads- og marginbeløp, og for feltene bare en journalansvarlig skal lese.

Svarer på«Ser alle som ser en kontrakt marginen på den?»

07Klienter er en annen klasse brukere

En portalbruker har overhodet ingen tilgang til backoffice — ikke en begrenset visning av det, ingenting av det. De når bare sidene som er publisert for dem. Offentlige nettsider kjører som en anonym bruker med nesten ingenting gitt.

Svarer på«Hva er det verste som kan skje om en klientinnlogging blir stjålet?»

08Hver rute erklærer sin egen tilgang

Hver nettadresse i denne installasjonen sier om den krever en innlogget bruker eller er bevisst offentlig: 174 krever innlogging, 57 er offentlige ved design. Ingenting er offentlig ved et uhell.

Svarer på«Hvilke av URL-ene deres virker uten innlogging?»

09Det er alt lesbar konfigurasjon

Rettigheter leveres som rene tekstfiler inne i hver modul. Ditt eget sikkerhetsteam kan lese hvem som får hva uten å kjøre systemet, og sammenligne mellom utgivelser.

Svarer på«Kan vi revidere rettighetene selv?»

Én database per klinikk, og ingen vei på tvers

Opplysningene dine ligger i en egen database. Det er ikke en delt tabell med en kundekolonne i, som er ordningen der én gal spørring returnerer noen andres poster.

Odoo håndhever det skillet ved forbindelsen: en forespørsel bærer et vertsnavn, vertsnavnet velger nøyaktig én database, og det finnes ingen vei fra inne i én database til en annen som kjører på den samme tjeneren. Ingenting i applikasjonen kan adressere en database den ikke ble koblet til. I tillegg er skjermene som oppretter, kopierer, gjenoppretter og sletter hele databaser stengt i produksjon, så ingen som utforsker tjeneren kan liste opp hva som finnes der.

Inne i din egen database gjør et annet lag samme jobb mellom selskaper: driver du mer enn én klinikk på én installasjon, er selskapsskillet skrevet som globale regler — den typen som gjelder for alle og aldri kan utvides ved å legge til en rolle.

OWASP Topp ti, og hvor Odoo står på hver av dem

Open Web Application Security Project utgir listen over de vanligste måtene vevapplikasjoner brytes inn i. Det er listen en sikkerhetsrevisor går gjennom, så her er den med Odoos svar på hver av dem. Mønsteret det er verdt å legge merke til, er at de fleste av disse hindres av rammeverkets design framfor av at utviklere husker å være forsiktige — som er den eneste formen for hindring som tåler møtet med en tidsfrist.

Angrepet	Status	Hvorfor det ikke virker her
Injeksjon, særlig SQL-injeksjonfiendtlige inndata behandlet som en kommando	✓	Applikasjonskode skriver ikke databasespørringer for hånd. De bygges av rammeverket ut fra strukturerte filtre, med hver verdi sendt atskilt fra selve spørringen, så tekst noen har tastet kan aldri bli en del av kommandoen. En utvikler måtte gå ut av sin vei for å skrive en rå spørring, og de kliniske modulene gjør det ikke.
Kryssted-skriptingtekst lagret av én person kjører som kode for en annen	✓	Alt som gjengis på en side escapes som standard. Å legge rått innhold på en side må bes om uttrykkelig og er synlig i koden når det gjøres. Standarden er trygg, så å glemme gir noe stygt framfor noe farlig.
Kryssted-forespørselsforfalskninget annet nettsted sender inn et skjema som din innloggede bruker	✓	Hvert skjema som endrer opplysninger må bære et token knyttet til den personens økt, og tjeneren nekter en innsending uten det. Tokenet finnes bare fordi personen reelt lastet siden din, og en angripers nettsted kan ikke få tak i det.
Kjøring av ondsinnede filerå få tjeneren til å kjøre kode du leverte	✓	Det finnes ingen funksjon som inkluderer en fjernfil. Der brukere med rettigheter kan skrive små uttrykk for å tilpasse oppførsel, kjører de i en sandkasse som blokkerer tilgang til filsystemet, til nettet, og til alt hvis navn begynner med dobbel understrek — en bevisst kort liste over tillatte operasjoner framfor en liste over forbudte.
Usikker direkte objektreferanseå endre et tall i en URL for å nå noen andres post	✓	Dette er den som tar de fleste systemer, og Odoos svar er strukturelt: tilgangsstyring er ikke gjennomført i skjermene. Å endre et postnummer i en nettadresse når den samme kontrollen i datalaget som alt annet, og avvises der. Det er ingen risiko i at en referanse er synlig, for referansen er ikke det som gir tilgang.
Manglende begrensning av URL-tilgangå nå en side ved å kjenne adressen	✓	Det samme svaret, og verdt å si to ganger, for det er forskjellen mellom reell tilgangsstyring og en ryddig meny. Sikkerheten her hviler ikke på at en lenke er skjult. Der en side reelt må virke uten innlogging — en klient som bekrefter en time fra en e-post — bærer adressen et signert token som er unikt for den posten og den personen.
Usikker kryptografisk lagringlegitimasjon vernet svakt eller ikke i det hele tatt	✓	Passord hashes med PBKDF2-SHA512 og nøkkelstrekking, som beskrevet over, og kan unngås lokalt helt ved å autentisere mot din egen katalog eller identitetsleverandør. Kliniske dokumenter går enda lenger: kryptert per versjon under nøkler som ligger utenfor databasen.
Usikker kommunikasjontrafikk sendt i klartekst	✓	Krypterte forbindelser hele veien, med ukrypterte forespørsler omdirigert framfor besvart, og nettleserhoder som nekter en nedgradering. Fordi denne plattformen driftes av deg selv, er denne en driftskontroll framfor en egenskap ved programvaren — den settes opp som del av en standardinstallasjon og er beskrevet i avsnitt 07.
Å nå interne deler over API-etå kalle noe som aldri var ment å kalles	✓	Ikke på OWASP-listen, men verdt å legge til, fordi det er den folk antar er et hull. Det eksterne API-et nekter å kalle noen intern metode — alt hvis navn begynner med understrek, pluss en navngitt liste over farlige. Bare metoder som er publisert med vilje kan nås utenfra, som skarpt begrenser hva en feil i applikasjonskode kan eksponere.

Åpen kildekode, og hva det faktisk er verdt

«Åpen kildekode» sies ofte som om det var en sikkerhetsfunksjon i seg selv. Det er det ikke. Hva det gir deg er konkret og verdt å navngi presist.

Du kan kontrollere framfor å tro

Hver linje av Odoo Community og hver linje av de kliniske modulene kan leses av ditt eget sikkerhetsteam eller av testere du leier inn. Rettigheter leveres som rene tekstfiler. Ingenting på denne siden må tas på tro, som er en annen posisjon enn et lukket produkt der de samme påstandene bare kan hevdes.

Det er en invitasjon til revisjon, ikke en erstatning for å revidere.

Mange flere ser på den

Odoo undersøkes kontinuerlig av brukere, bidragsytere og uavhengige sikkerhetsforskere over hele verden, og feilrapporter fra fellesskapet er en reell kilde til sikkerhetstilbakemelding. Odoo driver et program for ansvarlig varsling og utgir rettinger som varsler.

Deres egen utviklingsprosess omfatter kodegjennomgang med sikkerhet som en av tingene som gjennomgås, for ny og innsendt kode likt.

Du kontrollerer når rettinger kommer inn

Egen drift betyr at sikkerhetsrettinger legges inn i din installasjon etter din plan framfor å dukke opp over natten. Det er en fordel for en klinisk tjeneste som må validere endringer — og det er også en plikt, for en retting ingen legger inn verner ingen.

Å holde seg oppdatert står på driftslisten i avsnitt 07, og det er den enkeltvis vanligste måten en ellers velbygget installasjon ender opp kompromittert.

Én forskjell det er verdt å være nøye med

Odoo utgir en egen sikkerhetsside, og deler av den beskriver Odoos skytjeneste — deres herdede tjenerbilder, deres oppdatering, det lille antallet av deres ingeniører som kan nå en maskin og bare over en kryptert nøkkel fra en kryptert bærbar maskin. De er reelle, og de er ikke dine, fordi denne plattformen driftes på din egen infrastruktur.

Alt på denne siden over streken er en egenskap ved programvaren og gjelder for deg nøyaktig som skrevet. Motstykkene på tjenersiden — herdet operativsystem, oppdatering, hvem som har SSH-tilgang, full diskkryptering på maskinene som administrerer det — er dine å drive, og de er satt ærlig fram i avsnitt 07, inkludert delene som hører til den som drifter tjenerne. Å lese Odoos skyside og anta at den beskriver din installasjon er den vanligste feilen som gjøres om selvdriftet Odoo, og det er den typen ting som rakner i en selskapsgjennomgang.

Der Odoos modell stopper og den kliniske begynner

Odoos fire lag er sterke, godt utprøvde og nok for alminnelige forretningsopplysninger. De er ikke nok alene for en klinisk journal, av én grunn: de er konfigurasjon, og konfigurasjon kan endres av noen med riktig rolle. Det er derfor kliniske dokumenter i tillegg krypteres under nøkler som ligger utenfor databasen, og hvorfor psykoterapinotater bruker en annen nøkkel igjen. Var hver Odoo-regel i systemet feil i morgen, ville det krypterte innholdet fortsatt ikke åpne seg.

07 — Tjeneren

Hvordan maskinen selv herdes

Applikasjonssikkerhet teller bare hvis tjeneren under den er lukket ordentlig. Plattformen driftes av deg selv, som betyr at den kjører på infrastruktur du kontrollerer framfor i en leverandørs sky. Det er en reell fordel for en helsetjeneste, og den kommer med en reell plikt: herdingen under er en del av installasjonen, og den må holdes sann etterpå.

Alt i den første tabellen settes opp som del av en standardinstallasjon og er dokumentert i installasjonsveiledningene. Den andre tabellen er delen som hører til den som drifter tjenerne.

Område	Hvordan det er satt opp	Hvorfor det gjøres slik
Ingenting er eksponert direkte	Applikasjonstjenestene lytter bare på maskinen selv. All trafikk utenfra kommer gjennom en nginx omvendt proxy, som er det eneste på en offentlig port	Én inngangsdør i stedet for flere. Sertifikater, hoder, grenser og logging legges på ett sted
Kryptering under overføring	TLS-sertifikater fra Let's Encrypt, utstedt og fornyet automatisk. Ren HTTP omdirigeres til HTTPS framfor å bli besvart	Det finnes ingen ukryptert vei inn, heller ikke ved et uhell, og fornyelse er ikke noe et menneske må huske
Sikkerhetshoder for nettleseren	Strict-Transport-Security i ett år, X-Frame-Options satt til samme opphav, X-Content-Type-Options satt til nosniff	Nettleseren nekter å nedgradere til HTTP, nekter å la nettstedet rammes inn av et annet nettsted, og nekter å gjette filtyper
Brannmur	Bare port 80 og 443 er åpne mot verden. Applikasjonsporter, databasen og Redis er ikke tilgjengelige utenfra maskinen	Databasen er aldri adresserbar fra internett. En telefon er minst to hopp fra en hvilken som helst rad
Mengdebegrensning	Grenser på proxyen for innkommende forespørsler, pluss tokenbøtter holdt i Redis inne i gatewayen for offentlige ruter og for portaloppslag i dokumenter	Proxyen stopper flommer. Redis-tellerne holder på tvers av flere serverprosesser, så en grense per bruker betyr det den sier
Ett vertsnavn, én database	Odoo er satt opp slik at vertsnavnet i forespørselen velger nøyaktig én database, og skjermene for databasebehandling er stengt	Ingen som utforsker tjeneren kan liste, kopiere, gjenopprette eller slette en database
Tjenester, ikke skall	Gatewayen og Odoo kjører som administrerte systemtjenester under sine egne kontoer, startet automatisk og startet på nytt ved feil	Ingenting kjører som en administratorkonto, og en omstart avhenger ikke av at noen er logget inn
Hemmeligheter bare på tjeneren	Signeringsnøkler og legitimasjon for tredjeparter ligger i en miljøfil som bare tjenestekontoen kan lese. Mobilappen leveres med ingen av dem	Appen kan tas fra hverandre uten at noe læres. En rotert legitimasjon får virkning for alle på én gang, uten en appversjon
Krypterte dokumenter ligger for seg	Kryptotekst skrives til sin egen mappe med sine egne rettigheter, utenfor Odoos vanlige fillagring, og leveres aldri av den vanlige nedlastingsruten	En feilkonfigurert vevtjener kan ikke ved et uhell publisere kliniske filer
Hovednøkkelen kontrolleres ved oppstart	Krypteringsmodulen leser nøkkelen fra en egen sti og nekter å starte hvis filen mangler, er lesbar for alle, er eid av feil konto, eller ligger inne i en mappe som sikkerhetskopieres sammen med opplysningene	Den vanligste nøkkelsvikten i praksis er at nøkkelen havner i samme sikkerhetskopi som opplysningene den verner. Programvaren kontrollerer for det i stedet for å stole på en prosedyre
WebSocket på samme kanal	Chat, tilstedeværelse og signalering for samtaler oppgraderes gjennom den samme proxyen og det samme sertifikatet som alt annet	Én forbindelse, én policy, ingen andre lytter å sikre for seg
Sporing av forespørsler	Hver forespørsel bærer en identifikator gjennom gatewayen og ut igjen i svarhodene, sammen med hvor lang tid den tok	En hendelse kan rekonstrueres på tvers av tjenester i stedet for å gjettes ut fra atskilte loggfiler

Herdingen som hører til den som drifter tjenerne

Dette er ikke mangler i programvaren. Det er beslutninger og rutiner bare den som drifter kan ta, og ingen leverandør kan ta dem for deg. De er listet rett ut slik at ingen antar at de er dekket.

Oppdatering av operativsystemet. En plan for sikkerhetsoppdateringer på verten, og noen som har som jobb å bekrefte at de ble lagt inn.
Diskkryptering på verten. Dokumenter krypteres hver for seg av plattformen, men full diskkryptering verner alt annet på maskinen, inkludert logger og midlertidige filer.
Sikkerhetskopier, og krypteringen av dem. Hvor sikkerhetskopier går, hvordan de krypteres, hvem som kan gjenopprette dem, og hvor lenge de bevares. En sikkerhetskopi er en full kopi av opplysningene dine uten noen av tilgangsreglene dine knyttet til den.
Hovednøkkelen sikkerhetskopieres for seg. Mistes nøkkelen, er hvert kryptert dokument tapt permanent — det er hele poenget med designet. Den må sikkerhetskopieres, og den må ikke sikkerhetskopieres sammen med opplysningene.
Administrativ tilgang til tjeneren. SSH-nøkler framfor passord, ingen direkte rot-innlogging, en liste over hvem som har tilgang, og å fjerne den den dagen noen slutter.
Testing av gjenoppretting. En sikkerhetskopi ingen noen gang har gjenopprettet er et håp, ikke en kontroll. Prøv den etter en plan, og skriv ned at du gjorde det.
Overvåking og varsling. Noen må få beskjed når en tjeneste stopper, en disk fylles, et sertifikat er i ferd med å utløpe, eller en planlagt slettejobb slutter å kjøre.
Tofaktorautentisering for ansattkontoer. Sterkt anbefalt for alle som når klinisk innhold, og i praksis påkrevd hvis den foreslåtte oppdateringen av HIPAAs sikkerhetsregel vedtas. Bekreft med administratoren din om det er slått på i din installasjon.
Plassering i nettet. Om databasen ligger på den samme maskinen eller en egen, hva som kan nå den, og om administrasjon skjer over et privat nett eller en VPN.
Penetrasjonstesting. Systemet er åpen kildekode og driftes av deg selv nettopp for at dine egne testere skal kunne undersøke det ordentlig. Det er en invitasjon, ikke en erstatning for å gjøre det.

08 — Vern i dybden

Fire lag, og hvert av dem nekter noe det neste aldri ser

Vern i dybden betyr å ikke stole på noe enkelt vern. En forespørsel må forbi alle fire lagene under. Verdien er ikke at noe av dem er umulig å bryte. Den er at de svikter på forskjellige måter, så en feil i ett er svært lite sannsynlig å være en feil i alle fire.

1 · Enhet og flate Hva en person holder i hånden Ikke betrodd

Ingen hemmeligheter på enhetenAppen bærer bare offentlige nøkler. Den kan tas fra hverandre uten at noe læres.

Biometrisk innlogging og applåsOppå telefonens egen låseskjerm, ikke i stedet for den.

Tokener i sikker lagringHoldt i plattformens nøkkelring, ikke i alminnelige appfiler.

Databasen er utilgjengeligAppen kan ikke adressere databasen i det hele tatt, på noe nett.

HTTPS · kortlevd token

2 · Gateway Den eneste backend appen kjenner til Holder hemmelighetene

Hver tredjepartsnøkkel bor herLegitimasjon for betaling, AI, meldinger og lagring forlater aldri tjeneren.

Kortlevde signerte tokenerHvert bærer hvem det er for, når det ble utstedt, når det utløper og en unik id. Fornyet framfor langlevd.

Hashing av passordEnveis, med metoden oppgraderbar uten nullstilling.

MengdebegrensningTellere holdt i Redis, delt på tvers av hver serverprosess.

Validering av inndataFeilformede forespørsler avvises her, før forretningskjernen i det hele tatt ser dem.

Signerte lenker som utløperMedier proxyes. Ingenting leveres fra en adresse du kunne gjettet.

tjenestekonto · minste rettighet

3 · Forretningskjernen Der reglene faktisk bor Autoritativ

Grupper, tilgangsrettigheter og postreglerOdoos fire lag, lagt på uansett hvordan posten nås.

Oppslag av behandlingsteamDet ene stedet som avgjør hvem som kan åpne en klinisk journal.

Kliniske rollerAvgjør hvilken del av programmet noen kommer til. Aldri hva de kan åpne.

Regnskap som ikke kan endresEn utstedt faktura er fast. En korreksjon er en kreditnota.

Daterte kontraktsversjonerVilkår kan ikke tilbakedateres, og historikken blir.

kryptert i ro · nøkler holdt for seg

4 · Lagring og nøkler Hva som overlever en stjålet disk Kryptografi

KryptotekstmappeUtenfor filstoren, utenfor databasen, med egne rettigheter.

HovednøkkelenPå disk, eid av tjenestekontoen, aldri i samme sikkerhetskopi som opplysningene.

En andre nøkkel for terapinotaterDen vanlige nøkkelen åpner dem ikke, hva reglene enn sier.

Hashlenket revisjonsloggBare-skriv. Manipulering kan oppdages, ikke bare frarådes.

09 — Praksis i helsebransjen

Kontrollene en klinisk revisor spør særskilt om

Brannmurer og kryptering forventes av et hvilket som helst system. De ni under er de som kommer opp i en gjennomgang innen psykisk helse særskilt, og som et alminnelig dokumentsystem ikke kan uttrykke i det hele tatt. Hver er skrevet med spørsmålet den svarer på, for det er vanligvis slik den kommer.

01Behandlingsrelasjoner

En registrert forbindelse mellom én kliniker og én klient, med en type, en start og en slutt. Når relasjonen tar slutt, tar tilgangen slutt også, etter en frist som er lang nok til å fullføre utestående notater.

Svarer på«Hvordan håndhever dere minste nødvendige?»

02Arkivering til lederen

Hendelser, klager og vernesaker går til klinikklederen og er lukket for den som arkiverte dem, og for alle klagen gjelder.

Svarer på«Kan en ansatt lese klagen på seg selv?»

03Rettighetsanmodninger som arbeidsflyt

Innsynsanmodninger bærer sin lovbestemte frist. Endringsanmodninger legger til en versjon framfor å overskrive. Begrensningsanmodninger forsegler dokumentene de dekker.

Svarer på«Vis meg en innsynsanmodning fra start til slutt»

04Utleveringsregister

Hva som gikk ut av tjenesten, til hvem, og på hvilket rettslig grunnlag. Dette er den oppføringen en person har rett til å be om seks år av i USA.

Svarer på«Hvem har dere delt denne personens opplysninger med?»

05Oppbevaringsankre

Siste kontakt, fødselsdato og dødsdato lagres som datoer å regne fra, fordi en regel skrevet i år er meningsløs uten et startpunkt.

Svarer på«Hvordan vet dere når dette skal slettes?»

06Å følge opp på status, aldri på innhold

Forfalte timerapporter finnes på fristen sin og tilstanden sin. En leder kan se at en rapport mangler uten å åpne en som ikke gjør det.

Svarer på«Leser ledere kliniske notater for å drive klinikken?»

07Identitets- og alderskontroll

Først en automatisk ansiktskontroll, så en menneskelig gjennomgangskø om det trengs. Identitetsdokumentene krypteres mens de holdes og slettes automatisk når kontrollen er ferdig.

Svarer på«Hva skjer med ID-dokumentet etterpå?»

08Klinisk e-signatur

Bekreftelse av samtykkekompetanse, signering på vegne av en klient, medsignatur fra veileder, og samtykke som kan trekkes tilbake senere framfor å være en engangsavkrysning.

Svarer på«Hvordan fanges samtykke, og kan det trekkes tilbake?»

09Signering blir i huset

Signaturtjenesten kjører på dine egne tjenere med sitt eget hashlenkede spor. Ingen dokumenter sendes til et selskap utenfor for å signeres, og det finnes ingen leverandørfaktura per signatur.

Svarer på«Hvilke tredjeparter ser våre signerte dokumenter?»

10 — Hvis noe går galt

To frister fra ett øyeblikk, og et unntak du må gjøre deg fortjent til

Krypteringen er formet som den er i stor grad på grunn av dette avsnittet. Både GDPR og HIPAA godtar at riktig krypterte opplysninger er uleselige, og derfor egentlig ikke en utlevering. Men det unntaket holder bare hvis du kan vise at nøklene ikke ble tatt også. Hele designet for nøkkelforvaltning finnes for at du skal kunne vise det.

Time null Å bli kjent med avviket

Begge fristene under starter fra det øyeblikket du blir kjent med avviket, ikke fra det øyeblikket hendelsen skjedde. Det gjør å slå fast og registrere det øyeblikket til det første du gjør, framfor noe som rekonstrueres senere.

Innen 72 timer · EU og Storbritannia Varsle tilsynet

GDPR artikkel 33 gir deg 72 timer fra du ble kjent med avviket til å varsle tilsynsmyndigheten — ICO i Storbritannia, den relevante nasjonale myndigheten i Den europeiske union. Denne fristen gjelder enten opplysningene var krypterte eller ikke.

Uten ugrunnet opphold · med mindre Varsle de berørte

Artikkel 34 krever at du varsler de berørte også, med mindre opplysningene var krypterte. Artikkel 34 nr. 3 bokstav a behandler riktig krypterte opplysninger som uleselige for den som tok dem. HIPAA har den samme tanken, og kaller den trygg havn.

Vilkåret for det unntaket Ble nøklene tatt også?

Unntaket avhenger helt av dette ene spørsmålet, så systemet stiller det uttrykkelig, og et ubesvart spørsmål teller mot unntaket. Å lukke et avvik som ikke varslingspliktig krever beviset, for et unntak som hevdes uten bevis er ett som faller sammen når det undersøkes.

Hvordan dette er bygget Én avvikspost, delt, med hvert lands regler oppå

Selve avviksposten ligger i den felles kjernen: når du ble kjent med avviket, hva det omfattet, hvem som ble berørt, om opplysningene var krypterte og om nøklene ble tatt. Hver jurisdiksjonsmodul legger så sine egne plikter oppå den ene posten. Den europeiske modulen legger til 72-timersfristen i artikkel 33 og beslutningen etter artikkel 34. Den amerikanske modulen legger til risikovurderingen av fire momenter, 60-dagersfristen for de berørte, medieterskelen over 500 innbyggere i én delstat, og rapportering til Department of Health and Human Services. Én hendelse, vurdert én gang, mot de reglene som gjelder for deg.

Hele veien Tilgangsloggen er granskingen

Fordi hvert oppslag ble logget før noe innhold ble gitt videre, har spørsmålet «hva ble faktisk eksponert, og for hvem?» et virkelig svar framfor et anslag. Det er forskjellen mellom å varsle elleve mennesker og å varsle alle i databasen.

11 — Kontroller i plattformen

De alminnelige spørsmålene, besvart på ett sted

Ingenting i denne tabellen er uvanlig. Den er her fordi en revisor kommer til å spørre, og fordi en leverandør som ikke kan svare raskt på disse vanligvis ikke kan svare på de vanskeligere heller.

Område	Hva som er på plass	Hvorfor det gjøres slik
Innlogging	Passord lagret bare som enveis hashverdier. Kortlevde signerte tokener som bærer hvem brukeren er, når tokenet ble utstedt, når det utløper og en unik id	Et stjålet token utløper av seg selv, og hashingen kan oppgraderes uten å be noen om å nullstille passordet sitt
Forvaltning av hemmeligheter	Hver tredjepartslegitimasjon bor på tjeneren. Mobilappen bærer bare offentlige nøkler	Appen kan dekompileres uten at noe tapes. Å rotere en nøkkel får virkning for alle brukere på én gang, uten en utgivelse i appbutikken
Overføring	HTTPS over alt, inkludert WebSocket brukt til chat, tilstedeværelse og signalering for samtaler	Én forbindelse, én policy, og ingen tilbakefall til klartekst
Mengdebegrensning	Grenser på proxyen, pluss Redis-tellere på offentlige ruter og på portaloppslag i dokumenter	Talt fra delt tilstand, så en grense per bruker holder på tvers av hver serverprosess framfor per prosess
Medier	Proxyet gjennom gatewayen med signerte lenker som utløper. Ingenting leveres fra en sti du kan gjette	Lagring adresseres aldri direkte av en klientenhet
Database	Ikke tilgjengelig fra noen klient. Gatewayen kobler til kjernen gjennom en tjenestekonto med bare de rettighetene den trenger	To atskilte hopp mellom en telefon og en rad, hvert med sin egen anledning til å nekte
Offentlige skjemaer	reCAPTCHA på skjemaer på nettstedet, og telefonnumre normalisert mens de tastes	Søppel og feilformede inndata avvises før de blir poster noen må rydde opp i
Å gjette referanser	Et dokument du ikke får se gir «ikke funnet», aldri «ikke tillatt»	Ellers forteller forskjellen mellom de to svarene en angriper hvilke poster som finnes
Klientkontoer	Portalbrukere har overhodet ingen tilgang til backoffice. Tofaktorautentisering leveres med plattformen og kan gjøres påkrevd for alle ansatte, eller for alle, med én innstilling — og dokumenttilgang i portalen kan legges bak den	Det verste tilfellet for en kompromittert klientinnlogging er én klients egne opplysninger, og med portalporten slått på, ikke engang det
Eksponering mot tredjeparter	Betaling, kunstig intelligens, meldinger og lagring ligger hver bak et grensesnitt med en attrappversjon på den andre siden av en bryter	Leverandører kan byttes. Demonstrasjoner og testing kjører uten noen levende leverandørkonto og uten levende opplysninger i det hele tatt
Lisensiering og drift	Odoo 19 Community og åpne komponenter hele veien, kjørende på din egen infrastruktur	Ditt eget sikkerhetsteam kan lese koden framfor å ta en leverandørs ord for det

12 — Hva du kan vise fram

Forskjellen mellom en kontroll og et løfte

I en revisjon, et anbud eller en klage er det som betyr noe ikke hva du hadde tenkt. Det er hva du kan vise fram. Under står de seks spørsmålene som kommer oftest, og hva systemet produserer som svar på hvert av dem.

Hvem leste denne journalen?Tilgangslogg

En komplett, hashlenket liste ingen kunne ha endret — inkludert dine egne administratorer

Ble denne journalen endret?Versjonshistorikk

Rettinger er nye versjoner og den tidligere er intakt, så en endring er synlig framfor noe du slutter deg til

Ble utløpte opplysninger ødelagt?Ødeleggelse av nøkkel

Nøkkelen er borte, og det tomme journalskallet viser at filen fantes og ble slettet etter planen

Hvem delte vi det med?Utleveringsregister

Hva som gikk ut av tjenesten, til hvem og på hvilket rettslig grunnlag — seks år av det, på forespørsel

Kunne en administrator ha sett det?Autorisasjonsmodell

Lukket som standard uten hovedoverstyring. En administratorkonto gir ingenting, og nødtilgang er en logget, gjennomgått hendelse

Er regnskapet til å stole på?Økonomiske kontroller

Utstedte fakturaer kan ikke endres, utbetalingslinjer bærer kontraktsversjonen som priset dem, og ingenting faktureres uten at en person bekrefter det

13 — Hvor programvaren stopper

Hva ingen plattform kan gjøre for deg

Programvare gjør ikke en virksomhet etterlevende. Den gjør etterlevelse oppnåelig, og den gjør det mulig å vise fram. Å være rett fram om den grensen er verdt mer i en gjennomgang enn en lengre liste med påstander, så her er grensen i sin helhet.

Dette er ikke juridisk rådgivning, og ingen produkter er sertifiserte

Ingenting på denne siden er juridisk rådgivning. Ingen programvare er HIPAA-sertifisert eller GDPR-sertifisert, fordi ingen myndighet utsteder de sertifikatene for produkter. Det som finnes, er et sett tekniske og organisatoriske kontroller. Denne plattformen gjennomfører de tekniske og støtter de organisatoriske. Resten hører til virksomheten din, og en god rådgiver vil si nøyaktig det samme.

Avtalene er dine å signere. Business associate-avtaler i USA, databehandleravtaler og vilkår for underdatabehandlere i EU og Storbritannia. Plattformen modellerer dem. Den inngår dem ikke for deg.
Advokatene dine bekrefter ordlyden. Meldingen om videreformidling etter 42 CFR Part 2 lages framfor å skrives, nettopp for at den ikke skal kunne skli over tid. Men forskriften foreskriver innholdet, og det trenger juridisk gjennomgang før driftsstart.
Lokal rett går lenger enn grunnlinjen. Amerikanske delstatslover — Californias CMIA, og regler i New York og Texas blant andre — går lenger enn HIPAA. I EU kommer nasjonal rett i tillegg til GDPR: Tysklands § 203 StGB og § 630f BGB er eksempler. Oppbevaringstider særlig må bekreftes med advokat for ditt eget land.
Atferden til ansatte er ikke en programvarekontroll. Opplæring, nyansatte og avganger, disiplinærprosess, og hvem som i første omgang får en behandlingsrelasjon er beslutninger systemet registrerer men ikke tar.
Fysisk sikkerhet og infrastruktur hører til den som drifter. Hvor tjenerne er, hvem som kan gå bort til dem, hvordan sikkerhetskopier krypteres og lagres utenfor stedet, hvordan hovednøkkelen holdes, og den katastrofegjenopprettingstesten du faktisk kjører framfor den i planen.
Penetrasjonstesting og håndtering av sårbarheter er et program, ikke en funksjon. Systemet er åpen kildekode og driftes av deg selv for at ditt eget team eller dine egne testere skal kunne undersøke det ordentlig. Det er en invitasjon, ikke en erstatning.
Organisasjoner som vender mot NHS fyller ut Data Security and Protection Toolkit. Den vurderingen handler om virksomheten din og menneskene i den, og er utenfor omfanget av all programvare.
Noen må følge med på slettemotoren. Oppbevaring og sletting kjører som planlagte jobber. En planlagt jobb som stille slutter å kjøre er et etterlevelsesproblem som først kommer fram i en revisjon, og det er derfor det å kontrollere den står på månedsrutinen.

Hele siden på ett avsnitt, for en revisor som har lite tid

Kliniske journaler krypteres én versjon om gangen, under nøkler som holdes utenfor databasen. De åpnes bare når en uttrykkelig regel tillater det, og den regelen følger behandlingsrelasjonen framfor ansiennitet. Hvert oppslag skrives til en logg ingen kan endre. Rettinger legges til som nye versjoner framfor å overskrive den gamle. Når oppbevaringstiden løper ut, ødelegges nøkkelen, som gjør innholdet uleselig mens beviset for at det fantes og ble slettet består. Oppå den samme kjernen legger en jurisdiksjonsmodul rettighets- og styringsmaskineriet for USA, Den europeiske union eller Storbritannia. Under den verner Odoo Communitys firelagsmodell for tilgang de alminnelige forretningsopplysningene, og tjeneren er lukket bak én proxy med TLS, en brannmur og mengdebegrensning.

14 — Hvor du går videre

Resten av bildet

Denne siden er posisjonen på sikkerhet og etterlevelse. Oversikten viser hvordan delene henger sammen, katalogen lister modulene disse kontrollene faktisk bor i, og plantegningen for administratoren dekker rutinen som holder alle disse bevisene sanne måned etter måned.

MaskinenSystemoversiktFire lag, og hvor hemmelighetene og journalene faktisk ligger. ReferanseModulkatalogModulene for sikre dokumenter, kliniske journaler og e-signatur i sin helhet. PlantegningAdministratorEtterlevelsesmappen, oppbevaringskontrollene og den kvartalsvise gjennomgangen. PlantegningKlientHva en klient blir fortalt om sine egne journaler, og hva de kan be om.