Demystifying the FHIR Consent Resource: Enhancing Patient Privacy in Healthcare

What is FHIR Consent?

FHIR (Fast Healthcare Interoperability Resources) Consent is a specification developed by HL7 to manage consent directives in healthcare settings. It allows patients to specify how their health information can be accessed, shared, and used. The Consent resource provides flexibility by enabling both basic metadata recording and more advanced, machine-readable rules.

If you're unfamiliar with how to interpret FHIR resource pages, our guide to reading FHIR resource documentation offers helpful tips, using the Patient resource as an example but covering general rules that apply across resources.

Simple Consent

In its simplest form, the Consent resource records basic metadata about the consent, such as status, date and time, patient, and organization. This data allows healthcare systems to discover, index, search, and retrieve consents. The original consent document may be included as an attachment or a reference to another resource, providing context for the consent.

Computable Consent

For more advanced use cases, FHIR Consent supports the encoding of privacy preferences as machine-readable rules. These rules can be processed by a decision engine to evaluate whether a specific activity is allowed according to the patient's consent. This means that the Consent resource can be directly used to define rules for accessing or sharing information, which can then be enforced by external systems.

The current version of the Consent resource provides two mechanisms for recording these computable rules:

1. Provision Structure: A simple structure for capturing most common privacy rules.

2. PolicyBasis: A more flexible option to reference external policies written in languages such as XACML or ODRL (Open Digital Rights Language), offering a way to encode complex and customized consent rules.

By using these mechanisms, the FHIR Consent resource not only records consent data but also enables it to be processed by automated systems to enforce patient preferences.

FHIR Consent Resource Explains the Rules but Doesn’t Enforce Them

While FHIR provides the framework and guidelines for managing consent, it doesn’t handle enforcement.

Think of consent like a stop sign on a street: it clearly indicates what should happen (in this case, access restrictions), but enforcement of that rule, such as stopping vehicles, is handled by other systems — like security measures, access control protocols, or legal requirements in healthcare systems.

FHIR defines the rules; enforcement is up to the systems that implement these protocols. In practice, this means that while FHIR can define when and where data can be accessed based on patient consent, it is up to other systems and technologies to ensure that the right security measures are in place to protect the sensitive information being exchanged.

In this context, SMART on FHIR provides a standardized framework for implementing secure access controls. By leveraging OAuth 2.0 and OpenID Connect, SMART on FHIR enables applications to request and obtain access to FHIR resources in a manner that respects patient consent and privacy preferences. This integration ensures that only authorized applications and users can access sensitive health data, aligning with the consent directives defined within FHIR resources.​

If you're interested in how applications securely access patient-authorized data, our article on SMART on FHIR offers a clear overview of how authorization and access control operate within this ecosystem.

​Discover how our FHIR Services can help you harness the power of FHIR in your healthcare solutions.

The Key Components of FHIR Consent

• Consent Decision: At the core of any consent directive is the patient's decision, which is either a permit or deny. This decision sets the baseline for how data can be used. For example, a patient might agree to share their health data for medical purposes but deny its use for marketing.

• Provisions and Exceptions: The provision structure adds layers of flexibility. While the base decision might be to permit access, provisions allow for exceptions. For instance, a patient might permit data sharing with their doctor but deny access to pharmaceutical companies. Provisions can be hierarchical, with parent provisions and child provisions providing even more nuanced control.

• Policy Basis: The PolicyBasis connects the consent directive to a specific policy or regulatory framework. It ensures that the consent aligns with the organization’s legal and regulatory obligations, such as HIPAA in the United States or GDPR in Europe.

There are three uses of Consent resources, each serving a different purpose:

• Privacy Consent Directive: Agreement, Restriction, or Prohibition to collect, access, use, or disclose (share) information.

• Medical Treatment Consent Directive: Consent to undergo a specific treatment (or record of refusal to consent).

• Research Consent Directive: Consent to participate in a research protocol and information sharing required.

The FHIR Consent resource is intended to support all three primary use cases, but currently, only the privacy-related use case has been fully developed and modeled. While the other use cases are being used in practice, they haven't been formally defined within the resource yet. As these additional scenarios are further explored, tested, or customized, the scope of the resource may expand. HL7 is also actively developing support for Advance Directives and encourages contributions from the community.

How Consent Itself Can Become a Privacy Risk

When a patient gives consent, such as agreeing to share their mental health records with a therapist, the consent document itself often contains sensitive data. Just the existence of this consent can reveal private health information:

• It may indicate the patient has mental health records.

• Specific conditions or treatments may be disclosed.

• It could reference confidential services or involved parties.

This poses a new challenge: how to share or store consent without exposing sensitive details. For instance:

• Full consent statement: “I, John Doe, consent to sharing my HIV treatment records from Hospital X to Dr. Y for treatment purposes from Jan to Dec 2025.” This reveals:

  • The person’s HIV status.

  • Treatment details.

  • Specific people and dates involved.

• Partial consent statement: “Consent granted for record sharing.” This version signals that consent exists but avoids revealing sensitive information.

In these cases, consent needs to be securely stored and shared, ensuring that only authorized parties can access full details.

Empowering Privacy and Interoperability with FHIR Consent

FHIR’s Consent resource is designed to be a machine-readable mechanism for conveying privacy policies and permissions within healthcare systems. It facilitates the exchange of data and ensures that patient consent is captured and respected across various systems. However, as we discussed, consent alone doesn’t guarantee that the data will be kept private. For FHIR to work effectively, additional safeguards must be in place, especially when consent information itself contains sensitive data.

Ensuring Security and Compliance

The security and privacy of consent data itself should not be overlooked. Many healthcare organizations must implement strict protocols for securing consent documents, especially when they contain highly sensitive information, such as mental health status, HIV treatment details, or other private health data.

By storing consent information in a secure system, and sharing it only with those who need to know, organizations can maintain trust with patients while complying with privacy regulations.

Conclusion

FHIR Consent resources serve as a foundational element in managing digital health data, offering a standardized and interoperable method for capturing and communicating patient consent. They are designed to accommodate a wide range of healthcare scenarios, ensuring that patient choices are accurately represented and respected. However, while FHIR structures and encodes the consent information, the responsibility for enforcing those rules lies with the systems that use it.

By embedding FHIR Consent into clinical and administrative workflows, healthcare organizations can strengthen regulatory compliance, build patient trust, and efficiently manage access to sensitive health information.