Overview
The FHIR Consent resource represents patient consent decisions in structured, machine-readable format. Consent records include authorizations for treatment, disclosure of health information, research participation, data sharing with specific parties, or other decisions requiring patient consent under HIPAA, state privacy laws, or organizational policy. FHIR Consent resources enable programmatic management of patient consent preferences across disparate systems — EHRs, health information exchanges (HIEs), payer portals, clinical trial platforms, and patient-mediated exchange applications.
Resource structure: FHIR Consent resources include core elements: status (draft, proposed, active, rejected, inactive, entered-in-error), scope (the domain of the consent — patient privacy, research, advance-directive, treatment), category (specific type of consent per value set), patient (the patient whose consent is recorded), date/dateTime (when consent was given), provision (the specific terms of the consent including allowed or prohibited actions, resources, time periods, and purposes), and policy (reference to the underlying consent form or policy). The provision element is particularly rich, supporting complex consent logic with allowed/denied actions, specific data classes, individual provider references, and time-bound constraints.
Use cases span the healthcare spectrum. HIPAA-required authorizations for specific data uses are represented as Consent resources. Advance directives and healthcare proxy designations are represented. Research participation consent for specific studies is represented. Patient preferences for data sharing through patient-mediated exchange are represented. State-specific consent requirements (for HIV, behavioral health, substance use disorder records) can be modeled through Consent resources with appropriate scope and category. 42 CFR Part 2 substance use disorder consent requirements are a common use case.
Consent management workflow: FHIR Consent resources are typically created when patients sign or grant consent, either on paper (later entered into the system) or electronically through portals, apps, or e-signature workflows. Consent is stored in the Consent resource and referenced when data access decisions are made. Systems evaluating whether to share data for a specific purpose consult the relevant Consent resources to determine patient authorization status. Consent revocations are recorded through updated Consent resource status and provenance.
Relationship with other resources: FHIR Consent integrates with other FHIR resources for full workflow support. Provenance resources document who created or modified consent. DocumentReference resources link to underlying paper consent forms or PDFs. Patient resource provides the patient identity. Organization and Practitioner resources identify consent parties. AuditEvent resources track data access decisions made based on consent.
For interoperability, FHIR Consent enables consent-aware data exchange. An HIE receiving a data request can consult FHIR Consent resources to determine whether the patient has authorized sharing for the specific purpose and recipient. Patient-mediated exchange apps can display consent status to patients and support consent modification. Payer APIs exposing clinical data can respect patient consent preferences expressed through Consent resources.
For RCM operations, consent affects data flow for specific operations: release of information to external requestors (legal, insurance, worker's compensation), data sharing for care coordination with other providers, data sharing with payers for risk adjustment (subject to HIPAA TPO exemption but sometimes requiring express consent for specific state or record categories), and patient-mediated data exchange. Structured FHIR Consent management reduces manual consent tracking and supports compliance audit.
Implementation considerations include: consent form-to-Consent resource mapping (translating existing consent forms into structured FHIR Consent representations), consent UI/UX (how patients view, grant, and revoke consent through portals and apps), system integration (ensuring all data-access points consult Consent resources), state law variation (consent requirements vary significantly by state and record type), and audit and compliance (demonstrating consent-based access decisions were correct). Vendor implementations of FHIR Consent capability vary; mature EHRs and HIEs increasingly support robust Consent resource functionality.
Industry benchmark
FHIR Consent use cases: treatment, disclosure, research, data sharing, advance directives. Integration: HIEs, payer APIs, patient-mediated exchange. State law variation: significant.
Worked example
A patient authorizes data sharing with a specific research study through a portal workflow. The EHR creates a FHIR Consent resource with: status = active, scope = research, category = research consent for study XYZ, patient = this patient, dateTime = signing time, and provision specifying allowed actions (share medication data, problem list, lab results), denied actions (share behavioral health records), and time limitation (valid for 2 years). The research platform consults the Consent resource before accessing data; access to behavioral health records is denied per the patient's specific constraint.
Frequently asked questions — FHIR Consent Resource
What consent types does FHIR Consent support?
Treatment consent, information disclosure, research participation, data sharing, advance directives, and other consent categories. Scope and category elements identify the specific consent type.
How is consent revoked?
By updating the Consent resource status to inactive and recording the revocation through provenance. Systems consulting consent resources must check current status at the time of access decisions.
How does FHIR Consent handle 42 CFR Part 2?
Consent resources can represent Part 2 substance use disorder consent requirements through specific scope, category, and provision elements. Implementation must reflect the detailed consent logic Part 2 requires.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.