Health Data and AI-Use Consent Profile v1.0
A HUGS ID authorization profile for Apple Health, EHR/EMR, wearable and other health-adjacent data used by healthcare, research or AI organizations.
Implemented control-plane profile
A form is not a durable authorization record.
A participant may connect a personal device, Apple Health, an electronic health record and selected health information so an organization can deliver a de-identified dataset for research or model development. A submission alone does not prove which source, recipient, operation, study, model, retention period or downstream use the person approved.
This gap reflects the healthcare-system lessons that motivated HUGS ID and the early WaveOn Health Network work: identity, consent and provenance must remain governable after data moves.
Every permitted use binds the complete tuple.
| Element | Required evidence |
|---|---|
| Person | Durable HUGS subject and authorizing person or authority. |
| Source | Registered provider, classification and hashed source identity. |
| Recipient | Registered organization, display name and recipient role. |
| Purpose | Understandable declared purpose—not merely “research.” |
| Scope | Permitted data categories and each permitted processing operation. |
| Study or model | Exact study/model reference for analysis, training or validation. |
| Time | Start, expiration and separate retention end. |
| Downstream use | Prohibited, named processors only, or an authorized research network. |
| Withdrawal | Future-access stop plus the recorded obligation for prior disclosures. |
| Consent evidence | Consent version and SHA-256 digest of the document shown. |
model_training and model_validation must be explicitly authorized.Authorization happens before access.
- The subject, relying-party link, source, connector grant and named recipient must all be active.
- The requested operation and every requested category must be within the immutable authorization.
- The study/model reference must match exactly.
- Expired, paused or withdrawn authorization fails closed.
- Each successful decision creates an append-only event tied to the payload hash.
- Each disclosure or model-use receipt must point to the earlier authorization event.
Stop future use without rewriting history.
Pause or withdrawal stops future authorization immediately. Historical evidence remains so the participant and reviewer can see what already occurred. The profile records whether prior copies are subject to future-access cessation, a deletion request or contractual retention. HUGS does not claim a recipient deleted data until a deletion attestation is recorded.
What exists now.
hugs_health_data_authorizationsstores the immutable authorization tuple.hugs_health_data_use_eventsstores append-only authorization, disclosure, model-use and deletion evidence.- Signed APIs create, inspect, pause, resume and withdraw consent; authorize operations; and record use receipts.
- Row-level security blocks direct public access, and schema tests verify the gate and exclusion of raw health values.
How a WaveOn pilot must use HUGS ID.
The approved WaveOn entity must be registered as the recipient organization. Every Apple Health or EHR source must be registered separately. The participant must see the complete authorization tuple, and the adapter must call the HUGS authorization gate before every covered operation.
Any research sponsor, processor, model developer or downstream network participant must be named or covered by the recorded downstream policy. A general research consent cannot silently expand into future model training or secondary use.