Is honoring a Patients Consent a form of forbidden Information Blocking

As I work hard to enable a patient to express the privacy rules around how their health information can be used and by whom for what reasons; I hear that there is worry that an organization that honors those wishes by blocking the data for a given use, that this Organization may be seen as violating the regulations forbidding Information Blocking.

In HTI-2 there is some discussion around some sensitive data that has been expressed as being a special case. However, this is just one kind of data that is or might be considered sensitive by a patient.

My concern is wider than just the ONC HTI-2 and the USA Information Blocking regulations. There are other state level regulations that might force data to be shared in circumstances for which the patient does not want to share. This is not to say I am against some required reporting, but to recognize that there is a wider overlap between potential sensitive classes of data and unreasonable expectations to mandate data sharing.

I am a fan of defining classes of data that are sensitive, that are generally stigmatizing health topics. These defined classes need a specific and actionable definition, so that it is clear to all what is within that class and what is not within that class. This is important to be sure policies work together when bridged. The reality is that these classes are not as distinct as we would like, but today they are hardly even given names of the classes.

One class that is discussed is sexual health topics; which seems clear but is not clear at the detail and technical level. 

The Patient should be empowered to define what is sensitive to them. The use of sensitive classes of data should be a starting point, but the patient should also be allowed to restrict data within a timeframe, or data associated with a specific treatment episode/encounter, or even to identify specific data by identifier.

When these complex Consents can be implemented by an organization, and that organization allows more refined Consent provisions; then these restrictions should not be seen as a forbidden Information Blocking. We should not be questioning the patient's choices.

Healthcare AI - Provenance of AI outputs

AI is the focus of the HL7 Workgroup Plus meeting this week. As I sit in on the presentations, I find that there are some efforts that the Security WG has already put in place that are not understood. So this article will expose some of the things that Security WG has already put in place to support AI.

AI Output Provenance

First up is that there is a concern that any diagnosis, notes, observations, or other content that is created by AI, or assisted by AI, should be tagged as such. With this provenance any downstream use of the data or decisions are informed that the data came from an AI output.

An important aspect of this is to understand the background of the data, the Provenance. This might be a positive aspect, or might be seen as a drawback. The Security WG is not trying to impugn or promote; we are just wanting to provide the way for the data or decision to be tagged appropriately.

There are two methods.

Provenance Tag

There is a data tag that can be applied to any data to indicate that it came from AI.

AIAST - Artificial Intelligence asserted  --- Security provenance metadata observation value used to indicate that an IT resource (data, or information object) was asserted by a Artificial Intelligence (e.g. Clinical Decision Support, Machine Learning, Algorithm).

This might appear on the top of the FHIR Resource in the .meta.security

           "resourceType" : "Condition",
           "id" : "1",
           "meta" : {
              "security" : [{
                "system" : "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",             
                "code" : "AIAST" }
                ]
              },
           ... other content etc.....
         }
 

This can also be used using the element level tagging defined in the DS4P - inline security labels

Using this would cover a DiagnosticReport that has one .note element that is the output of an AI analysis of the data. The DiagnosticReport would indicate that there is an inline label, and just that one .note would be tagged as being AI Asserted.

Non-FHIR - The AIAST code is available for use elsewhere. Such as in HL7 v2, CDA, DICOM, and IHE-XDS. As a code it is very portable. These other standards include ways of carrying security tags, and thus this AIAST code.

Provenance Resource

The Provenance resource would be used when more than the tag is needed. This Provenance would take advantage of the AIAST tag, to indicate that the purpose of this Provenance is to indicate details about the AI Assertion.

The above Provenance Tag might still be useful to use, with the Provance Resource providing the details of the provenance of that assertion.

The Provenance Resource might also use the target element extension or target path extension. to point at the specific elements of the target resource that came from AI Assertions.

The Provenance Resource can also indicate the specific AI algorithm using a Device resource. In this way one can understand the revision of the AI that was used. Possible that if there is then determined to be a problem (bias) with that version of the AI model, one can find all the decisions that were recorded from it. This might also include parameters and context around the use of the AI algorithm.

The Provenance Resource can indicate the data from the patient chart that were considered by the AI algorithm.

The Provenance can also indicate other traceability, such as what portion of the AI model were used.

As with any Provenance, the other elements can be filled out to provide details on when, why, where.

AI use of Provenance

AI will often look at a patient record to determine a NEW diagnosis or write a new note. These interactions by AI should be aware of data that has the AIAST tag, so that the AI can distinguish data that has been entered as new, from data that was derived by previous AI use. This is often referred to as “model collapse” or “feedback loops.” One possibility is that AI will ignore any data or data elements previous authored by AI.

Speaking at free #HL7 #FHIR #HealthIT #Cybersecurity Event

Excited to announce that I'll be speaking at the HL7 FHIR Security Education Event on September 4-5! This virtual event is packed with insights and discussions tailored for everyone in the health IT community.

Two Tracks to Choose From:

1. General Track: Perfect for those looking to deepen their understanding of FHIR security without getting too technical.
2. Developer Track: Designed for health IT architects, developers and engineers who want to dive into the details.

Join me and other experts as we explore the latest in FHIR security. Don’t miss out on this opportunity to enhance your knowledge and network with fellow professionals!

Register free at: https://info.hl7.org/hl7-fhir-security-education-event-0

#FHIR #HL7 #HealthIT #Cybersecurity #FHIRSecurity