Navigating Patient Consent in the Age of AI: A New Framework for Healthcare Data Use
Patients are increasingly faced with choices regarding how their data is utilized, particularly with the rapid integration of artificial intelligence into healthcare. A new framework is emerging to address these concerns, allowing individuals to consent to – or dissent from – various AI applications, ranging from clinical decision support to data training.
The core of this evolving system lies in the Consent model, which enables patients to authorize AI access either broadly, based on the PurposeOfUse, or specifically, by referencing the Device resource identifying the AI system itself. This approach aims to balance innovation with patient autonomy, a critical consideration as AI becomes more prevalent in medical settings.
The Power of PurposeOfUse
According to experts, the most streamlined method for managing AI consent is through the PurposeOfUse. This allows a patient’s consent to remain independent of specific AI systems, avoiding constant updates as new technologies are developed. “The PurposeOfUse acts as a reason code for AI data access,” a senior official stated, “such as MLTRAINING for AI model development or TREATDS for clinical decision support.”
Further clarification comes from a defined PurposeOfUse Vocabulary, which specifies the intent behind the data access. For example, MLTRAINING explicitly denotes data used for training AI, while TREATDS signifies its use in providing clinical support, and PMTDS indicates analysis for payment decisions.
However, this system relies on a crucial trust model: the AI, or the agent feeding it data, must accurately indicate the PurposeOfUse when accessing patient information. While this trust model isn’t unique to AI – it’s common in many healthcare data access scenarios – its accuracy is paramount.
Here’s how consent provisions might look in practice:
- Allow AI for ML Training:
- provision.type = #permit
- provision.purpose[+] = $purposeOfUse#MLTRAINING
- Deny AI for ML Training:
- provision.type = #deny
- provision.purpose[+] = $purposeOfUse#MLTRAINING
- Allow AI for Clinical Decision Support:
- provision.type = #permit
- provision.purpose[+] = $purposeOfUse#TREATDS
- Deny AI for Clinical Decision Support:
- provision.type = #deny
- provision.purpose[+] = $purposeOfUse#TREATDS
Consent for Specific AI Systems
An alternative approach involves identifying AI as a FHIR Device resource. In this model, consent is granted or denied for a specific AI system by referencing its Device resource within a Consent provision. This method, however, presents challenges. It requires attributing all AI access to the corresponding FHIR Device, which may not always be feasible given complex AI orchestration. Furthermore, it’s a fragile system, as each new AI model or software update would necessitate a new consent provision.
A simplified approach allows consent for a specific AI without specifying a PurposeOfUse, though additional restrictions can be applied. This is represented as:
- provision.type = #permit
- provision.agent.reference = Reference(Device/AIdevice)
Addressing Limitations with Consent Extensions
Recognizing the need for greater control, extensions to the FHIR Permission model are being developed to replicate the “limit” concept. These extensions allow for restrictions on permit provisions, such as obligations, refrains, or the removal of specific data elements. “A ‘limit’ should never expose data if that limit can’t be reliably enforced,” one analyst noted.
For example, consent can be granted for AI training, but only on de-identified data:
- provision.type = #permit
- provision.purpose[+] = $purposeOfUse#MLTRAINING
- provision.modifierExtension[limit].extension[control].valueCodeableConcept = $obligation#DEID
A Unified Approach to Consent
The examples presented demonstrate how a Consent.provision iteration can effectively convey consent or dissent for AI applications. These provisions can be combined with existing consent frameworks for traditional clinical use, creating a single, comprehensive consent document that reflects a patient’s preferences for both conventional and AI-driven healthcare.
Further details and refinements to this framework are available in a draft Implementation Guide on Consent About AI, which is expected to evolve as the field progresses. The ultimate goal is to empower patients with greater control over their data while fostering responsible innovation in the rapidly expanding world of artificial intelligence in healthcare.
