{"slug": "scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing", "title": "Scoped, time-limited patient consent in FHIR R4 (and the leaks we found enforcing it)", "summary": "The team behind Anpheros, a patient-owned health record built on FHIR R4, has published a pattern for modeling scoped, time-limited, revocable patient consent using the FHIR Consent resource, mapping actor, purpose, resource class and period onto Consent.provision. The writeup details enforcement traps encountered in practice, including unguarded search reads, _include and _revinclude pulling in uncovered resources, and deny provisions that must override outer permits. Anpheros says every app and clinician access in its system passes through such consent, and it offers a free FHIR sandbox with synthetic patients for experimentation.", "body_md": "Most health apps treat consent as a checkbox at signup. Patients tick \"I agree\", and from then on every integration, every clinician and every AI assistant reads everything, forever.\n\nThat model breaks the moment a patient asks a reasonable question: *\"Can my cardiologist see my lab results for the next month, but not my mental-health notes?\"*\n\nFHIR R4 already has the building block for this: the `Consent` resource. Here is how we model **scoped, time-limited, revocable** consent with it, and the enforcement traps we hit along the way.\n\nA consent a patient can understand has four parts:\n\nAll four map onto `Consent.provision`:\n\n```\n{\n  \"resourceType\": \"Consent\",\n  \"status\": \"active\",\n  \"scope\": {\n    \"coding\": [{\n      \"system\": \"http://terminology.hl7.org/CodeSystem/consentscope\",\n      \"code\": \"patient-privacy\"\n    }]\n  },\n  \"category\": [{\n    \"coding\": [{ \"system\": \"http://loinc.org\", \"code\": \"59284-0\" }]\n  }],\n  \"patient\": { \"reference\": \"Patient/123\" },\n  \"dateTime\": \"2026-11-06T10:00:00Z\",\n  \"provision\": {\n    \"type\": \"permit\",\n    \"period\": { \"start\": \"2026-11-06\", \"end\": \"2026-12-06\" },\n    \"actor\": [{\n      \"role\": {\n        \"coding\": [{\n          \"system\": \"http://terminology.hl7.org/CodeSystem/v3-ParticipationType\",\n          \"code\": \"IRCP\"\n        }]\n      },\n      \"reference\": { \"reference\": \"Practitioner/cardio-42\" }\n    }],\n    \"purpose\": [{\n      \"system\": \"http://terminology.hl7.org/CodeSystem/v3-ActReason\",\n      \"code\": \"TREAT\"\n    }],\n    \"class\": [\n      { \"system\": \"http://hl7.org/fhir/resource-types\", \"code\": \"Observation\" },\n      { \"system\": \"http://hl7.org/fhir/resource-types\", \"code\": \"DiagnosticReport\" }\n    ]\n  }\n}\n```\n\nRead it as: *Practitioner cardio-42 may read Observations and DiagnosticReports for treatment, from 6 Nov to 6 Dec.*\n\nWhen the patient taps \"revoke\", set `status` to `inactive` and keep the resource. You want the history: who had access, when it started, when it ended. Deleting the Consent destroys the audit trail you will need the first time someone asks \"who saw my results in March?\"\n\nStoring a `Consent` resource does nothing on its own. FHIR servers don't enforce consent out of the box. The checks have to live in your access layer, on **every** read:\n\n`GET /Observation?patient=123` must drop resources whose type isn't in `provision.class`. This is the leak we see most often: single-resource reads are guarded, searches aren't.`_include` and `_revinclude`.` DiagnosticReport` can drag in resources the consent doesn't cover. Apply the same filter to included resources.`deny` provision after the outer `permit`, and let the deny win.\nThe technical model is only half of it. Patients need one screen that lists every active connection: who, what, until when, plus a revoke button. If a patient can't see a consent, they didn't meaningfully give it.\n\nWe build [Anpheros](https://anpheros.com), a patient-owned health record on FHIR R4 where every app and clinician access goes through a scoped, time-limited consent like the one above. If you want to experiment with the pattern, there's a free FHIR sandbox with synthetic patients at [developers.anpheros.com](https://developers.anpheros.com).\n\nHow are you handling consent in your health app: checkbox, scopes, or something in between?", "url": "https://wpnews.pro/news/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing", "canonical_source": "https://dev.to/adrian_kereky_23e9b987b1b/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing-it-25pc", "published_at": "2026-11-06 16:11:22+00:00", "updated_at": "2026-11-06 16:24:38.677597+00:00", "lang": "en", "topics": ["artificial-intelligence"], "entities": ["Anpheros", "FHIR R4", "HL7", "LOINC"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing", "markdown": "https://wpnews.pro/news/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing.md", "text": "https://wpnews.pro/news/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing.txt", "jsonld": "https://wpnews.pro/news/scoped-time-limited-patient-consent-in-fhir-r4-and-the-leaks-we-found-enforcing.jsonld"}}