Stream: implementers
Topic: Provenance.agent.type for programmatically derived CareTeam
David Riddle (Jul 18 2020 at 13:24):
@John Moehrke,
Our team is implementing code that will programmatically derive CareTeam resource instances based on multiple, disparate resource inputs. For example, it will derive a CareTeam based off of a combination of discrete PractitionerRole resources + existing documented CareTeam resources w/only Practitioner CareTeam.participant.member(s). We want the Provenance for these programmatically derived CareTeams to have a Provenance.agent.type that clearly conveys how the Device agent.who (the software) participated in the generation of the CareTeam. The existing provenance-agent-type code assembler (‘A device that operates independently of an author on custodian's algorithms for data extraction of existing information for purpose of generating a new artifact.’) feels like it might work; however, @Michelle (Moseman) Miller noticed, based on the resolution to this JIRA, that changes are occurring to the terminology binding for Provenance.agent.type. The JIRA resolution does indicate ‘Add the existing codes as they are useful and specific’, but I want to be sure I am following what this means…
• Is this JIRA resolution indicating that the new terminology binding for Provenance.agent.type will be to the participation-role-type value set?
• If so, does ‘Add the existing codes‘ mean that all of the existing codes (including assembler) in the current provenance-agent-type terminology binding are going to be added to the participation-role-type value set?
• If the assembler code will be carried forward into the new terminology binding for Provenance.agent.type, do you feel that assembler conveys our Device agent.who’s (the software’s) participation in the generation of these programmatically derived CareTeams? To be clear, our processing is doing more than simply 'extracting' existing information, it has business rules for reasoning with that information before generating a new CareTeam artifact. i.e., It is not simply performing a mapping of extracted information to a new CareTeam artifact.
• If not, is there another code in the new value set that would convey the Device agent.who’s participation in the generation of these derived CareTeams?
Lloyd McKenzie (Jul 18 2020 at 16:00):
@John Moehrke
Lloyd McKenzie (Jul 27 2020 at 21:11):
Ping - @John Moehrke :)
John Moehrke (Jul 27 2020 at 21:53):
That CP has been applied to the continuous build, so you can see the result at http://build.fhir.org/provenance.html
John Moehrke (Jul 27 2020 at 21:56):
There was not any interest at the time to preserving the provenance-agent-type vocabulary, as that was a extraction of concepts out of W3C PROV, and many of the extractions were not clean. I would welcome a CP that recommends bringing them back. I like all of them. If they were brought back it would be as the original codeSystem. If that was done, then you could use the same code/system in all versions of FHIR.
John Moehrke (Jul 27 2020 at 21:58):
YES, I think what you have described is the intent of an assembler. An example of a classic assembler is a service that would create a medical summary document.
John Moehrke (Jul 27 2020 at 22:01):
note the codeSystem does live.... https://terminology.hl7.org/CodeSystem-provenance-participant-type.html
David Riddle (Aug 06 2020 at 12:50):
@John Moehrke,
I have logged https://jira.hl7.org/browse/FHIR-28218 to request that the 'performer', 'assembler' and 'composer' codes from the provenance-agent-type (http://hl7.org/fhir/valueset-provenance-agent-type.html) value set be carried forward into the new participation-role-type (http://build.fhir.org/valueset-participation-role-type.html) value set.
That said, we are still struggling with whether or not 'assembler', defined as ''A device that operates independently of an author on custodian's algorithms for data extraction of existing information for purpose of generating a new artifact." is an accurate reflection of the role that our software device is playing when it is deriving the CareTeams.
Since the software is doing more than simply 'extracting' existing information (it has business rules for reasoning with that information before generating a new CareTeam artifact) and is not simply performing a mapping of extracted information to a new CareTeam artifact, we had a lot of internal debate about the use of the 'assembler' code to convey the devices participation role type.
The 'device used by an author to record new information' verbiage in the composer definition seems to rule out that option, since there is no human author involved in our programmatically derived CareTeam generation.
I know you indicated 'YES, I think what you have described is the intent of an assembler' above, but I wanted to make sure the fact we are doing more than simply extracting existing information doesn't change your opinion on this.
cc @Michelle (Moseman) Miller
John Moehrke (Aug 06 2020 at 12:58):
given that we will be taking ownership of these new codes, that they will be just inspired by W3C PROV, then I think we can add any clarification we feel is needed. I see no reason to not add clarification that the assembler is using intelligence or business rules or policy or logic... pick a phrase and recommend it in the CR or a new CR.
Last updated: Apr 12 2022 at 19:14 UTC
