FHIR Chat · References to elements? · implementers

Stream: implementers

Topic: References to elements?

Josh Mandel (Dec 01 2021 at 17:12):

I have a use case where I need to point to a specific attachment inside of a DocumentReference. I was planning to do something like:

"extension": [{
  "url": "https://examle.org/derived-from-attachment",
  "valueSomething": {} //???  "DocumentReference/123#abc"
}]

... assuming that #abc is an element id for a specific attachment in DocumentReference/123.

I was initially planning to use a valueReference, but I think that's invalid because I'm not pointing to a resource but rather an element. So, I'm now planning to use a valueUri here to point to a specific attachment.

Does this make sense? Has anyone else used this approach or found something they like better?

John Moehrke (Dec 01 2021 at 17:25):

There is an approved CR from FHIR-I that addresses this but has not been applied. This was approved 16 months ago. I have been waiting for it to be applied as I have CR for Provenance to use it. https://jira.hl7.org/browse/FHIR-21284

John Moehrke (Dec 01 2021 at 17:26):

there is no indication in that CR on how FHIR-I expected to solve the need.

Josh Mandel (Dec 01 2021 at 17:27):

Yeah, that's not a super helpful resolution, but it's good to know about this. For my use case, I don't think I'd want an extension inside the valueReference of my extension...

John Moehrke (Dec 01 2021 at 17:33):

im not sure I follow you... is this not what you are trying to do? A Reference not just to a Resource but an element within a Resource?

John Moehrke (Dec 01 2021 at 17:33):

your use-case does bring up a question of not just a named element, but an indexable element.

Josh Mandel (Dec 01 2021 at 18:10):

I'm just saying that the following "feels OK" to me in terms of usability:

{
  "resourceType": "Condition",
  "id": "789",
  "extension": [{
    "url": "https://example.org/derived-from-attachment",
    "valueUri": "DocumentReference#123"
  }]
}

... whereas the following seems (to me) like it crosses some kind of line into "difficult territory":

{
  "resourceType": "Condition",
  "id": "789",
  "extension": [{
    "url": "https://example.org/derived-from-attachment",
    "valueReference": {
      "reference": "DocumentReference/123",
      "extension": [{
        "url": "http://hl7.org/fhir/StructureDefinition/Reference-targetElement",
        "valueUri": "abc"
      }]
    }
  }]
}

John Moehrke (Dec 01 2021 at 18:18):

well, I was hoping that your engagement would solve this for more use-cases. But if you see a general solution as combersome, than I am not sure I can convince you otherwise.

Josh Mandel (Dec 01 2021 at 18:38):

Let me noodle on this. Fundamentally I think a FHIR "Reference" is supposed to be a pointer to a resource (not an arbitrary element), so the idea of using an extension to change this would at the very least be a "modiferExtension", which is always a bit of a red flag.

John Moehrke (Dec 01 2021 at 18:42):

I think the intent of the use-cases I have are that it is a pointer to a Resource, with emphasis on an element(s) within that Resource. Not a pointer to ONLY the element within a Resource.
I was also looking for something in core, something in R5. Not sure it needs to be an extension in my case. In your case, urgency might drive that an extension must be used.

John Moehrke (Dec 01 2021 at 18:42):

but, that question of what is the meaning of an element pointer is a good question

John Moehrke (Dec 01 2021 at 18:44):

seems any element pointer would have that question

John Moehrke (Dec 01 2021 at 18:45):

The use-cases for this that I am aware of:
Provenance -- where one wants to record a provenance statement of a subset of a target Resource. I provided the data in the X element. -- FHIR-23076

John Moehrke (Dec 01 2021 at 18:45):

@Rik Smithies has commented on the FHIR-I approved CR

John Moehrke (Dec 01 2021 at 18:46):

as has @Michelle (Moseman) Miller (I think)

Josh Mandel (Dec 01 2021 at 18:49):

And my use case is just: pointing to a specific Attachment.

Grahame Grieve (Dec 01 2021 at 19:05):

I don't follow the use case. The intent of a document reference is that's what you reference - a wrapper around an attachment with metadata

Josh Mandel (Dec 01 2021 at 19:22):

The use case is to point to a specific attachment (e.g., if a DocumentReference has more than one).

In the general case, a DocumentReference can include a whole array of attachments (e.g., different formats of the same content), and the aim here is to be able to say things like "This Condition was derived from bytes 300-325 of a particular attachment". So if I have a DocRef containing a .txt and .pdf attachment with the same clinical content, I want a way to point specifically to the .txt file.

Josh Mandel (Dec 01 2021 at 19:23):

(Haven't shared a full proposal yet; I was trying to iron out this one detail of how to point to an Attachment first.)

John Moehrke (Dec 01 2021 at 19:26):

seems like a very Provenance like use-case... :-)

Josh Mandel (Dec 01 2021 at 19:26):

I don't follow the use case.

Let me know if this helps @Grahame Grieve

John Moehrke (Dec 01 2021 at 19:27):

how do you intend to further refine to bytes 300-325?

Grahame Grieve (Dec 01 2021 at 19:27):

well, it certainly seems very much what the extension is for - 'and I mean this particular element is of interest in the target resource'

Grahame Grieve (Dec 01 2021 at 19:28):

but also, why are you using an extension for the reference in the first place. How is this not Condition.evidence.detail?

Josh Mandel (Dec 01 2021 at 19:29):

how do you intend to further refine to bytes 300-325?

There's a team at MS looking to make a proposal for NLP annotations as a FHIR Core (complex) extension, if we can work out something simple enough.

Josh Mandel (Dec 01 2021 at 19:30):

How is this not Condition.evidence.detail?

Aim is many kinds of derived resources with a consistent approach, not just Conditions.

John Moehrke (Dec 01 2021 at 19:30):

it might not have been clear that in Provenance there is both a need to say here is the provenance for that specific element in that resource, but also when I created some target, I used (Provenance.entity) this specific element from this specific resource (which seems like Josh use-case). Provenance use-cases are waiting for the FHIR-I CR to get applied.

Grahame Grieve (Dec 01 2021 at 19:31):

it does seem like provenance to me - need a profile on provenance that provides the details

John Moehrke (Dec 01 2021 at 19:32):

FHIR-I approved, but not yet applied -- FHIR-23076

Josh Mandel (Dec 01 2021 at 19:32):

Agreed that Provenance can convey these semantics; still, externalizing this information into Provenance is going to a tough sell. Same basic reason we see Meta.source used even though Provenance can tell this story.

John Moehrke (Dec 01 2021 at 19:36):

Josh, I am not saying something else should never be done (see fiveWs), but creating extensions for the same function seems like bad governance. Meaning, I would like you to help get Provenance to be functional for your use-cases, rather than building something else because Provenance seems not usable. but, I don't have the vsibility into your project that you do.

Grahame Grieve (Dec 01 2021 at 19:38):

there is an extension to forward reference Provenance. And that would be better than using a really complex extension. Or you put a contained provenance in the resource (no need to forward reference it, and the target reference is just #)

John Moehrke (Dec 01 2021 at 19:42):

yes, but we still don't have, even in Provenance, the ability to say this specific element at this Proveanance.entity.what
so, as much as I want to push Provenance upon Josh... It still does not solve his specific "element" need... until FHIR-I updates build.fhir.org to explain what that kind of a Reference looks like.

Grahame Grieve (Dec 01 2021 at 19:43):

I put it on my todo list for today or tomorrow

John Moehrke (Dec 01 2021 at 19:43):

thus, short term we need an extension for the "this element within..." this Reference. but that extension should look very much like what FHIR-I intends for R5 Reference use-case

Brian Alper (Dec 01 2021 at 23:01):

Would a "path" element of datatype uri be relevant for "this element within..."? This is what we are using in ArtifactAssessment Resource when referring to a specific element within the referenced resource.

Rik Smithies (Dec 01 2021 at 23:25):

My use case is for an element level Provenance target. A simple extension like Josh showed would do (i.e. extension/valueUrl). But it could also work outside of Provenance.
I don't see the need for an extension that has more than just a single element reference. If you need a list (mentioned in some of the jira referenced threads) then just repeat the extension, keeping it simpler for the majority of cases.

Josh Mandel (Dec 02 2021 at 16:40):

@John Moehrke Thinking about the use of Provenance here -- let's say I have a whole bunch of resources derived from a single source document, and a whole bunch of individual elements within these resources for which even more detailed attribution can be expressed. So I want to say things like:

• Condition 123 came from this source doc, character range X
• Condition 123's status came from this source doc X'
• Condition 123's onset date came from this source doc X''
• Condition 456 came from this source doc, character range Y
• Condition 456's status came from this source doc Y'
• Condition 456's onset date came from this source doc Y''

Is there a way to do this with just one Provenance instance, or would I need 2 or 6?

John Moehrke (Dec 02 2021 at 16:43):

I think that would need 6. The way it is today. Your need is not been presented before

Josh Mandel (Dec 02 2021 at 16:47):

Understood! Just trying to work through some examples and get an intuition here.

Rik Smithies (Dec 02 2021 at 17:19):

A single Provenance can have more than one target, so a single change can point at Condition 123 and 456, and could have several extensions to say which elements were affected. So it could be less than 6. But you would need at least one for doc X and doc Y, because they are different "changes" I assume.
I suppose it depends if we consider that a single "change process" (the source doc) can cause multiple FHIR level changes. I don't see why it cannot - they are conceptually part of one change. But if there are 2 change processes (2 documents, or 2 users doing different things) then that would presumably need 2 provenances.

Josh Mandel (Dec 02 2021 at 18:41):

In a "plain old extension" world, this is pretty easy: you just decorate each resource and element with a "came from NLP of ..." extension. It's less generic/abstract, which is part of what makes it more ergonomic.

Grahame Grieve (Dec 02 2021 at 19:01):

ergonomics is a matter of perspective. If an NLP system constructs a resource and litters it with NPL process related extensions, what should another system do when it updates a value? preserve the extensions, or strip some of them, or all of them?

I really think that having the NLP traceability in a separate resource has a lot going for it, even if it's more complex initially

Michelle (Moseman) Miller (Dec 02 2021 at 19:27):

FWIW, I believe my prior use cases were all around provenance, per

• https://chat.fhir.org/#narrow/search/pop.20and.20health.20and.20person.20and.20patient.20and.20provenance
• https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Source.20of.20information

Both of which led me to log J#20583 summarizing my two use cases (resolved in 2019, but not applied yet)

Grahame Grieve (Dec 06 2021 at 03:53):

http://build.fhir.org/extension-targetelement.html and http://build.fhir.org/extension-targetpath.html

John Moehrke (Dec 06 2021 at 12:43):

Can we work up the Provenance examples that @Michelle (Moseman) Miller indicated as examples of how to use this in Provenance? I am not exactly sure what it looks like in use.

Grahame Grieve (Dec 22 2021 at 11:24):

I added some examples

John Moehrke (Dec 22 2021 at 13:12):

ah, I had not seen those show up on build Provenance examples.

• Targeted Provenance Example #1 -- this is a .target use with targetElement extension. that is to an element by .id.
• Targeted Provenance Example #2 -- similar
• Targeted Provenance Example #3 -- this is a .target use with targetPath extension.
  These address the first usecase in FHIR-20583, the second more of the same but use with the extension in .entity.

Last updated: Apr 12 2022 at 19:14 UTC