FHIR Consent backed by XACML enforcement

Imagine a scenario where my organization uses XACML for all of our policy. This is where HR policies are on what HR relevant data can be accessed by whom, etc. This same XACML system would also be used to protect Patient data, including imaging, EHR, and HIE access. Thus, the XACML system is very broad and deep. Thus, it is the one that we want to use to protect everything.

Along comes FHIR Consent and we feel that there is a need to have some representation of the Patient Consent in FHIR form, but the actual rules that are applied stay in XACML. So, what does the FHIR Consent look like?

Generally speaking, the FHIR Consent would be just a cross-reference between the Patient as known in FHIR with the XACML subject id as known in XACML. The FHIR Consent would not replicate any of the patient specific rules. 

So, lets imagine a Patient has indicated that they agree to permit all the normal clinical activities with Normal sensitivity data, but that they do not allow external access to Restricted sensitivity data. 

In FHIR Consent, this would be a set of Consent.provisions; but in my case I already have this in computable form in XACML.

Further, my organizational overriding policies are written in XACML.

To see what this looks like, I have written a simple Implementation Guide: The Consent points at the overriding policy and the patient specific policy as shown below. This is Profiled:

XACML Policies

For those more familiar with XACML, can you check my work? I don't pass off these two policy sets as perfect, but as small representative examples.

Using XACML leverages an existing standard for defining access control policies. XACML policies are XML documents that specify rules for granting or denying access to resources based on various attributes, such as user roles, resource types, and environmental conditions.

XACML Overriding Policy

The XACML Overriding Policy is a policy set that defines the overarching access control rules for FHIR resources. This policy is intended to be used in conjunction with patient-specific XACML policies referenced in FHIR Consent resources. The overriding policy ensures that certain organizational or regulatory requirements are consistently applied across all patient consents.

<!-- This XACML policy file defines an organizational governance layer that overrides patient consent preferences. Specifically:

Purpose: It demonstrates how an organization's data access rules take precedence over patient consent policies using XACML's "deny-overrides" combining algorithm.

Key Rules:

1. Emergency Access - Permits doctors to access data during life-safety emergencies, regardless of consent restrictions
2. Archived Data Denial - Strictly forbids access to archived records, overriding any patient permits
3. Administrative Staff Restriction - Denies administrative staff access to data tagged as "Restricted" (R), even if patient consent would allow it

Context: This sits within a larger governance framework where patient consent (referenced via PolicySetIdReference) is evaluated, but organizational policies can override patient preferences when necessary for clinical workflows, safety, or compliance reasons. A master container applies default-deny if neither permits nor denies are found.
-->

<Policy PolicyId="Org_Policy_7890_Workflow_Governance" 
        RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides" 
        xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
    
    <Description>
        Organizational Governance: Enforces workflow roles and clinical status.
        This policy overrides subject-level permits.
    </Description>

    <Target/> 
    
    <Rule RuleId="Emergency_Access_Permit" Effect="Permit">
        <Description>Allows doctors to access data regardless of tags during a life-safety event.</Description>
        <Condition>
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Emergency</AttributeValue>
                <AttributeDesignator 
                    AttributeId="urn:example:names:clinical:access-context" 
                    Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" 
                    DataType="http://www.w3.org/2001/XMLSchema#string" 
                    MustBePresent="true"/>
            </Apply>
        </Condition>
    </Rule>

    <Rule RuleId="Deny_Archived_Data_Access" Effect="Deny">
        <Description>Strictly forbids access if the record is in 'Archived' status, overriding user permits.</Description>
        <Target>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Archived</AttributeValue>
                        <AttributeDesignator 
                            AttributeId="urn:example:names:resource:status" 
                            Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
                            DataType="http://www.w3.org/2001/XMLSchema#string" 
                            MustBePresent="true"/>
                    </Match>
                </AllOf>
            </AnyOf>
        </Target>
    </Rule>

    <Rule RuleId="Deny_Non_Clinical_Staff_Restricted" Effect="Deny">
        <Description>Forbids administrative staff from seeing any data tagged as 'Restricted' (R).</Description>
        <Condition>
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
                <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Administrative</AttributeValue>
                    <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
                </Apply>
                <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">R</AttributeValue>
                    <AttributeDesignator AttributeId="urn:example:med:names:resource:data-tag" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
                </Apply>
            </Apply>
        </Condition>
    </Rule>
</Policy>

XACML Patient Consent Policy

The XACML Patient Consent Policy is a policy document that defines the specific access control rules for an individual patient. This policy is referenced in the FHIR Consent resource and works in conjunction with the XACML Overriding Policy to determine access permissions for FHIR resources.

<!-- This XACML policy file encodes a patient consent for Patient ID 12345. Specifically:

Purpose: Defines the patient's preferences for data sharing based on sensitivity tags using Attribute-Based Access Control (ABAC).

Consent Rules:

1. Permits Normal Data - Allows sharing of data tagged as "Normal" (N) sensitivity
2. Denies Restricted Data - Blocks sharing of data tagged as "Restricted" (R) sensitivity

How it Works:

- Targets requests where the subject-id matches patient 12345
- Uses "deny-overrides" at the PolicySet level to ensure denials take precedence
- Contains two sub-policies: one for Normal data (permit-overrides) and one for Restricted data (deny-overrides)
- Evaluates the data-sensitivity attribute on resources to determine access
- This represents the patient's preferences layer in the consent framework, which works in conjunction with organizational policies (like xacml-overriding.xml) to make final access decisions.
-->

<PolicySet xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
           PolicySetId="consent-policy-set-12345"
           Version="1.0"
           PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">

    <Description>Consent Policy Set for Patient ID 12345</Description>
    <Target>
        <AnyOf>
            <AllOf>
                <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">12345</AttributeValue>
                    <AttributeDesignator 
                        AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" 
                        Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" 
                        DataType="http://www.w3.org/2001/XMLSchema#string" 
                        MustBePresent="true"/>
                </Match>
            </AllOf>
        </AnyOf>
    </Target>

    <Policy PolicyId="consent-policy-12345-normal-data"
            RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">

        <Description>Policy to permit sharing of Normal (N) data</Description>

        <Target>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Normal</AttributeValue>
                        <AttributeDesignator AttributeId="data-sensitivity"
                                             Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                                             DataType="http://www.w3.org/2001/XMLSchema#string"
                                             MustBePresent="true"/>
                    </Match>
                </AllOf>
            </AnyOf>
        </Target>

        <Rule RuleId="permit-normal-data" Effect="Permit">
            <Description>Permit access to Normal data</Description>
        </Rule>

    </Policy>

    <Policy PolicyId="consent-policy-12345-restricted-data"
            RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

        <Description>Policy to deny sharing of Restricted (R) data</Description>

        <Target>
            <AnyOf>
                <AllOf>
                    <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Restricted</AttributeValue>
                        <AttributeDesignator AttributeId="data-sensitivity"
                                             Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                                             DataType="http://www.w3.org/2001/XMLSchema#string"
                                             MustBePresent="true"/>
                    </Match>
                </AllOf>    
            </AnyOf>
        </Target>
        <Rule RuleId="deny-restricted-data" Effect="Deny">
            <Description>Deny access to Restricted data</Description>
        </Rule>
    </Policy>
</PolicySet>




AI Assisted Patient Appointment Traceability

The following scenario is just an example of AI use and AI Transparency impact. The intent of the use-case is to show that where AI gets engaged in the Patient care, attribution to the AI needs to be clearly indicated. The AI use in specifically Patient Appointment is not what I am endorsing but rather using it as a representative interaction for the purpose of showing Provenance and thus Accountability to AI use.

1. Patient provides lab test specimens prior to appointment.
2. AI analyzes lab test results along with patient history.
3. Patient appointment with Doctor considering AI report.
4. Patient care improved by AI

Detailed Steps

1. Patient is scheduled for a routine check-up appointment.
2. Patient had provided specimens for lab tests prior to the appointment.
3. On the day of the appointment, an AI is called to analyze the lab test results.
4. The AI considers the lab test results, related to prior lab test results, current conditions, current medications, and family medical history.
5. The AI generates a summary report highlighting any abnormalities or areas of concern.
6. The AI summary report includes various actions that could be recommended based on the analysis.
7. During the appointment, the healthcare provider reviews the AI-generated report with the patient.
8. The healthcare provider discusses any abnormalities or concerns identified in the report.
9. The healthcare provider considers the recommendations from the AI generated report and recommends further tests or lifestyle changes if necessary.
10. The patient is given an opportunity to ask questions and discuss their health.
11. The appointment concludes with a follow-up plan, if needed, and scheduling of the next routine check-up.
12. The AI-generated report is stored in the patient's medical records for future reference. Patient AI Summary
13. The healthcare provider documents the appointment details and any recommendations made.
14. The patient receives a summary of the appointment and any next steps via their patient portal.

Patient AI Summary

This document outlines the steps involved in a typical patient appointment for a routine check-up, including the integration of AI analysis for lab test results and AI recommendations.

In this case, since the Patient AI Summary is generated by the AI, the author of the document is the AI system itself. The document may also be tagged with metadata indicating that it was AI-generated.

The summary would itemize the list of history, conditions, medications, lab results, and family history that were considered by the AI in its analysis. It would indicate the new lab test results that were analyzed in the context of prior lab test results and the patient's overall medical history. It would include citations to medical knowledge bases or guidelines that the AI used to inform its analysis and recommendations.

The recommendations would each include a rationale, linking to evidence from the patient's data and relevant medical literature. There would be discussion of benefits, risks, and side effects.

AI Provenance

Provenance information about the AI analysis is recorded to ensure transparency and accountability. This includes details such as the AI model version, data sources used for analysis, and any relevant parameters or settings applied during the analysis process.

Audit the AI

An audit trail is maintained to track the AI's analysis process, ensuring that all steps taken by the AI are documented for future reference. This includes logging the input data, analysis steps, and output results. This is different from Provenance as it records the searches into the patient medical record that the AI made to gather information for its analysis. The audit record of a search typically includes the search request parameters, and does not include the response to the search request. As such the audit analysis would re-run the search to determine what was returned. For example a broad search on a patient record would include all medical history. The AI would likely not process some of this medical history that is determined by the AI to be not relevant. As not relevant data, it would not be included in the AI Provenance as data used by the AI Analysis. Data the AI considered not relevant to the analysis, such as resolved conditions, resolved broken bones, prior medications no longer being taken, etc. The AI may appropriately pull all historic medical data, as there may be some relevant data in the historic record. The AI can quickly determine what is relevant and what is not relevant. The Audit would include the search of the full medical history, while the Provenance would only include the relevant data used by the AI.

The Audit would include a independent Audit entry for the creation of the Patient AI Summary document itself. This might include the data used, depending on the configuration of the audit system.

If there is some business rule, or privacy consent restriction, that would prevent the AI from accessing certain data in the patient record, the Audit would include the access control denial.

The Audit log would cover everything found in the Provenance, but would be less succinct.

Encounter Documentation

The healthcare provider documents the appointment details, including any findings from the AI report and recommendations made during the consultation.

The writing of this documentation may also be assisted by AI, which can help summarize the key points discussed during the appointment and ensure that all relevant information is accurately recorded in the patient's medical record. This is a different use of AI from the above, and has different inputs and outputs. This documentation would be authored by the Doctor, with assistance from the AI. Thus another Provenance indicating the AI assistance in documentation, with authorship attribution to the Doctor.

Patient Summary

The patient receives the summary of the appointment, including any next steps or recommendations, via their patient portal for easy access and reference.

AI slop remediation

Now imagine that the healthcare providing organization has learned that the AI model they were using make specific mistakes with specific kinds of lab results. The organization can find all of the Provenance attributed to that AI Model, thus the subset of outputs that that AI Model influenced. They could further find those Provenance that have a .entity relationship with a given AI Prompt known to have produced poor results, so now have the subset of instances where the AI was used with the defective AI Prompt. They can then review those outputs, and determine if any patient care was negatively impacted. If so, they can reach out to those patients to remediate the situation. This is an example of how Provenance enables accountability for AI use in healthcare.

New AI software, Models, and Prompts

When new AI software, models, or prompts are introduced, the healthcare organization can track their adoption and usage through Provenance records. This allows them to monitor the performance and impact of the new AI tools on patient care. If any issues arise, they can quickly identify which AI tools were involved and take appropriate action to address any concerns. This ongoing monitoring and accountability help ensure that AI integration in healthcare continues to benefit patients while minimizing risks.

The change would be represented in a new Device resource representing the new AI software or model, and if there is configured prompt this would also be represented in the Device resource.

The Provenance records for AI analyses would then reference the new Device resource as the .agent, allowing for clear tracking of which AI tools were used in each analysis.

Conclusion

The AI Transparency IG includes standards for recording that data was influenced by AI. The IG does not try to control how AI is used or restrict how the AI Transparency are used. The examples given in the guide are very focused on minimal expression for illustrative purposes. I try here to express a more realistic use-case so as to drive more clear understanding of the benefit of AI Transparency.

Controlling AI in Healthcare

AI must be controlled. That is to say that AI accessing data and making data is a privileged activity. It is not uncommon during the early days of a new technology for that technology to be uncontrolled. It is not uncommon for Security to be seen as There are three specific moments when AI needs to be controlled. \

1. when the AI is trained on a dataset, 
2. when the AI is used to make treatment decisions (e.g. on a given Patient),
3. when the AI is used to make payment decisions (e.g., on a given Patient)

Teaching

Teaching an AI/ML/LLM with dataset needs to be controlled to prevent ingestion of data that is not authorized to be used for this purpose. With this use-case, HL7 has identified a specific PurposeOfUse that would be used to indicate this teaching/training purpose - MLTRAINING. With this code a few things can be done:

When the training is done, the authorization request is for MLTRAINING PurposeOfUse. Thus, the access control will either permit or deny such a PurposeOfUse, and the authorization would be audited as such. This PurposeOfUse would not be given to Agent that is not authorized to use this PurposeOfUse. Thus, this PurposeOfUse can't be used by other actors.

A Dataset can be marked as forbidden for MLTRAINING PurposeOfUse, which would make that Dataset unavailable for training. This, in theory, could be done down to the data artifact basis.

There is a standard in the general AI world that I helped create to tag datasets with Provenance and Authorizations including the license that would need to be followed if the data are to be ingested by an AI/ML/LLM. The Data & Trust Alliance has published this Data Provenance Standard, that is elaborated on here.

Patient based Consent on Teaching

This MLTRAINING PurposeOfUse could be leveraged in a Patient specific Consent. This would enable a Patient to indicate that they do not want THEIR data used to teach an AI. This would mean that the Access Control is more fine-grain, in that each datum pulled from the database must be checked to see if the given subject of the data (the Patient) has authorized, or did not deny authorization for AI to learn from their data.

Treatment Decisions

There are other PurposeOfUse when the AI is used during treatment (TREATDS) or payment (PMTDS) decisions. These PurposeOfUse are specific to the outcome, and are therefore distinct so that business rules or Patient Consent can allow one but not the other. They would otherwise work rather similar.

The most likely use-case is one where Patients get to indicate that they do or do-not want AI used in making Clinical Decisions (or Payment Decisions). This is diagrammed below where each Patient has a Consent with a term around PurposeOfUse of TREATDS of go or no-go; and that is used by the AI System authorization to allow the AI to make decisions, and thus look at historic patient data.

Conclusion

These PurposeOfUse already are defined for these purposes. There may be other PurposeOfUse codes that need to be defined, this is a good exercise for discussion. The above scenarios are also not the only ones, and indeed these scenarios might not be the most likely or most useful ones. My point in this article is to show that we (Security WG) have done some thinking and developed some standards codes.

Healthcare AI Transparency ballot

Healthcare use of AI needs to be Transparent, clearly labeling and attributing when patient data was created or influenced by AI. This is the goal of a new Implementation Guide going to HL7 Ballot really soon. This Implementation Guide will also be the focus of an HL7 FHIR Connectathon testing track in January.

The guide is designed for health IT developers, clinicians and institutions that use AI (including generative AI or large language models) to generate or process health data. It provides a common format so downstream systems and human users can see what data came from AI — when, how, and by which algorithm. This helps them judge whether AI-derived data are reliable, appropriate, or need further review.

Key features include:

• Tags or flags on FHIR resources (or individual data elements) to mark AI involvement.
• Metadata about the AI tool: model name and version, timestamps, confidence or uncertainty scores.
• Documentation of human oversight (for example, whether a clinician reviewed or modified AI outputs).
• Traceability: which inputs (e.g., clinical note, image, lab result) were fed to the AI, and how outputs were used to produce or update health data.
  

For stakeholders — such as patients, clinicians, and health-system administrators — the main benefit is transparency. Users can tell whether data was AI-generated or human-authored, which supports trust, safety, and informed use of AI in care.

And when the AI model or prompt is found to produce unsafe recommendations, then this transparency indications can be used to find potential problems that can then be reexamined.

AI will be used, and attribution to that use will help us deal with the data in the future.

Age Verification is much more important than porn

There is much talk now days, driven by some regulations around the globe, of a need on the internet for services to know a user's age. The main one that comes to the discussion is to protect children from accidently seeing porn. This use-case is hiding a much more important problem that must be solved at the same time.  The porn problem is rather easy to argue is a universal "good" use-case. Not many will be able to argue against this use-case from any perspective. Thus, it is used to hammer a solution into existence. But once that solution exists, it will be used for many use-cases that are not as "universal good". Meaning it will be used by some governments against small groups that have much less leverage than the porn industry has.

Parent solution:

Many solutions that are being proposed today have 'the parent' indicate their children's 'age'. This seems like a good solution for a while, but who proves that that individual is 'a parent' and specifically 'the parent of that child'? These solutions are trying to build a sound logic upon ground that is not solid.

What is Age limited

Porn is easy to identify as a problem, and as I have said above it is easy to agree. One might add some topics like online gambling as easy to identify and universally agreed to.

In the physical world we have access to Alcohol, Tobacco, Vaping, and other drugs; along with Driving, Voting, Military Services, Credit Cards, Car Rental, and even solo travel. In the physical world these are controlled at the source, where they item or service is dispensed. 

In the mixed physical and virtual world, we somewhat have a history (mostly failed) with Movies, Music, and Video Games.  It can be argued that these were early efforts that if we had age verification that these would be more effectively controlled.  These are all, like porn, in that they are rather universally agreed to.

Problematic Age Limited

Less clear are other information (internet) topics that "some" people consider should be "age limited". Who are these "some" people, and what criteria are they using to determine what is "age limited"? I am sure many of the things beyond porn will NOT be universally agreed to. Which means that in one location topic ABC is age limited, and in another area it is not. Some of these topics are deep/heavy topics, like abortion; while others are stigmatizing topics that are appear to be simply embarrassing. But all of them can be leveraged to great harm by governments, parents, spouse, peers, and bullies.

- Abortion (information, consulting, or services)

- Sexual Health

- Self-harm

- Addiction

- Trauma

- Telehealth

- Weight advice

- LGBTQ+

- sex education and reproductive health

- domestic violence, sexual assault

- emotional abuse

- child abuse or neglect

- homelessness

- poverty

- ADHD

- chronic pain

- autoimmune disorders

- emancipation or foster care

- etc...

The problem is not that these information topics exist, but rather that anyone seeking these information must provide age verification; and the government must NOT be able to determine who has tried to gain access to these information.

Note that someone might be simply intellectually curious, or doing research for school, or helping out a friend. But because they search a topic, they will be vulnerable to being discovered as having been interested. Being interested should not be a crime, even in government regions where the act is a crime.

Age Verification Service

There is good discussion going on about the design and standardization of these services. The discussion more broadly is mostly about how those that provide an "age limited" service want to use an "age verification" service so that they don't have to do this difficult task. This is a good topic to discuss as the doing this wrong is easy and exposing the individual privacy is common.

What is not discussed broadly, but I have confidence that in the standards this is discussed, is how the "age verification" service must also be isolated from knowing WHY the age assertion was requested. This is to say that the "age verification" service can't become the thing that a government can subpoena to turn over records so that the government can know the individuals that have been seeking "abortion" information (for example). 

The governments will want to be able to do this subpoena, so they are not going to be pointing out this privacy problem. Much like they want encryption backdoors, they want backdoors to age verification.

Thus, the solution must be blinded BOTH directions; this is what makes it so much harder.

The Age Verification Service must not have an audit trail. None at all. It is far better for it to have failed "open" (allowing access when it should have been forbidden) than for the whole service to expose the whole population that it serves. Privacy Principles must be prime.

Age Verification Service problem

The App stores, like Apple and Google, are being challenged to provide these Age-Verification services. If they focus on the easy use-cases they will not see the hard problems. I hope that they are not blind. Once we have a solution, however flawed it is, it will be used everywhere.