phi-vault-contract-profile

PHI Vault Contract Profile v0.1 draft. A healthcare-specific profile of the AI Procurement Decision Card v0.2 + v0.3 vault contract — names HIPAA's 18 Safe Harbor identifier categories as concrete data_vault_targets field exemplars and pairs them with default retention_envelope rules a hospital procurement reviewer can sign without re-deriving them per vendor.

Part of the Kinetic Gain Protocol Suite.

Status: v0.1 draft. The profile at profile.json, the canonical example at examples/regional-hospital-radai.json.

Why this exists

The buyer-side AI Procurement Decision Card spec defines data_vault_targets[] (v0.2 — vendor-neutral field-level tokenization contract) and retention_envelope[] (v0.3 — per-field TTL + signed deletion-proof endpoint). Both are intentionally vendor-neutral and shape-only.

In healthcare procurement, the contents of those fields are not arbitrary. HIPAA's Safe Harbor de-identification standard at 45 CFR §164.514(b)(2)(i) enumerates 18 specific identifier categories that a covered entity strips (or vaults) before a record is considered de-identified. A hospital procurement reviewer signing a Decision Card for a clinical AI vendor needs a way to say "these 18 categories, vaulted, with the retention defaults our records-retention policy already uses."

This profile gives them that. It is opinionated content for a vendor-neutral contract: the Decision Card spec stays generic, the profile pins healthcare specifics, the runtime stays unchanged.

What the profile asserts

A Decision Card that conforms to this profile declares:

• A data_vault_targets[] entry whose fields_authorized[] lists at least the HIPAA Safe Harbor identifiers the vendor product collects.
• A retention_envelope[] rule for each of those fields, with a redact_on_expiry action drawn from the profile's per-category defaults.
• A deletion_proof_uri + deletion_signer_key_uri so deletion receipts append cleanly to the buyer's audit-stream.

The profile does not:

• Define a new schema. Decision Cards conforming to this profile are valid against decision-card.schema.json at v0.3.
• Claim HIPAA compliance. Compliance is a posture established by the covered entity's overall program. This profile is readiness scaffolding — naming the field categories and retention defaults so the procurement signature lands in the right shape.
• Endorse a tokenization vendor. The Decision Card's vendor enum stays the buyer's choice.

The 18 categories

#	HIPAA category	Default redact_on_expiry	Default TTL
1	Names	tokenize	P7Y
2	Geographic subdivisions smaller than state (street, city, county, ZIP < 3 digits)	tokenize	P7Y
3	Dates directly related to an individual (birth, admission, discharge, death)	hash	P7Y
4	Telephone numbers	purge	P30D
5	Fax numbers	purge	P30D
6	Email addresses	purge	P30D
7	Social Security numbers	tokenize	P7Y
8	Medical record numbers	tokenize	P7Y
9	Health plan beneficiary numbers	tokenize	P7Y
10	Account numbers	tokenize	P7Y
11	Certificate / license numbers	tokenize	P7Y
12	Vehicle identifiers + VINs	purge	P90D
13	Device identifiers + serial numbers	tokenize	P7Y
14	Web URLs	purge	P30D
15	IP addresses	hash	P30D
16	Biometric identifiers (finger, voice prints)	tokenize	P7Y
17	Full-face photographs and comparable images	tokenize	P7Y
18	Any other unique identifying number, characteristic, or code	tokenize	P7Y

Why these defaults:

• Direct contact fields (4, 5, 6, 14) purge on a short cycle — the buyer's records-retention rarely needs them past the operational window.
• Stable internal identifiers (1, 7, 8, 9, 10, 11, 13, 16, 17, 18) tokenize at P7Y — the HIPAA Privacy Rule's default retention horizon for clinical records, kept as tokens so longitudinal analytics survive without raw PII.
• Dates (3) + IP addresses (15) hash so cohort-level analytics work without reidentification.
• Vehicle identifiers (12) are a middle case — purged at P90D because they rarely matter past episode-of-care + a transition window.

Buyers can override any default per Decision Card; the profile is the floor we agree on absent a reason to deviate. Deviations live in notes on the rule.

How a Decision Card declares it conforms

Inside the Decision Card, point at this profile in the rationale or in a per-rule notes. Suggested convention:

{
  "decision_card_version": "0.3",
  // ... existing fields ...
  "rationale": "Approved-with-conditions. Vault + retention conform to the PHI Vault Contract Profile v0.1 (https://github.com/mizcausevic-dev/phi-vault-contract-profile) with one declared deviation on field session.transcript (P1Y vs the profile's P7Y default — see Condition C-3).",
  "data_vault_targets": [ /* ... */ ],
  "retention_envelope": [ /* per-category rules; see examples/ */ ]
}

A Decision Card validator can additionally check the profile membership by running the optional scripts/check-profile.mjs script in this repo (Phase 1).

Examples

File	Vertical	Conforms to v0.1?	Notes
examples/regional-hospital-radai.json	HealthTech (regional hospital × radiology AI)	✅	Approved-with-conditions; vaults names, MRN, dates, account number; retention follows the profile defaults

The example validates against the upstream decision-card.schema.json v0.3 (CI in ai-procurement-decision-spec will gate it).

Optional conformance check

Phase 1 deliverable: scripts/check-profile.mjs reads a Decision Card and asserts each declared category matches the profile's default unless an override is declared in notes. Not shipped in v0.1 — the profile is read by humans first.

Compliance posture

This profile supports HIPAA Safe Harbor readiness scaffolding. It does not establish HIPAA compliance, certify a vendor, or substitute for a covered entity's privacy + security program. Per the standing public-language guardrail: readiness · evidence · posture · controls · scaffolding — never "HIPAA-compliant" without an external attestation.

Specs this profile composes with

Spec	Repo	Role
AI Procurement Decision Card v0.3	ai-procurement-decision-spec	The base buyer-side artifact
Clinical AI Disclosure	clinical-ai-disclosure-spec	The vendor-side artifact a covered entity reviews before signing the Decision Card
AI Evidence Format	evidence-bundle-spec	The evidence packets the Decision Card references via subject.documents_reviewed[].url
Suite audit-stream	audit-stream-py	Where deletion receipts land

License

MIT — profile text + JSON + example documents are freely implementable.