{"slug": "put-health-data-access-behind-a-consent-receipt-api", "title": "Put Health-Data Access Behind a Consent-Receipt API", "summary": "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.", "body_md": "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.\n\nOpenAI 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](https://openai.com/index/health-in-chatgpt/) and should not be expanded into undocumented implementation assumptions.\n\nA receipt records bounded authority and its version:\n\n```\n{\n  \"grant_id\": \"g_7f2\",\n  \"version\": 4,\n  \"subject_id\": \"user_local_9\",\n  \"connector\": \"supported_source\",\n  \"purposes\": [\"dashboard\"],\n  \"data_classes\": [\"activity\", \"sleep\"],\n  \"status\": \"active\",\n  \"granted_at\": \"2026-07-24T09:00:00Z\"\n}\n```\n\nAvoid 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.\n\nA minimal **unexecuted API contract** might expose:\n\n```\nPOST /v1/consent-grants\nGET  /v1/consent-grants/{id}\nPOST /v1/consent-grants/{id}/revocations\nGET  /v1/revocations/{operation_id}\n```\n\nCreation returns `201`\n\nwith version 1. Revocation returns `202`\n\nbecause 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.\n\n```\n{\n  \"operation_id\": \"rv_82a\",\n  \"grant_id\": \"g_7f2\",\n  \"revoked_version\": 4,\n  \"state\": \"canceling_jobs\",\n  \"requested_at\": \"2026-07-24T10:15:00Z\"\n}\n```\n\nThe worker receives `{grant_id, grant_version, purpose, requested_classes}`\n\nrather 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.\n\n``` php\nACTIVE -> REVOKE_REQUESTED -> SOURCE_BLOCKED\n       -> JOBS_CANCELED -> DERIVATIONS_HANDLED -> COMPLETE\n                              \\-> PARTIAL_FAILURE -> RETRY/REVIEW\n```\n\nThis 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.\n\n| Failure | Expected UI | API/storage invariant |\n|---|---|---|\n| double revoke | show same operation | idempotency key returns original operation |\n| old tab reconnects | require fresh review | revoked grant cannot become active |\n| import is in flight | show cleanup progress | no write after stale-version rejection |\n| connector timeout | show partial state | new reads remain blocked |\n| receipt scope changes | summarize diff | create new immutable version |\n\nAlso 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.\n\nThis 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.\n\nOpenAI 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.\n\nAI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.", "url": "https://wpnews.pro/news/put-health-data-access-behind-a-consent-receipt-api", "canonical_source": "https://dev.to/kongkong1/put-health-data-access-behind-a-consent-receipt-api-3gag", "published_at": "2026-07-25 11:03:28+00:00", "updated_at": "2026-07-25 11:32:33.858629+00:00", "lang": "en", "topics": ["developer-tools", "ai-products"], "entities": ["OpenAI", "ChatGPT", "Apple Health"], "alternates": {"html": "https://wpnews.pro/news/put-health-data-access-behind-a-consent-receipt-api", "markdown": "https://wpnews.pro/news/put-health-data-access-behind-a-consent-receipt-api.md", "text": "https://wpnews.pro/news/put-health-data-access-behind-a-consent-receipt-api.txt", "jsonld": "https://wpnews.pro/news/put-health-data-access-behind-a-consent-receipt-api.jsonld"}}