HIPAA Readiness Evidence Bundle Profile v0.1 draft. A profile of the Evidence Bundle spec scoped to the HIPAA Security Rule (45 CFR §164.302–§164.318). Names the 18 required Administrative / Physical / Technical safeguard standards and the evidence item shape each one expects, so a covered entity (or a business associate) can assemble a portable, ed25519-signed evidence packet that an external auditor reads natively.
Part of the Kinetic Gain Protocol Suite.
Status: v0.1 draft. Profile at
profile.json, canonical example bundle atexamples/mercy-regional-2026-q2-hipaa/.
The base evidence-bundle-spec defines a portable, hash-verified, signable evidence packet: one directory, one manifest.json, every item hashed, optional relationships, optional signature. It's deliberately vendor-neutral.
When a covered entity or a business associate produces evidence for HIPAA Security Rule readiness — for a SOC 2 + HIPAA combined audit, a vendor due-diligence response, or an OCR breach-investigation cooperation — the contents of that bundle are not arbitrary. The Security Rule enumerates 18 standards with required + addressable implementation specifications, and an auditor reading the bundle expects to see specific evidence types per standard.
This profile names them.
A bundle conforming to this profile carries labels.profile = "hipaa-readiness-v0.1" and labels.control_family = "<standard-citation>" on items, so an auditor's tooling can pivot from manifest.json straight to the relevant control evidence without re-deriving the mapping.
| # | Family | Citation | Standard | Required ifs | Addressable ifs |
|---|---|---|---|---|---|
| 1 | Administrative | §164.308(a)(1) | Security Management Process | risk-analysis, risk-management, sanction-policy, info-system-activity-review | — |
| 2 | Administrative | §164.308(a)(2) | Assigned Security Responsibility | security-official-designated | — |
| 3 | Administrative | §164.308(a)(3) | Workforce Security | — | authorization-and-or-supervision, workforce-clearance-procedure, termination-procedures |
| 4 | Administrative | §164.308(a)(4) | Information Access Management | isolating-healthcare-clearinghouse-functions | access-authorization, access-establishment-and-modification |
| 5 | Administrative | §164.308(a)(5) | Security Awareness and Training | — | security-reminders, protection-from-malicious-software, log-in-monitoring, password-management |
| 6 | Administrative | §164.308(a)(6) | Security Incident Procedures | response-and-reporting | — |
| 7 | Administrative | §164.308(a)(7) | Contingency Plan | data-backup-plan, disaster-recovery-plan, emergency-mode-operation-plan | testing-and-revision-procedures, applications-and-data-criticality-analysis |
| 8 | Administrative | §164.308(a)(8) | Evaluation | periodic-technical-and-nontechnical-evaluation | — |
| 9 | Administrative | §164.308(b)(1) | Business Associate Contracts | written-contract-or-other-arrangement | — |
| 10 | Physical | §164.310(a)(1) | Facility Access Controls | — | contingency-operations, facility-security-plan, access-control-and-validation, maintenance-records |
| 11 | Physical | §164.310(b) | Workstation Use | workstation-use-policy | — |
| 12 | Physical | §164.310(c) | Workstation Security | workstation-security-controls | — |
| 13 | Physical | §164.310(d)(1) | Device and Media Controls | disposal, media-re-use | accountability, data-backup-and-storage |
| 14 | Technical | §164.312(a)(1) | Access Control | unique-user-identification, emergency-access-procedure | automatic-logoff, encryption-and-decryption |
| 15 | Technical | §164.312(b) | Audit Controls | hardware-software-procedural-audit-mechanisms | — |
| 16 | Technical | §164.312(c)(1) | Integrity | — | mechanism-to-authenticate-ephi |
| 17 | Technical | §164.312(d) | Person or Entity Authentication | authentication-mechanism | — |
| 18 | Technical | §164.312(e)(1) | Transmission Security | — | integrity-controls, encryption |
"Required" implementation specifications must be implemented; "Addressable" specifications must be implemented OR a reasonable alternative documented OR a justified decision not to implement documented (§164.306(d)). This profile expects evidence to cover whichever path the covered entity took for addressable items.
A bundle conforming to this profile:
- Sets
bundle.labels.profile = "hipaa-readiness-v0.1". - Includes at least one item per Required implementation specification across all 18 standards.
- For each Addressable specification, includes EITHER an evidence item OR a documented-decision artifact (named
decision.<spec>.jsonor similar) explaining the alternative or non-implementation, per §164.306(d). - Tags each item with
labels.control_family = "<citation>"(e.g."§164.312(a)(1)") so consumers can group by standard. - Tags each item with
labels.control_spec = "<spec-id>"(e.g."unique-user-identification") so consumers can group by implementation specification. - Is signed (
signatureblock) — the bundle is meaningless to an auditor without a signer.
The base evidence-bundle-spec validator (in evidence-bundle-spec) accepts conforming bundles unchanged. A Phase 1 conformance checker in this repo (scripts/check-conformance.mjs) will additionally verify the per-standard coverage.
examples/mercy-regional-2026-q2-hipaa/ — a canonical bundle for Mercy Regional Health System's 2026 Q2 HIPAA Security Rule readiness package. Covers all 18 standards. Items are placeholders (sha256 hashes are illustrative) — the structure is the spec.
mercy-regional-2026-q2-hipaa/
manifest.json <- conforms to evidence-bundle.schema.json
content/
risk-analysis-2026-q2.pdf <- §164.308(a)(1) - risk-analysis
sanction-policy-v3.md <- §164.308(a)(1) - sanction-policy
workforce-clearance-procedure.md <- §164.308(a)(3) - addressable
business-associate-contract-radai.pdf <- §164.308(b)(1)
facility-security-plan-mercy-regional.pdf
workstation-use-policy-v2.md
media-disposal-log-2026-q2.csv <- §164.310(d)(1)
iam-unique-user-id-evidence.json
audit-controls-config-2026-q2.json <- §164.312(b)
transmission-encryption-config.json
...
| Spec | Role |
|---|---|
evidence-bundle-spec (v0.1) |
The base packet shape this profile constrains |
evidence-bundle-builder |
The tool that materializes a bundle directory with hashes |
hash-attestation-rs |
The ed25519 signer this profile expects to find in signature |
ai-procurement-decision-spec (v0.3) |
A Decision Card can reference a HIPAA-readiness bundle via subject.documents_reviewed[].type = "ai-evidence" |
phi-vault-contract-profile |
The vault contract profile a buyer signs sits upstream of the evidence this bundle assembles |
audit-stream-py |
Bundle assembly + signing emits evidence_bundle_assembled + evidence_bundle_signed events into the audit-stream |
This profile establishes HIPAA Security Rule readiness scaffolding. It does not establish HIPAA compliance, certify a covered entity, or substitute for the covered entity's formal Security Rule program documentation. Per the standing public-language guardrail: readiness · evidence · posture · controls · scaffolding — never "HIPAA-compliant" without an external attestation.
OCR enforcement actions, breach investigations, and audit findings depend on the totality of an entity's program; an evidence bundle is one input.
Profile text + JSON + example bundle structure: MIT.