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).
"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
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 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.