FHIR Chat · Source of information · implementers

Stream: implementers

Topic: Source of information

Thomas Johansen (May 16 2018 at 13:25):

Hi!

I'm wondering about references in resources connected to critical information. In the Norwegian standardization of critical information it is said that most critical information must be referred to by a code defined in the Volven code system. I'm looking at fields like asserter to reference to whom reported the critical information. In the specc asserter is reference to Patient, RelatedPerson, Practioneer, but as stated we do this by code.

Am I breaking conformance by using a CodeSystem? What can be used with e.g Procedure (using for Device and not the Procedure it self)?

Here is what I tried to make it look like. We are offering this resource on our server as well.

"asserter": {
"reference": "CodeSystem?system=urn:uid:2.16.578.1.12.4.1.1.7519|1"
}

// Thomas

Grahame Grieve (May 16 2018 at 13:48):

asserter can't be a code - what makes it a code system?

Thomas Johansen (May 19 2018 at 15:43):

@Grahame Grieve As I mentioned, it is the definition by the Norwegian Standardization. We use codes from Volven on this. Reporter will be e.g Observed by treating doctor, result from tests etc. We don't use it the same way as in spec. You have any other ideas of how to use this? Trying to remove an extension here :) I guess I could try suggesting this as a CR

Grahame Grieve (May 20 2018 at 13:20):

this is still confusing; the asserter is a reference to a instance of a person, not a type of a person in a code system

Brian Postlethwaite (May 20 2018 at 14:06):

Maybe that is the value that could be used in the practitionerrole.role property.

Eric Haas (May 22 2018 at 00:31):

Could always make an implementation specific extension. Not sure how you can code all the performers. There are type codes for a kind of performer and identifiers for actual living breathing performers. For the latter you will still use Reference.

Thomas Johansen (May 22 2018 at 05:42):

@Grahame Grieve Exactly, that's why I'm asking. Doctors aren't logging the 'who' on who observed or confirmed the information. They save an int 1 - 7 and that code refers to the general idea on who observed the case. So if there is nothing today, then maybe there is room for expanding the allowed reference?

@Eric Haas I was trying to avoid the extension obviously, cause we are still referring to the same general meaning of the observer, but there is no data on the actual person.

Is Norway the only one with this approach to this way of confirming critical information on a patient? In that case I guess extension is the only way to go.

Grahame Grieve (May 22 2018 at 08:07):

well, nothing right now. You could create a task asking for that. but I've not seen it elsewhere personally. But it's definitely something we should cater for on Provenance

John Moehrke (May 22 2018 at 12:39):

I am not sure I understand fully what is being discussed. What I think I hear is that the Provenance.agent.who can only be identified as a role, not an individual? In that case can it be a PractitionerRole that has no values n PractitionerRole.practitioner? Possibly a contained PractitionerRole?

Grahame Grieve (May 22 2018 at 12:40):

actually, in Provenance, now that I actually look (!), it looks like this is covered by Provenance.agent.role

John Moehrke (May 22 2018 at 12:43):

except that you must have a who. that was what I figured was the problem

John Moehrke (May 22 2018 at 12:44):

given the purpose of Provenance is to capture Who, What, Where, When, and Why... the Who value is especially important for the concept of Provenance.

Grahame Grieve (May 22 2018 at 12:46):

oh right. well, if you don't have it, and just have a role... that's still useful, right?

Grahame Grieve (May 22 2018 at 12:46):

I think that this is the kind of use case that would make agent.who optional

John Moehrke (May 22 2018 at 13:01):

possibly.. but I am not sure what the value of a Provenance with only one agent and only an agent.role... What value is provided? I might be convinced, but it is not clear to me.

Grahame Grieve (May 22 2018 at 17:41):

more value than if you can't say anything at all , but less value than if you can identify the agent

Thomas Johansen (May 24 2018 at 17:40):

I don't think I quite understand the practical use of Provenance. In this case the resource that needs an asserter must be able to refer to a Provenance resource?

@John Moehrke You are right that the issue is that a 'who' is required instead of a general idea of the person which observed the condition. I would required a simple 1..1 Coding as asserter.

Grahame Grieve (May 24 2018 at 17:55):

Provenance, the link is the other way around - Provenance refers to the resource

Thomas Johansen (May 24 2018 at 18:04):

That is what I thought, so I couldn't fit how it would fit the use case where a role would be the asserter on a resource. The role of how a resource was observed is very relevant especially for older data. Would be interesting if at least a resource could have a reference to a code that could describe the case. Not sure how to formulate it in a general way though.

Jens Villadsen (Aug 14 2018 at 11:36):

What would the proper way of using provenance for only parts of a resource be? I'm in a situation where I specifically need provenance on a Patients telecom, communication and address - individually. My idea is to make an identifier extension on the elements telecom, communication and address and then provide that Identifier in the Provenance.target for each of the three elements. I don't find this design super awesome, but I should work, right?

John Moehrke (Aug 14 2018 at 12:19):

The Provenance is recorded for each update of the target resource, thus showing each update provenance. This is focused on revision provenance, not element level provenance. This has been the scope to this point for Provenance. There are edge cases, such as yours, that have not been seen as within 80% of what systems do today. I would be glad to work with you on some extensions to support the usecase, so that others can experiment with you.

Jens Villadsen (Aug 14 2018 at 12:31):

Just as I would expect. My case (if we go into more of the gory details) is that I'm interfacing a custom Web service that serves me CDA documents with custom extensions and custom elements (all out of my control) - among these are relatives, languages and telecom. Each of these custom elements also have 'dataEnterer' field that supposedly provides a record of who has entered this information. Now, I'm mapping this document into FHIR resources and all of these fields fits nicely into the Patient resource . I just also need model the provenance part which requires me to find some kind of mapping on the element level - and that is why I thought that providing the elements with Identifiers and then reference them from the Provenance resource could be a way out for me. So essentially a ProvenanceIdentifierExtension on the elements

John Moehrke (Aug 14 2018 at 12:49):

That might work. I do expect this kind of need to be mostly on the Patient resource. Most other resources tend to be single source. So it would also be good to think about how widely needed this extension is, not to limit the use but to best characterize the need. A resource that is an amalgamation of information from many sources is nice for readers, but is complicated for create/update/delete.

Michelle (Moseman) Miller (Aug 14 2018 at 14:41):

I thought I asked a similar question before, https://chat.fhir.org/#narrow/stream/4-implementers/topic/Pop.20Health.3A.20Person.20vs.20Patient.20vs.20Provenance, and the response (at the time) was:

the target on a provenance can have a fragment identifier, and so indicate a particular piece of information in the resource

<address id="23">
<blah...>
</address>

<Provenance>
<target value="....#23">
<Provenance>

John Moehrke (Aug 14 2018 at 14:51):

Will that work? I would be happy if someone would write that up in a CR for improvement of the Provenance notes. The concern this brings for me is ho do I identify multiple elements in the Patient resource that -this- Provenance is describing? Does this Provenance.target hold many fragment identifiers? If so, are they all fully specified? Does this survive outside a transaction into persistence?

Jens Villadsen (Aug 17 2018 at 10:08):

Well, fragment Identifiers to my knowledge are not fully qualified - so that won't fit the bill, unless I molest it and code some magic 'separators' into the ID. So I guess the proper way to do it would be to make an extension containing an Identifier

Michelle (Moseman) Miller (Mar 22 2019 at 13:41):

@John Moehrke Did anyone log that CR you asked about (Aug 14, 2018 - above)? We have a situation now where we want to convey this Procedure, for example, was extracted from a specific service line item within Claim or ExplanationOfBenefit. In the earlier examples (from 2018), there was a suggestion to use a fragmented identifier in the Provenance.target, but in my new example, the ask would be can we use a fragment identifier in the Provenance.entity.what? In both cases, it would be nice to have some additional guidance or examples in Provenance.

John Moehrke (Mar 22 2019 at 13:44):

No one entered that CR. I agree that Provenance.entity.what might need clarificaiton. Can we put fragment identifiers into a Reference datatype? Or will there need to be an additional element(s) added to Provenance.entity?

Michelle (Moseman) Miller (Mar 22 2019 at 13:51):

GF#20583 has been logged

Michelle (Moseman) Miller (Mar 22 2019 at 13:55):

I thought @Grahame Grieve had suggested using fragment identifiers in that prior thread where Provenance.target is also a Reference data type (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pop.20Health.3A.20Person.20vs.20Patient.20vs.20Provenance). It was an older discussion, so not sure if that is still true or not. It's a recurring question for me (on the pop health side), so hopefully GF#20583 will lead to some clarity on the recommended approach

Grahame Grieve (Mar 22 2019 at 21:13):

it would be an extension to clarify a particular element in the source, because reference is constrained to point to a whole resource. I don't think we actually defined the extension though

John Moehrke (Mar 22 2019 at 21:24):

can you help me with how that would look?

Grahame Grieve (Mar 22 2019 at 21:26):

{
  "resourceType" : "Provenance",
  "target" : [{
    "reference" : "Observation/xxxxx",
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/targetElement",
      "valueUrl" : "#a1"
    }]
  }]
}

Grahame Grieve (Mar 22 2019 at 21:27):

where there's an element in the target observation with id="a1" on it

John Moehrke (Mar 22 2019 at 21:28):

so the hash tag concept is well enough defined? I am simply showing my ignorance. It seems clear to me.

Grahame Grieve (Mar 22 2019 at 23:23):

I think it is pretty clearly defined, except for 2 things:
- we didn't define the extension
- you need an id in the resource. There's been some interest in referring to an element by it's path, but it's not clear whether you'd use xpath, jsonpath, or fhirpath

John Moehrke (Mar 25 2019 at 13:57):

should FHIR-I be assigned to resolve this? Seems the better SME

Grahame Grieve (Mar 25 2019 at 20:00):

is there a task?

John Moehrke (Mar 25 2019 at 22:07):

GF#20583

Brian Postlethwaite (Apr 03 2019 at 12:57):

And we'd like to use that in the VerificationResult resource too - and replace/update the targetLocation property.

Michele Mottini (Apr 30 2019 at 22:46):

I think it should be a list of target elements:

{
  "resourceType" : "Provenance",
  "target" : [{
    "reference" : "Observation/xxxxx",
    "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/targetElements",
        "extension" : [{
            "url" : "element",
            "valueUrl" : "#a1"
          },
         {
            "url" : "element",
            "valueUrl" : "#b52"
          }]
    }]
  }]
}

because usually more than one element would come from a certain source - and I don't think we want multiple Provenance just for that

Brian Postlethwaite (Apr 30 2019 at 22:48):

This should also be consistent with OperationOutcome location which points to a specific field in the resource (which is how VerificationResult currently does it)

Michele Mottini (Apr 30 2019 at 22:51):

Using the element ids is much easier for a client - parsing FHIR paths and getting the element they reference is not trivial

Grahame Grieve (May 04 2019 at 16:26):

{
  "resourceType" : "Provenance",
  "target" : [{
    "reference" : "Observation/xxxxx",
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/targetPath",
      "valueString" : "context.name"
    }]
  }]
}

where context.name is a FHIRPath. We would restrict that to the simple subset (http://hl7.org/fhir/fhirpath.html#simple), or maybe even more restricted.

Grahame Grieve (May 04 2019 at 16:26):

use that alternative if you can't put an id in theresource

Grahame Grieve (May 04 2019 at 16:30):

also - we could do it as a list of target elements, as Michele put above - that would be legal, but it would be a departure from our usual way of doing extensions, which would just be this, as I showed earlier:

Grahame Grieve (May 04 2019 at 16:30):

{
  "resourceType" : "Provenance",
  "target" : [{
    "reference" : "Observation/xxxxx",
    "extension" : [{
      "url" : "http://hl7.org/fhir/StructureDefinition/targetElement",
      "valueUrl" : "#a1"
    }]
  }]
}

Grahame Grieve (May 04 2019 at 16:31):

just repeat the extension if you have more ids

Michele Mottini (May 04 2019 at 17:25):

OK, thanks, good for me

Michele Mottini (May 05 2019 at 13:31):

Should I create a tracker?

Grahame Grieve (May 05 2019 at 14:06):

yes please

Michele Mottini (May 05 2019 at 14:43):

Done - GF#21284

Espen Stranger Seland (May 08 2019 at 12:51):

@Thomas Johansen Just for the record: The FHIR-profiles for critical information is now being cleaned up and moved to R4, and in the same time more compatible with International Patient Summary. It will now reffer to a "real" Practitioner (etc) from Recorder/Asserter (like in AllergyIntolerance).

We do have an issue that we want a reference to a "recording organization", hopefully without using an Encounter or a hard profiled PractitonerRole. I'll probably open this issue as a new thread.

Now that Forge R4 is out, drafts will be available in a week. Please contact me for any questions and/or if you want to contribute. Dugnad!

Michel Rutten (May 08 2019 at 20:38):

Hi @Espen Stranger Seland, Forge R4 is pretty stable but thare are a couple of rough edges I'd like to fix/improve, e.g. type slicing. Feel free to contact me if you run into trouble, or if you have suggestions for improvement.
Cheers, Michel

Michelle (Moseman) Miller (May 16 2019 at 20:45):

Regarding GF#21284:

Add two extensions http://hl7.org/fhir/StructureDefinition/targetElement and http://hl7.org/fhir/StructureDefinition/targetPath that specify the element that come from the Provenance in the target resource.

Both extensions apply to the target element, the first one has a valueUri with the id of the target element, the second has a valueString containing a simplified FHIRPath specifying how to get to the element.

For repeating elements, such as Patient.address, does FHIRPath allow us to specify a single address? If so, can you show an example? If not, then it sounds like we're concluding if there is different provenance for each repeating element (e.g. each address was from a different source), then we're forced to use targetElement with an id.

Lloyd McKenzie (May 16 2019 at 20:59):

You mean point to a specific repetition? Just specify the repetition you want in brackets. E.g. Patient.address[0] for the first one. That said, be cautious about referring to specific repetitions for elements whose semantics is unordered.

Lloyd McKenzie (May 16 2019 at 20:59):

(which is the case for Patient.address)

Michelle (Moseman) Miller (May 16 2019 at 21:03):

Yep, that is what I was asking.

John Moehrke (Aug 09 2019 at 15:36):

I created GF#23076 to drive adding narrative description of this extension within Provenance given that it is very much in demand for Provenance, and an example showing the use. I request FHIR-I assist with the writing of this narrative and creation of this example.

Michele Mottini (Aug 09 2019 at 15:50):

Here is an example from our server (where we did implement the feature): ExampleProvenance.zip
It is a Patient with data coming from two different sources - represented by two Provenance resources

John Moehrke (Aug 09 2019 at 16:01):

thanks. so you used only targetElement extension, and in target id tagged elements. This seems like the one most would use. I will attach this zip to the new CR so that when the extension is added can derive off of this. This is very helpful.

Thomas Tveit Rosenlund (Sep 06 2019 at 12:38):

I created GF#23076 to drive adding narrative description of this extension within Provenance given that it is very much in demand for Provenance, and an example showing the use. I request FHIR-I assist with the writing of this narrative and creation of this example.

I have tried to make an extension for the targetElement, but had to include information about the old and new value of the element because the people making the specification of our Provenance needs to document that part as well. If any of you want to review it is is available in our simplifier project.
extension: https://simplifier.net/Grunndata-R4/targetElement
Provenance profile using the extension: https://simplifier.net/grunndata-r4/gdprovenance

Jay Lyle (Oct 21 2019 at 16:09):

I don't see http://hl7.org/fhir/StructureDefinition/targetElement published anywhere.
From the example,
* target points to resource
* extensions identify elements, but not prior data.
The NO extension (simplifier: http://hl7.no/fhir/StructureDefinition/reference-targetElement)
* target points to resource
* extension identifes target element _and_ (optionally) old and new values.
* I think this is the one that meets our requirements (VA Pharmacy "AMPL")

Thomas Tveit Rosenlund (Dec 20 2019 at 07:57):

I don't see http://hl7.org/fhir/StructureDefinition/targetElement published anywhere.
From the example,
* target points to resource
* extensions identify elements, but not prior data.
The NO extension (simplifier: http://hl7.no/fhir/StructureDefinition/reference-targetElement)
* target points to resource
* extension identifes target element _and_ (optionally) old and new values.
* I think this is the one that meets our requirements (VA Pharmacy "AMPL")

Missed this one @Jay Lyle
I though I also updated the GF23076, looks like my New name is Eric Rose?!?

Jay Lyle (Dec 26 2019 at 14:49):

@Thomas Tveit Rosenlund ; yours looks great; I'm just trying to work out US realm assumptions. Thanks.

Jay Lyle (Jul 15 2020 at 17:20):

@Thomas Tveit Rosenlund That extension (3 versions in Simplifier) still say "draft" and the canonical returns a 404. Do you have maturation assumptions or plans?

Thomas Tveit Rosenlund (Aug 10 2020 at 09:29):

@Jay Lyle We want to test it in our implementation. Looks like we can have an actual implementation this fall. Would be great to hear from any other implementers as well.

Rik Smithies (Apr 20 2021 at 14:24):

This one https://jira.hl7.org/browse/FHIR-21284 is still unimplemented, and it is not assigned to anyone. Can someone from FHIR-I take it on?

Amit Cudykier (Jun 25 2021 at 19:52):

@Thomas Tveit Rosenlund Did you end implementing this extension in your implementation? any interesting learnings?
We are looking at a similar use case where we want to enrich data using an external service on the FHIR response coming back to the client. And we want do have why to communicate to the client what we changed.

Thomas Tveit Rosenlund (Jun 28 2021 at 06:12):

Amit Cudykier said:

Thomas Tveit Rosenlund Did you end implementing this extension in your implementation? any interesting learnings?
We are looking at a similar use case where we want to enrich data using an external service on the FHIR response coming back to the client. And we want do have why to communicate to the client what we changed.

We are still struggeling to get the Provenance records straight so the implementers have not gotten around to implement the targetElement unfortunately.

Last updated: Apr 12 2022 at 19:14 UTC