Guide›Sicurezza e conformità

Diritto della sicurezza e della privacy · Stati Uniti, Unione europea, Regno Unito

Prima la legge, poi il software che la esegue.

Una cartella di salute mentale è uno dei tipi di dato più protetti che esistano. Uno sguardo sbagliato a un solo fascicolo può diventare una violazione da segnalare. Questa pagina comincia dalle tre leggi che decidono che cosa dobbiate fare — HIPAA negli Stati Uniti, il GDPR nell'Unione europea, e il GDPR britannico nel Regno Unito. Poi mostra esattamente quale parte della piattaforma assolva ciascun obbligo. Dopo di che copre come sia costruito il software stesso, come Odoo Community controlli chi veda che cosa, come venga irrobustito il server e, alla fine, le parti che restano alla vostra organizzazione.

È scritta in linguaggio semplice di proposito. Dovreste poterla consegnare a un responsabile della protezione dei dati, a un revisore della sicurezza, o a un dirigente che non ha mai letto una norma, e che tutti e tre la seguano.

Responsabili della protezione dei dati Revisori della sicurezza delle informazioni Direttori clinici Acquirenti che conducono una due diligence

3regimi giuridici coperti 5proprietà di ogni fascicolo 0modi per scavalcare l'accesso AES-256-GCMdi cifratura su ogni file 20 annila conservazione più lunga modellata

Scegliete il vostro paese Che cosa chiede la legge Stati Uniti · UE · Regno Unito a confronto Che cosa è protetto Le cinque proprietà Chi può aprire un fascicolo Odoo: accessi, connessione, ruoli Irrobustimento del server Difesa in profondità Prassi del settore sanitario Se qualcosa va storto Controlli della piattaforma Che cosa potete dimostrare Dove finisce il software

Cominciate da qui

Scegliete il paese in cui operate

La maggior parte di ciò che segue è uguale ovunque — la cifratura, il controllo degli accessi, il registro di audit, l'irrobustimento del server. Ciò che cambia da paese a paese è la macchina dei diritti e della governance che sta sopra, e quella ha una pagina tutta sua. Se state conducendo una due diligence, cominciate dal vostro paese e tornate dopo al materiale condiviso.

Stati Uniti USA HIPAA · HITECH · 42 CFR Part 2 · diritto statale La più grande delle tre. Ogni regola statunitense che raggiunga uno studio di salute mentale, che cosa sia stato costruito per ciascuna, e — alla fine — sette percorsi passo per passo di ciò che succede davvero dentro il software.

Privacy Rule: ogni diritto del paziente, comprese le parti che la maggior parte dei sistemi lascia fuori
Security Rule: tutte e otto le garanzie tecniche, più i registri amministrativi e fisici
Notifica delle violazioni: quattro fattori, 60 giorni, soglie per stato, entrambi gli orologi del fornitore
42 CFR Part 2 compresa la regola del 2024
Sette flussi — una richiesta di fascicolo, una correzione rifiutata, una comunicazione, una violazione, un nuovo paziente, uno schermo inattivo, e l'anno di conformità

Unione europea GDPR Regolamento (UE) 2016/679 Base giuridica ai sensi dell'art. 9(2)(h) anziché il consenso, cancellazione eseguita distruggendo la chiave di cifratura, portabilità come esportazione registrata, e le due scadenze per le violazioni con l'esenzione che va meritata.

Perché le cartelle di trattamento non devono poggiare sul consenso
Una cancellazione che onora il diritto senza distruggere le prove
L'orologio delle 72 ore e la domanda sulle chiavi compromesse
Registro dei trattamenti e valutazione d'impatto come documenti vivi

Deutschland Germania § 203 StGB · § 630f BGB · NIS2 · SGB V Le regole europee si applicano qui immutate — e poi la Germania aggiunge uno strato proprio, un pezzo del quale è diritto penale e decide se uno studio possa legittimamente acquistare da noi.

§ 203 StGB: perché la scelta del fornitore sia il rischio giuridico del terapeuta
Che cosa dica una Verpflichtungserklärung § 203, clausola per clausola
Dieci anni dalla fine del trattamento, non dalla data del fascicolo
NIS2 per i gruppi di studi, e il programma già costruito
Un resoconto onesto del binario convenzionato che non abbiamo

Regno Unito GDPR britannico DPA 2018 · NHS Code of Practice 2021 Che cosa il Regno Unito aggiunga sopra il GDPR: il criterio del danno grave costruito come flusso che scade da sé, il calendario di conservazione NHS fornito come dati, e un diritto sulle cartelle delle persone decedute.

Un diniego che esige un professionista nominato e decade a sei mesi
Vent'anni dall'ultimo contatto per le cartelle di salute mentale
Access to Health Records Act 1990
Il principio Caldicott 7 e perché la rottura del vetro sia una funzionalità

Australia Privacy Act 13 APP · regime NDB · diritto statale sulla conservazione Una legge federale senza esenzione per le piccole imprese quando si è erogatori sanitari, otto insiemi di regole statali sulla conservazione, e — da giugno 2025 — un paziente che può fare causa senza aspettare un regolatore.

Tutti e tredici gli Australian Privacy Principles, uno per uno
APP 8: perché nulla debba lasciare il paese
Sette anni dall'ultima annotazione, e fino ai 25 per un minore
Il flusso delle violazioni, passo per passo, più la segnalazione a 72 ore dei riscatti
Essential Eight, ISO 27001, RACGP C6.4 — e perché SOCI non si applichi

Canada PIPEDA e PHIPA 10 principi · leggi provinciali · conservazione fissata dall'ordine Nessun HIPAA, nessuna legge unica: una legge federale, una legge sanitaria che cambia con la provincia, e un ordine professionale sopra entrambe che fissa per quanto tempo conserviate un fascicolo.

Quale legge e quale commissario, provincia per provincia
I dieci principi di PIPEDA, e la PHIPA custodian per custodian
Il lockbox — l'unico concetto canadese che ancora non abbiamo
Due orologi per le violazioni, e la relazione statistica annuale di marzo
Il binario di fatturazione provinciale su cui non siamo, detto nella sezione 09

Condivisi da tutti e sei Documenti sicuri La macchina su cui ogni pagina di paese poggia Come viene cifrato un fascicolo clinico, chi possa aprirne uno, l'intera vita di un documento dall'archiviazione alla distruzione — e, alla fine, sette rischi che non hanno rimedio tecnico.

La cifratura a busta, e perché le chiavi siano due e non una
Un accesso che segue la relazione di cura
Una distruzione che distrugge una chiave anziché cancellare una riga
Sette rischi detti chiaramente, con ciò che resta a voi

01 — Cominciate dalla legge

Che cosa HIPAA, il GDPR e il GDPR britannico vi chiedano davvero

La maggior parte dei documenti di sicurezza comincia dalla tecnologia e lascia la legge alla fine. Questo fa il contrario, perché è rispetto alla legge che sarete giudicati. Qui sotto c'è ogni regime in linguaggio semplice: che cos'è, a chi si applica, e gli obblighi che pone a una clinica. Sotto ciascuno c'è la parte della piattaforma che assolve quell'obbligo.

Stati Uniti

HIPAA

HIPAA è l'Health Insurance Portability and Accountability Act. Si applica agli erogatori sanitari negli Stati Uniti e alle aziende che trattano dati sanitari per loro conto. È fatto di due parti principali. La Privacy Rule dice chi possa vedere i dati sanitari e che cosa un paziente possa chiedere. La Security Rule dice come i dati sanitari elettronici debbano essere protetti.

Minimo necessario. Il personale può vedere solo i dati che gli servono per il lavoro che ha davanti. Nella piattaforma lo fanno valere le relazioni di cura: un terapeuta raggiunge i pazienti del proprio carico di lavoro, non quelli di tutta la clinica.
L'insieme di fascicoli designato. Un paziente può chiedere una copia del proprio fascicolo, ma non di tutto ciò che la clinica detenga. Ogni tipo di documento è contrassegnato come dentro o fuori da quell'insieme, e una richiesta non può restituire ciò che ne sta fuori.
Le note di psicoterapia sono separate. HIPAA tratta gli appunti di processo di un terapeuta diversamente dal fascicolo. Nella piattaforma sono cifrati sotto una chiave diversa, così la chiave che apre il fascicolo ordinario non li apre.
Rendicontazione delle comunicazioni. Un paziente può chiedere con chi i suoi dati siano stati condivisi negli ultimi sei anni. Il registro delle comunicazioni vi risponde da registrazioni memorizzate.
Notifica delle violazioni. Se dati sanitari protetti vengono esposti, le persone vanno avvisate — salvo che i dati fossero cifrati correttamente. Quell'esenzione si chiama porto sicuro, ed è il motivo per cui la cifratura è costruita come è.
42 CFR Part 2 è una regola statunitense separata per i fascicoli dei trattamenti delle dipendenze. È più severa di HIPAA ed esige un avvertimento di ritrasmissione su tutto ciò che viene condiviso. La piattaforma genera quell'avviso anziché chiedere al personale di digitarlo.

Unione europea

GDPR

Il GDPR è il Regolamento generale sulla protezione dei dati. Si applica a qualunque organizzazione tratti dati personali di persone nell'Unione europea. I dati sanitari sono ciò che il GDPR chiama dati di categoria particolare, il che significa che trattarli è vietato salvo che ricorra una condizione precisa. Mentre HIPAA riguarda soprattutto la protezione, il GDPR riguarda anche i diritti della persona sui propri dati.

Una base giuridica per ogni tipo di documento. Per le cartelle di trattamento la condizione corretta è l'articolo 9(2)(h), la prestazione di assistenza sanitaria — non il consenso. Un consenso che una persona non possa rifiutare liberamente non è un consenso valido, e in un contesto di cura di solito non può rifiutare. La piattaforma registra la base rispetto al tipo di documento, così poi non è mai una supposizione.
Il diritto di accesso (art. 15). Una persona può chiedere una copia dei propri dati, e c'è una scadenza di legge per rispondere. La richiesta si svolge come un flusso tracciato con quell'orologio sopra.
Il diritto alla cancellazione (art. 17). Spesso chiamato diritto all'oblio. La piattaforma lo onora distruggendo la chiave di cifratura anziché la riga del database, così il contenuto sparisce ma la prova che un fascicolo sia esistito e sia stato smaltito resta.
Il diritto alla portabilità (art. 20). Una persona può chiedere i propri dati in una forma che possa portare altrove. La piattaforma costruisce un archivio zip in memoria e lo trasmette, e registra singolarmente ogni documento contenuto.
Notifica delle violazioni (artt. 33 e 34). Il regolatore va avvisato entro 72 ore da quando ne venite a conoscenza. Anche le persone coinvolte vanno avvisate, salvo che i dati fossero cifrati.
Documenti di governance (artt. 30 e 35). Dovete tenere un registro delle vostre attività di trattamento, e svolgere una valutazione d'impatto sulla protezione dei dati per il lavoro ad alto rischio. Entrambi vivono nel sistema come documenti vivi, non come un file Word che si invecchia.

Regno Unito

Il GDPR britannico e la DPA 2018

Dopo l'uscita dall'Unione europea il Regno Unito ha mantenuto il GDPR quasi immutato e lo chiama GDPR britannico. Il Data Protection Act 2018 gli sta accanto e aggiunge regole proprie del Regno Unito, diverse delle quali contano moltissimo in sanità. Il regolatore è l'Information Commissioner's Office, l'ICO.

Tutto ciò che il GDPR esige vale ancora. Accesso, cancellazione, portabilità, notifica delle violazioni e i registri di governance sono gli stessi obblighi dell'UE.
Il criterio del danno grave. I dati sanitari si possono negare alla richiesta di accesso della persona stessa quando comunicarli le causerebbe probabilmente un danno grave. Per un servizio di salute mentale è l'equivalente dell'eccezione statunitense sulle note di psicoterapia, e la procedura che la circonda è severa.
I periodi di conservazione NHS. L'NHS Records Management Code of Practice 2021 fissa per quanto tempo si conservino le cartelle — per la salute mentale, 20 anni dall'ultimo contatto. Quel calendario è fornito come dati di partenza.
Access to Health Records Act 1990. I familiari di una persona deceduta possono in certi casi chiederne le cartelle. Il GDPR non copre affatto i defunti, quindi è un diritto solo britannico con proprie regole su chi sia legittimato a chiedere.
Il principio Caldicott 7. Le linee guida sanitarie britanniche dicono che il dovere di condividere informazioni può essere importante quanto il dovere di proteggerle. Bloccare tutto è un fallimento a modo suo, ed è per questo che l'accesso di emergenza esiste ed è registrato anziché vietato.

Su che cosa tutti e quattro concordano

Sotto le differenze, i quattro regimi vogliono le stesse cinque cose. Proteggere i dati così che una copia rubata sia inutile. Lasciare che solo le persone giuste li vedano. Tenere traccia di chi li abbia visti. Conservarli solo per il tempo che serve, poi smaltirli correttamente. Poter dimostrare tutte e quattro le cose dopo. Quell'elenco condiviso è ciò che la piattaforma costruisce nello strato di archiviazione una volta, per ogni installazione. La macchina dei diritti che sta sopra è ciò che cambia da paese a paese, e arriva come modulo separato che installate per la vostra giurisdizione.

Nessuno è certificato per queste cose, e chi dice il contrario sta vendendo qualcosa

Non esiste un prodotto certificato HIPAA o certificato GDPR. Nessuna autorità rilascia quel certificato. Ciò che esiste è un elenco di controlli tecnici e organizzativi. Un software può realizzare quelli tecnici e rendere quelli organizzativi facili da eseguire e da dimostrare. Non può rendere un'organizzazione conforme da solo. L'ultima sezione di questa pagina espone esattamente quali parti restino a voi.

02 — A confronto

Lo stesso nucleo tecnico ovunque. Una macchina dei diritti diversa sopra

Cifratura, controllo degli accessi, registro di audit e conservazione sono identici in ogni paese. Sono costruiti una volta, nel nucleo condiviso, e ogni installazione li riceve. Ciò che cambia fra Stati Uniti, Unione europea, Regno Unito, Australia e Canada è il lavoro sui diritti e sulla governance che sta sopra quel nucleo. È per questo che un sistema costruito su uno standard statunitense non soddisfa automaticamente l'UE, e perché ogni paese arriva come modulo installabile a sé.

Le ultime due colonne portano i contrassegni più onesti. Gli Australian Privacy Principles chiedono meno dell'Europa in due punti, e non esiste ancora un modulo australiano — la macchina dei diritti che un'installazione australiana usa oggi è il nucleo condiviso più parti dei moduli europeo e britannico. La pagina Australia nomina ogni cucitura.

Il Canada è il più recente, e l'unica colonna in cui il corpo di regole cambia dentro il paese. Non esiste nemmeno un modulo canadese, e un obbligo non ha equivalenti in nessun altro punto di questa tabella — il lockbox, un'istruzione del paziente che recinta parte del proprio fascicolo dentro il cerchio di cura. La pagina Canada espone che cosa comporti costruirlo, e quale legge provinciale si applichi dove.

Che cosa è richiesto	Stati Uniti HIPAA · 42 CFR Part 2	Unione europea GDPR	Regno Unito GDPR britannico · DPA 2018	Australia Privacy Act 1988 · APP	Canada PIPEDA · PHIPA e leggi provinciali
Cifratura, controllo degli accessi, registro di audit, conservazione	✓ nucleo condiviso	✓ nucleo condiviso	✓ nucleo condiviso	✓ nucleo condiviso	✓ nucleo condiviso
Una ragione giuridica registrata per detenere ciascun tipo di documento	— non è così che funziona HIPAA	✓ art. 9(2)(h) per le cartelle di trattamento, non il consenso	✓ lo stesso, sotto il GDPR britannico	✓ APP 3.3 e art. 16B, registrati per tipo di documento	§ finalità e consenso, non una base giuridica enumerata
Una persona può chiedere una copia del proprio fascicolo	✓ 45 CFR 164.524, limitato all'insieme di fascicoli designato	✓ art. 15, con una scadenza di legge	✓ art. 15, più il criterio del danno grave	✓ APP 12, un termine ragionevole, e nessun costo per chiedere	✓ principio 9 di PIPEDA e art. 52 della PHIPA — 30 giorni, prorogabili
Una parte gli si può negare	✓ le note di psicoterapia stanno fuori dall'insieme di fascicoli	§ stretto, e dipende dallo Stato membro	✓ criterio del danno grave, svolto come flusso che scade	◐ i motivi dell'APP 12.3 esistono; il flusso è fornito con l'elenco britannico	◐ i motivi della PHIPA esistono; il flusso è fornito con l'elenco britannico
Una persona può chiedere la cancellazione dei propri dati	§ HIPAA non dà alcun diritto generale; decide la conservazione	✓ art. 17, eseguita distruggendo la chiave	✓ lo stesso, con le esenzioni britanniche	§ nessun diritto generale alla cancellazione; ci pensa la distruzione dell'APP 11.2	§ nessun diritto generale; ci pensano conservazione e distruzione
Una persona può portare i propri dati altrove	§ tramite il diritto di accesso; HIPAA non ne ha uno separato	✓ art. 20, zip trasmesso, ogni file registrato	✓ lo stesso	§ nessun diritto alla portabilità; lo porta il diritto di accesso	✓ il diritto della Legge 25 del Québec atterra sull'esportazione GDPR; nessun equivalente federale
Un registro di ciò che è stato condiviso, e con chi	✓ sei anni, su richiesta	✓ che cosa sia uscito, verso chi, su quale base	✓ lo stesso	✓ APP 6, che cosa sia uscito e su quale base	✓ che cosa sia uscito, verso chi, su quale base e perché
Avvisare il regolatore e le persone coinvolte dopo una violazione	✓ valutazione a quattro fattori, avviso a 60 giorni, soglie per i media e per l'HHS	✓ artt. 33 e 34, 72 ore, due orologi, domanda sulle chiavi registrata	✓ lo stesso, segnalato all'ICO	✓ regime NDB: 30 giorni per valutare, poi notificare non appena possibile	◐ la registrazione è completa; i due depositi e il conteggio di marzo non vengono prodotti
Documenti di governance scritti tenuti aggiornati	✓ registro delle politiche, versionato, sei anni per versione	✓ valutazione d'impatto (art. 35) e registro dei trattamenti (art. 30)	✓ lo stesso	✓ APP 1: registro delle politiche, registro dei rischi, reclami come registrazioni	✓ registro delle politiche, registro dei rischi, reclami come registrazioni
Un calendario di conservazione fornito pronto all'uso	⚙ varia per stato, quindi i periodi li fissate voi	⚙ varia per Stato membro, quindi i periodi li fissate voi	✓ NHS Records Management Code of Practice 2021	◐ i periodi sono noti a livello nazionale, e non è seminato nulla	⚙ fissati dal vostro ordine, quindi non c'è alcun calendario nazionale da seminare
Cartelle delle persone decedute	⚙ HIPAA le protegge 50 anni; regola non seminata	— il GDPR non si applica ai defunti	✓ Access to Health Records Act 1990	§ la legge federale si ferma alla morte; il NSW protegge per 30 anni dopo	⚙ le leggi proseguono dopo il decesso; il periodo è quello del vostro ordine
Protezione supplementare per i fascicoli sulle dipendenze	✓ 42 CFR Part 2, con l'avviso di ritrasmissione	— nessuna regola equivalente	— nessuna regola equivalente	— nessuna regola equivalente	— nessuna regola equivalente

✓CostruitoNel modulo di giurisdizione oggi, e dimostrabile. ⚙Costruito — il valore lo fissate voiIl meccanismo c'è e il numero è vostro, perché la legge lo lascia a voi o al vostro stato. Non è una mancanza. §Quel regime chiede menoNon manca nulla. La legge di questo paese dà un diritto più stretto, o arriva allo stesso punto per un'altra via. ◐Costruito in parteManca davvero qualcosa. La pagina del paese nomina esattamente che cosa. —Assente da quel regimeLa legge semplicemente non contiene questo diritto.

I due contrassegni centrali erano un contrassegno solo fino a poco fa, il che si leggeva come un unico genere di mancanza mentre solo ◐ lo è. Un periodo di conservazione che fissate voi perché lo fissa il vostro stato non è una funzionalità mancante, e nemmeno lo è il fatto che HIPAA non conceda un diritto che il GDPR concede.

03 — Che cosa è protetto

Tre tipi di dati, e uno solo è ordinario

Non tutto in una clinica ha bisogno della stessa protezione. Se trattate ogni campo come massimamente sensibile, il sistema diventa lento e scomodo e il personale comincia a tenere gli appunti in un foglio di calcolo. È quello il vero rischio di violazione nella maggior parte delle cliniche. Se non trattate nulla come sensibile, il sistema è semplicemente insicuro. La piattaforma quindi ordina i dati in tre tipi e applica la macchina pesante solo al tipo che ne ha bisogno.

Tipo di dati	Esempi	Come sono conservati	Chi può raggiungerli
Dati aziendali ordinari	Recapiti, ordini, fatture, prenotazioni, messaggi di chat	Nel database, protetti dalle regole di accesso proprie di Odoo	Il personale a cui servono per il lavoro. Il paziente stesso, tramite il portale
Fascicoli clinici e professionali	Relazioni di seduta, schede di incidente e di tutela, documenti d'identità	Come documenti sicuri: cifrati una versione alla volta, conservati fuori dall'area file normale	Solo l'équipe di cura di quel paziente, per regola esplicita. Nessuna qualifica lo concede
Registrazioni finanziarie	Fatture, compensi ai professionisti, versioni di contratto, scritture contabili	Nel libro contabile, che non si può modificare una volta emessa una scrittura	Amministrazione e direzione. Una correzione lascia una traccia anziché sovrascrivere

Perché la linea si traccia al fascicolo, non al campo

Cifrare ogni singolo campo renderebbe impossibile la ricerca. Il personale terrebbe allora i propri appunti di lavoro fuori dal sistema, dove nulla è registrato e nulla è protetto. La piattaforma quindi traccia la linea al tipo di fascicolo anziché al singolo campo. Il materiale sensibile resta dentro il sistema, dove ogni sua lettura può essere registrata.

04 — Il modello di fascicolo

Cinque cose vere di ogni fascicolo protetto

Queste cinque sono proprietà di come i dati sono conservati. Non sono politiche che si chiede al personale di seguire. Quella differenza è tutto l'argomento di questa pagina. Un controllo che dipende dal comportamento corretto delle persone è un controllo che non potete dimostrare a un revisore. Un controllo costruito nell'archiviazione sì.

Proprietà uno

Ogni versione è cifrata per conto suo

La piattaforma usa la cifratura a busta con AES-256-GCM. Significa che ogni versione di documento riceve una propria chiave casuale, e che quella chiave viene poi chiusa con una seconda chiave che appartiene a tutta l'installazione. Quella seconda chiave non è mai conservata nel database.

Chi ruba una copia del solo database non ha nulla di leggibile
I file cifrati vivono fuori dall'archivio file ordinario di Odoo e non sono mai serviti attraverso il normale percorso di scaricamento
Ruotare la chiave dell'installazione richiude le chiavi piccole senza riscrivere un solo file cifrato
Il software rifiuta di partire se quella chiave manca, è leggibile da tutti, appartiene all'account sbagliato, o è tenuta dove verrebbe copiata insieme ai dati che protegge

Proprietà due

Chiuso salvo che una regola apra

Ogni lettura deve trovare una regola che la consenta e nessuna che la vieti. Si verifica ogni volta, non una sola volta all'accesso. Essere amministratore, dirigente, o la persona che ha scritto il documento non concede nulla di per sé.

Non esiste alcuna deroga principale né alcuna via da superutente verso i contenuti clinici
L'accesso segue l'équipe di cura del paziente, non l'organigramma
Quando il personale archivia un documento, la finestra gli dice in parole semplici chi potrà aprirlo, prima che venga salvato

Proprietà tre

Ogni lettura è messa per iscritto

Si registrano le aperture, non solo le modifiche. Il registro è in sola aggiunta e concatenato per impronte, il che significa che ogni voce è legata matematicamente alla precedente. Rimuovere o modificare una voce spezza la catena e diventa visibile.

La voce è scritta prima che il contenuto sia consegnato, non dopo
Nessuno può modificarla o cancellarla, comprese le persone che amministrano il sistema
Si può produrre un elenco completo di chi abbia aperto un fascicolo per un paziente, un regolatore o i vostri legali
Le letture dal portale sono limitate in frequenza per utente, contate da quello stesso registro, così il limite tiene anche su più processi del server

Proprietà quattro

Le correzioni aggiungono, non sovrascrivono mai

Quando qualcosa viene corretto, si archivia una nuova versione. La precedente resta esattamente com'era, metadati compresi. Un fascicolo che si può modificare in silenzio non vale nulla come prova, e un giorno il vostro potrebbe dover valere qualcosa.

Una richiesta di modificare un fascicolo vi si aggiunge anziché sostituirlo
Ogni versione porta la propria chiave, così la distruzione si può fare versione per versione
Un'alterazione è quindi visibile nello storico anziché qualcosa da dedurre

Proprietà cinque

La distruzione distrugge la chiave

Quando un periodo di conservazione scade, la piattaforma distrugge la chiave di cifratura anziché cancellare la riga. Il contenuto diventa definitivamente illeggibile. Il guscio vuoto e la pista di audit restano. Questa tecnica si chiama crypto-cancellazione.

La distruzione si può dimostrare anziché soltanto affermare
La prova che un fascicolo sia esistito, e sia stato distrutto nei tempi, sopravvive
La conservazione si conta da una data di ancoraggio vera: ultimo contatto, data di nascita o data di decesso

La lacuna deliberata

Che cosa non farà, detto apertamente

La piattaforma non può cercare dentro documenti cifrati. È una conseguenza diretta della cifratura, non una funzionalità mancante. I documenti si trovano per persona di riferimento, tipo e data di archiviazione.

È detto qui perché un fornitore che prometta sia una cifratura forte sia la ricerca a testo pieno dello stesso contenuto ne sta promettendo falsamente uno dei due
È un servizio di documenti sicuri, non un dossier sanitario elettronico: nessuna cartella clinica strutturata, nessuna messaggistica HL7 o FHIR, nessuna prescrizione elettronica
Il nucleo non sa nulla di diritto sanitario. Le regole di ciascun paese arrivano come modulo separato sopra

05 — Chi può aprire un fascicolo

L'accesso segue la relazione di cura, non la qualifica

È l'idea più importante della pagina, ed è l'unica cosa che un gestore di documenti ordinario non sa esprimere. Una relazione di cura è un legame registrato fra un clinico e un paziente, con un tipo, una data di inizio e una data di fine. Un terapeuta raggiunge i fascicoli delle persone del proprio carico di lavoro. Non quello della clinica. Il proprio. Quando la relazione finisce, finisce anche l'accesso, dopo un breve periodo di grazia abbastanza lungo da finire gli appunti in sospeso.

È questo che trasforma il « minimo necessario » da politica in un manuale a qualcosa che il software fa davvero valere, e che potete dimostrare in un audit.

Che cosa succede a ogni singola lettura

Cinque passi, ogni volta, per ogni documento

Chi sta chiedendo?Un utente collegato, ricondotto a una persona precisa. Non un ruolo e non un gruppo.
Esiste una regola che lo consenta?Perché è l'interessato, perché è nell'équipe di cura, o perché qualcuno gli ha concesso un accesso nominato. Nessuna regola, nessun accesso.
Esiste una regola che lo vieti?Un rifiuto batte sempre un permesso. Le note di psicoterapia, i documenti sigillati e i fascicoli negati rifiutano su ogni via d'ingresso.
Scrivere la voce di registroAggiunta al registro in sola aggiunta prima che venga rimandato indietro qualunque contenuto.
Decifrare in memoria e trasmettereNulla viene scritto su disco in uscita e nulla viene servito dall'area file ordinaria.

Che cosa non vi fa entrare

Elencato esplicitamente, perché gli acquirenti lo chiedono sempre

Essere amministratoreUn account amministratore non apre di per sé alcun contenuto clinico. Non c'è porta di servizio per l'assistenza o la manutenzione.
Averlo scritto di personaLe schede di incidente e di tutela sono chiuse anche alla persona che le ha depositate, perché sono depositate presso il direttore della clinica.
Essere alti in gerarchiaI ruoli clinici decidono quali schermate dell'applicazione una persona raggiunga. Non decidono mai che cosa possa aprire.
Essere il pazienteUn paziente vede un fascicolo che lo riguarda solo quando una regola glielo concede espressamente. È una decisione clinica e giuridica, presa di proposito e registrata con il motivo e il nome di chi l'ha presa.
Indovinare un riferimento di documentoUn documento che non potete vedere restituisce « non trovato », mai « vietato ». Altrimenti indovinare riferimenti diventa un modo per scoprire chi detenga fascicoli.

L'accesso di emergenza esiste, e non è mai silenzioso

A volte un clinico ha davvero bisogno di un fascicolo con cui non ha alcuna relazione — una crisi, una chiamata fuori orario, un collega che si è ammalato. Se la vostra organizzazione lo permette, è disponibile una via di accesso di emergenza. Usarla è registrato come evento e riesaminato dopo dal responsabile della privacy.

È questo il progetto in una frase: l'accesso è disponibile quando qualcuno ne ha davvero bisogno, e non è mai silenzioso. È deliberato. Un sistema che si limita a bloccare fallisce a modo suo. Le linee guida britanniche (principio Caldicott 7) dicono che il dovere di condividere può essere importante quanto quello di proteggere, ed è per questo che l'accesso di emergenza è una funzionalità progettata del nucleo anziché un buco lasciato dentro.

06 — Il nucleo aziendale

Come Odoo Community decide chi siete, e che cosa vedete

La macchina clinica descritta sopra poggia su Odoo 19 Community, che è il nucleo aziendale a codice aperto. Odoo porta il proprio modello di controllo degli accessi, e vale la pena capirlo, perché è ciò che protegge i dati aziendali ordinari — le prenotazioni, le fatture, i contatti e i messaggi che compongono la maggior parte del sistema.

Questa sezione ha sei parti: i quattro livelli di controllo degli accessi che decidono che cosa una persona collegata possa raggiungere; l'accesso — password, autenticazione a due fattori, passkey e le politiche attorno; che cosa significhi davvero « basato sui ruoli » qui, perché l'espressione si usa a sproposito dappertutto; l'isolamento dei database; la OWASP Top Ten con la risposta di Odoo a ciascuna voce; e quanto valga davvero il codice aperto .

Tutto ciò che segue è fornito con Odoo 19 Community. Nulla è un componente aggiuntivo a pagamento, ed è tutto codice sorgente leggibile che il vostro reparto sicurezza può esaminare.

Il modello di accesso di Odoo ha quattro livelli. Ciascuno risponde a una domanda diversa, e una richiesta deve superarli tutti e quattro. Sono verificati dentro lo strato dati stesso, che è la parte importante: le stesse verifiche valgono sia che un fascicolo si raggiunga dall'interfaccia web, dalla passerella dell'applicazione mobile, o dall'API remota di Odoo. Non esiste una via che le aggiri.

Livello uno

Gruppi — quale parte del sistema raggiungete

Un gruppo è un ruolo. L'appartenenza decide quali menu, schermate e pulsanti una persona veda. I gruppi possono implicarne altri, così un supervisore detiene in automatico tutto ciò che detiene un clinico, senza che i permessi siano scritti due volte.

I ruoli di questa installazione comprendono clinico curante, supervisore, direttore di clinica, custode dei fascicoli, accoglienza e responsabile della privacy
L'accoglienza è solo anagrafica: nessun contenuto clinico e nessun accesso ai documenti di alcun tipo
Un gruppo concede portata, mai contenuto. Avere il ruolo di clinico non apre di per sé il fascicolo di alcun paziente — lo fa la relazione di cura

Livello due

Diritti di accesso al modello — che cosa potete fare a un tipo di fascicolo

Per ogni tipo di fascicolo e ogni gruppo, Odoo conserva quattro permessi distinti: leggere, creare, modificare e cancellare. Sono dichiarati in file di testo semplice forniti con ciascun modulo, così si possono leggere e riesaminare senza eseguire nulla.

Questa installazione dichiara 660 voci di accesso su 35 moduli
Tutto ciò che non è elencato è negato. L'accesso si concede nominandolo, mai dimenticandosi di bloccarlo
Leggere senza modificare è comune di proposito: molti ruoli possono vedere un fascicolo che non devono cambiare

Livello tre

Regole di record — quali singoli fascicoli potete toccare

Una regola di record è un filtro applicato a ogni interrogazione. È ciò che rende « i vostri pazienti » e « la vostra azienda » reali anziché una questione di quale schermata uno apra. Le regole globali valgono sempre. Le regole attaccate a un gruppo allargano l'accesso solo per quel gruppo.

Questa installazione definisce 117 regole di record nei moduli clinico, di prenotazione, dei contratti, della firma elettronica e della reportistica
Esempi tipici: un clinico vede le relazioni di cura in cui è il clinico; un utente del portale vede solo le prenotazioni che appartengono alla propria scheda contatto
La regola è applicata dallo strato dati, quindi vale allo stesso modo per le viste a elenco, le relazioni, le esportazioni e l'API remota

Livello quattro

Regole di campo e separazione del portale

Singoli campi si possono riservare a gruppi precisi, così due persone possono aprire lo stesso fascicolo e vederne quantità diverse. Separatamente, Odoo tiene gli utenti del portale in una classe del tutto distinta dal personale.

Un utente del portale — un paziente o un contatto esterno — non ha alcun accesso al back office, solo alle pagine pubblicate espressamente per lui
Le pagine web pubbliche girano come utente anonimo a cui è concesso quasi nulla, così un errore su una pagina pubblica non può esporre dati del personale
Ogni via di controllo di questa installazione dichiara se richieda un utente collegato o sia deliberatamente pubblica: 174 vie richiedono un accesso, 57 sono pubbliche per progetto

Protezione del framework	Che cosa fa Odoo	Che cosa impedisce
Costruzione delle interrogazioni	Tutte le interrogazioni al database sono costruite dal framework a partire da filtri strutturati. Il codice applicativo non scrive SQL grezzo per letture e scritture ordinarie	L'iniezione SQL attraverso campi di ricerca, filtri e parametri di URL
Escape nei modelli	Il motore dei modelli di Odoo esegue per impostazione predefinita l'escape dei valori che rende in una pagina. L'output grezzo va chiesto espressamente	Il cross-site scripting, in cui un testo salvato da un utente viene eseguito come codice nel browser di un altro
Token dei moduli	I moduli web che modificano dati portano un token legato alla sessione dell'utente, e il server rifiuta un invio che ne sia privo	La falsificazione di richiesta intersito, in cui un altro sito invia in silenzio un modulo come vostro utente collegato
Sessioni	Lo stato di sessione è tenuto sul server. Il browser detiene solo un identificativo, in un cookie contrassegnato così che gli script della pagina non possano leggerlo	Il furto di sessione tramite uno script in esecuzione nella pagina
Password	Conservate solo come impronta a senso unico, mai in una forma reversibile. Lo schema di hashing si può aggiornare senza chiedere a tutti di reimpostare	Che una tabella utenti rubata diventi un elenco di password utilizzabili
Gestore dei database	Le schermate che creano, copiano, ripristinano e cancellano interi database sono chiuse in produzione, e un nome host è legato esattamente a un database	Che chiunque raggiunga il server possa trovare, copiare o sovrascrivere un database
Operazioni privilegiate	Il codice può scavalcare le regole di accesso solo dove uno sviluppatore l'abbia scritto deliberatamente, per un'operazione definita, in un punto nominato. I contenuti clinici non sono uno di quei punti	Un'ampia escalation di privilegi accidentale sepolta nel codice applicativo
Codice aperto	Odoo Community è pubblicato con licenza aperta e i moduli di questa piattaforma sono leggibili per intero. Le correzioni di sicurezza sono pubblicate da Odoo e applicate alla vostra installazione	Dover prendere per buone le affermazioni di sicurezza di un fornitore

L'accesso: password, secondi fattori e le politiche attorno

I quattro livelli qui sopra decidono che cosa una persona collegata possa raggiungere. Questa è la parte che viene prima — come Odoo stabilisca che qualcuno sia chi dichiara di essere, e che cosa faccia quando non lo è. È tutto fornito con Odoo 19 Community; nulla è un componente aggiuntivo a pagamento.

Controllo	Stato	Che cosa fa, e che cosa decidete voi
Le password sono hashate, mai conservate	✓	Conservate come impronta PBKDF2-SHA512 con un sale per password e un fattore di lavoro configurabile. Un'impronta non si può ritrasformare in una password, quindi una tabella utenti rubata non è un elenco di credenziali. Il fattore di lavoro si può alzare man mano che l'hardware accelera, e le password vengono rihashate al valore più forte alla successiva connessione di ciascuno — a nessuno si chiede di reimpostare. Nessuno può rileggere una password, compresi i vostri amministratori e noi compresi: il campo si legge sempre come vuoto, chiunque lo chieda. Se qualcuno perde la password, l'unica via è una reimpostazione, ed è la risposta corretta anziché una funzionalità mancante.
Autenticazione a due fattori	⚙	Costruita e fornita in ogni installazione, con i codici standard delle app di autenticazione (TOTP) che funzionano con Google Authenticator, Authy, 1Password e gli altri. Una persona può registrare un dispositivo da sé, e i dispositivi fidati si possono ricordare per un periodo. Fissate voi: se sia facoltativa o obbligatoria. Un'impostazione la attiva per tutti, un'altra per tutti gli account del personale — e chi non abbia un'app di autenticazione riceve invece un codice monouso via email, così imporla non lascia nessuno a piedi. In un'installazione statunitense dovrebbe essere attiva: è attesa dalla Security Rule e diventa di fatto obbligatoria se l'aggiornamento proposto verrà finalizzato.
Il doppio fattore chiude anche la porta dell'API	✓	Il dettaglio che lo rende prezioso. Una volta che una persona ha un secondo fattore, la sua password smette di funzionare per l'accesso da macchina a macchina — un'integrazione deve usare una chiave API nominata. Senza quella regola, l'autenticazione a due fattori protegge la schermata di accesso e lascia aperta la porta sul retro, che è il modo in cui la si aggira nella pratica.
Passkey	⚙	Odoo 19 supporta le passkey — accesso con un'impronta digitale, il volto o una chiave hardware anziché con una password. Non si digita nulla di sottraibile con l'inganno, quindi elimina tutta la classe di attacchi in cui si convince qualcuno a inserire la propria password su una copia convincente della vostra pagina di accesso. Decidete voi se offrirle.
Chiavi API anziché password per le integrazioni	✓	Ogni integrazione riceve una propria chiave nominata con il proprio ambito, elencata rispetto alla persona che l'ha creata, revocabile una alla volta. Una chiave che trapela si spegne senza cambiare la password di nessuno e senza rompere le altre integrazioni.
Politica sulle password	⚙	Una lunghezza minima imposta nel momento in cui si fissa una password, con un indicatore di robustezza mostrato mentre si digita. Fissate voi il minimo. Alla consegna è zero, il che significa che deciderlo fa parte della messa in esercizio anziché essere una scoperta successiva. Non c'è deliberatamente alcuna impostazione per imporre classi di caratteri — una maiuscola, una cifra, un simbolo. Non è un'omissione. La ricerca e le linee guida attuali del NIST hanno entrambe concluso che quelle regole sono controproducenti: spingono verso sostituzioni prevedibili e verso password scritte su un foglietto, e rendono meno della lunghezza. Lunghezza più un secondo fattore è la combinazione che funziona.
Protezione dalla forza bruta	✓	Attiva per impostazione predefinita. Dopo dieci tentativi falliti, ogni ulteriore prova è rifiutata per sessanta secondi contati dall'ultimo fallimento — così un attacco a tentativi è ridotto a un tentativo al minuto anziché a migliaia. Entrambi i numeri sono impostazioni che un amministratore di database può cambiare (o disattivare, mettendo il primo a zero). Funziona senza che nessuno debba accorgersi dell'attacco.
Riautenticazione per le azioni sensibili	✓	Cambiare impostazioni di sicurezza, registrare un secondo fattore o creare una chiave API chiede alla persona di dimostrare di nuovo chi sia, anche a sessione in corso. Uno schermo incustodito non si può usare per indebolire l'account a cui è collegato.
Cambiare una password chiude ogni sessione	✓	La validità di sessione deriva dall'account stesso, quindi cambiare una password o disattivare un account invalida ogni sessione esistente ovunque nello stesso istante — ogni browser, ogni dispositivo, subito. È ciò che rende « qualcuno se n'è andato, chiudetegli l'accesso » un'unica azione anziché una speranza.
Accesso aziendale, dove lo usate	⚙	Odoo può autenticarsi contro la vostra directory esistente (LDAP o Active Directory) o un fornitore di identità OAuth2, così gli ingressi e le uscite si gestiscono una volta sola nel posto in cui la vostra organizzazione li gestisce già. Facoltativo, e vale la pena solo se ne avete già uno.
Documenti del portale dietro un secondo fattore	⚙	Questo è nostro e non di Odoo, ed esiste perché l'accesso di un paziente è il punto più debole di qualunque sistema clinico. Attivatelo e un utente del portale che non abbia registrato un secondo fattore può comunque collegarsi e vedere che dei documenti esistano — ma non può aprirne uno finché non lo fa. Tocca persone che usano già il portale, quindi avvisatele prima di attivarlo.

✓Attiva per impostazione predefinitaFunzionante dal momento in cui il sistema è installato. ⚙Costruito — lo attivate voiPresente e supportato. Se usarlo, e con quanto rigore, è una vostra decisione.

Che cosa significa davvero « basato sui ruoli » qui

Quasi ogni sistema si dichiara basato sui ruoli. L'espressione va disfatta, perché nella maggior parte dei prodotti significa che cambia il menu e in Odoo significa che cambiano i dati.

Un ruolo in Odoo è un gruppo. I gruppi possono contenerne altri, così un supervisore detiene in automatico tutto ciò che detiene un clinico senza che nessuno scriva i permessi due volte — e quando un permesso viene corretto, lo è una volta sola per tutti quelli che lo ereditano. Ciò che un gruppo concede non è una schermata. Sono quattro permessi distinti (leggere, creare, modificare, cancellare) su ciascun tipo di fascicolo, più filtri che decidono quali fascicoli di quel tipo, più la possibilità di nascondere singoli campi.

La conseguenza importante: nascondere un menu non è un permesso. In un sistema in cui i ruoli cambiano solo il menu, chiunque impari un indirizzo web raggiunge i dati che ci stanno dietro. In Odoo le verifiche vivono nello strato dati, quindi lo stesso rifiuto avviene sia che il fascicolo si raggiunga da una schermata, da una relazione, da un'esportazione, da una ricerca o dall'API remota. Non esiste una via che le salti.

01I ruoli portano il nome del mestiere

Clinico curante, supervisore, direttore di clinica, custode dei fascicoli, accoglienza, responsabile della privacy, contabile, gestore dei contratti. L'accoglienza è solo anagrafica — nessun contenuto clinico e nessun accesso ai documenti di alcun tipo.

Risponde a« Mostratemi che cosa può vedere un addetto alla reception »

02I ruoli concedono portata, mai contenuto

Avere il ruolo di clinico non apre di per sé il fascicolo di alcun paziente. Lo fa la relazione di cura. È la frase più importante di questo sito sull'accesso.

Risponde a« Un terapeuta può leggere i fascicoli di tutta la clinica? »

03Quattro permessi, non uno

Leggere, creare, modificare e cancellare sono distinti per ogni tipo di fascicolo. Leggere senza modificare è comune di proposito: moltissimi ruoli devono vedere qualcosa che non devono cambiare.

Risponde a« Chi può modificare una fattura dopo che è stata emessa? »

04I filtri di riga decidono quali fascicoli

« I vostri pazienti », « la vostra azienda », « le prenotazioni che vi appartengono ». Applicati a ogni interrogazione, quindi valgono allo stesso modo per elenchi, relazioni, esportazioni e API.

Risponde a« Che cosa impedisce a un'esportazione di tirare fuori tutto? »

05Le regole globali non si possono allargare

Una regola attaccata a nessun gruppo vale per tutti e si combina con ogni altra regola, quindi restringe l'accesso e non si può mai aggirare aggiungendo un ruolo. La separazione fra aziende è costruita così.

Risponde a« Una clinica può vedere i dati di un'altra? »

06Singoli campi si possono nascondere

Due persone possono aprire lo stesso fascicolo e vederne quantità diverse. Usato qui per le cifre di costo e di margine, e per i campi che solo un custode dei fascicoli dovrebbe leggere.

Risponde a« Chi vede un contratto ne vede anche il margine? »

07I pazienti sono una classe di utenti diversa

Un utente del portale non ha alcun accesso al back office — non una vista ristretta, proprio nessuno. Raggiunge solo le pagine pubblicate per lui. Le pagine web pubbliche girano come utente anonimo a cui è concesso quasi nulla.

Risponde a« Qual è il caso peggiore se un accesso paziente viene rubato? »

08Ogni via dichiara il proprio accesso

Ogni indirizzo web di questa installazione dichiara se richieda un utente collegato o sia deliberatamente pubblico: 174 richiedono un accesso, 57 sono pubblici per progetto. Nulla è pubblico per caso.

Risponde a« Quali dei vostri URL funzionano senza accesso? »

09È tutta configurazione leggibile

I permessi arrivano come file di testo semplice dentro ciascun modulo. Il vostro reparto sicurezza può leggere chi ottenga che cosa senza eseguire il sistema, e confrontarlo fra le versioni.

Risponde a« Possiamo verificare noi stessi i permessi? »

Un database per clinica, e nessun passaggio

I vostri dati vivono in un database tutto loro. Non è una tabella condivisa con una colonna cliente dentro, che è la disposizione in cui una sola interrogazione sbagliata restituisce i fascicoli di qualcun altro.

Odoo impone quella separazione alla connessione: una richiesta porta un nome host, il nome host seleziona esattamente un database, e non esiste alcun percorso dall'interno di un database a un altro in esecuzione sullo stesso server. Nulla nell'applicazione può indirizzare un database a cui non sia stata connessa. Oltre a questo, le schermate che creano, copiano, ripristinano e cancellano interi database sono chiuse in produzione, così nessuno che sfogli il server può elencare ciò che c'è.

Dentro il vostro database, un secondo livello fa lo stesso lavoro fra aziende: se fate girare più di una clinica su una sola installazione, la separazione fra aziende è scritta come regole globali — quelle che valgono per tutti e non si possono mai allargare aggiungendo un ruolo.

La OWASP Top Ten, e dove sta Odoo su ciascuna

L'Open Web Application Security Project pubblica l'elenco dei modi più comuni in cui le applicazioni web vengono violate. È l'elenco che un revisore della sicurezza percorre, quindi eccolo con la risposta di Odoo a ciascuna voce. Lo schema da notare è che la maggior parte di queste è impedita dalla progettazione del framework anziché dal fatto che gli sviluppatori si ricordino di stare attenti — che è l'unico tipo di prevenzione che sopravvive a una scadenza.

L'attacco	Stato	Perché qui non funziona
Iniezione, in particolare SQLun input ostile trattato come comando	✓	Il codice applicativo non scrive interrogazioni a mano. Sono costruite dal framework a partire da filtri strutturati, con ogni valore passato separatamente dall'interrogazione stessa, così un testo digitato da qualcuno non può mai diventare parte del comando. Uno sviluppatore dovrebbe uscire dalla propria strada per scrivere un'interrogazione grezza, e i moduli clinici non lo fanno.
Cross-site scriptingun testo salvato da una persona viene eseguito come codice per un'altra	✓	Tutto ciò che viene reso in una pagina passa per l'escape per impostazione predefinita. Mettere contenuto grezzo in una pagina va chiesto espressamente ed è visibile nel codice quando si fa. L'impostazione predefinita è sicura, quindi dimenticarsene produce qualcosa di brutto anziché di pericoloso.
Falsificazione di richiesta intersitoun altro sito invia un modulo come vostro utente collegato	✓	Qualunque modulo che modifichi dati deve portare un token legato alla sessione di quella persona, e il server rifiuta un invio che ne sia privo. Il token esiste solo perché la persona ha davvero caricato la vostra pagina, e il sito di un attaccante non può ottenerlo.
Esecuzione di file malevolifar eseguire al server del codice che avete fornito	✓	Non esiste alcuna funzionalità che includa un file remoto. Dove utenti privilegiati possono scrivere piccole espressioni per adattare il comportamento, queste girano in un ambiente isolato che blocca l'accesso al file system, alla rete, e a qualunque cosa il cui nome cominci con un doppio trattino basso — un elenco deliberatamente corto di operazioni permesse anziché un elenco di proibite.
Riferimento diretto non sicuro a un oggettocambiare un numero in un URL per raggiungere il fascicolo di qualcun altro	✓	È quella che prende la maggior parte dei sistemi, e la risposta di Odoo è strutturale: il controllo degli accessi non è realizzato nelle schermate. Cambiare il numero di un fascicolo in un indirizzo web raggiunge la stessa verifica dello strato dati di tutto il resto e lì viene rifiutato. Non c'è alcun rischio nel fatto che un riferimento sia visibile, perché non è il riferimento a concedere l'accesso.
Mancata limitazione dell'accesso agli URLraggiungere una pagina conoscendone l'indirizzo	✓	La stessa risposta, e vale la pena dirla due volte perché è la differenza fra un vero controllo degli accessi e un menu ordinato. Qui la sicurezza non poggia su un collegamento nascosto. Dove una pagina debba davvero funzionare senza accesso — un paziente che conferma un appuntamento da un'email — l'indirizzo porta un token firmato unico per quel fascicolo e quella persona.
Archiviazione crittografica non sicuracredenziali protette male o per nulla	✓	Le password sono hashate con PBKDF2-SHA512 e allungamento della chiave, come descritto sopra, e si possono evitare del tutto in locale autenticandosi contro la vostra directory o il vostro fornitore di identità. I documenti clinici vanno ancora oltre: cifrati per versione sotto chiavi tenute fuori dal database.
Comunicazioni non sicuretraffico inviato in chiaro	✓	Connessioni cifrate ovunque, con le richieste non cifrate reindirizzate anziché servite, e intestazioni del browser che rifiutano un declassamento. Poiché questa piattaforma è auto-ospitata, questo è un controllo di installazione anziché una proprietà del software — si imposta come parte di un'installazione standard ed è descritto nella sezione 07.
Raggiungere gli interni tramite l'APIchiamare qualcosa che non doveva essere chiamato	✓	Non è nell'elenco OWASP ma vale la pena aggiungerlo, perché è quello che si dà per scontato sia una falla. L'API remota rifiuta di chiamare qualunque metodo interno — tutto ciò il cui nome cominci con un trattino basso, più un elenco nominato di metodi pericolosi. Solo i metodi pubblicati deliberatamente si possono raggiungere da fuori, il che limita nettamente ciò che un errore nel codice applicativo possa esporre.

Il codice aperto, e quanto valga davvero

« Codice aperto » si dice spesso come se fosse di per sé una funzionalità di sicurezza. Non lo è. Ciò che vi dà è preciso e merita di essere nominato con esattezza.

Potete verificare anziché credere

Ogni riga di Odoo Community e ogni riga dei moduli clinici possono essere lette dal vostro reparto sicurezza o da collaudatori che assumete. I permessi arrivano come file di testo semplice. Nulla di questa pagina va preso per buono, che è una posizione diversa da quella di un prodotto chiuso in cui le stesse affermazioni si possono solo asserire.

È un invito a verificare, non un sostituto della verifica.

Molte più persone lo guardano

Odoo è esaminato di continuo da utenti, contributori e ricercatori di sicurezza indipendenti in tutto il mondo, e le segnalazioni di bug della comunità sono una fonte reale di riscontri sulla sicurezza. Odoo gestisce un programma di divulgazione responsabile e pubblica le correzioni come avvisi.

Il suo processo di sviluppo comprende una revisione del codice in cui la sicurezza è una delle cose riviste, tanto per il codice nuovo quanto per quello contribuito.

Decidete voi quando arrivano le correzioni

Auto-ospitare significa che le correzioni di sicurezza si applicano alla vostra installazione secondo il vostro calendario anziché comparire da un giorno all'altro. È un vantaggio per un servizio clinico che deve convalidare i cambiamenti — ed è anche un dovere, perché una correzione che nessuno applica non protegge nessuno.

Tenersi aggiornati sta nell'elenco dell'esercente alla sezione 07, ed è il modo più comune in cui un'installazione per il resto ben costruita finisce compromessa.

Una distinzione da maneggiare con cura

Odoo pubblica una propria pagina sulla sicurezza, e parti di essa descrivono il servizio in nuvola di Odoo — le loro immagini server irrobustite, i loro aggiornamenti, il piccolo numero di loro ingegneri che può raggiungere una macchina e solo tramite una chiave cifrata da un portatile cifrato. Quelle cose sono reali, e non sono vostre, perché questa piattaforma è auto-ospitata sulla vostra infrastruttura.

Tutto ciò che in questa pagina sta sopra la linea è una proprietà del software e vale per voi esattamente come scritto. Gli equivalenti lato server — sistema operativo irrobustito, aggiornamenti, chi detenga l'accesso SSH, cifratura integrale del disco sulle macchine che lo amministrano — spettano a voi, e sono esposti onestamente nella sezione 07, comprese le parti che spettano a chi gestisce i server. Leggere la pagina sulla nuvola di Odoo e supporre che descriva la vostra installazione è l'errore più comune che si fa su Odoo auto-ospitato, ed è il genere di cosa che si sfalda in una due diligence.

Dove finisce il modello di Odoo e comincia quello clinico

I quattro livelli di Odoo sono robusti, ben collaudati e sufficienti per dati aziendali ordinari. Non bastano da soli per un fascicolo clinico, per un motivo: sono configurazione, e la configurazione può essere cambiata da chi abbia il ruolo giusto. È per questo che i documenti clinici sono cifrati in aggiunta sotto chiavi tenute fuori dal database, e perché le note di psicoterapia usano un'altra chiave ancora. Se domani ogni regola Odoo del sistema fosse sbagliata, il contenuto cifrato continuerebbe a non aprirsi.

07 — Il server

Come viene irrobustita la macchina stessa

La sicurezza applicativa conta solo se il server sotto è chiuso come si deve. La piattaforma è auto-ospitata, il che significa che gira su un'infrastruttura che controllate voi anziché sulla nuvola di un fornitore. È un vantaggio reale per un servizio sanitario, e viene con un dovere reale: l'irrobustimento qui sotto fa parte dell'installazione, e va mantenuto vero anche dopo.

Tutto ciò che sta nella prima tabella si imposta come parte di un'installazione standard ed è documentato nelle guide di installazione. La seconda tabella è la parte che spetta a chi gestisce i server.

Area	Come è configurata	Perché si fa così
Nulla è esposto direttamente	I servizi applicativi ascoltano solo sulla macchina stessa. Tutto il traffico esterno arriva attraverso un proxy inverso nginx, che è l'unica cosa su una porta pubblica	Una porta d'ingresso sola anziché diverse. Certificati, intestazioni, limiti e registrazione si applicano tutti in un solo posto
Cifratura in transito	Certificati TLS da Let's Encrypt, emessi e rinnovati in automatico. L'HTTP semplice è reindirizzato a HTTPS anziché servito	Non c'è alcuna via non cifrata, nemmeno per sbaglio, e il rinnovo non è qualcosa che una persona debba ricordare
Intestazioni di sicurezza del browser	Strict-Transport-Security per un anno, X-Frame-Options impostato su same-origin, X-Content-Type-Options impostato su nosniff	Il browser rifiuta di scendere a HTTP, rifiuta che il sito sia incorniciato da un altro sito, e rifiuta di indovinare i tipi di file
Firewall	Solo le porte 80 e 443 sono aperte verso il mondo. Le porte applicative, il database e Redis non sono raggiungibili da fuori la macchina	Il database non è mai indirizzabile da Internet. Un telefono è ad almeno due salti da qualunque riga
Limitazione di frequenza	Limiti al proxy sulle richieste in entrata, più secchi a gettoni tenuti in Redis dentro la passerella per le vie pubbliche e le letture di documenti dal portale	Il proxy ferma le ondate. I contatori Redis tengono su più processi del server, così un limite per utente significa ciò che dice
Un nome host, un database	Odoo è configurato così che il nome host nella richiesta selezioni esattamente un database, e le schermate di gestione dei database sono chiuse	Nessuno che sfogli il server può elencare, copiare, ripristinare o cancellare un database
Servizi, non shell	La passerella e Odoo girano come servizi di sistema gestiti sotto account propri, avviati in automatico e riavviati in caso di guasto	Nulla gira sotto un account di amministrazione, e un riavvio non dipende dalla presenza di qualcuno collegato
I segreti restano sul server	Le chiavi di firma e le credenziali di terze parti vivono in un file di ambiente leggibile solo dall'account di servizio. L'applicazione mobile non ne porta nessuna	L'applicazione si può smontare senza apprendere nulla. Una credenziale ruotata ha effetto per tutti nello stesso istante, senza una nuova versione dell'applicazione
I documenti cifrati vivono a parte	Il testo cifrato è scritto in una directory propria con permessi propri, fuori dall'archivio file ordinario di Odoo, e non è mai servito dal percorso di scaricamento ordinario	Un server web mal configurato non può pubblicare per sbaglio file clinici
La chiave principale è verificata all'avvio	Il modulo di cifratura legge la chiave da un percorso proprio e rifiuta di partire se il file manca, è leggibile da tutti, appartiene all'account sbagliato, o si trova in una directory che viene salvata nel backup insieme ai dati	Il guasto più comune nel mondo reale è la chiave che finisce nello stesso backup dei dati che protegge. Il software lo verifica anziché fidarsi di una procedura
WebSocket sullo stesso canale	Chat, presenza e segnalazione delle chiamate passano dallo stesso proxy e dallo stesso certificato di tutto il resto	Una connessione, una politica, nessun secondo ascoltatore da mettere in sicurezza a parte
Tracciamento delle richieste	Ogni richiesta porta un identificativo attraverso la passerella e lo restituisce nelle intestazioni di risposta, insieme al tempo impiegato	Un incidente si può ricostruire fra i servizi anziché indovinare da file di registro separati

L'irrobustimento che spetta a chi gestisce i server

Non sono lacune del software. Sono decisioni e routine che solo l'esercente può prendere, e nessun fornitore può prenderle per voi. Sono elencate chiaramente così che nessuno le dia per coperte.

Aggiornamenti del sistema operativo. Un calendario di aggiornamenti di sicurezza sull'host, e qualcuno il cui mestiere sia confermare che siano stati applicati.
Cifratura del disco sull'host. I documenti sono cifrati singolarmente dalla piattaforma, ma la cifratura integrale del disco protegge tutto il resto sulla macchina, compresi i registri e i file temporanei.
I backup, e la loro cifratura. Dove vanno i backup, come sono cifrati, chi possa ripristinarli, e per quanto si conservino. Un backup è una copia completa dei vostri dati senza alcuna delle vostre regole di accesso attaccata.
La chiave principale va salvata a parte. Se la chiave si perde, ogni documento cifrato è perso definitivamente — è questo il senso del progetto. Va salvata in backup, e non va salvata accanto ai dati.
Accesso amministrativo al server. Chiavi SSH anziché password, nessun accesso diretto come root, un elenco di chi detenga l'accesso, e la sua rimozione il giorno in cui qualcuno se ne va.
Prove di ripristino. Un backup che nessuno ha mai ripristinato è una speranza, non un controllo. Provatelo secondo un calendario e mettete per iscritto che l'avete fatto.
Monitoraggio e avvisi. Qualcuno dev'essere avvisato quando un servizio si ferma, un disco si riempie, un certificato sta per scadere, o un processo di conservazione pianificato smette di girare.
Autenticazione a più fattori per gli account del personale. Fortemente raccomandata per chiunque raggiunga contenuti clinici, e di fatto richiesta se l'aggiornamento proposto alla HIPAA Security Rule verrà finalizzato. Verificate con il vostro amministratore se sia attiva nella vostra installazione.
Collocazione in rete. Se il database stia sulla stessa macchina o su un'altra, che cosa possa raggiungerlo, e se l'amministrazione avvenga su una rete privata o una VPN.
Test di penetrazione. Il parco è a codice aperto e auto-ospitato proprio perché i vostri collaudatori possano esaminarlo come si deve. È un invito, non un sostituto del farlo.

08 — Difesa in profondità

Quattro livelli, e ciascuno rifiuta qualcosa che il successivo non vede mai

Difesa in profondità significa non affidarsi ad alcuna protezione singola. Una richiesta deve superare tutti e quattro i livelli qui sotto. Il valore non sta nel fatto che uno di essi sia impossibile da violare. Sta nel fatto che falliscono in modi diversi, così un errore in uno è molto improbabile che sia un errore in tutti e quattro.

1 · Dispositivo e superficie Ciò che una persona tiene in mano Non fidato

Nessun segreto sul dispositivoL'applicazione porta solo chiavi pubbliche. Si può smontare senza apprendere nulla.

Accesso biometrico e blocco dell'applicazioneSopra il blocco schermo del telefono, non al suo posto.

Token in archiviazione sicuraTenuti nel portachiavi della piattaforma, non in file applicativi ordinari.

Il database è irraggiungibileL'applicazione non può indirizzare affatto il database, su nessuna rete.

HTTPS · token di breve durata

2 · Passerella L'unico back-end che l'applicazione conosca Custodisce i segreti

Ogni chiave di terze parti vive quiLe credenziali di pagamento, IA, messaggistica e archiviazione non lasciano mai il server.

Token firmati di breve durataCiascuno porta per chi sia, quando sia stato emesso, quando scada e un identificativo unico. Rinnovati anziché di lunga durata.

Hashing delle passwordA senso unico, con lo schema aggiornabile senza reimpostazione.

Limitazione di frequenzaContatori tenuti in Redis, condivisi da ogni processo del server.

Convalida dell'inputLe richieste malformate sono rifiutate qui, prima che il nucleo aziendale le veda.

Collegamenti firmati e a scadenzaI media passano da un proxy. Nulla è servito da un indirizzo che si possa indovinare.

account di servizio · privilegio minimo

3 · Nucleo aziendale Dove le regole vivono davvero Autorevole

Gruppi, diritti di accesso e regole di recordI quattro livelli di Odoo, applicati comunque si raggiunga il fascicolo.

Risoluzione dell'équipe di curaL'unico posto che decida chi possa aprire un fascicolo clinico.

Ruoli cliniciDecidono quale parte dell'applicazione una persona raggiunga. Mai che cosa possa aprire.

Un libro contabile non modificabileUna fattura emessa è fissata. Una correzione è una nota di credito.

Versioni di contratto datateLe condizioni non si possono retrodatare e lo storico resta.

cifrato a riposo · chiavi tenute a parte

4 · Archiviazione e chiavi Che cosa sopravvive a un disco rubato Crittografia

Directory del testo cifratoFuori dall'archivio file, fuori dal database, con permessi propri.

La chiave principaleSu disco, di proprietà dell'account di servizio, mai nello stesso backup dei dati.

Una seconda chiave per le note di terapiaLa chiave ordinaria non le apre, qualunque cosa dicano le regole.

Registro di audit concatenato per impronteIn sola aggiunta. La manomissione si rileva, non è soltanto scoraggiata.

09 — Prassi del settore sanitario

I controlli di cui un revisore clinico chiede espressamente

Firewall e cifratura sono attesi da qualunque sistema. I nove qui sotto sono quelli che saltano fuori in particolare in una revisione di salute mentale, e che un gestore di documenti generalista non sa esprimere affatto. Ciascuno è scritto con la domanda a cui risponde, perché di solito è così che arriva.

01Relazioni di cura

Un legame registrato fra un clinico e un paziente, con un tipo, un inizio e una fine. Quando la relazione finisce finisce anche l'accesso, dopo un periodo di grazia abbastanza lungo da finire gli appunti in sospeso.

Risponde a« Come fate valere il minimo necessario? »

02Deposito presso il direttore

Incidenti, reclami e segnalazioni di tutela vanno al direttore della clinica e sono chiusi a chi li ha depositati, e a chiunque il reclamo riguardi.

Risponde a« Un membro del personale può leggere il reclamo che lo riguarda? »

03Le richieste di diritti come flussi

Le richieste di accesso portano la propria scadenza di legge. Le richieste di modifica aggiungono una versione anziché sovrascrivere. Le richieste di limitazione sigillano i documenti che coprono.

Risponde a« Mostratemi una richiesta di accesso dall'inizio alla fine »

04Registro delle comunicazioni

Che cosa sia uscito dal servizio, verso chi, e su quale base giuridica. È la registrazione di cui una persona ha diritto di chiedere sei anni negli Stati Uniti.

Risponde a« Con chi avete condiviso i dati di questa persona? »

05Ancoraggi di conservazione

Ultimo contatto, data di nascita e data di decesso sono conservate come date da cui contare, perché una regola scritta in anni non significa nulla senza un punto di partenza.

Risponde a« Come sapete quando smaltire questo? »

06Sollecito per stato, mai per contenuto

Le relazioni di seduta in ritardo si trovano per scadenza e per stato. Un dirigente può vedere che una relazione manchi senza aprirne una che non manca.

Risponde a« I dirigenti leggono appunti clinici per far funzionare la clinica? »

07Verifiche di identità ed età

Prima una verifica facciale automatica, poi una coda di revisione umana se serve. I documenti d'identità sono cifrati mentre sono detenuti e cancellati in automatico una volta completata la verifica.

Risponde a« Che fine fa il documento d'identità dopo? »

08Firma elettronica clinica

Attestazione di capacità, firma per conto di un paziente, controfirma del supervisore, e un consenso che si può revocare in seguito anziché una casella spuntata una volta per tutte.

Risponde a« Come si raccoglie il consenso, e si può revocare? »

09La firma resta in casa

Il servizio di firma gira sui vostri server con una propria pista concatenata per impronte. Nessun documento viene inviato a un'azienda esterna per essere firmato, e non c'è una fattura del fornitore per ogni firma.

Risponde a« Quali terze parti vedono i nostri documenti firmati? »

10 — Se qualcosa va storto

Due scadenze da un solo momento, e un'esenzione che va meritata

La cifratura ha la forma che ha in gran parte per via di questa sezione. Sia il GDPR sia HIPAA ammettono che dati cifrati correttamente siano illeggibili, e quindi non siano davvero una divulgazione. Ma quell'esenzione tiene solo se potete dimostrare che non siano state prese anche le chiavi. Tutto il progetto della custodia delle chiavi esiste perché possiate dimostrarlo.

Ora zero Venirne a conoscenza

Entrambe le scadenze qui sotto decorrono dal momento in cui ne venite a conoscenza, non da quello in cui l'incidente è avvenuto. Questo fa dello stabilire e registrare quel momento la prima cosa da fare, anziché qualcosa ricostruito dopo.

Entro 72 ore · UE e Regno Unito Avvisare il regolatore

L'articolo 33 del GDPR vi dà 72 ore dalla conoscenza per notificare all'autorità di controllo — l'ICO nel Regno Unito, l'autorità nazionale competente nell'Unione europea. Questa scadenza vale che i dati fossero cifrati o no.

Senza ingiustificato ritardo · salvo che Avvisare le persone coinvolte

L'articolo 34 esige che avvisiate anche gli interessati, salvo che i dati fossero cifrati. L'articolo 34(3)(a) tratta i dati correttamente cifrati come illeggibili per chi li abbia presi. HIPAA ha la stessa idea, e la chiama porto sicuro.

La condizione di quell'esenzione Sono state prese anche le chiavi?

L'esenzione dipende interamente da questa sola domanda, quindi il sistema la pone espressamente e una domanda senza risposta conta contro l'esenzione. Chiudere una violazione come non notificabile richiede le prove, perché un'esenzione rivendicata senza prove è un'esenzione che crolla all'esame.

Come è costruito Una registrazione di violazione, condivisa, con sopra le regole di ciascun paese

La registrazione della violazione sta nel nucleo condiviso: quando ne siete venuti a conoscenza, che cosa fosse in gioco, chi fosse coinvolto, se i dati fossero cifrati e se le chiavi siano state prese. Ogni modulo di giurisdizione aggiunge poi i propri obblighi sopra quell'unica registrazione. Il modulo europeo aggiunge la scadenza di 72 ore dell'articolo 33 e la decisione dell'articolo 34. Il modulo statunitense aggiunge la valutazione del rischio a quattro fattori, la scadenza individuale di 60 giorni, la soglia per i media sopra i 500 residenti di uno stesso stato, e la segnalazione al Department of Health and Human Services. Un incidente, valutato una volta, rispetto alle regole che vi riguardano.

Per tutto il tempo Il registro degli accessi è l'indagine

Poiché ogni lettura è stata registrata prima che qualunque contenuto fosse consegnato, la domanda « che cosa sia stato davvero esposto, e a chi? » ha una risposta vera anziché una stima. È la differenza fra avvisare undici persone e avvisare tutti quelli che sono nel database.

11 — Controlli della piattaforma

Le domande ordinarie, con risposta in un solo posto

Nulla in questa tabella è insolito. Sta qui perché un revisore lo chiederà, e perché un fornitore che non sappia rispondere in fretta a queste di solito non sa rispondere nemmeno a quelle più difficili.

Area	Che cosa è in essere	Perché si fa così
Accesso	Password conservate solo come impronte a senso unico. Token firmati di breve durata che portano chi sia l'utente, quando il token sia stato emesso, quando scada e un identificativo unico	Un token rubato scade da sé, e l'hashing si può aggiornare senza chiedere a nessuno di reimpostare la password
Custodia dei segreti	Ogni credenziale di terze parti vive sul server. L'applicazione mobile porta solo chiavi pubbliche	L'applicazione si può decompilare senza perdere nulla. Ruotare una chiave ha effetto per tutti gli utenti insieme, senza una pubblicazione su uno store
Trasporto	HTTPS ovunque, compreso il WebSocket usato per chat, presenza e segnalazione delle chiamate	Una connessione, una politica, e nessun ripiego in chiaro
Limitazione di frequenza	Limiti al proxy, più contatori Redis sulle vie pubbliche e sulle letture di documenti dal portale	Contati da uno stato condiviso, così un limite per utente tiene su ogni processo del server anziché per processo
Media	Passati dalla passerella con collegamenti firmati che scadono. Nulla è servito da un percorso che si possa indovinare	L'archiviazione non è mai indirizzata direttamente da un dispositivo client
Database	Non raggiungibile da alcun client. La passerella si collega al nucleo tramite un account di servizio con i soli diritti che gli servono	Due salti distinti fra un telefono e una riga, ciascuno con la propria occasione di rifiutare
Moduli pubblici	reCAPTCHA sui moduli del sito, e numeri di telefono normalizzati alla digitazione	Lo spam e gli input malformati sono rifiutati prima di diventare registrazioni che qualcuno debba ripulire
Indovinare riferimenti	Un documento che non potete vedere restituisce « non trovato », mai « vietato »	Altrimenti la differenza fra le due risposte dice a un attaccante quali fascicoli esistano
Account dei pazienti	Gli utenti del portale non hanno alcun accesso al back office. L'autenticazione a due fattori è fornita con la piattaforma e si può rendere obbligatoria per tutto il personale, o per tutti, con una sola impostazione — e l'accesso ai documenti dal portale si può mettere dietro di essa	Il caso peggiore per un accesso paziente compromesso sono i dati di quel solo paziente, e con la barriera del portale attiva nemmeno quelli
Esposizione a terze parti	Pagamenti, intelligenza artificiale, messaggistica e archiviazione stanno ciascuno dietro un'interfaccia con una versione simulata dall'altra parte di un interruttore	I fornitori si possono sostituire. Dimostrazioni e collaudi girano senza alcun account fornitore attivo e senza alcun dato reale
Licenze e ospitalità	Odoo 19 Community e componenti a codice aperto dappertutto, in esecuzione sulla vostra infrastruttura	Il vostro reparto sicurezza può leggere il codice anziché credere sulla parola a un fornitore

12 — Che cosa potete dimostrare

La differenza fra un controllo e una promessa

In un audit, in una gara o in un reclamo, ciò che conta non è che cosa intendevate fare. È che cosa potete dimostrare. Qui sotto ci sono le sei domande che saltano fuori più spesso, e che cosa il sistema produca in risposta a ciascuna.

Chi ha letto questo fascicolo?Registro degli accessi

Un elenco completo, concatenato per impronte, che nessuno avrebbe potuto modificare — compresi i vostri amministratori

Questo fascicolo è stato alterato?Storico delle versioni

Le correzioni sono nuove versioni e la precedente è intatta, così un cambiamento è visibile anziché da dedurre

I dati scaduti sono stati distrutti?Distruzione della chiave

La chiave non c'è più, e il guscio vuoto del fascicolo prova che il file sia esistito e sia stato smaltito nei tempi

Con chi l'abbiamo condiviso?Registro delle comunicazioni

Che cosa sia uscito dal servizio, verso chi e su quale base giuridica — sei anni, su richiesta

Un amministratore avrebbe potuto vederlo?Modello di autorizzazione

Chiuso per impostazione predefinita, senza deroga principale. Un account amministratore non concede nulla, e l'accesso di emergenza è un evento registrato e riesaminato

Il libro contabile è affidabile?Controlli finanziari

Le fatture emesse non si possono modificare, le righe di pagamento portano la versione di contratto che le ha valorizzate, e nulla si fattura senza che una persona lo confermi

13 — Dove finisce il software

Che cosa nessuna piattaforma può fare per voi

Un software non rende conforme un'organizzazione. Rende la conformità raggiungibile, e rende possibile dimostrarla. Essere schietti su quel confine vale più in una revisione di un elenco più lungo di affermazioni, quindi ecco il confine per intero.

Non è consulenza legale, e nessun prodotto è certificato

Nulla in questa pagina è consulenza legale. Nessun prodotto software è certificato HIPAA o certificato GDPR, perché nessuna autorità rilascia quei certificati per i prodotti. Ciò che esiste è un insieme di controlli tecnici e organizzativi. Questa piattaforma realizza quelli tecnici e sostiene quelli organizzativi. Il resto appartiene alla vostra organizzazione, e un buon consulente vi dirà esattamente la stessa cosa.

Gli accordi spetta a voi firmarli. I business associate agreement negli Stati Uniti, gli accordi sul trattamento dei dati e le condizioni sui sub-responsabili nell'UE e nel Regno Unito. La piattaforma li modella. Non li stipula per voi.
I vostri legali confermano il testo. L'avviso di ritrasmissione del 42 CFR Part 2 è generato anziché digitato, proprio perché non possa divergere nel tempo. Ma la norma ne prescrive il contenuto, e serve una revisione legale prima della messa in esercizio.
Il diritto locale va oltre il minimo comune. Le leggi statali statunitensi — la CMIA della California, e regole a New York e in Texas fra le altre — vanno oltre HIPAA. Nell'UE, il diritto degli Stati membri si aggiunge al GDPR: il § 203 StGB e il § 630f BGB tedeschi ne sono esempi. I periodi di conservazione in particolare vanno confermati con un legale del vostro paese.
Il comportamento del personale non è un controllo software. La formazione, gli ingressi e le uscite, il procedimento disciplinare, e chi riceva una relazione di cura in primo luogo sono decisioni che il sistema registra ma non prende.
La sicurezza fisica e infrastrutturale è dell'esercente. Dove stiano i server, chi possa avvicinarvisi, come i backup siano cifrati e conservati fuori sede, come sia custodita la chiave principale, e la prova di ripristino che fate davvero anziché quella che sta nel piano.
Test di penetrazione e gestione delle vulnerabilità sono un programma, non una funzionalità. Il parco è a codice aperto e auto-ospitato così che il vostro reparto o i vostri collaudatori possano esaminarlo come si deve. È un invito, non un sostituto.
Le organizzazioni che lavorano con il NHS compilano il Data Security and Protection Toolkit. Quella valutazione riguarda la vostra organizzazione e la sua gente, ed è fuori dall'ambito di qualunque software.
Qualcuno deve sorvegliare il motore di conservazione. Conservazione e distruzione girano come processi pianificati. Un processo pianificato che smetta di girare in silenzio è un problema di conformità che emerge solo in un audit, ed è per questo che verificarlo sta nella routine mensile.

L'intera pagina in un paragrafo, per un revisore di fretta

I fascicoli clinici sono cifrati una versione alla volta, sotto chiavi tenute fuori dal database. Si aprono solo quando una regola esplicita lo consente, e quella regola segue la relazione di cura anziché l'anzianità. Ogni lettura è scritta in un registro che nessuno può modificare. Le correzioni si aggiungono come nuove versioni anziché sovrascrivere la vecchia. Quando la conservazione scade la chiave viene distrutta, il che rende il contenuto illeggibile lasciando la prova che sia esistito e sia stato smaltito. Sopra quello stesso nucleo, un modulo di giurisdizione aggiunge la macchina dei diritti e della governance per gli Stati Uniti, l'Unione europea o il Regno Unito. Sotto, il modello di accesso a quattro livelli di Odoo Community protegge i dati aziendali ordinari, e il server è chiuso dietro un unico proxy con TLS, un firewall e limiti di frequenza.

14 — Dove andare adesso

Il resto del quadro

Questa pagina è la posizione su sicurezza e conformità. La panoramica mostra come i pezzi si incastrino, il catalogo elenca i moduli in cui questi controlli vivono davvero, e lo schema dell'amministratore copre la routine che tiene vere tutte queste prove mese dopo mese.

La macchinaPanoramica del sistemaQuattro livelli, e dove i segreti e i fascicoli stiano davvero. RiferimentoCatalogo dei moduliI moduli dei documenti sicuri, delle cartelle cliniche e della firma elettronica per intero. SchemaAmministrazioneIl fascicolo di conformità, le verifiche di conservazione e il riesame trimestrale. SchemaPazienteChe cosa si dice a un paziente sui propri fascicoli, e che cosa può chiedere.