Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-23341

Provenance: Argonaut vs Da Vinci - HRex #112

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci HRex (FHIR)
    • Financial Mgmt
    • Profile overview
    • Hide

      We will try to improve alignment between DaVinci Provenance and US-Core Provenance, as follows:

      • we will add target as 1..* mustSupport in DaVinci, the same as it is in US-Core because a Provenance that doesn't point to its target is not meaningful
      • we will propose to US Core that they add 'occurred' as mustSupport and question whether recorded should be mustSupport - typically what you care about is "When did the target resource get created/updated/etc.", not "When was the Provenance metadata get created".  We will make 'occurred' 0..1 rather than 1..1 though because in some cases, systems might not know when the creation/update occurred, even though they will know who was involved.
      • We will mark agent.type as mustSupport and adopt the US-Core value set
      • We will raise a change request to Provenance asking for greater clarity about the use of onBehalfOf because many of the choices listed there don't necessarily seem to make sense.  Also, would you say Patient did this onBehalf of themselves or would there be an expectation that onBehalfOf would only be populated if different than the who.  Similarly, if you've got PractitionerRole or RelatedPerson, those resources have innate 'onBehalfOf' so do we prohibit onBehalfOf for those?  Should we have invariants to enforce appropriate practice?
        Based on the guidance coming out of that, we will decide whether to constrain to only Organization or not.
      • We will add a section in HRex that provides explicit guidance around the use of Provenance to try to drive consistency around what agents are listed, how they're represented, and how the provenance data relates to what appears on the target resources both in resource elements and resource.meta - when is the data present in both places, when in only one (and which one).  Will ask IGs to consider adding explicit IG-specific guidance if appropriate.
      • The called-out slices on author and transmitter in US Core aren't actually accomplishing anything technical - it won't change conformance expectations or validation.  All it really does is draw more visual attention to those agents.  Da Vinci will not follow this same approach.  Instead, we will have narrative that specifically identifies expectations (and desires) around the use of each agent type - i.e. what information is most relevant in which circumstances.  This will include what should be sent when the same individual takes on multiple roles.  We will also evaluate whether additional guidance on Provenance is needed in specific Da Vinci use-cases.  E.g. sometimes attester matters more than author.
      Show
      We will try to improve alignment between DaVinci Provenance and US-Core Provenance, as follows: we will add target as 1..* mustSupport in DaVinci, the same as it is in US-Core because a Provenance that doesn't point to its target is not meaningful we will propose to US Core that they add 'occurred' as mustSupport and question whether recorded should be mustSupport - typically what you care about is "When did the target resource get created/updated/etc.", not "When was the Provenance metadata get created".  We will make 'occurred' 0..1 rather than 1..1 though because in some cases, systems might not know when the creation/update occurred, even though they will know who was involved. We will mark agent.type as mustSupport and adopt the US-Core value set We will raise a change request to Provenance asking for greater clarity about the use of onBehalfOf because many of the choices listed there don't necessarily seem to make sense.  Also, would you say Patient did this onBehalf of themselves or would there be an expectation that onBehalfOf would only be populated if different than the who.  Similarly, if you've got PractitionerRole or RelatedPerson, those resources have innate 'onBehalfOf' so do we prohibit onBehalfOf for those?  Should we have invariants to enforce appropriate practice? Based on the guidance coming out of that, we will decide whether to constrain to only Organization or not. We will add a section in HRex that provides explicit guidance around the use of Provenance to try to drive consistency around what agents are listed, how they're represented, and how the provenance data relates to what appears on the target resources both in resource elements and resource.meta - when is the data present in both places, when in only one (and which one).  Will ask IGs to consider adding explicit IG-specific guidance if appropriate. The called-out slices on author and transmitter in US Core aren't actually accomplishing anything technical - it won't change conformance expectations or validation.  All it really does is draw more visual attention to those agents.  Da Vinci will not follow this same approach.  Instead, we will have narrative that specifically identifies expectations (and desires) around the use of each agent type - i.e. what information is most relevant in which circumstances.  This will include what should be sent when the same individual takes on multiple roles.  We will also evaluate whether additional guidance on Provenance is needed in specific Da Vinci use-cases.  E.g. sometimes attester matters more than author.
    • Richard Esmond / Marti Velezis : 9-0-0
    • Clarification
    • Compatible, substantive

    Description

      Comment:

      Isn't Argonaut also profiling Provenance? Da Vinci should not conflict with the USCDI Argonaut profile of Provenance.

      Summary:

      Provenance: Argonaut vs Da Vinci

      Attachments

        Activity

          People

            Unassigned Unassigned
            Isaac.Vetter Isaac Vetter
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: