What is enforced, what is verified, and what is missing.
Written so an evaluator can decide without a call. The gaps are listed at the same weight as the controls, because you will find them anyway.
The grade is a live self-test
Every deployment can grade itself A–F. The probe creates a synthetic patient, drives real requests through the running stack, and checks seven properties against what actually comes back. Nothing is asserted from configuration.
app.healthclaw.io/r6/fhir/$conformance
This page prints no grade. It would be a copy of a number that changes, and a stale copy always reads as the better one. The check runs on request, so what you get is what is true when you ask.
It is a self-test of the guardrail layer, not an audit, not a certification, and not a HIPAA compliance determination. It says the controls fired on a synthetic record a moment ago. It says nothing about the organisation running the deployment, its hosting, or its staff.
The seven properties
These are the names in the code, so a result you read here matches a result you get from the endpoint.
| Property | What passing means |
|---|---|
| phi_redaction | Names, phone numbers and identifier-class fields do not come back in full on reads or searches. |
| audit_trail | Every resource access writes an AuditEvent, and the audit detail itself carries no PHI. |
| step_up_enforcement | A write without a valid signed token is refused. |
| human_in_the_loop | A clinical write without human confirmation is blocked with a 428, and an approved one is accepted. |
| tenant_isolation | A request scoped to one tenant cannot read another's records. |
| medical_disclaimer | Clinical reads carry a disclaimer, applied by the server rather than the prompt. |
| error_fidelity | Failures are reported truthfully: an upstream auth failure is not reported as "not found", and a degraded read is not reported as an empty one. |
The last one is the unusual entry, and it is the one this project cares about most. A guardrail that returns nothing when it could not check looks identical to a guardrail that checked and found nothing. Every serious defect found in this codebase has been a version of that.
Where PHI can and cannot go
- The agent never receives raw identifiers. Redaction is applied on every read path: direct reads, searches, upstream proxy responses, and context envelopes.
- Labels are re-applied after redaction, from a terminology table keyed by code — never by preserving text the upstream sent. Upstream systems put patient names in display fields, so passing those through to make a record readable is how a redaction layer leaks.
- The consumer app stores no PHI. Accounts and pointers only.
- Consumer chat channels are not treated as covered transport. Telegram, Slack and Discord are patient-directed channels, not a substitute for a BAA-covered path where a covered entity is disclosing.
What is missing
If any of these is disqualifying for your process, it will still be disqualifying in month three.
There is no third-party audit report today. What exists instead is the live conformance check, a public test suite, and a public incident history. That is evidence, not a substitute for an audit.
Field redaction removes identifier-class fields. It is a compensating control. It is not HIPAA Expert Determination and must not be described as de-identified data in a filing. A profile-specific recursive allowlist and an Expert Determination path are on the roadmap.
An organisation running this against real patient data owns its own compliance, agreements and controls. Terms, section 5 is the governing text.
There is no support rota and no contractual response time. For a design partnership that is usually acceptable. For a production dependency it is a risk you should price.
Controls that are in place
- Deny by default on permission evaluation.
- Signed step-up tokens with a nonce and a short expiry for writes.
- Human confirmation required before a clinical write lands.
- Append-only audit, with the audit detail held PHI-free.
- Tenant isolation enforced server-side, never from a client-supplied claim alone.
- A strict content security policy: the site loads no third-party script, stylesheet or font, so no outside party observes a page a patient opens.
- Transport security headers, and framing denied.
Reporting a vulnerability
Email security@healthclaw.io. Please include what you did, what you expected, and what happened. If it involves patient data on a deployment you do not operate, report it without retrieving more of it than the report needs.
Findings are fixed in the open. The repository carries the write-ups, including the ones that were the maintainer's fault.
If you are evaluating this formally
Available today, on request: the conformance output for your own deployment, the test suite and its coverage of these properties, the architecture documentation, and a written account of known gaps that matches this page.
Not available today: a SOC 2 report, a signed BAA, or a penetration test report from a third party. Ask anyway if you need them, because knowing who is asking changes what gets built next.