Regulatory Compliance

HIPAA (United States)

§ 164.508 — Authorisation for non-routine uses and disclosures

The ConsentRecord satisfies the elements required for a valid HIPAA authorisation:

HIPAA element	Consent Manager field
What information will be used/disclosed	resourceClasses + scopeValues
Who may use or disclose	actorReference
Purpose	regulatoryBasis + purpose_of_use JWT claim
Expiry date	periodEnd
Patient authorisation	Recorded at portal revoke / REST API create time in ConsentAuditEvent

§ 164.312(b) — Audit controls

The ConsentAuditEvent table and FHIR AuditEvent resources satisfy the requirement for mechanisms to record and examine activity in systems containing PHI.

Every permit and deny decision is logged with patient ID, actor, resource type, operation, purpose of use, and outcome.

§ 164.512(f) — Emergency treatment (break-glass)

Enterprise Edition

Break-glass emergency access (HIPAA § 164.512(f)) is available in the Enterprise Edition. It requires the BreakGlassAuditService, the append-only break_glass_event table, and the admin compliance review workflow — none of which are present in the Community Edition.

HTI-1 / TEFCA (United States)

The ONC Health Data, Technology, and Interoperability Final Rule (HTI-1) mandates SMART App Launch v2.2 from July 2026. The Consent Manager integrates with any SMART v2.2-compliant auth server.

The TEFCA requirement that data sharing requires patient consent and that consent must be recorded with the date, purpose, and scope is satisfied by the ConsentRecord lifecycle and the IHE ATNA audit trail.

Enterprise Edition

The OAuth2 consent screen (SmartConsentCustomizer) that automatically creates ConsentRecord entries from SMART app approvals is part of the Enterprise Edition.

GDPR Art. 9 (European Union / EEA)

Health data is a special category under GDPR Article 9. Processing requires explicit consent.

GDPR requirement	How it is met
Explicit consent	Patient must actively create a consent record — no opt-in by default
Specific purpose	regulatoryBasis and purpose_of_use fields document the purpose
Revocable at any time	Patients can revoke via the portal; effective immediately
Auditable	Every processing action is logged with the consent record ID
Portable	Consent history is queryable via the FHIR API (GET /fhir/Consent)

Data Protection by Design

Consent is enforced by default. default-policy: deny is the only valid production configuration — the startup check prevents the application from running without a JWT key source, and HTTPS must be enforced at the load balancer. A patient's data is inaccessible to any application until explicit consent exists.

GDPR Art. 17 — Right to erasure and right to withdraw consent

Patients can revoke consent at any time via the patient portal. Revocation is effective immediately on the next FHIR request.

Consent records themselves are retained for regulatory compliance. The balance between Art.17 erasure rights and audit retention obligations should be addressed in your Data Processing Agreement and your organisation's DPA.

DISHA (India)

The Digital Information Security in Healthcare Act requires:

• Electronic health data may not be shared without informed consent — satisfied by deny-by-default enforcement
• Consent must be specific to the recipient and purpose — satisfied by actorReference + resourceClasses + regulatoryBasis
• Consent can be revoked at any time — satisfied by the portal revocation flow
• An audit log of all data access must be maintained — satisfied by the IHE ATNA audit trail

My Health Record Act 2012 (Australia)

Requirement	How it is met
Patient-controlled access	Default deny — patients must actively create consents
Patient self-service	Portal at /consent/portal (view, history, revoke)
Audit visibility	Patients see every access decision in their history
Explicit opt-out	provisionType = deny records support explicit blocking

Compliance deployment checklist

Before going live in a regulated environment:

• default-policy: deny is set (never change to permit in production)
• JWT_EXPECTED_ISSUER and JWT_EXPECTED_AUDIENCE are set — validates every token
• A JWT key source is configured (CONSENT_JWKS_URI recommended)
• HTTPS is enforced on all endpoints at the load balancer or reverse proxy
• DB_PASS is set to a strong random password
• FHIR_SERVICE_TOKEN has minimum required permissions on HAPI FHIR
• FLYWAY_EXCLUDE_MIGRATIONS is set to exclude V3 sandbox data in production
• Database backups include consent_record and consent_audit_event tables
• regulatory-basis default string is updated to match your jurisdiction
• default-consent-period-days is reviewed against your jurisdiction's guidance
• /actuator/info is not publicly accessible (not exposed by default)

---

← API Reference · Home