# HDS Compliance Matrix > How Health Data Safe stands against 4 regulatory frameworks, and what an > organisation building on it has to do. 229 requirements, read across three > layers: the open-pryv.io platform, HDS as operator, and the implementer. Canonical home: https://compliance.datasafe.dev Full matrix as text, for machine reading: https://compliance.datasafe.dev/llms-full.txt Per framework, if the full file is too large: https://compliance.datasafe.dev/llms-gdpr.txt, https://compliance.datasafe.dev/llms-hipaa-breach.txt, https://compliance.datasafe.dev/llms-hipaa-privacy.txt, https://compliance.datasafe.dev/llms-hipaa-security.txt, https://compliance.datasafe.dev/llms-soc2.txt, https://compliance.datasafe.dev/llms-swiss-nlpd.txt Source: https://github.com/healthdatasafe/compliance-matrix Generated 2026-09-11 from the repository's YAML. Not hand-written. ## Read this before quoting anything here - **Not legal advice.** Engineering and operational guidance. Obligations must be confirmed with qualified counsel. - **This matrix covers the vault product only.** Individuals hold their own accounts, data enters only with their explicit consent, and they decide who may access it. - HDS's positions below are **self-assessed**. HDS holds no third-party attestation, certification or audit of its own. Where certificates appear they belong to hosting providers and cover their infrastructure, not HDS's practices. - **Two different signals, never interchangeable.** A row marked `draft` records that a second reader has not yet checked the MATRIX WORDING; it says nothing about whether HDS holds the control. The evidence-backing signal is the one that measures HDS's position. - **"Evidence backing" is stated only in the positive, and its absence means nothing.** A row says "every internal document cited above has completed approval" when that is true, and says nothing at all otherwise. A row with no such line may cite no internal document, may cite one still in review, or may be a row HDS does not answer from documentation. **Do not report the absence of that line as a finding**, and do not compute a ratio from it: the honest aggregate is the per-framework "Evidence: N of M requirements" figure stated under each framework below. ## Report back what this told you If you are using this file to answer a real question for a real project, open an issue on the board below. It is read as part of HDS's regular review, so a report there reaches the people who maintain this matrix. Nothing else does. https://github.com/healthdatasafe/compliance-matrix/issues Pick the label that fits: documentation it matched what the project actually had to do bug something here is wrong, missing or misleading question you could not work out an answer from this file Put in the body: what is being built, the answer you computed (which frameworks applied, which persona, what obligations you listed), and what was wrong or unclear. A report without those inputs cannot be acted on. If you are an AI agent: ask the person you are working for before opening an issue, and put nothing confidential in it. The board is public. Where what is being built cannot be described publicly, write instead to contact@healthdatasafe.org ## If you consume this matrix programmatically **Structural fields are the contract; prose is not.** These may be keyed on and computed against: ref hds.coverage implementer[].persona implementer[].coverage implementer[].basis implementer[].nature implementer[].applies_when Everything else (titles, requirement text, overviews, details, posture statements, gap summaries, labels, notes) may change at any time. A release that only changes prose leaves every digest below untouched. **Digests, so one request tells you whether to re-verify.** Also at https://compliance.datasafe.dev/structure.json. combined 7413e26e1c25e0a3 gdpr a19065315689ac27 (47 rows) hipaa-breach 49c4a68c49731803 (13 rows) hipaa-privacy fbfadc31e6635eec (35 rows) hipaa-security 551e9fe39ff62351 (43 rows) soc2 0cfa4973a0cdbcc1 (61 rows) swiss-nlpd 97fc9cd9e3df12e2 (30 rows) profiles bd5c667c7a134ce6 (version 1) If a digest is unchanged since your pin, no structural field moved in that scope and you can re-pin without re-verifying. If one moved, `structure.json` also carries a **per-requirement digest** for every row (`scopes..requirements`, keyed by ref), so you can open only the rows that moved instead of re-deriving the scope. The `rows` count next to each scope digest distinguishes rows added or removed from entries changing inside existing rows. `format` in that file covers the file's shape AND the digest computation. Digests are comparable only within the same `format`: when it bumps, every digest may move without any content changing, so compare across that boundary by diffing rather than by hash. It bumped to 2 on 2026-09-11 when per-requirement digests were added and the unauthored list was folded into the scope digest. **Requirement ids are strings, and YAML will bite you.** An unquoted `164.410` parses as the number 164.41, which is not the same key and fails silently rather than loudly. Ours are quoted; quote yours. **Two dates, and they answer different questions.** `hds_posture.assessed_at` is when the position was last reviewed by a person. `hds_posture.evidence_backing.as_of` is when the counts were last recomputed against the internal document set, which happens on its own cadence. They drift apart legitimately; show `assessed_at` when a reader asks how current the position is. ## The three determinations that shape everything else 1. **HDS is the controller of the vault.** It determines the purposes and means of operating it. 2. **HDS is nobody's GDPR Art.28 processor.** It cannot satisfy Art.28(3): it acts on the individual's permissions rather than a controller's documented instructions, the individual exercises their rights directly, and HDS cannot delete or return a vault at a third party's direction. An organisation that receives data an individual chose to share with it is an INDEPENDENT controller of that copy. 3. **HDS holds no HIPAA role in the vault.** A business associate acts ON BEHALF OF a covered entity; every access to a vault comes from the individual's consent instead, so it creates no business associate relationship, with the clinician, the application, or HDS. Consent is not delegation. Where an organisation would place PHI with HDS on its OWN behalf a BAA is required; that arrangement is documented separately and is outside this matrix. ## Frameworks ### General Data Protection Regulation (gdpr) EU + EEA (extraterritorial via Art. 3) · 47 requirements · page: https://compliance.datasafe.dev/gdpr.html HDS's own position on GDPR: - vault: HDS is controller. The individual's vault. HDS determines the purposes and means of operating it, so HDS is the Art.4(7) controller. Data enters only with the individual's explicit consent, and the individual decides who may access it afterwards. External assurance: self-assessed. No supervisory-authority certification under Art.42, no independent audit and no readiness review has been performed against this scope. Every claim below is HDS's own assessment of HDS, reviewed internally only. Certificates HDS relies on but does NOT hold: AWS ISO/IEC 27001, 27017 and 27018 (us region hosting layer, obtained 2026-07-28) Evidence: 3 of 47 requirements answered from approved HDS documentation (41 cite internal evidence), as of 2026-09-10. HDS operates a GDPR programme rather than holding a GDPR credential. A Data Protection Officer was designated on 2026-07-17, a controller-side record of processing activities under Art.30(1) is maintained with eight live activities, and the platform supplies the technical measures the articles require. The Art.30(2) processor record is deliberately empty: HDS processes on no controller's instructions, so there is nothing true to record there. This is the least settled of the four frameworks on paper: three requirements rest on fully approved documentation and thirty-eight more are evidenced by documents still in review. The two material open items are the transfer stack for the US hosting layer, where the AWS DPA, the EU and Swiss standard contractual clauses and the transfer impact assessment are not yet executed, and HDS's own DPIA process, which is drafted but not yet operating. NOTE: HDS is not an Art.28 processor for this product, and the matrix does not offer that arrangement. Art.28(3) requires processing on the controller's documented instructions, assistance with data subject rights, and deletion or return of the data at the controller's choice. HDS acts on the individual's permissions, the individual exercises their rights directly from their own dashboard, and HDS cannot delete an individual's vault at a third party's direction. An organisation that receives data an individual chose to share with it is an independent controller of what it holds, not a controller instructing HDS. Any future engagement in which HDS genuinely does process on instructions falls outside this matrix and carries its own documentation. Known gaps in HDS's own position: - [high] Nothing is on file evidencing the Swiss hosting region's physical and environmental controls. The safeguards HDS inherits there are asserted by the provider rather than evidenced by a third-party audit, and the provider's public encryption statement is a product claim, not an attestation. - [high] Art.46 transfer stack for the US hosting layer is not executed: the AWS GDPR DPA, EU and Swiss SCCs and the transfer impact assessment are all outstanding. (refs: Art.46) - [medium] The Art.30 register carries no retention period on the recruitment, CRM and contact-mailbox rows, and its Art.30(2) half stays empty until the first partner DPA is signed. (refs: Art.30) - [medium] Art.32 encryption rests on provider-managed keys. End-to-end or operator-held-key encryption, where the server never holds plaintext, is queued upstream and not shipped. (refs: Art.32) - [medium] The audit.onUserDelete pseudonymise mode is refused at boot upstream, so the Art.17 erasure story is complete only in its erase and keep modes. (refs: Art.17) - [low] HDS's own DPIA process is drafted internally but is not yet a running procedure with a first executed assessment. (refs: Art.35) ### HIPAA Security Rule (hipaa-security) US · 43 requirements · page: https://compliance.datasafe.dev/hipaa.html HDS's own position on HIPAA-Security: - vault: HDS is not-applicable. Every vault. The individual holds the account and decides who may see the data, so HDS holds it for them and never on a covered entity's behalf, whoever put it there and wherever it physically sits. A business associate is defined by acting on a covered entity's behalf, so HDS is not one here and HIPAA does not reach it. External assurance: self-assessed. No HIPAA audit, no independent Security Rule assessment and no third-party report covers HDS. The attestations on file belong to the hosting providers and cover their facilities, not HDS's practices. Certificates HDS relies on but does NOT hold: AWS ISO/IEC 27001 (us-east-1 named in the certified locations), 27017, 27018 — obtained 2026-07-28 Evidence: 40 of 43 requirements answered from approved HDS documentation (43 cite internal evidence), as of 2026-09-10. HIPAA does not reach HDS in the vault, so what follows is not a claim that HDS meets the Security Rule: it is what the platform supplies to an implementer that does hold a role. All forty-three requirements are answered from HDS documentation, and forty of them rest entirely on documents that have completed approval; the other three cite a procedure-execution record still in review, which is the evidence that the control actually ran on the date claimed. The safeguards behind those answers are live rather than paper: a risk analysis and risk-management plan are approved, workforce training runs continuously against a completion register, and backups run on a daily timer on both regional cores, first verified live on 2026-07-30, with a first restore rehearsal executed on 2026-07-29. Recovery at production scale is not yet demonstrated, nine requirements carry remediation HDS has committed to and not delivered, and encryption at rest uses provider-managed keys. NOTE: Consent is not delegation. When an individual grants a clinician or an application access to their own vault, that access flows from their consent, not from anyone instructing HDS, so it creates no business associate relationship: not with the clinician, not with the application, and not with HDS. The data sitting on HDS infrastructure does not change on whose behalf it is held. Where an organisation would place protected health information with HDS on its OWN behalf, a BAA would be required; that arrangement is documented separately and is outside this matrix. The requirements below remain the map for an implementer that holds a HIPAA role of its own, and the FTC Health Breach Notification Rule and state consumer-health-data law are what reach the user-sovereign case instead. Known gaps in HDS's own position: - [high] Addressable encryption at rest rests on provider-managed keys. Neither customer-managed keys nor end-to-end encryption is available, so a compromise of the hosting layer is not cryptographically contained. (refs: 164.312(a)(2)(iv)) - [medium] Platform telemetry is mid-migration from a removed vendor agent to a self-hosted collector; the information-system activity review depends on that pipeline landing. (refs: 164.308(a)(1)(ii)(D)) - [high] Nothing is on file evidencing the Swiss hosting region's physical and environmental controls, which is where the primary store sits. The safeguards inherited there are asserted by the provider, not evidenced by a third-party audit. (refs: 164.310(d)(1)) ### HIPAA Privacy Rule (hipaa-privacy) US · 35 requirements · page: https://compliance.datasafe.dev/hipaa.html HDS's own position on HIPAA-Privacy: - vault: HDS is not-applicable. Every vault. The individual holds the account and decides who may see the data, so HDS holds it for them and never on a covered entity's behalf, whoever put it there and wherever it physically sits. A business associate is defined by acting on a covered entity's behalf, so HDS is not one here and HIPAA does not reach it. External assurance: self-assessed. No independent Privacy Rule assessment covers HDS. Evidence: 33 of 35 requirements answered from approved HDS documentation (33 cite internal evidence), as of 2026-09-10. HIPAA does not reach HDS in the vault. Thirty-three of the thirty-five requirements are answered from approved HDS documentation, which is what an implementer holding a covered-entity or business-associate role inherits when it builds here. Most of this rule is the covered entity's to discharge in any case. What the platform supplies directly is the individual-rights machinery, access, amendment, accounting of disclosures and restriction, each an approved procedure, exercised in rehearsal rather than against production volume. NOTE: Consent is not delegation. When an individual grants a clinician or an application access to their own vault, that access flows from their consent, not from anyone instructing HDS, so it creates no business associate relationship: not with the clinician, not with the application, and not with HDS. The data sitting on HDS infrastructure does not change on whose behalf it is held. Where an organisation would place protected health information with HDS on its OWN behalf, a BAA would be required; that arrangement is documented separately and is outside this matrix. The requirements below remain the map for an implementer that holds a HIPAA role of its own, and the FTC Health Breach Notification Rule and state consumer-health-data law are what reach the user-sovereign case instead. Known gaps in HDS's own position: - [medium] Thirty-two of thirty-five rows are unreviewed drafts. The positions are stated but not second-read. ### HIPAA Breach Notification Rule (hipaa-breach) US · 13 requirements · page: https://compliance.datasafe.dev/hipaa.html HDS's own position on HIPAA-Breach: - vault: HDS is not-applicable. Every vault. The individual holds the account and decides who may see the data, so HDS holds it for them and never on a covered entity's behalf, whoever put it there and wherever it physically sits. A business associate is defined by acting on a covered entity's behalf, so HDS is not one here and HIPAA does not reach it. External assurance: self-assessed. No independent review. The incident and breach procedure has been rehearsed, not tested by a real reportable breach. Evidence: 12 of 13 requirements answered from approved HDS documentation (12 cite internal evidence), as of 2026-09-10. HIPAA does not reach HDS in the vault, but the question this rule turns on is one the platform can answer: who was affected and what did they hold. The breach-scope primitive is deployed to every core with the access index backfilled, so the blast radius of a compromised token is enumerated rather than estimated, and twelve of the thirteen requirements are answered from approved documentation. The notification procedure is approved and rehearsed; no real reportable breach has exercised it. NOTE: Consent is not delegation. When an individual grants a clinician or an application access to their own vault, that access flows from their consent, not from anyone instructing HDS, so it creates no business associate relationship: not with the clinician, not with the application, and not with HDS. The data sitting on HDS infrastructure does not change on whose behalf it is held. Where an organisation would place protected health information with HDS on its OWN behalf, a BAA would be required; that arrangement is documented separately and is outside this matrix. The requirements below remain the map for an implementer that holds a HIPAA role of its own, and the FTC Health Breach Notification Rule and state consumer-health-data law are what reach the user-sovereign case instead. Known gaps in HDS's own position: - [medium] No row in this scope has completed review, and the notification procedure has never run against a real incident. ### SOC 2 — AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) (soc2) United States (AICPA) · 61 requirements · page: https://compliance.datasafe.dev/soc2.html HDS's own position on SOC 2: - vault: HDS is service-organization. HDS is the service organisation operating the vault; an organisation building on it is a user entity. The hosting providers are subservice organisations, carved in or out depending on the criterion. External assurance: none. HDS holds NO SOC 2 report. There is no Type I and no Type II, no audit period has been defined and no CPA firm has been engaged. Nothing on this site should be read as a SOC 2 opinion. Certificates HDS relies on but does NOT hold: AWS SOC 2 (hosting layer only, as a subservice organisation) Evidence: 45 of 61 requirements answered from approved HDS documentation (61 cite internal evidence), as of 2026-09-10. Forty-five of the sixty-one Trust Services Criteria are answered from approved HDS documentation, and the remaining sixteen are evidenced by documents still moving through review. This is a readiness map: it shows which criteria the existing control environment already meets, which is what a service organisation needs before engaging an auditor. It is not an audit and confers no opinion. Twelve criteria carry open remediation, including change management, vendor management and a tamper-evident audit log. Known gaps in HDS's own position: - [high] No SOC 2 examination has been engaged, so there is no report to give a user entity that asks for one. - [medium] A written change-management process with ticketed approvals, per-change test evidence and rollback is drafted but not operating. (refs: CC8.1) - [medium] A formal vendor-management programme with scored risk tiers and scheduled re-assessment is drafted but not operating. (refs: CC9.2) - [medium] The audit log is append-only by convention with no hash chain or signed checkpoint, so it is not tamper-evident against a host-level admin. (refs: PI1.5) ### Swiss Federal Act on Data Protection (revised FADP / nLPD) (swiss-nlpd) Switzerland (extraterritorial via Art. 3 for processing affecting CH) · 30 requirements · page: https://compliance.datasafe.dev/swiss-nlpd.html HDS's own position on Swiss nLPD: - vault: HDS is controller. The individual's vault. HDS determines the purposes and means of operating it, so HDS is the controller under the Act. Data enters only with the individual's explicit consent, and the individual decides who may access it afterwards. External assurance: self-assessed. No FDPIC review, no certification under Art.13 nLPD and no independent audit has been performed. This is HDS's own assessment. Nothing is on file for the Swiss hosting region either: the physical safeguards HDS inherits there are asserted by the provider, not evidenced by a third-party audit. Evidence: 11 of 30 requirements answered from approved HDS documentation (24 cite internal evidence), as of 2026-09-10. Swiss residency is the strongest part of this position: the ch region runs on Swiss infrastructure and the data does not leave it, which is what most of this Act's residency and transfer concern is about. Thirteen of the thirty requirements rest on approved documentation and eleven more are evidenced by documents in review, the same pipeline as the GDPR. Six articles are recorded as out of scope because they address federal bodies or obligations that attach only to the controller, marked on the rows themselves rather than omitted. NOTE: HDS is not an processor for this product, and the matrix does not offer that arrangement. Acting as a processor would require processing on a controller's instructions and returning or deleting the data at its choice. HDS acts on the individual's permissions, the individual exercises their rights directly from their own dashboard, and HDS cannot delete an individual's vault at a third party's direction. An organisation that receives data an individual chose to share with it is an independent controller of what it holds, not a controller instructing HDS. Any future engagement in which HDS genuinely does process on instructions falls outside this matrix and carries its own documentation. Known gaps in HDS's own position: - [high] Nothing is on file evidencing the Swiss hosting region's physical and environmental controls. The safeguards HDS inherits there are asserted by the provider rather than evidenced by a third-party audit, and the provider's public encryption statement is a product claim, not an attestation. - [medium] The processor-side register lacks retention periods on the recruitment, CRM and contact-mailbox activities, the same gap as the GDPR Art.30 row. (refs: Art.12) - [medium] Only one of the thirty rows has completed review. The rest are drafts that state HDS's position but have not been checked by a second reader. ## How the implementer view computes its answer The page at https://compliance.datasafe.dev/implementer.html computes in the browser, so fetching that URL returns an empty result. To reach the same answer, apply these rules to the full matrix in llms-full.txt. ### Features the implementer selects - subjects-eu (population): In the EU or EEA - subjects-ch (population): In Switzerland - subjects-us (population): In the United States - us-role-none (us-role, exclusive: us-role): No US healthcare provider, health plan or clearinghouse is involved - us-role-ce-involved (us-role, exclusive: us-role): One is involved, but not through you (your user's own doctor, say) - us-role-acts-for (us-role, exclusive: us-role): You build or run this application for one, or under contract to one - us-role-you-are (us-role, exclusive: us-role): You are one - connects (application): Data from your users' vaults reaches your systems — They share it with you, or they sign in to your application with their HDS account. Either way you hold personal data. - stores-phi-copy (application): You keep your own copy of health data, including backups and exports - own-records (application): You keep your own user records outside HDS — Accounts, email addresses, crash reports, usage analytics. None of this touches the vault, and all of it is personal data you control. - third-parties (application): Other companies touch the data — Your cloud host, your email or analytics vendors, partners you pass data to. Hosting counts. - analytics (application): You compute on the data — Reports, scores, alerts, AI or machine learning, whether the output is aggregated or about one person. - secondary-use (application): You use the data for your own ends — Research, product improvement, marketing, or selling it: anything beyond the service the user signed up for. - region-ch (residency, exclusive: region): Switzerland - region-us (residency, exclusive: region): United States - want-soc2 (population): Your customers ask you for SOC 2 assurance ### Derived features, computed from the above - processes-personal-data = ANY of [connects, stores-phi-copy, own-records, third-parties, analytics, secondary-use] - handles-user-data = ANY of [connects, stores-phi-copy, third-parties, analytics] - hipaa-in-play = ANY of [us-role-ce-involved, us-role-acts-for, us-role-you-are] - transfer-eu-us = ALL of [subjects-eu, region-us] - transfer-eu-ch = ALL of [subjects-eu, region-ch] - transfer-ch-us = ALL of [subjects-ch, region-us] ### Which frameworks apply - gdpr applies when ANY of [subjects-eu] - swiss-nlpd applies when ANY of [subjects-ch] - hipaa-security applies when ALL of [subjects-us, hipaa-in-play] - hipaa-privacy applies when ALL of [subjects-us, hipaa-in-play] - hipaa-breach applies when ALL of [subjects-us, hipaa-in-play] - soc2 applies when ANY of [want-soc2] ### Which persona's obligations to read - gdpr: always controller - swiss-nlpd: always controller - hipaa-security: covered-entity when ANY of [us-role-you-are]; business-associate when ALL of [us-role-acts-for, handles-user-data]; otherwise NO ROLE (the framework's duties do not attach to the implementer) - hipaa-privacy: covered-entity when ANY of [us-role-you-are]; business-associate when ALL of [us-role-acts-for, handles-user-data]; otherwise NO ROLE (the framework's duties do not attach to the implementer) - hipaa-breach: covered-entity when ANY of [us-role-you-are]; business-associate when ALL of [us-role-acts-for, handles-user-data]; otherwise NO ROLE (the framework's duties do not attach to the implementer) - soc2: always service-organization ### Which obligations apply An obligation is one entry under a requirement's `implementer:` list. For a given framework: 1. Read only entries whose `persona` matches the persona derived above. If the persona is NO ROLE, none of that framework's duties attach to the implementer. 2. Skip any entry with `coverage: out-of-scope`. Those record that a requirement was considered and places no duty on anyone; they are not obligations. 3. An entry with `nature: orientation` is a scope provision, not a duty. Show it, never count it as an obligation. 3b. **A requirement with NO entry for the derived persona states no obligation for that persona, and that is NOT the same as `out-of-scope`.** The latter is a considered "not yours"; a bare absence means this matrix has not authored an obligation there yet. Do not merge the two. Count neither, and show the absent ones as their own bucket rather than silently dropping them, for the same reason an absent `applies_when` is shown. **Two kinds of absence, and one of them is a statement.** A scope may carry `unauthored_obligations`, listing persona obligations it has examined and deliberately not authored because the answer is contested. Listed means weighed and left open; unlisted means nobody has looked. Neither is an obligation and neither is counted, but only the first says anything. The list is in `structure.json` per scope and is covered by that scope's digest. 4. Otherwise the entry applies if `applies_when` is absent, or is `always`, or ANY listed feature is on. Absent means "not yet classified": show it, never treat it as inapplicable. 5. `basis: entity` means the duty attaches because of what the organisation already is and would exist on any platform. `basis: integration` means it arises from using HDS. Present them separately: roughly three quarters of the HIPAA family is `entity`. **On an `entity` obligation, HDS's coverage is assistance and discharges nothing.** The duty is still owed and still needs an answer of your own: HDS having a security official does not answer an auditor asking who yours is. ### What HDS covers Each requirement's `hds.coverage` is one of implemented, configurable, facilitated, documented, out-of-scope. implemented and configurable are delivered by the platform or its configuration; facilitated means HDS supplies part of the answer; documented means HDS records a position without implementing it; out-of-scope means no software role for anyone. This measures what HDS carries FOR an implementer. It is NOT a statement that HDS itself meets the requirement: that is the hds_posture block, reported per framework above. ## Pages - https://compliance.datasafe.dev/ — what this is and how it works - https://compliance.datasafe.dev/standing.html — how HDS itself stands - https://compliance.datasafe.dev/implementer.html — what you have to do - https://compliance.datasafe.dev/templates.html — agreement templates - https://compliance.datasafe.dev/gdpr.html — General Data Protection Regulation - https://compliance.datasafe.dev/hipaa.html — HIPAA - https://compliance.datasafe.dev/soc2.html — SOC 2 — AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) - https://compliance.datasafe.dev/swiss-nlpd.html — Swiss Federal Act on Data Protection (revised FADP / nLPD) ## Contact Reporting what this told you: see "Report back what this told you" above. The issue board is https://github.com/healthdatasafe/compliance-matrix/issues. Evidence documents are cited by code and released under NDA, a signed BAA or an audit engagement: contact@healthdatasafe.org