Deny-by-default
AJ Consent Manager uses a deny-by-default posture. If no Consent resource exists for a patient-actor-resource combination, the request is denied. This is the correct default for clinical data: access must be explicitly granted, not implicitly permitted.
Mapping regulations to FHIR Consent fields
The FHIR R4 Consent resource is rich enough to express the requirements of GDPR, HIPAA, and India’s DISHA without extensions.
GDPR Article 17 — Right to erasure
Mapped to provision.period.end. When a patient exercises the right to erasure, the consent period is closed:
"provision": {
"type": "deny",
"period": {"end": "2026-01-15"}
}
GDPR Article 5(1)(c) — Data minimisation
Mapped to provision.class. Each class entry restricts the scope to a specific FHIR resource type. A consent that permits only Patient and Observation access cannot be used to read MedicationRequest data.
HIPAA minimum necessary
Also mapped to provision.class combined with provision.action. The ConsentEnforcementInterceptor checks both the resource type and the HTTP method (GET/POST/PUT) before permitting access.
DISHA consent artefact
India’s Digital Information Security in Healthcare Act requires a structured consent artefact. The provision.actor array maps directly to the DISHA artefact’s consentee list.
The ConsentEnforcementInterceptor
Every HAPI FHIR request — read or write — passes through the interceptor before the JPA layer executes. This is the second line of defence after JamBridge’s GOVERN stage. The interceptor is a drop-in JAR requiring two configuration properties.