FHIR Chat · Provenance to capture V2 to FHIR conversion · v2 to FHIR

Stream: v2 to FHIR

Topic: Provenance to capture V2 to FHIR conversion

Rik Smithies (Mar 27 2019 at 21:49):

When converting an observation from a V2 message to a FHIR resource would the Provenance resource to record what happened be something like this:

<Provenance xmlns="http://hl7.org/fhir">
    <target>
        <reference value="Observation/theObservationFromMessage"/>
    </target>
    <recorded value="2019-03-27T21:11:24+00:00"/>
    <activity>
        <coding>
            <system value="http://terminology.hl7.org/CodeSystem/v3-DataOperation"/>
            <code value="CREATE"/>
        </coding>
    </activity>
    <agent>
        <type>
            <coding>
                <system value="http://terminology.hl7.org/CodeSystem/provenance-participant-type"/>
                <code value="assembler"/>
            </coding>
        </type>
        <who>
            <reference value="Device/theSoftwareThatConverted"/>
        </who>
    </agent>
    <entity>
        <role value="source"/>
        <what>
            <reference value="DocumentReference/theOriginalFile"/>
        </what>
    </entity>
</Provenance>

Note the use of agent.type = "assembler".
This http://hl7.org/fhir/provenance.html#6.3.4.5
says to use agent.role of assembler, but that seems to be a value from the value set used by agent.type not agent.role.

(This does relate to the recent thread https://chat.fhir.org/#narrow/stream/179188-v2-
to.20FHIR/topic/v2.20version.20in.20a.20FHIR.20resource
but that was getting a bit muddled)

Craig Newman (Mar 28 2019 at 12:53):

I documented some of that discussion and my own (amateur) thoughts at https://confluence.hl7.org/display/OO/v2-to-FHIR+Provenance but they look pretty close to what you came up with. I was thinking a single "genera transformation" Provenance resource for the whole transform of a v2 message to a FHIR bundle, so I had .target pointing to all the resources in the bundle (although I suppose it could be the Bundle itself). I'm not sure exactly what you are doing, so just pointing to the Observation resource might work if you're picking pieces from the message. I didn't propose a value for .activity because I didn't really like any of the values for a transformation. I suppose we could extend the value set with something that better indicates a format change. Finally, I thought .agent.who might either be a Device or an Organization I think both could make sense (the Organization might be more useful to a human looking at the resource).

John Moehrke (Mar 28 2019 at 16:11):

I think .target should point at ALL of the resources that are created or updated. Some might argue that it should also point at those that were extracted and found to already exist in that current form.
How about "Derivation" for the activity? -- this is what I used in IHE for creating FHIR resources from decomposing of CDA. https://github.com/IHE/fhir/blob/master/StructureDefinition/IHE_QEDm_Provenance.xml

John Moehrke (Mar 28 2019 at 16:16):

@Rik Smithies can you enter a CR to fix the Provenance text in 6.3.4.5? Indeed I think what you are doing here should be specifically mentioned in that section. It was originally written in 'theory'. We now have more to leverage. I would very much like to point at this V2 to FHIR profile in that section on the Provenance page. So would also welcome a CR to make that happen.

Rik Smithies (Apr 01 2019 at 23:02):

@Craig Newman @John Moehrke thanks guys. Yes I did intend to have "target" point to all the converted resources. In fact my original had that - I just wanted the example to be nice and small. I found the role "assembler" to be strange and unintuitive, but don't have a big problem with it (I assume some precedent to it). The resources are being Created, albeit as a conversion of or derivation from something else, so CREATE does seem right. The presence of the "source" entity implies its a conversion, though it's a little hard to work that out.

Rik Smithies (Apr 01 2019 at 23:03):

John, yes I will add that CR

Rik Smithies (Apr 01 2019 at 23:06):

Interesting point about "refreshing" a resource that already exists in the same form. There is no actual change in that record, but there is some provenance nevertheless, that it was again found to be the correct state (according to the new data). I think that is worth preserving.

Paul Church (Apr 02 2019 at 00:49):

I've encountered an interesting case where someone processing v2 messages wanted to be able to represent an update (e.g. to patient demographic data or admission status) that was received out of order when other messages had already made it moot, so there was no update. It could be valuable information to record that the system did receive and process the message - whether that's recorded in a provenance, or resource history, or some out of band mechanism could be a tricky decision.

Rik Smithies (Apr 03 2019 at 21:32):

added CR GF#20663

Last updated: Apr 12 2022 at 19:14 UTC