cd /news/developer-tools/put-health-data-access-behind-a-cons… · home topics developer-tools article
[ARTICLE · art-73254] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Put Health-Data Access Behind a Consent-Receipt API

A developer proposes a consent-receipt API pattern for health-data access, arguing that a full-stack contract failure occurs when a UI displays intent while a worker acts on stale authority. The pattern uses immutable versioned receipts and a state machine to separate stopping new access from handling existing data, ensuring authorization checks at every step.

read3 min views1 publishedJul 25, 2026

A person taps “Disconnect,” the UI flips to a reassuring state, and a queued import starts with yesterday’s authorization snapshot. That is a full-stack contract failure: the browser displayed intent while the worker acted on stale authority. A consent receipt should travel from the UI to the policy check, persistence layer, and every job.

OpenAI announced Health in ChatGPT on July 23, 2026. The company says eligible logged-in US users age 18+ are receiving a rollout on web and iOS, with supported medical-record and Apple Health connections. It says the dashboard can include labs, medications, activity, sleep, and other health information. OpenAI also states connected data and relevant conversations are not used for foundation-model training or advertising targeting. These details come from OpenAI’s announcement and should not be expanded into undocumented implementation assumptions.

A receipt records bounded authority and its version:

{
  "grant_id": "g_7f2",
  "version": 4,
  "subject_id": "user_local_9",
  "connector": "supported_source",
  "purposes": ["dashboard"],
  "data_classes": ["activity", "sleep"],
  "status": "active",
  "granted_at": "2026-07-24T09:00:00Z"
}

Avoid copying health values into this object. The receipt describes permission, not payload. Store immutable versions so an audit can determine which authority a job presented.

A minimal unexecuted API contract might expose:

POST /v1/consent-grants
GET  /v1/consent-grants/{id}
POST /v1/consent-grants/{id}/revocations
GET  /v1/revocations/{operation_id}

Creation returns 201

with version 1. Revocation returns 202

because invalidating credentials, canceling work, removing caches, and processing retained objects may not be instantaneous. The response should include an operation ID and machine-readable state, not a false promise of immediate completion.

{
  "operation_id": "rv_82a",
  "grant_id": "g_7f2",
  "revoked_version": 4,
  "state": "canceling_jobs",
  "requested_at": "2026-07-24T10:15:00Z"
}

The worker receives {grant_id, grant_version, purpose, requested_classes}

rather than a long-lived “approved” flag. Immediately before a source read or payload write, it asks the policy layer whether that exact request remains permitted. A version mismatch is a terminal authorization failure, not a retryable network error.

ACTIVE -> REVOKE_REQUESTED -> SOURCE_BLOCKED
       -> JOBS_CANCELED -> DERIVATIONS_HANDLED -> COMPLETE
                              \-> PARTIAL_FAILURE -> RETRY/REVIEW

This state machine separates stopping new access from handling information already present. Product and policy owners must define what “handled” means for source records, cached responses, user-created exports, backups, and legally retained evidence; code should not invent that policy.

Failure Expected UI API/storage invariant
double revoke show same operation idempotency key returns original operation
old tab reconnects require fresh review revoked grant cannot become active
import is in flight show cleanup progress no write after stale-version rejection
connector timeout show partial state new reads remain blocked
receipt scope changes summarize diff create new immutable version

Also test authorization: only the receipt subject or an explicitly delegated role can inspect or revoke it. Error bodies and logs must exclude record content. Rollback means disabling new connection creation while preserving revocation and status endpoints; never roll back by restoring an old active grant.

This is a proposed application pattern, not documentation of ChatGPT’s APIs, storage, revocation timing, architecture, or connector behavior. It has not been run. Real delivery needs identity verification, abuse controls, migration handling, observability, retention decisions, provider-specific failure mapping, and privacy/security review.

OpenAI says the health experience is designed to support—not replace—medical care and is not diagnosis or treatment. A consent API does not validate health information or make downstream output clinically safe. Its narrower promise is testable: current intent should constrain every layer that can move data.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.

── more in #developer-tools 4 stories · sorted by recency
── more on @openai 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/put-health-data-acce…] indexed:0 read:3min 2026-07-25 ·