Healthcare Exchange Standards

Consent about AI

noreply@blogger.com (John Moehrke) — Wed, 11 Feb 2026 17:10:00 +0000

There are various use-cases where a Patient might consent or dissent to various uses of AI.

A patient might consent to use of AI for clinical decision support
A patient might deny use of their data for training of AI.
A patient might consent to use of their data in de-identified form for training of AI.

Given the Consent model, the Patient might be indicated in a Consent authorizing either:

Generically allowing or denying AI by PurposeOfUse
Specifically allowing or denying a specific AI by referencing the Device resource for that AI.

PurposeOfUse

The most clean method is to use the PurposeOfUse as the basis for the provision in the Consent. This allows the Consent to be independent of the specific AI system or model, and thus not require updates as new AI systems or models are developed. The PurposeOfUse can be used to indicate the reason for the AI access, such as MLTRAINING for training of AI, or TREATDS for clinical decision support.

Further we look to PurposeOfUse Vocabulary to indicate what the reason the AI is giving for accessing data. For example, the PurposeOfUse of MLTRAINING is defined for when an AI is looking to train on data. The PurposeOfUse of TREATDS is defined for when an AI is looking to provide clinical decision support, or PMTDS when AI is looking to provide analysis for payment decisions.

The use of PurposeOfUse does require that any accesses the AI does, or an agent feeding the AI, must use the given PurposeOfUse code when accessing data. This is a trust model that the AI or the agent feeding the AI will accurately indicate the PurposeOfUse when accessing data. However, this is a common trust model used in many other aspects of healthcare data access and thus is not unique to AI.

Allow AI for ML Training

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse#MLTRAINING

Consent example: Allow ML Training

Deny AI for ML Training

* provision.type = #deny
* provision.purpose[+] = $purposeOfUse#MLTRAINING

Consent example: Deny ML Training

Allow AI for Clinical Decision Support

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse
#TREATDS

Consent example: Allow AI for Clinical Decision Support

Deny AI for Clinical Decision Support

* provision.type = #deny
* provision.purpose[+] = $purposeOfUse#TREATDS

Consent example: Deny AI for Clinical Decision Support

Specific AI Systems or Models

For this we look to current identification of AI as a FHIR Device resource. This Device would be indicated in a Consent when a specific AI system or model is identified in a Consent.provision.agent.reference with a permit or deny provision.

This model requires that all access by an AI are attributed to the FHIR Device describing the AI. This might not be the case given how the AI is orchestrated. This model also is fragile as a new model or software would be a new Device, and thus would require a new provision in the Consent to indicate consent or dissent for that new AI.

Allow a specific AI for a specific purpose

In this case there is simply a provision indicating that the AI is permitted. There is no purposeOfUse indicated, but that could be an additional restriction. There is no other restrictions on the kinds of actions or the kinds of data, but those could also be additional restrictions.

* provision.type = #permit
* provision.agent.reference = Reference(Device/AIdevice)

Consent example: Allow specific AI for specific purpose

Limitations on AI Access

In the FHIR Permission there is a concept of a "limit" which is limits placed on a permit provision. Where the limit might be an obligation or refrain, might be a specific additional data tag, or might be explicit removal of data elements. I have made an extension to replicate this "limit" concept so that it can be used on a Consent.provision. A "limit" should never be allowed to expose data where that limit can't be enforced. Specifically meaning that the recipient of the data must be trusted to enforce the obligation or refrain indicated. PermissionRuleLimit Extension

In FHIR R6 one could have a Consent that holds the provisions as a Permission resource, and thus the limits capability is available.

Allow AI for ML Training on De-Identified Data

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse#MLTRAINING
* provision.modifierExtension[limit].extension[control].valueCodeableConcept = $obligation#DEID

Consent example: Allow ML Training on De-Identified Data

Conclusion

The above examples are showing simply how a Consent.provision iteration can carry permit and deny to indicate consent or dissent for AI. The examples are not exhaustive, and there are many other combinations of provisions that could be used to indicate consent or dissent for AI. The examples are also not indicating any specific data elements that are being allowed or denied, but those could be added as additional restrictions on the provision.

The reader should be able to take a quilted Consent that has various provisions indicating consent or dissent for various clinical use (TPO) and add in provisions indicating consent or dissent for various AI use-cases, and thus have a single Consent that indicates the patient's preferences for both traditional clinical use and AI use.

The above examples are available in a draft IG on Consent About AI. That IG might further refine and improve beyond this blog article.

Security Labeling Service - Reference Implementation

noreply@blogger.com (John Moehrke) — Thu, 05 Feb 2026 23:26:00 +0000

I have spent far too much time with Co-Pilot AI, but I am so happy with the output. I have vibe coded two applications. I wrote in a readme what I wanted done, and co-pilot produced a working application on the first try. I then spent two days improving (adding features and robustness) them. I never needed to touch code, I just typed what I wanted changed, improved, or fixed.

I have insisted that the apps clearly indicate their Provenance:

This application was developed by GitHub Copilot (Claude Sonnet 4.5) ..., at the direction of John Moehrke of Moehrke Research LLC.

SAMHSA ValueSet viewer

The fist vibe coding project I had was to create a github.io app that allows me to see the contents of a given set of ValueSets from SAMHSA. The reason I needed this is because some of these are too big for the IG Publisher to render the expansion. I had asked to have a setting that would set the IG Publisher 1000 entry max to 2000. But this request was rejected. So, this was my inspiration.

All I did was ask co-pilot to make me an application that can use a FHIR defined $expand operation against the tx.fhir.org server, for a list of ValueSets by url; and display the results.

This was a total of 15 minutes of my time. I then proudly told my family, and my boys proceeded to break it. Turns out a feature I asked was the "Check All Sizes", and that was introduced a bug if run first. So, I told co-pilot about this effect, and it fixed it. Add 5 more minutes.

Try it out at SAMHSA ValueSet Viewer. Don't beat on it too much as it does use tx.fhir.org.

Security Labeling Service - Reference Implementation

This one is far bigger, and I have been thinking of asking AI to make this one for me. I created a github repository, and wrote a README.md with just a few words about what I wanted done. Mostly what you see at the beginning of the current README.md; although this has been touched up as I asked for more features.

Again, the result of the first try worked. I have since improved it in ways that I failed to explain in my original README.md ask. I failed to explain that I wanted a docker deployable server, that the API must be FHIR $operation compliant, that it needs to support ValueSet with multiple topic values, etc.

I was impressed that it started with a sample ValueSet bundle, and sample data Bundle. Very simplistic, but reasonable. These have since been updated to test some of the features added.

What took the most time is that I wanted to be sure that this SLS worked. For this I needed to have complex ValueSets, and complex Data. In both cases I have been working in SHIFT-Task-Force on these very things. I had an IG that had both together. First I chose to break the data use-cases out from the SLS and ValueSets. The main reason was that I know there is going to be significant improvement in the data use-cases; and the ValueSets cause the build to be very slow. In the ValueSets, I have many to choose from, but I chose to use the ValueSets that are derived from the existing LEAP SLS Reference Implementation. This is an early open-source and suffers from having the codes hard-coded into the source code.

So I have the data from the use-case, and it is "in theory" already properly tagged. Turns out, that tagging had some errors. I had ValueSets, but they needed to be rearranged and have topic indications. It is this topic indication that is key. These ValueSets are specific to a kind of sensitive data. That is to say the definition of what is composed in the ValueSet is a bunch of clinical codes or hierarchy of codes. The ValueSet then needs to be identified with the Sensitive code that it represents. That is to say that ValueSet (A) has a topic of "BH" (in the hl7 vocabulary this is behavioral health), and composed in the valueSet is behavioral health indicating codes from loinc, snomed, icd, etc.

Testing these ValueSets and data Bundles did find a few more bugs, and a few more features to add. I do have even bigger ValueSets and data to try, derived from S

I'm not going to go deeper here, as this is available as Open-Source, and there is an Implementation Guide with the defined FHIR Operations.

Conclusion

Next up is to see if my kids can break this. Another reason to not further explain it here, as any fixes I make will show up on the github.

I will note that my household is odd. My kids hate AI, with a passion. I seem to be doing okay with it. One would expect that the old-man would be the one with an aversion to AI. I am very suspicious, I have seen it really mess up, and I have seen the movies enough to worry about what it might do. But I choose to work with it in order to make it better at helping humans.

Sustaining the Work That Sustains Trust: Why I’m Seeking Support for Some of My Standards Efforts

noreply@blogger.com (John Moehrke) — Wed, 21 Jan 2026 21:17:00 +0000

For many years, I’ve used this blog to explore the intersection of healthcare, privacy, and interoperability. Much of my professional life has been dedicated to helping the industry build systems that respect patient autonomy, protect sensitive information, and communicate clearly across organizational and technical boundaries.

Recently, I launched Moehrke Research, my independent consulting practice. It’s still early in its development, but it reflects the same principles that have guided my work for decades: clarity, transparency, and a commitment to practical, implementable standards. As I grow this business, I’m also continuing to invest deeply in common-goods efforts that advance the broader ecosystem.

Right now, that includes two areas that are both urgent and foundational:

AI transparency in healthcare, through my pro bono work on the HL7 AI Transparency Implementation Guide
Privacy‑sensitive data handling, through contributions to the SHIFT Task Force and the HL7 Sensitivity IG (a specialization of HL7 DS4P)

These efforts are essential to the future of trustworthy digital health. They also require a significant investment of time—time that I’ve been donating because I believe deeply in the work and in the communities that will benefit from it.

But the reality is that these projects have grown in scope and complexity. They now demand sustained, focused attention to ensure they mature into practical, implementable guidance that organizations can rely on. And that level of commitment is difficult to maintain without dedicated support.

Why This Work Matters

Healthcare is entering a period where AI‑generated content, automated decision support, and increasingly granular privacy expectations are no longer theoretical. They are here, influencing care, shaping patient experiences, and challenging long‑standing assumptions about data governance.

The AI Transparency IG aims to give implementers a clear, standards‑based way to document how AI systems contribute to clinical information—what models were used, what data informed them, how confident they were, and what human oversight was involved. This is not just a technical exercise; it’s a trust exercise.

This IG just completed an HL7 ballot with over 100 comments. Very good and constructive comments. There is so much work yet to be done to make this IG better and more clear.

Sensitive health topics are improving thru, the SHIFT Task Force and HL7 Sensitivity IG are tackling the nuanced, often fragmented world of privacy‑sensitive data. From reproductive health to behavioral health to social determinants, organizations need consistent, interoperable ways to tag, segment, and protect information that carries heightened risk.

We are looking for a way to better and more clearly manage valueSets that can inform real-world use of data sensitivity tagging. This was once started by SAMHSA, but that effort has languished for 10+ years. The community need a more sustainable and actionable methodology.

These are not optional capabilities. They are becoming regulatory expectations, ethical imperatives, and operational necessities.

Why I’m Asking for Support

I’ve always believed in contributing to the standards community. It’s where some of the most important work in healthcare happens. I have benefitted from past employers that allowed me to work on these Privacy and Authenticity topics. But the volume and depth of the current projects have reached a point where continuing entirely as pro bono work is no longer sustainable.

As I work to establish Moehrke Research, I also want to ensure that my contributions to these critical standards efforts remain strong and consistent. Funding would allow me to:

Dedicate focused time to advancing the AI Transparency IG
Support the SHIFT Task Force with detailed modeling, examples, and implementation guidance
Strengthen the HL7 Sensitivity IG with real‑world, policy‑grounded segmentation patterns
Produce documentation, diagrams, and educational materials that help implementers adopt these standards correctly
Continue writing openly about these topics so the broader community benefits

In short, support would ensure that this work moves forward with the rigor, clarity, and speed it deserves.

How Organizations Can Help

If your organization depends on trustworthy AI, interoperable privacy controls, or clear guidance on handling sensitive health information, I invite you to consider sponsoring this work. Support can take many forms—direct funding, project‑based engagements, or contributions aligned with specific deliverables.

My goal is simple: to keep doing the work that helps the entire ecosystem function more safely and transparently. With your support, I can continue contributing at the level these efforts require.

If you’re interested in discussing sponsorship or collaboration, please reach out through MoehrkeResearch.com.

Tracking Patient Data Corrections

noreply@blogger.com (John Moehrke) — Wed, 07 Jan 2026 15:09:00 +0000

When data are corrected, especially when the Patient themselves reported that the data was wrong, there needs to be breadcrumbs left behind. Correction is a form of updating of data, but with the special need to indicate that previous data was in error. Some corrections result in the previous data being removed, while others result in the previous data being replaced with corrected data.

Therefore the needs to be a special indication of a correction Provenance, as distinct from a general update Provenance, with the following goals:

So that future uses understand the past might have seen different data
So that requests for data, especially from outside (e.g. HIE), can see that previous data has been corrected.

The recipient can then find if they have a copy or used the previous data, and take appropriate action.

I have this documented in an IG that has both FHIR R4 and R6 details

- ci-build for FHIR R4 - http://build.fhir.org/ig/JohnMoehrke/correction/branches/main/index.html

- ci-build for FHIR R6 - https://build.fhir.org/ig/JohnMoehrke/correction/branches/R6/index.html

Use-cases

A patient contacts their provider to report that there is some data that is incorrect. An investigation is done, and the data are found to be in error. The data is corrected, and a Provenance resource is created to indicate the correction.
- One possibility for this workflow is the HL7 FHIR Patient Requested Correction
A Quality Improvement process finds that some data is incorrect. An investigation is done, and the data are found to be in error. The data is corrected, and a Provenance resource is created to indicate the correction.
- One possibility for this detection is an AI system that reviews data and finds potential errors.

Profiling

Recommended use of a Profile on Provenance to indicate corrections:

activity.coding: will be code FIXDATA from v3-ActReason to indicate that this Provenance is for a data correction.
reason.coding: can use a set of codes often associated with a correction.
recorded: will be the time the correction was made.
target: points at the resource(s) that are corrected.
agent: indicates who made the correction.
- the Patient would be indicated here for corrections requested by the patient.
entity: indicates the records corrected.
- entity.role=#removal points at the record being replaced or removed (if applicable).
- entity.role=#revision points at the record being revised (if applicable).
textual reason can be in why in R6, or in activity.text in R4/R5.
evidence such as the request for the correction can be in basedOn in R6, or in entity with role=#derivation in R4/R5.

Examples:

Provenance removal resource documenting the removal of incorrect food allergy observation. This example does not point at a resource that explains the correction, such as a DocumentReference.
Provenance replacement Provenance resource documenting the replacement of an immunization record that was in error. This example includes a reference to a DocumentReference that explains the correction.
Provenance AI corrected Provenance resource documenting the detection of an error in FHIR data by an AI system. The original Observation that is error is removed, and a new AllergyIntolerance resource is created to replace it.
Provenance AI corrected with replacement Provenance resource documenting the detection of an error in FHIR data by an AI system, where the Observation was used to record a food allergy, but the AI system detected that this should have been an AllergyIntolerance resource instead. Thus the Observation is removed, and the AllergyIntolerance is created.
Provenance patient correction Provenance resource documenting a patient requested correction of their birth date.
Provenance revision correction Provenance resource documenting the revision of a Condition resource with corrected onset date. In this case the original Condition is revised. Thus the old version history/1 is indicated as revised, and the new version history/2 is indicated as the current version.

changes from R4->R6 Provenance:

In R6 basedOn would be used to hold the evidence for the correction. Where in R4 would use entity with role=derivation, and in R5 with role=instantiates.
In R6 patient element exists. Same in R6. R4 didn't have patient, so other methods would be needed to find all Provenance pointing at a patient's data.
In R6 why exists. This does not exist in R4 or R5. Sometimes the activity.text would be used for this.
In R6 and R5 authorization is a codeableReference, where in R5 reason is used to hold the PurposeOfUse

Discovering Corrections

To find all corrections for a specific patient, one can search for Provenance resources with Provenance.activity with the FIXDATA code, and where the Provenance points at resources related to the patient.

FHIR R5 and R6

In FHIR R5 and R6 there is a patient element on Provenance, making it easy to find all Provenance resources related to a specific patient. One needs to simply filter on Provenance.activity with the FIXDATA code.

GET [base]/Provenance?patient=[patient-id]&activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA

FHIR R4

In FHIR R4 one needs to search for Provenance resources that point at resources related to the patient. This can be done by searching for Provenance with Provenance.activity with FIXDATA and where the target or entity.what points at resources related to the patient. Since either target or entity.what may point at resources that contain a patient reference, these cannot be combined in a single standard FHIR search query. Both chained searches must be performed and results combined client-side to find all relevant Provenance resources:

GET [base]/Provenance?activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA&target.patient=[patient-id]
GET [base]/Provenance?activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA&entity.what.patient=[patient-id]

Proposed FHIR Document section

I could not find an existing FHIR Document section that covers this topic. For example, in an International Patient Summary (IPS) this could be an additional section. In this way as new Cross-Community requests are made corrections would be communicated. This section contains information about corrections made to the patient's data, including details of the original data, the corrected data, and the reason for the correction. This information is provided to ensure data integrity and transparency in the patient's health record. I propose a new section:

Section code: http://loinc.org#77472-9 (Information integrity attribute)
Section title: Corrections to Data
Section text: Text summary of the corrections made.
Section entries: Provenance resources documenting corrections made to the patient's data following the correction Profile on Provenance.

Note that loinc code 77472-9 is "Information integrity attribute", which seems appropriate for this section. I am open to other code suggestions.

Conclusion

This is just my view on this use-case. I expect there is experience that might help refine. Please let me know

FHIR Consent backed by XACML enforcement

noreply@blogger.com (John Moehrke) — Sun, 28 Dec 2025 23:32:00 +0000

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

noreply@blogger.com (John Moehrke) — Fri, 12 Dec 2025 13:29:00 +0000

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.

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

Detailed Steps

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

noreply@blogger.com (John Moehrke) — Wed, 10 Dec 2025 23:06:00 +0000

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. \

when the AI is trained on a dataset,
when the AI is used to make treatment decisions (e.g. on a given Patient),
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

noreply@blogger.com (John Moehrke) — Wed, 10 Dec 2025 14:34:00 +0000

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

noreply@blogger.com (John Moehrke) — Mon, 20 Oct 2025 21:56:00 +0000

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.

Modern view on Pseudonymization

noreply@blogger.com (John Moehrke) — Mon, 13 Oct 2025 21:50:00 +0000

For years, the terms 'anonymization' and 'pseudonymization' described distinct technical methods for de-identifying data. But if you're still thinking of them that way, you might be behind the times. Driven by regulations like GDPR and court decisions, the focus has shifted from pseudonymization as the method to pseudonymized is the dataset itself. Key is who possesses the re-identification method. This subtle change has profound implications.

Ten years ago, I worked on the De-Identification Handbook with IHE and also on the Health Informatics Pseudonymization standard within ISO at that time the concept of de-identification was broken down into two kinds there was "anonymization" and there was "pseudonymization".

Where anonymization had no way to reverse and pseudonymization had some mechanism for reversing the pseudonymization. At the time these were seen as methods not as the resulting dataset. These methods would be used to identify how data would be De-Identified. The resulting dataset would then be analyzed for its risk to re-identification. That risk would be inclusive of risks relative to the pseudonymization methodology.

Today IHE is working on updating the De-Identification handbook. I'm no longer working on that project due to my employment situation. But while I was working on it before then the other subject matter experts were insisting on a very different meaning behind the words "pseudonymization" and "anonymization".

The following podcast by Ulrich Baumgartner really opened my eyes to how these words got a different meaning. They got a different meaning because they are used in a different contextual way. Whereas before the words were used purely as explanations of methodologies, they are today more dominantly used as words to describe a dataset that has either been pseudonymization or fully anonymized.

[The Privacy Advisor Podcast] Personal data defined? Ulrich Baumgartner on the implications of the CJEU's SRB ruling #thePrivacyAdvisorPodcast https://podcastaddict.com/the-privacy-advisor-podcast/episode/208363881

Where today because of GDPR there is a bigger focus on the dataset than the methodology. GDPR sees "pseudonymization" as a word describing the dataset that has only been pseudonymized but is still in the hands of the organization that possesses the methodology to re-identify. This is contextual. Therefore, the contextual understanding of that dataset is that it is contextually in the hands of an organization that has the ability to undo the pseudonymization. Therefore, the data are NOT de-identified. The data becomes de-identified when the pseudonymization re-identification mechanism is broken, that is to say when the dataset is passed to another party while the re-identification mechanism is NOT passed to that party.

This is the key point that is adding clarity to me. To me, the organization that is using pseudonymization is preparing a dataset to give to someone else; the first party organization already has the fully identified data, thus the pseudonymized data is not something they intend to operate on. It is the NEXT party, the data processor, that gets the dataset and does NOT get the re-identification mechanism. It is this NEXT party that now has de-identified data.

I now do understand the new diagram, as there was a diagram that was drawing distinction between Identified data, and Anonymized data; with the transition of data from Fully-Identified->Pseudonymized->Anonymized. I saw this diagram, and it did not align with the original methodology perspective, but it does follow with this contextual/relative perspective.

Overall, this understanding is consistent with the original "methodology" meaning of the words, but for some reason the GDPR courts needed to say it out loud that the FIRST organization doesn't get the benefit of de-identification until they pass the data to the NEXT organization. This concept is why

There are some arguments within the GDPR community as to whether it is ever possible to make anonymous data out of pseudonymous data. This because there is SOME organization that does have access to the re-identification mechanism. As long as someone has that ability, then some courts see the data as potentially re-identifiable. That conclusion is not wrong on the blunt fact, but it does not recognize the controls in place to prevent inappropriate use of the re-identification mechanism. The current courts do see that there is a perception of a pathway from pseudonymization to anonymization.

Pseudonymization is more like Encryption than Anonymization

The interesting emphasis at this point is that within Europe under GDPR pseudonymization of a data-set is much like an encryption of a data-set. Both encryption and pseudonymization are seen as purely methodologies of protecting data, neither are a clear methodology to gain anonymization.

Conclusion

GDPR has placed a different emphasis on pseudonymization with the default meaning is where the data holder has used pseudonymization methods but still holds the re-identification key. This state of the data transition was never mentioned in the past, as ultimately the goal of pseudonymization is to produce a dataset that could be passed to another organization who does NOT get the re-identification keys. Whereas in the past we would have said that the other organization got a pseudonymized dataset without ability to re-identify; GDPR would now say that the other organization got an anonymized dataset.

How are complex trust networks handled in http/REST/OAuth.

noreply@blogger.com (John Moehrke) — Fri, 10 Oct 2025 14:26:00 +0000

> How are http/REST authorized in complex trust networks handled?

I don't have all the answers. This has not been worked out. I am not holding back "the" answer just waiting for someone to ask.

Whereas in XCA today we use a network of trust (saml signers certificate authorities, and tls certificate authorities), and the network communication also goes through "trusted intermediaries".

In OAuth there are no "Trusted intermediaries". The search parameters and responses are always point to point between the one requesting and the one responding. The OAuth token used in that point-to-point request/response has been the hard thing to create. Where OAuth has a mechanism to "discover" who that responding service trusts. This is advertised as well-known metadata at that responding service endpoint. So, the Requester queries that well-known metadata, and from that data it then needs to figure out a trust arrangement between the requesting OAuth authorities and that responding trusted OAuth issuers.

A. Where no trusted third party is needed

The majority case that is used very often today is that the well-known OAuth metadata can be directly used by the client. Client asks that OAuth authority to create a new token, given the requester token, for authorization to access the responder system.

THIS is what everyone is doing today with client/server FHIR RESTful. This is what everyone looks to get their system to work with OAuth

The token has some lifetime and scope; and is used for multiple request/response. Again, this is normal. and this fact is normal for all uses of OAuth.

B. Where a trusted third party is needed

The case where the requester does not have a trust relationship with that responder defined OAuth authority is where the hard work comes in. In our use-cases where the requester and responder are in different communities. Like with XCA some trust authority is needed. Like with XCA discovering who that trust authority is the job of directory services.

Ultimately the requesting system finds a trusted OAuth issuer, and it asks for a new token, given the requesting system token, be generated targeting the responding system. Once this token is issued then the requester can do http/REST/FHIR direct to the responding service endpoint using the internet for routing, with that last OAuth token. The responding system can test that OAuth token is valid.

In the healthcare scenario we might want to force an unusual nesting of prior tokens. In this way the responding service can record who/why and from where the request came from. This nesting is not typical and considered complex to implement and parse.

see: OAuth 2.0 Token Exchange (RFC 8698)

C. Where multiple trusted third parties are needed

I think that the (B) solution can be iterated or recursed on infinitely.

SO:

The main point of OAuth is that you get a new OAuth token issued for a given target/scope based on the OAuth token that you have. EACH OAuth authority makes a permit or deny decision; hence why an issued OAuth token is always a statement of authorization. If you were not authorized, you would not be issued a token.

In this way the authorization is established up-front; and the data transactions reuse that token until it expires. Thus, the up-front authorization may be expensive, but that token is reused 1000 times in the 60 seconds it is good for (simplified for illustration sake)

Caveat Emptor

I have no idea if the above is right. I think it is close, but I don't know.

I welcome commentors to correct me, especially if they can point at standards profiles that have been established. Especially if these standards profiles are established in general IT, not specific to healthcare. I am suspicious of healthcare experts who invent healthcare specific standards profiles.

FHIR RLS - Record Location Service

noreply@blogger.com (John Moehrke) — Mon, 29 Sep 2025 14:01:00 +0000

I was asked

> Does an IG for such a thing exist (FHIR RLS)? I was wondering if IHE did this? Part of MHD?

Not fully. IHE has PDQm, which has most of what is needed, but no one has brought federation to IHE to solve. PDQm supports a FHIR way to do Patient Identity resolution. It supports a few models

Demographics to identity
Identifier to identity
Fuzzy match to identity
Search to identity

The result is one of more Patient Identity. Some of them might be already correlated to the same individual, some may be alternatives. This is common support for a RLS.

What is missing is an indication of the community that the given identity exists within. When using MHD the assumption is that your MHD Document Responder can figure this out on the backend. This the PDQm + MHD client doesn't need to know. This gap is being discussed now.

The second thing that is missing is some mechanism for the PDQm server to seek out partners that might have identity matches. This mechanism is not defined today in IHE XCPD, so might not need to be said for FHIR. I expect some may want that.

The third thing, that is needed, is a way to translate a community identifier to network communication mechanism. This is available in mCSD. This mechanism can work like it would for XCA, listing XCA gateways; or could be more Internet based simply listing FHIR endpoints.

There is a very good white paper from Grahame in HL7 on Intermediaries. This multiple levels of services is a vision like what IHE has with XCPD+XCA, but for full access to FHIR services. There are some solutions proposed, but no further solution defined. HL7 didn't want to work on it as it is not core, so plan was to have IHE work on it with backing from HL7. The problem is that although the problem was presented to IHE IT-Infrastructure, not enough interest in working on it came forward. Thus, a gridlock.

These struggles, there is XCPD, which is not FHIR, but would work to find identity at community, lookup in mCSD to find, the FHIR servers.

The fall of the Profile

noreply@blogger.com (John Moehrke) — Mon, 22 Sep 2025 21:09:00 +0000

FireLy has looked at #FHIR use, and came to the conclusion "Too many profiles, not enough reuse...". I agree and find this trend very troubling.

IHE started the concept of Profiling 25 years ago. An joint effort of Vendors and Users. The Users would collaborate on use-case based needs, needs fully focused on outcomes and overcoming problems. The Users tempted the Vendors with a promise to "buy" if the Vendors agreed to One solution. Economics drove this to succeed.

Lately neither of these parties are leading, rather it is Governments and Consultants (yes I am now a consultant). This not only doesn't have the right Market forces, but is not done globally. with no global focus the solutions are regional.. all different.

AI use Transparency in Healthcare: Building Trust Through Provenance

noreply@blogger.com (John Moehrke) — Thu, 18 Sep 2025 18:40:00 +0000

I want to bring some additional visibility to a project I am involved in regarding AI transparency in Healthcare. The goal of Transparency is to be able to indicate when data in the Medical Record has been influenced by AI, this is an important goal to providing Integrity of the use of AI.

The Challenge: A Spectrum of AI Influence

The goal of our project is to indicate the level of AI influence on medical data. This isn't a simple "yes or no" question, but a spectrum that includes:

AI-authored data: The data was created entirely by an AI.
AI-recommended data: An AI suggested the data, and a human approved it.
AI-assisted data: An AI helped a human in some way, but the human was the primary author.

To address this, we're using two key approaches: data tagging and provenance.

Data Tagging

With data tagging, this is simply a tag of the kind of interaction that the AI had with a data object. So it is not useful to explain the details of the interaction beyond a generalizable kind of interaction. This tag is however helpful as a flag for those who want to know when data was influenced.

One use of a simple tag is to recognize that the object may be not original thinking. There might be recognition that data that has been influenced by AI might not be as useful to train future models. The tag might also be used simply to know that there is more details in a Provenance.

Provenance

With Provenance we can carry details about what AI, what version, what model, what prompt, what card, etc. The FHIR Provenance is a derivative of W3C PROV, reformed to the data encoding standard that HL7 has based on RESTful Resources.

We are trying to reuse more general AI standards such as model-card, but find that there is a lack of consensus. I am confident that the HL7 group will use external standards as appropriate.

One might need to know this level of detail to understand the usefulness of the output. One might also use this Provenance to track down AI influence that may have been determined to be suspect or incorrect. This might find decisions that need to be reevaluated.

Element level, not just Resource level

Both data tagging and Provenance have methods of focus on the element level, rather than the whole Resource. For some resources the whole resource is all that is needed to be tagged or referenced, but for some more workflow specific Resources like CarePlan, there are some data within that might be influenced while the whole is not. So, this element level is supported by both Data Tagging and Provenance solutions.

Concerns with Provenance model

A concern I heard was voiced at the connectathon this weekend is that Provenance is hard to work with. I think this is just an educational issue. Provenance is different in that Provenance.target points at the resources for which it is describing the provenance of; and thus the targeted resource does not contain some evidence of the Provenance. There are a few solutions to this:

Use the Data Tag to indicate that the data was influenced by AI, and this gives evidence that searching for Provenance might be useful. When the AI tag is found, one just searches for Provenance with a target equal to the resource you have.
Put the Provenance inside the Resource. FHIR supports a concept of a Resource "containing" another resource. This is used when the contained resource can't stand alone, but can also be used where the outer Resource really wants to carry the inner Resource
Searching for resources, one can use the "_revinclude" parameter to also include any Provenance. Indeed, _revinclude is defined for anything, but the example given is Provenance.

Developing Implementation Guide

The HL7 implementation guide is in development so I don't, yet, have a formal publication to point at. The CI build is -- https://build.fhir.org/ig/HL7/aitransparency-ig/branches/main/index.html

All of the above discussion is already included in this Implementation Guide.

I have other blog articles on AI controls

Learning Dataset Provenance

Wearing a different hat, I was a standards expert contract with Data and Trust Alliance to help them define a Provenance standard for the datasets that are offered to be used as source-learning material. https://dataandtrustalliance.org/work/data-provenance-standards

Conclusion

These are developing, so please get involved to help us address your use-case and learn from your experience.

Approach to Product use of Standards

noreply@blogger.com (John Moehrke) — Mon, 08 Sep 2025 12:32:00 +0000

I have expressed a role for me as a standards expert to participate with product development to assure good implementation. This would focus on quality implementation, that is robust, and can then stand the test of time. However, I really don't think that this is a standalone role, but rather a role that someone on the product team plays. Likely a systems architect, maybe the db architect.

Now that I have started my consulting organization, Moehrke Research LLC, I have been approached by people trying to get me to take on this kind of a full-time role. The role is rather consistently defined and defined in a very standalone way with what I think is unreasonable expectations. The Job description includes many years of standards work, many years of product development, many years of healthcare market knowledge, etc. Job titles like:

FHIR (Fast Healthcare Interoperability Resources) Architect
Lead Data Modeler (FHIR)
FHIR Interoperability Specialist
Senior IT Solutions Architect
Healthcare Solution Architect

I fit these expectations, but I really don't think that what you need is full-time position. I think that it is a great medium sized engagement with me.

I recommend Build from within

Where someone (or two) from the product team get elevated. Yes, it is an additional role and thus a change in their role. I assure you paying them a bit more to take on this role will be worth it. You need to include a test engineer as well. I work with them 2-3 days a week for a few months, then a few days a month for a few more months, and then a few hours per month for a few more months. Overall, this likely takes 6-9 months. I teach them how to:

discover appropriate standards,
approaches to reading standards,
extracting the requirements and alternatives,
where to find help,
where to find open-source,
where to find test tools and procedures,
how to leverage Postel's Law,
how to engage in improving the standard,
how to dispute interpretations of the standard,
where to get creative and
where to be strict.

With an engagement like I am proposing, I am providing this guidance over 600-1000 hours; and you walk away with the skills on the team. This is a bargain relative to a full-time position for 6 months. We all have a personal relationship that can handle occasional contact or result in future contract engagements.

More sustainable

The roles that are posted are not possible to be met except by a few dozen people globally. The expectation of number of years of experience, depth of knowledge, and unusual education. There is simply not that many people doing what I have done over the past 25 years. It is very small group (I would like to see it expand).

Interoperability is not something to build a product around, it is something to build a product on-top-of. Meaning it is not the inspiration for something that doesn't exist. The standard was written because many have needed something like what the standard has defined.

There are HL7 training certifications that can help, but I see these also as something that someone already on your team adds to their job roles.

Conclusion

Similar is true of the other topic areas I have skills in: Privacy and Security... these are a role, but not necessarily a full-time position. These are all more a culture thing, with a role to watch that the culture is followed.

In very large organizations like Oracle Health, Epic, GE Healthcare, etc... these can be full-time roles; but even there are constant struggles with justifying standalone positions. Even in these large organizations the sustainable position is a role that team members take on.

Build your team from within. I provide subject matter expertise, but your team is key. We all walk away happy and with better Interoperability.

Product use of Standards

noreply@blogger.com (John Moehrke) — Tue, 02 Sep 2025 18:22:00 +0000

The third kind of contract I’m well-suited for involves working directly with product developers—whether client or server-side—to ensure their solutions optimally leverage existing standards. This role is often overlooked in traditional standards development but is critical for real-world adoption. While it may seem like a large engagement, it often resembles a small contracts, focused contract. I’ll explore that nuance more in the next blog post.

Government Mandated Standards

A product can be compelled to be compliant with a standard or Implementation Guide (IG). This is common nowadays around the globe with regulation requiring that products and the organizations that use them be compliant with a given standard or IGs. These government efforts are trying to move their realm beyond some point, with the goal of having a better outcome after the standards are deployed.

A good example of how a government required standard can dramatically improve that realm that government controls is electric socket, light socket, or lately USB-C. In these cases, without standardization there were many alternatives that the consumer must be burdened with. By mandating a standard, the products all align on that standard, the consumers don't need to think about that anymore.

Purchase Power

A product may choose to implement a standard because market pressures (customers) demand it. In this case it is the power of the purchase ($$$) that forces the use of a standard. An important perspective here is where the first vendor works with the purchaser to define that which all later must implement. In the case of early Health Information Exchanges, and Radiology Exchanges; this was the dominant method for standards to become required. That is to say those purchasing products demanded that a given IHE-Profile must be used, and that drove mandates. This was the success story for IHE, in that it was a collaboration between those with purchase power in the radiology departments that wanted ONE standard to mandate, and the vendors that knew that one standard would be less overall work. Unfortunately, this story has been lost to time

Implement Once, Innovate Beyond

The overall benefit to using standards that those developing products that need that standard can now be assured that their efforts to use the standard will be reusable over and over; thus, that product development group can focus more on the features and value of the product. A good standard is one that one can implement once and not spend more time on (realistically it takes some maturing to get here). The point is that by using a standard one does not need to constantly adjust how one communicates with peers.

This use of standards overall benefits everyone.

What help do you need?

The fact that a regulation picks a standard or IG does not mean that developing a product to that standard is easy. The standard might not be all that easy to read, most standards are hard to read. The needs that the product have might not be expressed in the standard, so some interpolation needs to be done. There are often things that are needed to be implemented that the standard doesn't mention, most of the time it is in an area where the standard wants to be lenient, so one must understand a range of possibilities.

Postel's Law

When I work with your team, I will stress multiple times a day a principle that is credited for the success of the TCP/IP internet. Often called Postel's Law. It has two very different things to say. To those about to send some content to another, be as compliant as you possibly can be. To those receiving some content from another, be very robust and lenient in how you interpret that content. Many people have a problem with this second part as they feel that receivers should be strict, rejecting anything that is not compliant. The problem with this is that it is very fragile and doesn't recognize reality. Reality that often comes along with revisions of the standard over time.

Conclusion

Let me be your thoughtful, experienced guide in the often murky world of standards implementation.

Standards Development Contracts

noreply@blogger.com (John Moehrke) — Thu, 21 Aug 2025 13:30:00 +0000

The medium sized contracts that I envision would be where I help an organization develop a standard or defend their position within a standard development project. Where a "standard development" effort is not limited to core standards like FHIR, CDA, or HL7; but inclusive of international Implementation Guides (what IHE calls a Profile, or HL7 calls accelerators), or regional Implementation Guides.

I have even used the Implementation Guide tooling to produce a private publication (for the VA - MyHealtheVet) that defines how existing data would map to FHIR Resources and be aligned with us-core. I use this tooling in my own experiments as it is a quick way to get a publication that is easy to author and edit over time.

Leading a standard project takes a good bit of negotiations and consensus building. These are skills that I have been working over the past 25 years (actually more, as I also did this in the internet standards world in the 80s and 90s with TCP/IP, NFS, Telnet, FTP, and a few others that many people today don't remember are foundations of the internet.)

Defending an organizations position is similar but very different. It involves discovering the potential problems and crafting a solution that the author and contributors find as understandable and worthy of addressing. Sometimes this effort is simply helping by providing examples of good and bad outcomes; such as working examples.

Along with this is providing tooling to support internal testing, simulation, and demonstration.

Developing Standards is the best way to develop a market for your product to further enhance. Standards are not a threat to a product unless that product is not truly adding value. By defining standards, one moves the opportunity for improvement up into the application layer.

Organizations, which might be provider or payer organizations, or might be regional organizations, often need to refine a standard to make it more clear for their region, and thus make testing and dispute resolution more effective.

I am well-seasoned to be able to help you with this effort. These projects might be medium, but they might also be small or large. The size is more defined by the outcome needed. Contact me at Moehrke Research.

Small contracts are also encouraged

Small contracts

noreply@blogger.com (John Moehrke) — Tue, 19 Aug 2025 19:35:00 +0000

Over the past few years, I have taken on small contracts. These would be a few hours and be focused on delivering a training session or two. These were never big enough projects for my employer at the time, so they allowed me to take these on "the side". I would tend to work these in the evenings and weekends so as to not interfere with my day job at the time.

Now that I am looking for contracts, these small contracts are something I am looking forward to. There is not much fuss in getting them going, and they are a great way for me to interact with groups of people just getting going in Interoperability or Healthcare Informatics.

Training in Healthcare Privacy and Security

The subject matter that I am known for is teaching FHIR Privacy and Security topics. I have presented a HL7 Tutorial on "FHIR Privacy and Security" many times. I am not limited to giving this tutorial at HL7. HL7 has a recording from a few years ago that is freely available through HL7 sponsored by ONC (now ASTP). If you just want to listen to the recording, then the HL7 recorded tutorial is good enough. But if you have specific use-case that you want me to focus on and have discussion, design, and policy writing; then this might be a good small contract to start with me.

I can also handle going deeper on each of the topics within the tutorial. I have had to make the 3-hour tutorial very high level. Which is a good level for many people, but does not satisfy someone who is focusing on a given topic:

Access Control - considering Privacy Consent
Access Control - considering Break-Glass
Audit Logging - to detect intrusion and investigate
Audit Logging - to inform an Accounting of Disclosures or Access Log to a Patient
Digital Signatures
Document Encryption
Consent encoding in FHIR and management over time
Data Sensitivity Tagging methodologies and architectures
De-Identification / Pseudonymization / Anonymization
Provenance

Training in Healthcare Infrastructure -- Implementation Guides

IHE IT Infrastructure Profiles

XDS / XCA / XCPD -- Document Sharing
MHD / MHDS / PDQm / PMIR
mXDE -- decomposing Documents into FHIR Resources with Provenance
Basic Audit Log Patterns (BALP)
Privacy Consent on FHIR (PCF)
Digital Signatures (DSG)

FHIR International Patient Summary (IPS)
FHIR International Patient Access (IPA)
FHIR Data Segmentation for Privacy (DS4P)
FHIR Consent
FHIR AuditEvent
FHIR Provenance
FHIR Signature

Contact me at Moehrke Research.

What's next for me?

noreply@blogger.com (John Moehrke) — Tue, 22 Jul 2025 15:01:00 +0000

It has been a relaxing week, but I am still interested in opportunities for me. I have had a handful of phone calls. I hear that my name is mentioned positively in many conversations, that I am not involved in. LinkedIn tells me that my announcement has been seen 11,000 times, my blog article only 104. So, you can understand that I am getting really dramatically mixed messages.

What I'm looking for

I have put together a Resume, and doing that did solidify my interests in

Standards development (FHIR)
Profile development (Implementation Guides)
Use of Profiles and Standards (Apps and Infrastructure that use standards)

I don't like doing the administrative things that a consultant needs to do, like finding new work, billing, following up on billing. I did this a few times over the last few years, and it is outright drudgery. I also don't want to move into a corporate position, like a director of blah, or senior so-and-so. Learning a new corporate process is not inviting, I did that three times already.

I know that I am close to retirement, I can feel the beach sand beneath my feet. Thus, I understand that whatever I do needs to make this transparently clear. And I recognize that might limit my opportunities. I am okay with that.

Ongoing Contributions

I will continue my work in HL7 and SHIFT:

SHIFT on their work to make Consent more implemented. I have been providing subject matter expertise in FHIR Consent and the IHE Privacy Consent on FHIR (PCF) implementation guide. Right now, the team is working on implementing, so I don't have much to contribute. I would like to be involved in code reviews. I am also providing expertise in the discussion with various stakeholders and implementers.
HL7 on their work with FAST Consent, which is taking an administrative step beyond IHE-PCF to define policies and management steps for instances of Consent. This work can only be done in a regional context where regional policies can limit the variability. So, context is critical here. Having reviewed many regional policies and applied them to the development of FHIR Consent, I have a pragmatic and realistic perspective to provide.
HL7 on AI Transparency IG, which is using features we built into FHIR for tagging data that was contributed by AI and providing details of that AI actions in Provenance. I have applied these concepts to IHE profiles and Data Trust Alliance, and other side projects. The power of Provenance is best shown with use-case analysis and examples.

I will continue with these, even if only Pro Bono. I certainly hope that I have other opportunities that I could contribute to. I think I still have plenty of energy and expertise to be applied to Healthcare Interoperability Standards development and promulgation.

Monday Morning, nowhere to report

noreply@blogger.com (John Moehrke) — Mon, 14 Jul 2025 13:26:00 +0000

This Monday morning started differently—I’m awake, ready to work, but with nowhere to report.

After nearly nine years at ByLight, my journey there has abruptly ended. ByLight had taken me on as a standards representative back in November of 2016. I have worked on multiple CDA, XDS, and FHIR-based projects ever since. Most recently, I was helping modernize MyHealtheVet—the VA’s patient portal where Veterans securely access their medical records, message their care teams, and manage prescriptions. Our team was about halfway through a FHIR transition and updating the web interface, with Oracle Health (Cerner) integration just beginning to support the VA’s evolving EHR ecosystem.

But the contract was unexpectedly not renewed. We were all let go, and I imagine many of my colleagues are now, like me, seeking what comes next. ByLight fought hard to continue the work, but I don’t know what led to the decision or what the future holds for the portal itself.

What now?

I had expected to retire somewhere in the next 2–5 years, with time to prepare and transition. That plan changed overnight.

Today, I was supposed to co-chair the IHE IT Infrastructure Technical Committee’s face-to-face meeting. Instead, I had to inform my co-chairs and peers that I’m no longer employed and no longer have standing within IHE. Others had scheduling challenges too, so we opted to postpone and shift to our regular t-con development calls instead. IHE will also need to redistribute the roles I held—GitHub administration, IG publishing, and more.

I’ve also informed HL7, and they’ve revoked my authority. I recall from before that HL7 has a method to extend membership continuity, but I haven’t heard whether that will apply to my case.

What's next?

While I had begun thinking about retirement, this came too soon. I’m now exploring consulting work—perhaps independently, perhaps through a contracting organization. I’m not interested in stepping into a dramatically different role or climbing further up the leadership ladder; when I look at what’s done “up there,” I don’t find much that sparks inspiration. It doesn’t feel like the right way to wind down. More likely that I use my FHIR Implementation Guide experience and skills to help projects and regions on their profiling.

I’ve seen other standards geeks continue consulting into their later years, which I’ve always viewed with mixed feelings. The world needs space for fresh leadership, and that’s hard to foster when the same people continue to occupy those positions.

So, here I am again—like I was in 2016—dusting off my resume and pondering the next chapter. I do have a few camping vacations scheduled from before all this, and I plan to take them. Maybe the timing will turn out to be fortuitous.

How to record that the Patient authored FHIR Resources or elements

noreply@blogger.com (John Moehrke) — Mon, 02 Jun 2025 19:14:00 +0000

Lately there has been more groups thinking about how Patient contributions to the medical record might be distinguished from clinician authored data. Also, how AI contributions could be recognized as distinct. This article will cover a couple of methods that exist in FHIR core, but also exist in CDA and HL7 v2. I will only speak about FHIR.

General need

The general need is to express the provenance of a Resource or an element within a Resource. For this we have two different solutions that are related, but distinct. Two solutions as sometimes one needs a lightweight solution, sometimes you need full powerful Provenance.

Security Tags
Provenance

As stated above sometimes you want to indicate the whole resource was authored by the Patient, sometimes you just want to indicate one or more elements within the resource was authored by the Patient.

E.g.

Patient record of body weights taken at home
Patient's partner indicated the Patients nickname
AI produced a CarePlan based on current labs and observations; relative to clinical care guidelines, and care plan definitions.
AI produced an Observation interpretation code value

Using Tags

All of the FHIR Resource have a meta.security coding element that has a valueSet binding that includes a set of provenance codes that include a set of codes for this usecase. The fact that these are indicated as .security tags does not mean they are exclusively only to be used for security purposes; and note that security is the domain of managing risks to (Confidentiality, Availability, and Integrity). Provenance comes under Integrity and a bit of Availability.

There are some that will see the .meta.tag. The temptation is strong (especially with those in the AI space); but this is not the right element. This is not wrong to use this element, but putting your code here will mean that those looking in meta.security will not find what they are looking for. So we should agree to use the meta.security and the given standardized codes (when they apply).

The ValueSet available for meta.security covers all of the security space including Availability and Integrity. Most important here are the Provenance sub valueSet, but you should also note that the Integrity valueSet has some very useful codes (highly reliable, reliable, uncertain, unreliable)

Within the Provenance sub valueSet are codes for the distinction of data being reported by or asserted by:

clinician
device
healthcare professional
patient acquaintance
patient
payer
professional
substitute decision maker
artificial intelligence
dictation (software)

I am not all that clear on what the distinction between reporting vs asserting is; nor do I understand the distinction between a clinician and a healthcare professional. I think these distinctions exist in the core codeSystem so that they can be further profiled and made distinct.

So, use these codes at the Resource.meta.security to indicate that the whole resource is contributed by one of those codes. Here is an example of how a whole Observation would be indicated as contributed by AI.

Using Tags at the element level

Where the FHIR Resource .meta.security with the code of patient would be understood as indicating that the whole of the resource was asserted to by the patient; often this is too blunt of a tag. Sometimes one just wants to indicate an element was contributed to differently. Like the example above where the patient acquaintance indicate their nickname. Thus one wants to tag that only that nickname was contributed by the patient acquaintance. For this we use the extension that is defined in the Data Segmentation for Privacy (DS4P), again pointing out that this IG is broader than just data segmentation and/or privacy.

So, here we show an example of a Patient resource where the nickname was contributed by the patient acquaintance. In this case we need to have the inline code at the Resource.meta.security level to indicate that inline codes are used in this Resource, as inline codes can appear on any element, thus it is expensive to look for inline codes.

{
"use": "nickname",
"given": [
"Jimmy"
],
"extension": [
{
"url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
"valueCoding": {
"code": "PACQAST",
"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"display": "patient acquaintance asserted"
}
}
]
}

Provenance Solution

The tagging solution, even with the element level capability, often can't convey enough information. Like who is this patient acquaintance, when was that element added, why was it added, who was involved in agreeing to add that to the record, where did that data come from, how was the original data used, etc... All those things that are part of Provenance ( Who, What, Where, When, and Why). Now recording all of this will make the database rather full of Provenance data, where as the tag mechanism is very focused and carried fully by the data. But sometimes one does need to know more provenance detail.

In the Provenance, these same codes from above can be used for the various Agent(s), but there are more nuance available in the participation type codeSystem. So a Provenance that indicates that the whole Observation was contributed by the Patient would look like this.

{
  "resourceType" : "Provenance",
  "id" : "example1",
  "target" : [{
    "reference" : "Observation/obs2/_history/1"
  }],
  "recorded" : "2021-12-07T12:23:45+11:00",
  "agent" : [{
    "type" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
        "code" : "INF"
      }]
    },
    "who" : {
      "reference" : "Patient/pat3"
    }
  }]
}

Provenance at the element level

Where as the Patient nickname example would look like (Note the use of the `targetElement` extension). There is also a `targetPath` extension where a path can be used.

{
  "resourceType" : "Provenance",
  "id" : "example2",
  "target" : [{
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/targetElement",
      "valueUri" : "n2"
    }],
    "reference" : "Patient/pat3/_history/1"
  }],
  "recorded" : "2021-12-08T16:54:24+11:00",
  "agent" : [{
    "type" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
        "code" : "INF"
      }]
    },
    "who" : {
      "reference" : "RelatedPerson/f001"
    }
  }]
}

You can, in Provenance.target, use the extension targetElement or targetPath to indicate that just some of the data within a Resource was patient contributed. See examples 1, 2, and 3 -- in Provenance examples - https://build.fhir.org/provenance-examples.html

Conclusion

The .meta.security and Provenance are not exclusively to be set or used by Security. These values might be populated by a Security Labeling Service (SLS), but that service should not overwrite values that have been explicitly set. Yes, they are used by Security, but security also uses many other elements in the resources that many think are only useful for clinical use.

Why the IHE Integration Statement is important

noreply@blogger.com (John Moehrke) — Thu, 22 May 2025 15:29:00 +0000

The current text on Integration Statement is not complete. I have found that many topics that I associate with an IHE Integration Statement are not well published by IHE.

However I have found that AI/LLM do understand the points. Here is output from Google Gemini that is similar to what I got from chatgpt and co-pilot. These points are that which I associate with an IHE Integration Statement, especially the second part about Product Labling.

References:
https://profiles.ihe.net/GeneralIntro/ch-F.html
https://www.ihe.net/about_ihe/faq/
https://infocentral.infoway-inforoute.ca/en/collaboration/communities-2/ihe
https://www.ihe-europe.net/about-us/faq
https://www.siemens-healthineers.com/en-us/services/it-standards/ihe-integrating-the-healthcare-enterprise
https://www.ihe.net/about_ihe/ihe_process/#:~:text=IHE%20tests%20vendors'%20systems%20at,and%20supervised%20events%20called%20Connectathons.

----------------------------

how do customers use an IHE Integration Statement published by a vendor?

----------------------------
Customers in healthcare organizations use an IHE Integration Statement published by a vendor as a crucial tool during the procurement, planning, and implementation of healthcare IT systems. These statements provide a standardized way for vendors to declare how their products conform to IHE Technical Frameworks.

Here's how customers typically use them:

System Selection and Procurement: When a healthcare organization is looking to purchase new IT systems (e.g., Electronic Health Records, Picture Archiving and Communication Systems, laboratory systems), they often require interoperability with their existing systems and with systems from other vendors. IHE Integration Statements allow them to quickly assess a product's declared interoperability capabilities. Customers can specify the required IHE Integration Profiles in their Requests for Proposals (RFPs), making it easier to compare offerings from different vendors and ensure that the chosen systems will "speak the same language" as other systems in their environment.
Integration Planning: Once a product is selected, the IHE Integration Statement helps the customer's IT team understand exactly which IHE Actors and Integration Profiles the product supports. This detailed information is vital for planning the integration of the new system into the existing IT infrastructure. It clarifies how data will be exchanged and what workflows can be supported, minimizing surprises during implementation.
Validation and Testing: While an IHE Integration Statement is a vendor's self-declaration, it serves as a baseline for validation. Customers can use it to guide their own testing process, verifying that the product indeed performs the integrated functions as stated. This helps ensure that the systems will work together as expected in a real-world clinical setting.
Troubleshooting and Support: In cases of interoperability issues, the IHE Integration Statement can be a valuable reference point for troubleshooting. It helps identify which specific IHE-defined transactions and profiles are expected to be supported by a product, aiding in pinpointing the source of any communication problems.

In essence, IHE Integration Statements empower customers to make informed decisions, reduce integration risks, and accelerate the deployment of interoperable healthcare IT solutions. They contribute to better patient care by facilitating the seamless flow of health information across different systems and departments.

------------------------------

is the IHE Integration Statement considered product labeling? Is that helpful to a customer?

------------------------------

Yes, an IHE Integration Statement is very much considered a form of product labeling in the healthcare IT context, and it is extremely helpful to a customer.

Here's why:

Formal Declaration of Interoperability: Unlike general marketing claims, an IHE Integration Statement is a formal, structured document published by the vendor. It explicitly states which IHE Integration Profiles, Actors, and Options their specific product version supports. This is a highly technical and precise declaration, akin to a "nutrition label" for interoperability.
Transparency and Trust: It provides a level of transparency that goes beyond typical product brochures. Customers can review these statements to understand the exact interoperability capabilities a vendor claims, fostering trust and enabling informed decision-making.
Standardized Language: IHE provides a common, internationally recognized language for interoperability. By stating support for specific IHE Profiles (e.g., XDS.b for document sharing, PDQ for patient demographics query), vendors and customers can speak the same "interoperability language," reducing ambiguity and misinterpretation.
Basis for Procurement and Contracts: Customers often include requirements for specific IHE Profiles in their Request for Proposals (RFPs) or contracts. The IHE Integration Statement serves as the vendor's official response to these requirements, allowing customers to hold vendors accountable for the declared interoperability.
Facilitates System Integration: For the customer's IT team, the detailed information in an Integration Statement is invaluable for planning and executing the integration of new systems with existing ones. It helps them understand the expected data flows, supported transactions, and potential integration points, reducing implementation time and costs.
Risk Mitigation: By clearly outlining supported interoperability features, these statements help customers mitigate risks associated with system integration failures. They provide a common ground for discussing and resolving interoperability challenges.
Connectathon Verification (Implied): While the Integration Statement is a vendor's self-declaration, it often follows successful participation in an IHE Connectathon, where vendors test their implementations with other vendors. While not a certification, this process adds a layer of confidence in the declared capabilities.

In summary, the IHE Integration Statement serves as essential product labeling that translates complex interoperability capabilities into a standardized, digestible format. It's a cornerstone for healthcare organizations seeking to build and maintain a truly integrated and efficient IT ecosystem.

------------------------------

I then add that as product labeling, the customer has legal standing to compel the vendor to adhere to the product labeling statements they have made. This is to say that if an interoperability statement does not work in the real-world, there is legal standing to force the vendor to fix it.

The AI/LLM did respond to that with nuance as reality is not as bold as I state, but it is very close.

Did something change in the IG I am using?

noreply@blogger.com (John Moehrke) — Fri, 07 Feb 2025 17:14:00 +0000

IHE and HL7 are writing and revising Implementation Guides at a fervent rate. There are other organizations also writing and revising Implementation Guide, some are regional IHE or HL7 organizations, and many more. Everyone that writes an Implementation Guide (IG) desires to create a perfect and fully comprehensive specification on the first try. However, that is simply not realistic, and any IG that has had only one version is most likely one that no one is using.

Two very important standards organization mechanisms are critical to the achieving a perfect IG.

Clear indications of the changes that were made and why.
Method for the users of the IG to submit comments and improvement requests.

How do you know what has changed?

Within IHE we try hard to produce a human friendly listing of the changes that have happened at each version. These would not include inconsequential changes such as typos. This likely just summarizes some change (e.g. "added examples"). You will find these on the main page (index.html) of the IG, in a pink Note section

You can also get to all the historic versions through the "Directory of published versions" link found on the top of the main page (index.html) in the bright yellow box. On the history page you can find each historic version, and the above mentioned changes should also show up here.

The next level of details is to look at all the closed github issues (or in the case of HL7 the closed jira tickets). Select the "Issues" link in the footer, and navigate to closed issues. Sorry, not going to try to explain github issue tracking here. If you know how to use it, then you know.

If you are really interested in technical conformance resource changes, this also available, although not as easy to find. This you must first go to the footer of the IG, and select "QA Report"

On the QA Report, there is a section "Previous Version Comparison" that will give you very detailed computer generated differences.

How do I submit a comment?

Standards live by comments; they really are the food that makes standards useful. So please submit a comment anytime you have one. Best time to comments is during Public-Comment, as we are planning on addressing comments at that time with the intent to resolve all of the public-comments received.

Comments can be identifying a typo or bug, something that is not clear to you, something you and a peer argue about, or something you would like the IG to do. All comments are welcome.

You can comment at any time, even after Public-Comment when the IG is Trial-Implementation, or even when it goes Final-Text (normative). Within the Implementation Guide you want to comment on there are two ways. The first way is to submit a github issue, this is the first red circle. The second yellow circle is "Propose a change" which is a web form that anyone (member or not) can use.

Conclusion

As a specification gets more normative, it will change less. In theory normative status (Final-Text) the specification will not get a change that breaks any system that used the previous. But the status of a specification should never stop you from submitting a comment at anytime.

AI privacy controls

noreply@blogger.com (John Moehrke) — Tue, 04 Feb 2025 17:49:00 +0000

AI and privacy are hot topics lately. I have effected some changes in HL7 as well as blog articles about those capabilities that exist. I am also a participant in a few AI initiatives in HL7 and within the VHA. These solutions are most well developed in FHIR, but are fundamental provenance, data tagging, and Consent so can work with most standardized data and datasets.

The main topic areas in AI:

1) Can data be used to train an AI?

Given that there are some data that should be authorized to be used to train an AI, how does one indicate rules that enables some data to be used, while forbidding other data to be used to train an AI?

This needs to be done at the whole dataset (e.g. EHR) level, where one might want to forbid some subset of the data from the teaching.

This also is needed at the patient specific Consent level. So that a patient can choose to not have their data included.

https://healthcaresecprivacy.blogspot.com/2023/10/teaching-aimlllm-should-be-distinct.html

2) How to indicate the data that was used to train an AI model?

Once you have an AI Model, it is important to keep track of what data was used to train that AI Model. This enables knowing what data are used to teach the AI, thus if a concern comes up one knows if that concern impacts your AI model or not.

Provenance of the data used to create the AI Model -- https://healthcaresecprivacy.blogspot.com/2024/01/provenance-use-in-ai.html

3) How can the use of "my data" in an AI decision can be controlled?

How the consent can allow/deny that the patients data can be used in a clinical decision on behalf of the patient outcome (no article yet)

When an AI retrieves patient specific data to enable payment decisions or treatment decisions, those data accesses use a very specific PurposeOfUse. This enables policy to enable or deny that access. The AI accessing the data is independent from a person accessing for payment or clinical purposes.
PurposeOfUse: PMTDS (when the AI is acting to aid with payment decisions)
PurposeOfUse: TREATDS (when the AI is acting to aid with clinical decisions)
If there is no rule that use these PurposeOfUse values, then their parent term (payment or treatment) takes precedence.
These can be used in a Consent for patient specific rules, or at Permission for an organization rule. Realistically both, as the overriding policy must be stated so that Consent can accept and/or override it.

4) How to indicate data is the output of an AI?

Once an AI is used to produce a decision or recommendation. How is that recorded into the dataset (e.g. EHR) so that future uses know that it came from AI vs came from a Clinician or other professional. This is simply provenance, enabling knowing where data came from.

On how data can be tagged as having come from an AI - https://healthcaresecprivacy.blogspot.com/2024/09/healthcare-ai-provenance-of-ai-outputs.html

Tagging can be at the data resource or element level
Tagging can be by simple security tag
Tagging can be full Provenance for more details

An important attribute of the Provenance is to know what version of the AI was used, what Model was used, and what data inputs were given (what portion of the patient's chart was input).

Conclusion

We have a lot more than most people that start to talk about AI think we have. I am sure it is not everything we need, but I want to help encourage the use of the methods we already have before we reinvent the wheel.

IHE Updates for PCC and ITI

noreply@blogger.com (John Moehrke) — Fri, 13 Dec 2024 14:42:00 +0000

Some Explanations

Most of these releases are incremental updates that don't require much comment. Either addressing the public-comment from last quarter or integrating formal Change Proposals (CPs) that were balloted and passed. If you need to understand these changes, there is traceability within the representative IHE GITHub repositories. All issues and CPs are indicated with individual github issues and pull-requests.

The biggest news is:

with an important mention of:

QEDm

This is mostly a conversion to IG publication of the QEDm profile that has before this been only published in PDF form. In PDF form, the supplement was nothing but narrative. There was some conformance resources but there was little assurance they were right. Now that QEDm is published in IG form there is a full set of conformance resources, and examples. There is a clear connection to MHD using mXDE.

The future of QEDm is still in play. We are intending to adjust QEDm to be a derivative of the HL7 IPA. In this way there will be little mismatch between the two. This effort will need to address that IPA includes functionalities that IHE covers with PDQm and MHD. I expect this might be ready in Summer 2025, assistance is always welcome.

DSG - JSON signature option

This is an addition of an Option to the normative Document Digital Signature. Original Profile used XML-Signature, as that was the best solution at the time. However, there is more tooling support for JSON Digital Signatures now days, and less interest in XML-Signature. So IHE adjusted the DSG profile to have two options, the original XML-Signature (which is assumed if no option is declared), and the JSON Digital Signature. The use-cases supported have not changed, the DSG is about Document Digital Signature and has some variations for the various ways that Documents can be moved around using IHE Document Sharing.

Finance and Insurance Services

This supplement is a new domain for IHE. Although there is a robust community in the USA that is profiling the FHIR standard to support Finance and Insurance Services; there is a need outside the USA for similar profiling. This is the scope of this supplement, mostly "Not the USA". This does not mean it is conflicting with USA needs, but rather to indicate that the intended audience is everyone outside the USA.

The current profiling is not all that much different than the use-case analysis found in the FHIR Core for the Finance profiles but does define some capabilities that have been identified by some open-source implementations. The initial deployment is expected to be by WHO. I would expect we will receive robust comments as this gets "Trial Implemented", which is an admission that this IG is rather immature and open for discussion.

Scheduling

This IHE profile is based on the Argonaut Scheduling Implementation Guide, originally published back in the FHIR STU3 days. Argonaut has agreed to hand over the FHIR R4 and future to IHE. Thus, this IG is mostly a conversion to FHIR R4, but includes significant improvements based on experience.

The following are some of the major differences from the Argonaut IG:The IHE Profile is based on FHIR R4

The IHE Profile is intended for international use, and it does not have required bindings or any dependencies to national profiles
The operations described are $find, $hold, and $book
A separate transaction describes the use of FHIR Search for the Appointment resource
The operation parameters use explicit data types, and support only POST transactions