Security & compliance · Raznameh Clinics

Start here

Pick the country you operate in

Most of what follows is the same everywhere — the encryption, the access control, the audit log, the server hardening. What changes by country is the rights and governance machinery on top, and that has a page of its own. If you are running due diligence, start with your own country and come back to the shared material afterwards.

United States USA HIPAA · HITECH · 42 CFR Part 2 · state law The largest of the three. Every United States rule that reaches a mental-health practice, what has been built for each one, and — at the end — seven step-by-step walkthroughs of what actually happens inside the software.

Privacy Rule: every patient right, including the parts most systems leave out
Security Rule: all eight technical safeguards, plus the administrative and physical registers
Breach notification: four factors, 60 days, per-state thresholds, both supplier clocks
42 CFR Part 2 including the 2024 rule
Seven flows — a records request, a refused correction, a disclosure, a breach, a new patient, an idle screen, and the compliance year

European Union GDPR Regulation (EU) 2016/679 Lawful basis under Article 9(2)(h) rather than consent, erasure carried out by destroying the encryption key, portability as a logged export, and the two breach deadlines with the exemption you have to earn.

Why treatment records must not rest on consent
Erasure that honours the right without destroying the evidence
The 72-hour clock and the keys-compromised question
Processing register and impact assessment as live records

Deutschland Germany § 203 StGB · § 630f BGB · NIS2 · SGB V The European rules apply here unchanged — and then Germany adds a layer of its own, one piece of which is criminal law and decides whether a practice may lawfully buy from us at all.

§ 203 StGB: why the supplier choice is the therapist's legal risk
What a § 203 undertaking says, clause by clause
Ten years from the end of treatment, not from the file date
NIS2 for practice groups, and the programme already built
An honest account of the statutory rail we do not have

United Kingdom UK GDPR DPA 2018 · NHS Code of Practice 2021 What the United Kingdom adds on top of GDPR: the serious-harm test built as a workflow that expires by itself, the NHS retention schedule as shipped data, and a right over the records of people who have died.

Withholding that requires a named professional and lapses at six months
Twenty years after last contact for mental-health records
Access to Health Records Act 1990
Caldicott Principle 7 and why break-glass is a feature

Australia Privacy Act 13 APPs · NDB scheme · state retention law One federal law with no small-business exemption for a health provider, eight sets of state rules on retention, and — since June 2025 — a patient who can sue without waiting for a regulator.

All thirteen Australian Privacy Principles, one by one
APP 8: why nothing has to leave the country
Seven years from the last entry, and until 25 for a child
The breach flow, step by step, plus 72-hour ransomware reporting
Essential Eight, ISO 27001, RACGP C6.4 — and why SOCI does not apply

Canada PIPEDA & PHIPA 10 principles · provincial statutes · college retention No HIPAA, no single Act: a federal law, a health statute that changes with the province, and a professional college on top of both setting how long you keep a chart.

Which statute and which commissioner, province by province
PIPEDA's ten principles, and PHIPA custodian by custodian
The lockbox — the one Canadian concept we do not have yet
Two breach clocks, and the annual statistics report each March
The provincial billing rail we are not on, said in section 09

Shared by all six Secure documents The machinery every country page relies on How a clinical record is encrypted, who can open one, the whole life of a document from filing to disposal — and, at the end, seven risks that have no technical fix.

Envelope encryption, and why there are two keys not one
Access that follows the treatment relationship
Disposal by destroying a key rather than deleting a row
Seven risks stated plainly, with what stays yours

01 — Start with the law

What HIPAA, GDPR and UK GDPR actually ask of you

Most security documents start with the technology and leave the law until the end. This one does the opposite, because the law is what you are judged against. Below is each regime in plain language: what it is, who it applies to, and the duties it puts on a clinic. Under each one is the part of the platform that carries that duty out.

United States

HIPAA

HIPAA is the Health Insurance Portability and Accountability Act. It applies to health providers in the United States and to the companies that handle health data on their behalf. It is built from two main parts. The Privacy Rule says who may see health information and what a patient may ask for. The Security Rule says how electronic health information must be protected.

Minimum necessary. Staff may only see the information they need for the job in front of them. In the platform this is enforced by care relationships: a therapist reaches the clients on their own caseload, not the whole clinic.
The designated record set. A patient can ask for a copy of their record, but not for everything the clinic holds. Each document type is marked as inside or outside that set, and a request cannot return what is outside it.
Psychotherapy notes are separate. HIPAA treats a therapist's own process notes differently from the record. In the platform they are encrypted under a different key, so the key that opens the ordinary record does not open them.
Accounting of disclosures. A patient may ask who their information was shared with over the last six years. The disclosure register answers that from stored records.
Breach notification. If protected health information is exposed, people must be told — unless the data was properly encrypted. That exemption is called the safe harbour, and it is the reason the encryption is built the way it is.
42 CFR Part 2 is a separate US rule for substance-use treatment records. It is stricter than HIPAA and requires a redisclosure warning on anything shared. The platform generates that notice rather than asking staff to type it.

European Union

GDPR

GDPR is the General Data Protection Regulation. It applies to any organisation handling personal data about people in the European Union. Health data is what GDPR calls special category data, which means it is forbidden to process unless a specific condition applies. Where HIPAA is mostly about protection, GDPR is also about the individual's rights over their own data.

A lawful basis for every document type. For treatment records the correct condition is Article 9(2)(h), health care provision — not consent. Consent that a person cannot freely refuse is not valid consent, and in a care setting they usually cannot refuse. The platform records the basis against the document type, so it is never a guess later.
The right of access (Art. 15). A person may ask for a copy of their data, and there is a legal deadline for answering. The request runs as a tracked workflow with that clock on it.
The right to erasure (Art. 17). Often called the right to be forgotten. The platform honours it by destroying the encryption key rather than the database row, so the content is gone but the proof that a record existed and was disposed of remains.
The right to portability (Art. 20). A person may ask for their data in a form they can take elsewhere. The platform builds a zip file in memory and streams it, and logs every document inside it individually.
Breach notification (Art. 33 and 34). The regulator must be told within 72 hours of you becoming aware. The people affected must also be told, unless the data was encrypted.
Governance paperwork (Art. 30 and 35). You must keep a record of your processing activities, and carry out a data protection impact assessment for high-risk work. Both live in the system as live records, not as a Word file that goes stale.

United Kingdom

UK GDPR and the DPA 2018

After leaving the European Union the United Kingdom kept GDPR almost unchanged and calls it UK GDPR. The Data Protection Act 2018 sits alongside it and adds UK-specific rules, several of which matter a great deal in health. The regulator is the Information Commissioner's Office, the ICO.

Everything GDPR requires, still applies. Access, erasure, portability, breach notification and the governance records are the same duties as in the EU.
The serious-harm test. Health data may be withheld from a person's own access request where releasing it would be likely to cause them serious harm. For a mental-health service this is the equivalent of the US psychotherapy-notes carve-out, and the process around it is strict.
NHS retention periods. The NHS Records Management Code of Practice 2021 sets how long records are kept — for mental health, 20 years after last contact. That schedule ships as starting data.
Access to Health Records Act 1990. Relatives of a person who has died may in some cases request their records. GDPR does not cover the deceased at all, so this is a UK-only right with its own rules about who is entitled to ask.
Caldicott Principle 7. UK health guidance says the duty to share information can be as important as the duty to protect it. Blocking everything is its own kind of failure, which is why emergency access exists and is recorded rather than forbidden.

What all four agree on

Underneath the differences, the four regimes want the same five things. Protect the data so a stolen copy is useless. Let only the right people see it. Keep a record of who saw it. Keep it only as long as you need it, then dispose of it properly. Be able to prove all four afterwards. That shared list is what the platform builds into the storage layer once, for every deployment. The rights machinery on top is what changes by country, and that ships as a separate module you install for your jurisdiction.

Nobody is certified for these, and anyone who says otherwise is selling something

There is no such thing as a HIPAA-certified or GDPR-certified product. No authority issues that certificate. What exists is a list of technical and organisational controls. Software can implement the technical ones and make the organisational ones easy to run and easy to evidence. It cannot make an organisation compliant on its own. The last section of this page sets out exactly which parts stay with you.

02 — Side by side

The same technical core everywhere. Different rights machinery on top

Encryption, access control, the audit log and retention are identical in every country. They are built once, in the shared core, and every deployment gets them. What changes between the United States, the European Union, the United Kingdom, Australia and Canada is the rights and governance work sitting on top of that core. This is why a system built to a US standard does not automatically satisfy the EU, and why each country arrives as its own installable module.

The last two columns carry the most honest marks. The Australian Privacy Principles ask for less in two places than Europe does, and there is no Australian module yet — the rights machinery an Australian deployment uses today is the shared core plus parts of the European and United Kingdom modules. The Australia page names every seam.

Canada is the newest, and the only column where the rulebook changes inside the country. There is no Canadian module either, and one obligation has no equivalent anywhere else on this table — the lockbox, a patient instruction that fences off part of their own record inside the circle of care. The Canada page sets out what building it means, and which provincial statute applies where.

What is required	United States HIPAA · 42 CFR Part 2	European Union GDPR	United Kingdom UK GDPR · DPA 2018	Australia Privacy Act 1988 · APPs	Canada PIPEDA · PHIPA and provincial
Encryption, access control, audit log, retention	✓ shared core	✓ shared core	✓ shared core	✓ shared core	✓ shared core
A recorded legal reason for holding each document type	— not how HIPAA works	✓ Art. 9(2)(h) for treatment records, not consent	✓ the same, under UK GDPR	✓ APP 3.3 and s16B, recorded per document type	§ purpose and consent, not an enumerated legal basis
A person can ask for a copy of their record	✓ 45 CFR 164.524, limited to the designated record set	✓ Art. 15, with a legal deadline	✓ Art. 15, plus the serious-harm test	✓ APP 12, a reasonable period, and no fee for asking	✓ PIPEDA principle 9 and PHIPA s. 52 — 30 days, extendable
Some material can be held back from them	✓ psychotherapy notes sit outside the record set	§ narrow, and depends on the member state	✓ serious-harm test, run as a workflow that expires	◐ APP 12.3 grounds exist; the workflow ships with the UK list	◐ PHIPA grounds exist; the workflow ships with the UK list
A person can ask for their data to be deleted	§ HIPAA gives no general right; retention decides	✓ Art. 17, done by destroying the key	✓ the same, with UK exemptions	§ no general erasure right; APP 11.2 destruction does the work	§ no general right; retention and disposal do the work
A person can take their data elsewhere	§ through the access right; HIPAA has no separate one	✓ Art. 20, streamed zip, every file logged	✓ the same	§ no portability right; the access right carries it	✓ Québec’s Law 25 right lands on the GDPR export; no federal equivalent
A register of what was shared, and with whom	✓ six years, on request	✓ what left, to whom, on what basis	✓ the same	✓ APP 6, what left and on what basis	✓ what left, to whom, on what basis and why
Telling the regulator and the people affected after a breach	✓ four-factor assessment, 60-day notice, media and HHS thresholds	✓ Art. 33 and 34, 72 hours, two clocks, keys question recorded	✓ the same, reported to the ICO	✓ NDB scheme: 30 days to assess, then notify as soon as practicable	◐ the record is complete; the two filings and the March count are not produced
Written governance records kept up to date	✓ policy register, versioned, six years per version	✓ impact assessment (Art. 35) and processing register (Art. 30)	✓ the same	✓ APP 1: policy register, risk register, complaints as records	✓ policy register, risk register, complaints as records
A retention schedule supplied ready to use	⚙ varies by state, so you set the periods	⚙ varies by member state, so you set the periods	✓ NHS Records Management Code of Practice 2021	◐ the periods are known nationally, and nothing is seeded	⚙ set by your college, so there is no national schedule to seed
Records of people who have died	⚙ HIPAA protects them 50 years; rule not seeded	— GDPR does not apply to the deceased	✓ Access to Health Records Act 1990	§ the federal Act stops at death; NSW protects for 30 years after	⚙ the statutes continue after death; the period is your college’s
Extra protection for substance-use records	✓ 42 CFR Part 2, with the redisclosure notice	— no equivalent rule	— no equivalent rule	— no equivalent rule	— no equivalent rule

✓BuiltIn the jurisdiction module now, and demonstrable. ⚙Built — you set the valueThe mechanism is there and the number is yours, because the law leaves it to you or to your state. Not a shortfall. §That regime asks for lessNothing is missing. This country's law gives a narrower right, or reaches the same place by a different route. ◐Partly builtSomething is genuinely missing. The country page names exactly what. —Not in that regime at allThe law simply does not contain this right.

The two middle marks were one mark until recently, which read as one kind of shortfall when only ◐ is one. A retention period you set because your state sets it is not a missing feature, and neither is HIPAA declining to give a right that GDPR gives.

03 — What is protected

Three kinds of data, and only one of them is ordinary

Not everything in a clinic needs the same protection. If you treat every field as maximally sensitive, the system becomes slow and awkward and staff start keeping notes in a spreadsheet instead. That is the real breach risk in most clinics. If you treat nothing as sensitive, the system is simply unsafe. So the platform sorts data into three kinds and applies the heavy machinery only to the kind that needs it.

Kind of data	Examples	How it is stored	Who can reach it
Ordinary business data	Contact details, orders, invoices, bookings, chat messages	In the database, protected by Odoo's own access rules	Staff whose job needs it. The client themselves, through the portal
Clinical and professional records	Session reports, incident and safeguarding files, identity documents	As secure documents: encrypted one version at a time, stored outside the normal file area	Only that client's care team, by an explicit rule. No job title grants it
Financial records	Invoices, expert payouts, contract versions, accounting entries	In the accounting ledger, which cannot be edited once an entry is issued	Finance and management. A correction leaves a trail instead of overwriting

Why the line is drawn at the record, not the field

Encrypting every single field would make searching impossible. Staff would then keep their working notes somewhere outside the system, where nothing is logged and nothing is protected. So the platform draws the line at the kind of record rather than at the individual field. Sensitive material stays inside the system, where every read of it can be recorded.

04 — The record model

Five things that are true of every protected record

These five are properties of how the data is stored. They are not policies that staff are asked to follow. That difference is the whole argument of this page. A control that depends on people behaving correctly is a control you cannot demonstrate to a reviewer. A control built into the storage is one you can.

Property one

Every version is encrypted on its own

The platform uses envelope encryption with AES-256-GCM. That means every document version gets its own random key, and that key is then locked with a second key belonging to the whole deployment. That second key is never stored in the database.

Someone who steals a copy of the database alone has nothing readable
The encrypted files live outside Odoo's ordinary file storage and are never served through the normal file download route
Rotating the deployment key re-locks the small keys without rewriting a single encrypted file
The software refuses to start if that key is missing, readable by everyone, owned by the wrong account, or kept somewhere it would be copied together with the data it protects

Property two

Closed unless a rule opens it

Every read has to find a rule that allows it and no rule that forbids it. This is checked every time, not once at login. Being an administrator, a manager, or the person who wrote the document grants nothing on its own.

There is no master override and no super-user route into clinical content
Access follows the client's care team, not the organisation chart
When staff file a document, the dialog tells them in plain words who will be able to open it, before it is saved

Property three

Every read is written down

Openings are logged, not only edits. The log is append-only and hash-chained, which means each entry is mathematically tied to the one before it. Removing or altering an entry breaks the chain and becomes visible.

The entry is written before the content is handed over, not afterwards
Nobody can edit or delete it, including the people who administer the system
A complete list of who opened a record can be produced for a client, a regulator or your own lawyers
Portal reads are rate limited per user, counted from that same log, so the limit holds even across several server processes

Property four

Corrections add, they never overwrite

When something is corrected, a new version is filed. The earlier one stays exactly as it was, including its metadata. A record that can be quietly edited is worth nothing as evidence, and one day yours may need to be worth something.

A request to amend a record appends to it rather than replacing it
Each version carries its own key, so disposal can be done version by version
An alteration is therefore visible in the history rather than something you have to infer

Property five

Disposal destroys the key

When a retention period runs out, the platform destroys the encryption key instead of deleting the row. The content becomes permanently unreadable. The empty shell and the audit trail stay. This technique is called crypto-shredding.

Disposal can be proved rather than merely claimed
The evidence that a record once existed, and was disposed of on time, survives
Retention is counted from a real anchor date: last contact, date of birth or date of death

The deliberate gap

What it will not do, said openly

The platform cannot search inside encrypted documents. This is a direct consequence of the encryption, not a missing feature. Documents are found by who they are about, what type they are, and when they were filed.

It is stated here because a supplier who promises both strong encryption and full-text search of the same content is promising one of them falsely
It is a secure document service, not an electronic health record: no charting, no HL7 or FHIR messaging, no e-prescribing
The core knows nothing about healthcare law. Each country's rules arrive as a separate module on top

05 — Who can open a record

Access follows the care relationship, not the job title

This is the single most important idea on the page, and it is the one thing an ordinary document manager cannot express. A care relationship is a recorded link between one clinician and one client, with a type, a start date and an end date. A therapist reaches the records of the people on their own caseload. Not the clinic's caseload. Their own. When the relationship ends, so does the access, after a short grace period long enough to finish outstanding notes.

This is what turns "minimum necessary" from a policy in a handbook into something the software actually enforces, and something you can demonstrate in an audit.

What happens on every single read

Five steps, every time, for every document

Who is asking?A signed-in user, resolved to a specific person. Not a role and not a group.
Is there a rule that allows it?Because they are the subject, because they are on the care team, or because someone granted them named access. No rule, no access.
Is there a rule that forbids it?A refusal always wins over a permission. Psychotherapy notes, sealed documents and withheld records refuse on every route in.
Write the log entryAdded to the append-only log before any content is sent back.
Decrypt in memory and stream itNothing is written to disk on the way out and nothing is served from the ordinary file area.

What does not get you in

Listed explicitly, because buyers always ask

Being an administratorAn admin account opens no clinical content by itself. There is no back door for support or maintenance.
Having written it yourselfIncident and safeguarding files are closed even to the person who filed them, because they are filed to the clinic director.
Being seniorClinical roles decide which screens of the application someone reaches. They never decide what someone can open.
Being the clientA client sees a record about themselves only when a rule specifically grants it. That is a clinical and legal decision, taken on purpose and recorded with the reason and the name of whoever took it.
Guessing a document referenceA document you may not see returns "not found", never "forbidden". Otherwise guessing references becomes a way to discover who holds records.

Emergency access exists, and it is never quiet

Sometimes a clinician genuinely needs a record they have no relationship with — a crisis, an out-of-hours call, a colleague taken ill. If your organisation permits it, an emergency access route is available. Using it is recorded as an event and reviewed afterwards by the privacy officer.

That is the design in one sentence: access is available when someone truly needs it, and never silent. This is deliberate. A system that only ever blocks fails in its own way. UK guidance (Caldicott Principle 7) says the duty to share can be as important as the duty to protect, which is why emergency access is a designed feature of the core rather than a hole left in it.

06 — The business core

How Odoo Community decides who you are, and what you see

The clinical machinery described above sits on top of Odoo 19 Community, which is the open-source business core. Odoo brings its own access control model, and it is worth understanding, because it is what protects the ordinary business data — the bookings, invoices, contacts and messages that make up most of the system.

This section has six parts: the four layers of access control that decide what a signed-in person may reach; signing in — passwords, two-factor authentication, passkeys and the policies around them; what "role based" actually means here, because the phrase is used loosely everywhere; database isolation; the OWASP Top Ten with Odoo's answer to each; and what being open source is actually worth.

Everything below ships with Odoo 19 Community. None of it is a paid add-on, and all of it is readable source your own security team can examine.

Odoo's access model has four layers. Each answers a different question, and a request has to pass all four. They are checked inside the data layer itself, which is the important part: the same checks apply whether a record is reached through the web interface, through the mobile app's gateway, or through Odoo's remote API. There is no route that bypasses them.

Layer one

Groups — what part of the system you reach

A group is a role. Membership decides which menus, screens and buttons a person sees at all. Groups can imply other groups, so a supervisor automatically holds everything a clinician holds, without the permissions being written twice.

Roles in this deployment include treating clinician, supervisor, clinic director, records custodian, front desk and privacy officer
Front desk is demographics only: no clinical content and no document access of any kind
A group grants reach, never content. Holding the clinician role opens no client's file by itself — the care relationship does that

Layer two

Model access rights — what you may do to a kind of record

For every type of record and every group, Odoo stores four separate permissions: read, create, edit and delete. They are declared in plain text files that ship with each module, so they can be read and reviewed without running anything.

This deployment declares 660 access entries across 35 modules
Anything not listed is denied. Access is granted by naming it, never by forgetting to block it
Read without edit is common on purpose: many roles can see a record they must not change

Layer three

Record rules — which individual records you may touch

A record rule is a filter applied to every query. It is what makes "your own clients" and "your own company" real rather than a matter of which screen someone happens to open. Global rules always apply. Rules attached to a group widen access for that group only.

This deployment defines 117 record rules across the clinical, booking, contract, e-signature and reporting modules
Typical examples: a clinician sees care relationships where they are the clinician; a portal user sees only bookings belonging to their own contact record
The rule is applied by the data layer, so it holds for list views, reports, exports and the remote API equally

Layer four

Field rules and portal separation

Individual fields can be restricted to particular groups, so two people can open the same record and see different amounts of it. Separately, Odoo keeps portal users in a different class from staff entirely.

A portal user — a client or an external contact — has no access to the back office at all, only to the pages explicitly published for them
Public web pages run as an anonymous user with almost nothing granted, so a mistake on a public page cannot expose staff data
Every controller route in this deployment declares whether it requires a signed-in user or is deliberately public: 174 routes require a login, 57 are public by design

Framework protection	What Odoo does	What it prevents
Query building	All database queries are built by the framework from structured filters. Application code does not write raw SQL for ordinary reads and writes	SQL injection through search fields, filters and URL parameters
Template escaping	Odoo's template engine escapes values it renders into a page by default. Raw output has to be asked for explicitly	Cross-site scripting, where text saved by one user runs as code in another user's browser
Form tokens	Web forms that change data carry a token tied to the user's session, and the server rejects a submission without it	Cross-site request forgery, where another website silently submits a form as your logged-in user
Sessions	Session state is held on the server. The browser holds only an identifier, in a cookie marked so that page scripts cannot read it	Session theft through a script running in the page
Passwords	Stored only as a one-way hash, never in a form that can be reversed. The hashing scheme can be upgraded without asking everyone to reset	A stolen user table becoming a list of usable passwords
Database manager	The screens that create, copy, restore and delete whole databases are closed in production, and one hostname is bound to exactly one database	Anyone reaching the server from finding, copying or overwriting a database
Elevated operations	Code can bypass access rules only where a developer wrote it deliberately, for a defined operation, in a named place. Clinical content is not one of those places	Broad, accidental privilege escalation buried in application code
Open source	Odoo Community is published under an open licence and the addons in this platform are readable in full. Security fixes are published by Odoo and applied to your own installation	Having to take a supplier's security claims entirely on trust

Signing in: passwords, second factors and the policies around them

The four layers above decide what a signed-in person may reach. This is the part before that — how Odoo establishes that somebody is who they claim to be, and what it does when they are not. All of it ships with Odoo 19 Community; none of it is a paid add-on.

Control	Status	What it does, and what you decide
Passwords are hashed, never stored	✓	Stored as a PBKDF2-SHA512 hash with a per-password salt and a configurable work factor. A hash cannot be turned back into a password, so a stolen user table is not a list of logins. The work factor can be raised as hardware gets faster, and passwords are re-hashed to the stronger setting the next time each person signs in — nobody is asked to reset. Nobody can read a password back, including your own administrators and including us: the field always reads as empty, whoever asks. If somebody loses their password the only route is a reset, and that is the correct answer rather than a missing feature.
Two-factor authentication	⚙	Built and shipped in every install, using the standard authenticator-app codes (TOTP) that work with Google Authenticator, Authy, 1Password and the rest. A person can enrol a device themselves, and trusted devices can be remembered for a period. You set: whether it is optional or compulsory. One setting turns it on for everyone, another for all staff accounts — and anybody without an authenticator app gets a one-time code by email instead, so enforcing it does not strand people. In a US deployment this should be on: it is expected under the Security Rule and becomes effectively compulsory if the proposed update finalises.
Two-factor also closes the API door	✓	The detail that makes it worth having. Once a person has a second factor, their password stops working for machine-to-machine access altogether — an integration has to use a named API key instead. Without that rule, two-factor authentication protects the login screen and leaves the back door open, which is how it is defeated in practice.
Passkeys	⚙	Odoo 19 supports passkeys — sign-in with a fingerprint, a face or a hardware key instead of a password. Nothing phishable is typed, so it removes the whole class of attack where somebody is talked into entering their password on a convincing copy of your login page. You decide whether to offer it.
API keys instead of passwords for integrations	✓	Every integration gets its own named key with its own scope, listed against the person who created it, revocable one at a time. A key that leaks is turned off without changing anybody's password and without breaking the other integrations.
Password policy	⚙	A minimum length enforced at the point a password is set, with a strength meter shown as it is typed. You set the minimum. It is zero out of the box, which means deciding it is part of go-live rather than something to discover later. There is deliberately no setting for forced character classes — one capital, one digit, one symbol. That is not an omission. Research and current NIST guidance both found those rules counter-productive: they push people towards predictable substitutions and towards writing passwords down, and they buy less than length does. Length plus a second factor is the combination that works.
Brute-force protection	✓	On by default. After ten failed attempts, every further try is refused for sixty seconds counted from the most recent failure — so a guessing attack is throttled to one attempt a minute rather than thousands. Both numbers are settings a database administrator can change (or disable, by setting the first to zero). It works without anybody having to notice the attack is happening.
Re-authentication for sensitive actions	✓	Changing security settings, enrolling a second factor or creating an API key asks the person to prove who they are again, even mid-session. An unattended screen cannot be used to weaken the account it is signed into.
Changing a password ends every session	✓	Session validity is derived from the account itself, so changing a password or deactivating an account invalidates every existing session everywhere at once — every browser, every device, immediately. This is what makes "somebody has left, lock them out" a single action rather than a hopeful one.
Company sign-on, where you use it	⚙	Odoo can authenticate against your existing directory (LDAP or Active Directory) or an OAuth2 identity provider, so joiners and leavers are handled once in the place your organisation already handles them. Optional, and only worth doing if you already run one.
Portal documents behind a second factor	⚙	This one is ours rather than Odoo's, and it exists because a client's login is the weakest point in any clinical system. Turn it on and a portal user who has not enrolled a second factor can still sign in and see that documents exist — but cannot open one until they do. It affects people already using the portal, so tell them before switching it on.

✓On by defaultWorking from the moment the system is installed. ⚙Built — you switch it onPresent and supported. Whether to use it, and how strictly, is your decision.

What "role-based" actually means here

Nearly every system claims to be role based. The phrase is worth unpacking, because in most products it means the menu changes and in Odoo it means the data changes.

A role in Odoo is a group. Groups can contain other groups, so a supervisor automatically holds everything a clinician holds without anybody writing the permissions twice — and when a permission is corrected, it is corrected once for everybody who inherits it. What a group grants is not a screen. It is four separate permissions (read, create, edit, delete) on each kind of record, plus filters that decide which records of that kind, plus the ability to hide individual fields.

The important consequence: hiding a menu is not a permission. In a system where roles only change the menu, anybody who learns a web address reaches the data behind it. In Odoo the checks live in the data layer, so the same refusal happens whether the record is reached through a screen, a report, an export, a search, or the remote API. There is no route that skips them.

01Roles are named for the job

Treating clinician, supervisor, clinic director, records custodian, front desk, privacy officer, accountant, contract manager. Front desk is demographics only — no clinical content and no document access of any kind.

Answers"Show me what a receptionist can see"

02Roles grant reach, never content

Holding the clinician role opens no client's file by itself. The care relationship does that. This is the single most important sentence about access on this site.

Answers"Can a therapist read the whole clinic's records?"

03Four permissions, not one

Read, create, edit and delete are separate for every kind of record. Read without edit is common on purpose: plenty of roles must see something they must not change.

Answers"Who can change an invoice after it is issued?"

04Row filters decide which records

"Your own clients", "your own company", "bookings belonging to you". Applied to every query, so they hold for lists, reports, exports and the API equally.

Answers"What stops an export pulling everything?"

05Global rules cannot be widened

A rule attached to no group applies to everyone and is combined with every other rule, so it narrows access and can never be escaped by adding a role. Company separation is built this way.

Answers"Can one clinic see another clinic's data?"

06Individual fields can be hidden

Two people can open the same record and see different amounts of it. Used here for cost and margin figures, and for the fields only a records custodian should read.

Answers"Does everyone who sees a contract see its margin?"

07Clients are a different class of user

A portal user has no back-office access whatsoever — not a restricted view of it, none of it. They reach only the pages published for them. Public web pages run as an anonymous user with almost nothing granted.

Answers"What is the worst case if a client login is stolen?"

08Every route declares its own access

Each web address in this deployment states whether it requires a signed-in user or is deliberately public: 174 require a login, 57 are public by design. Nothing is public by accident.

Answers"Which of your URLs work without logging in?"

09It is all readable configuration

Permissions ship as plain text files inside each module. Your own security team can read who gets what without running the system, and diff it between releases.

Answers"Can we audit the permissions ourselves?"

One database per clinic, and no way across

Your data lives in a database of its own. It is not a shared table with a customer column in it, which is the arrangement where one wrong query returns somebody else's records.

Odoo enforces that separation at the connection: a request carries a hostname, the hostname selects exactly one database, and there is no path from inside one database to another running on the same server. Nothing in the application can address a database it was not connected to. On top of that, the screens that create, copy, restore and delete whole databases are closed in production, so nobody browsing the server can enumerate what is there.

Inside your own database, a second layer does the same job between companies: if you run more than one clinic on one installation, company separation is written as global rules — the kind that apply to everybody and can never be widened by adding a role.

The OWASP Top Ten, and where Odoo stands on each

The Open Web Application Security Project publishes the list of the most common ways web applications get broken into. It is the list a security reviewer works through, so here it is with Odoo's answer to each one. The pattern worth noticing is that most of these are prevented by the framework's design rather than by developers remembering to be careful — which is the only kind of prevention that survives contact with a deadline.

The attack	Status	Why it does not work here
Injection, especially SQL injectionhostile input treated as a command	✓	Application code does not write database queries by hand. They are built by the framework from structured filters, with every value passed separately from the query itself, so text somebody typed can never become part of the command. A developer would have to go out of their way to write a raw query, and the clinical modules do not.
Cross-site scriptingtext saved by one person runs as code for another	✓	Everything rendered into a page is escaped by default. Putting raw content into a page has to be asked for explicitly and is visible in the code when it is. The default is safe, so forgetting produces something ugly rather than something dangerous.
Cross-site request forgeryanother site submits a form as your logged-in user	✓	Any form that changes data must carry a token tied to that person's session, and the server refuses a submission without it. The token exists only because the person genuinely loaded your page, and an attacker's site cannot obtain it.
Malicious file executiongetting the server to run code you supplied	✓	There is no feature that includes a remote file. Where privileged users can write small expressions to customise behaviour, those run in a sandbox that blocks access to the filesystem, to the network, and to anything whose name begins with a double underscore — a deliberately short list of permitted operations rather than a list of forbidden ones.
Insecure direct object referencechanging a number in a URL to reach someone else's record	✓	This is the one that catches most systems, and Odoo's answer is structural: access control is not implemented in the screens. Changing a record number in a web address reaches the same data-layer check as everything else and is refused there. There is no risk in a reference being visible, because the reference is not what grants access.
Failure to restrict URL accessreaching a page by knowing its address	✓	The same answer, and worth stating twice because it is the difference between real access control and a tidy menu. Security here does not rely on a link being hidden. Where a page genuinely must work without a login — a client confirming an appointment from an email — the address carries a signed token unique to that record and that person.
Insecure cryptographic storagecredentials protected weakly or not at all	✓	Passwords are hashed with PBKDF2-SHA512 and key stretching, as described above, and can be avoided locally altogether by authenticating against your own directory or identity provider. Clinical documents go further again: encrypted per version under keys held outside the database.
Insecure communicationstraffic sent in the clear	✓	Encrypted connections throughout, with unencrypted requests redirected rather than served, and browser headers that refuse a downgrade. Because this platform is self-hosted, this one is a deployment control rather than a property of the software — it is set up as part of a standard installation and described in section 07.
Reaching internals over the APIcalling something never meant to be called	✓	Not on the OWASP list but worth adding, because it is the one people assume is a gap. The remote API refuses to call any internal method — anything whose name begins with an underscore, plus a named list of dangerous ones. Only methods deliberately published can be reached from outside, which sharply limits what a mistake in application code can expose.

Open source, and what that is actually worth

"Open source" is often said as though it were a security feature by itself. It is not. What it gives you is specific and worth naming precisely.

You can check rather than believe

Every line of Odoo Community and every line of the clinical modules can be read by your own security team or by testers you hire. Permissions ship as plain text files. Nothing on this page has to be taken on trust, which is a different position from a closed product where the same claims can only be asserted.

That is an invitation to audit, not a substitute for auditing.

Many more people look at it

Odoo is examined continuously by users, contributors and independent security researchers worldwide, and community bug reports are a real source of security feedback. Odoo runs a responsible disclosure programme and publishes fixes as advisories.

Its own development process includes code review with security as one of the things reviewed, for new and contributed code alike.

You control when patches land

Self-hosting means security fixes are applied to your installation on your schedule rather than appearing overnight. That is an advantage for a clinical service that must validate changes — and it is also a duty, because a fix nobody applies protects nobody.

Keeping current is on the operator's list in section 07, and it is the single most common way an otherwise well-built installation ends up compromised.

One distinction worth being careful about

Odoo publishes a security page of its own, and parts of it describe Odoo's cloud service — their hardened server images, their patching, the small number of their engineers who can reach a machine and only over an encrypted key from an encrypted laptop. Those are real, and they are not yours, because this platform is self-hosted on your own infrastructure.

Everything on this page above the line is a property of the software and applies to you exactly as written. The server-side equivalents — hardened operating system, patching, who holds SSH access, full-disk encryption on the machines that administer it — are yours to run, and they are set out honestly in section 07, including the parts that belong to whoever operates the servers. Reading Odoo's cloud page and assuming it describes your deployment is the commonest mistake made about self-hosted Odoo, and it is the kind of thing that unravels in a due-diligence review.

Where Odoo's model stops and the clinical one starts

Odoo's four layers are strong, well-tested and enough for ordinary business data. They are not enough on their own for a clinical record, for one reason: they are configuration, and configuration can be changed by someone with the right role. That is why clinical documents are additionally encrypted under keys held outside the database, and why psychotherapy notes use a different key again. If every Odoo rule in the system were wrong tomorrow, the encrypted content would still not open.

07 — The server

How the machine itself is hardened

Application security only counts if the server underneath it is closed properly. The platform is self-hosted, which means it runs on infrastructure you control rather than on a supplier's cloud. That is a real advantage for a health service, and it comes with a real duty: the hardening below is part of the installation, and it has to be kept true afterwards.

Everything in the first table is set up as part of a standard deployment and is documented in the installation guides. The second table is the part that belongs to whoever runs the servers.

Area	How it is configured	Why it is done that way
Nothing is exposed directly	The application services listen only on the machine itself. All outside traffic arrives through an nginx reverse proxy, which is the only thing on a public port	One front door instead of several. Certificates, headers, limits and logging are all applied in one place
Encryption in transit	TLS certificates from Let's Encrypt, issued and renewed automatically. Plain HTTP is redirected to HTTPS rather than served	There is no unencrypted path in, even by mistake, and renewal is not something a person has to remember
Browser security headers	Strict-Transport-Security for one year, X-Frame-Options set to same-origin, X-Content-Type-Options set to nosniff	The browser refuses to downgrade to HTTP, refuses to let the site be framed by another site, and refuses to guess file types
Firewall	Only ports 80 and 443 are open to the world. Application ports, the database and Redis are not reachable from outside the machine	The database is never addressable from the internet. A phone is at least two hops away from any row
Rate limiting	Limits at the proxy on incoming requests, plus token buckets held in Redis inside the gateway for public routes and portal document reads	The proxy stops floods. The Redis counters hold across several server processes, so a per-user limit means what it says
One hostname, one database	Odoo is configured so the hostname in the request selects exactly one database, and the database management screens are closed	Nobody browsing the server can list, copy, restore or delete a database
Services, not shells	The gateway and Odoo run as managed system services under their own accounts, started automatically and restarted on failure	Nothing runs as an administrator account, and a restart does not depend on someone being logged in
Secrets on the server only	Signing keys and third-party credentials live in an environment file readable only by the service account. The mobile app ships with none of them	The app can be taken apart and nothing is learned. A rotated credential takes effect for everyone at once, with no app release
Encrypted documents live apart	Ciphertext is written to its own directory with its own permissions, outside Odoo's ordinary file storage, and is never served by the ordinary download route	A misconfigured web server cannot accidentally publish clinical files
The master key is checked at startup	The encryption module reads the key from a path of its own and refuses to start if the file is missing, readable by everyone, owned by the wrong account, or sitting inside a directory that gets backed up with the data	The most common real-world key failure is the key ending up in the same backup as the data it protects. The software checks for that instead of trusting a procedure
WebSocket on the same channel	Chat, presence and call signalling are upgraded through the same proxy and the same certificate as everything else	One connection, one policy, no second listener to secure separately
Request tracing	Every request carries an identifier through the gateway and back out in the response headers, along with how long it took	An incident can be reconstructed across services instead of guessed at from separate log files

The hardening that belongs to whoever runs the servers

These are not gaps in the software. They are decisions and routines that only the operator can make, and no supplier can make them for you. They are listed plainly so that nobody assumes they are covered.

Operating system patching. A schedule for security updates on the host, and someone whose job it is to confirm they were applied.
Disk encryption on the host. Documents are encrypted individually by the platform, but full-disk encryption protects everything else on the machine, including logs and temporary files.
Backups, and their encryption. Where backups go, how they are encrypted, who can restore them, and how long they are kept. A backup is a full copy of your data with none of your access rules attached to it.
The master key is backed up separately. If the key is lost, every encrypted document is lost permanently — that is the point of the design. It must be backed up, and it must not be backed up alongside the data.
Administrative access to the server. SSH keys rather than passwords, no direct root login, a list of who holds access, and removing it on the day someone leaves.
Restore testing. A backup nobody has ever restored is a hope, not a control. Test it on a schedule and write down that you did.
Monitoring and alerting. Someone must be told when a service stops, a disk fills, a certificate is about to expire, or a scheduled retention job stops running.
Multi-factor authentication for staff accounts. Strongly recommended for anyone reaching clinical content, and effectively required if the proposed update to the HIPAA Security Rule is finalised. Confirm with your administrator whether it is switched on in your deployment.
Network placement. Whether the database sits on the same machine or a separate one, what can reach it, and whether administration happens over a private network or a VPN.
Penetration testing. The estate is open source and self-hosted precisely so your own testers can examine it properly. That is an invitation, not a substitute for doing it.

08 — Defence in depth

Four layers, and each one refuses something the next never sees

Defence in depth means not relying on any single protection. A request has to get past all four layers below. The value is not that any one of them is impossible to break. It is that they fail in different ways, so a mistake in one is very unlikely to be a mistake in all four.

1 · Device and surface What a person holds in their hand Untrusted

No secrets on the deviceThe app carries public keys only. It can be taken apart and nothing is learned.

Biometric sign-in and app lockOn top of the phone's own lock screen, not instead of it.

Tokens in secure storageHeld in the platform keychain, not in ordinary app files.

The database is unreachableThe app cannot address the database at all, on any network.

HTTPS · short-lived token

2 · Gateway The only backend the app knows about Holds the secrets

Every third-party key lives herePayment, AI, messaging and storage credentials never leave the server.

Short-lived signed tokensEach carries who it is for, when it was issued, when it expires and a unique id. Refreshed rather than long-lived.

Password hashingOne-way, with the scheme upgradable without a reset.

Rate limitingCounters held in Redis, shared across every server process.

Input validationMalformed requests are refused here, before the business core ever sees them.

Signed, expiring linksMedia is proxied. Nothing is served from an address you could guess.

service account · least privilege

3 · Business core Where the rules actually live Authoritative

Groups, access rights and record rulesOdoo's four layers, applied however the record is reached.

Care-team resolutionThe single place that decides who may open a clinical record.

Clinical rolesDecide which part of the application someone reaches. Never what they can open.

Ledger that cannot be editedAn issued invoice is fixed. A correction is a credit note.

Dated contract versionsTerms cannot be backdated and the history stays.

encrypted at rest · keys held apart

4 · Storage and keys What survives a stolen disk Cryptography

Ciphertext directoryOutside the file store, outside the database, with permissions of its own.

The master keyOn disk, owned by the service account, never in the same backup as the data.

A second key for therapy notesThe ordinary key does not open them, whatever the rules say.

Hash-chained audit logAppend-only. Tampering is detectable, not merely discouraged.

09 — Health-industry practice

The controls a clinical reviewer asks about specifically

Firewalls and encryption are expected of any system. The nine below are the ones that come up in a mental-health review in particular, and that a general-purpose document manager cannot express at all. Each is written with the question it answers, because that is usually how it arrives.

01Care relationships

A recorded link between one clinician and one client, with a type, a start and an end. When the relationship ends the access ends too, after a grace period long enough to finish outstanding notes.

Answers"How do you enforce minimum necessary?"

02Filing to the director

Incidents, complaints and safeguarding referrals go to the clinic director and are closed to the person who filed them, and to anyone the complaint is about.

Answers"Can a staff member read the complaint about themselves?"

03Rights requests as workflows

Access requests carry their legal deadline. Amendment requests add a version rather than overwriting. Restriction requests seal the documents they cover.

Answers"Show me a subject access request from start to finish"

04Disclosure register

What left the service, to whom, and on what legal basis. This is the record a person is entitled to ask six years of in the United States.

Answers"Who have you shared this person's data with?"

05Retention anchors

Last contact, date of birth and date of death are stored as dates to count from, because a rule written in years is meaningless without a starting point.

Answers"How do you know when to dispose of this?"

06Chasing by status, never by content

Overdue session reports are found by their deadline and their state. A manager can see that a report is missing without opening one that is not.

Answers"Do managers read clinical notes to run the clinic?"

07Identity and age checks

An automatic face check first, then a human review queue if needed. The identity documents are encrypted while held and deleted automatically once the check is complete.

Answers"What happens to the ID document afterwards?"

08Clinical e-signature

Capacity attestation, signing on behalf of a client, supervisor co-signature, and consent that can be withdrawn later rather than being a one-off tick box.

Answers"How is consent captured, and can it be withdrawn?"

09Signing stays in-house

The signature service runs on your own servers with its own hash-chained trail. No document is sent to an outside company to be signed, and there is no per-signature vendor bill.

Answers"Which third parties see our signed documents?"

10 — If something goes wrong

Two deadlines from one moment, and an exemption you have to earn

The encryption is shaped the way it is largely because of this section. Both GDPR and HIPAA accept that properly encrypted data is unreadable, and therefore not really a disclosure. But that exemption only holds if you can show the keys were not taken as well. The whole key custody design exists so that you can show it.

Hour zero Becoming aware

Both deadlines below start from the moment you become aware, not from the moment the incident happened. That makes establishing and recording that moment the first thing you do, rather than something reconstructed later.

Within 72 hours · EU and UK Tell the regulator

GDPR Article 33 gives you 72 hours from becoming aware to notify the supervisory authority — the ICO in the United Kingdom, the relevant national authority in the European Union. This deadline applies whether or not the data was encrypted.

Without undue delay · unless Tell the people affected

Article 34 requires you to tell the individuals as well, unless the data was encrypted. Article 34(3)(a) treats properly encrypted data as unreadable to whoever took it. HIPAA has the same idea, and calls it the safe harbour.

The condition on that exemption Were the keys taken too?

The exemption depends entirely on this one question, so the system asks it explicitly and an unanswered question counts against the exemption. Closing a breach as non-notifiable requires the evidence, because an exemption claimed without evidence is one that collapses when examined.

How this is built One breach record, shared, with each country's rules on top

The breach record itself is in the shared core: when you became aware, what was involved, who was affected, whether the data was encrypted and whether the keys were taken. Each jurisdiction module then adds its own duties on top of that one record. The European module adds the 72-hour Article 33 deadline and the Article 34 decision. The United States module adds the four-factor risk assessment, the 60-day individual deadline, the media threshold above 500 residents of one state, and reporting to the Department of Health and Human Services. One incident, assessed once, against whichever rules apply to you.

Throughout The access log is the investigation

Because every read was logged before any content was handed over, the question "what was actually exposed, and to whom?" has a real answer rather than an estimate. That is the difference between notifying eleven people and notifying everyone in the database.

11 — Platform controls

The ordinary questions, answered in one place

Nothing in this table is unusual. It is here because a reviewer will ask, and because a supplier who cannot answer these quickly usually cannot answer the harder ones either.

Area	What is in place	Why it is done that way
Sign-in	Passwords stored only as one-way hashes. Short-lived signed tokens carrying who the user is, when the token was issued, when it expires and a unique id	A stolen token expires by itself, and the hashing can be upgraded without asking anyone to reset their password
Secret custody	Every third-party credential lives on the server. The mobile app carries public keys only	The app can be decompiled and nothing is lost. Rotating a key takes effect for all users at once, with no app store release
Transport	HTTPS everywhere, including the WebSocket used for chat, presence and call signalling	One connection, one policy, and no fallback to plain text
Rate limiting	Limits at the proxy, plus Redis counters on public routes and on portal document reads	Counted from shared state, so a per-user limit holds across every server process rather than per process
Media	Proxied through the gateway with signed links that expire. Nothing is served from a guessable path	Storage is never addressed directly by a client device
Database	Not reachable from any client. The gateway connects to the core through a service account with only the rights it needs	Two separate hops between a phone and a row, each with its own chance to refuse
Public forms	reCAPTCHA on website forms, and phone numbers normalised as they are entered	Spam and malformed input are refused before they become records anybody has to clean up
Guessing references	A document you may not see returns "not found", never "forbidden"	Otherwise the difference between the two answers tells an attacker which records exist
Client accounts	Portal users have no back-office access whatsoever. Two-factor authentication ships with the platform and can be made compulsory for all staff, or for everyone, with one setting — and portal document access can be gated behind it	The worst case for a compromised client login is that one client's own data, and with the portal gate switched on, not even that
Third-party exposure	Payments, artificial intelligence, messaging and storage each sit behind an interface with a mock version on the other side of a switch	Suppliers can be swapped. Demonstrations and testing run with no live vendor account and no live data at all
Licensing and hosting	Odoo 19 Community and open-source components throughout, running on your own infrastructure	Your own security team can read the code rather than taking a supplier's word for it

12 — What you can prove

The difference between a control and a promise

In an audit, a tender or a complaint, what matters is not what you intended. It is what you can demonstrate. Below are the six questions that come up most often, and what the system produces in answer to each.

Who read this record?Access log

A complete, hash-chained list that nobody could have edited — including your own administrators

Was this record altered?Version history

Corrections are new versions and the earlier one is intact, so a change is visible rather than something you infer

Was expired data destroyed?Key destruction

The key is gone, and the empty record shell proves the file existed and was disposed of on schedule

Who did we share it with?Disclosure register

What left the service, to whom and on what legal basis — six years of it, on request

Could an administrator have seen it?Authorisation model

Closed by default with no master override. An admin account grants nothing, and emergency access is a logged, reviewed event

Is the ledger trustworthy?Financial controls

Issued invoices cannot be edited, pay lines carry the contract version that priced them, and nothing is billed without a person confirming it

13 — Where the software stops

What no platform can do for you

Software does not make an organisation compliant. It makes compliance achievable, and it makes it possible to prove. Being straight about that boundary is worth more in a review than a longer list of claims, so here is the boundary in full.

This is not legal advice, and no product is certified

Nothing on this page is legal advice. No software product is HIPAA certified or GDPR certified, because no authority issues those certificates for products. What exists is a set of technical and organisational controls. This platform implements the technical ones and supports the organisational ones. The rest belongs to your organisation, and a good adviser will tell you exactly the same thing.

The agreements are yours to sign. Business associate agreements in the United States, data processing agreements and sub-processor terms in the EU and the UK. The platform models them. It does not execute them for you.
Your lawyers confirm the wording. The 42 CFR Part 2 redisclosure notice is generated rather than typed, precisely so that it cannot drift over time. But the regulation prescribes its content, and it needs legal review before you go live.
Local law goes further than the baseline. US state laws — California's CMIA, and rules in New York and Texas among others — go beyond HIPAA. In the EU, member-state law adds to GDPR: Germany's §203 StGB and §630f BGB are examples. Retention periods in particular must be confirmed with counsel for your own country.
Staff behaviour is not a software control. Training, joiners and leavers, disciplinary process, and who is given a care relationship in the first place are decisions the system records but does not make.
Physical and infrastructure security is the operator's. Where the servers are, who can walk up to them, how backups are encrypted and stored off site, how the master key is held, and the disaster recovery test you actually run rather than the one in the plan.
Penetration testing and vulnerability management are a programme, not a feature. The estate is open source and self-hosted so that your own team or your own testers can examine it properly. That is an invitation, not a replacement.
NHS-facing organisations complete the Data Security and Protection Toolkit. That assessment is about your organisation and its people, and is outside the scope of any software.
Somebody has to watch the retention engine. Retention and disposal run as scheduled jobs. A scheduled job that quietly stops running is a compliance problem that only surfaces in an audit, which is why checking it is on the monthly routine.

The whole page in one paragraph, for a reviewer in a hurry

Clinical records are encrypted one version at a time, under keys kept outside the database. They open only when an explicit rule allows it, and that rule follows the care relationship rather than seniority. Every read is written to a log that nobody can edit. Corrections are added as new versions rather than overwriting the old one. When retention expires the key is destroyed, which makes the content unreadable while leaving proof that it existed and was disposed of. On top of that same core, a jurisdiction module adds the rights and governance machinery for the United States, the European Union or the United Kingdom. Underneath it, Odoo Community's four-layer access model protects the ordinary business data, and the server is closed behind a single proxy with TLS, a firewall and rate limits.

14 — Where to go next

The rest of the picture

This page is the security and compliance position. The overview shows how the pieces fit together, the catalogue lists the modules these controls actually live in, and the administrator blueprint covers the routine that keeps all of this evidence true month after month.

The machineSystem overviewFour layers, and where the secrets and the records actually sit. ReferenceModule catalogueThe secure-document, clinical-records and e-signature modules in full. BlueprintAdministratorThe compliance file, the retention checks and the quarterly review. BlueprintClientWhat a client is told about their own records, and what they can ask for.