Stream: terminology
Topic: GF#17570
Rob Hausam (Jul 29 2018 at 23:27):
I've added GF#17570 to capture the continuing concern expressed on the Value Set Expansion (VSE) call last week about the "authoritative source" for ValueSet resources. @Robert McClure @Lloyd McKenzie @Grahame Grieve
Grahame Grieve (Jul 29 2018 at 23:47):
Since the interpretation is to be left to implementer discretion, Resource.meta.source can't be used to provide a consistent and reliable indication of the "authoritative source" as earlier described
Grahame Grieve (Jul 29 2018 at 23:48):
so I don't follow that. Why does this mean that you can't use that?
Grahame Grieve (Jul 29 2018 at 23:48):
the publisher sets the source, and then that's the source... so I'm not seeing the problem here
Grahame Grieve (Jul 29 2018 at 23:49):
is the group claiming that this is not provenance information?
Grahame Grieve (Jul 29 2018 at 23:49):
or is the group claiming that value sets are somehow very special?
Rob Hausam (Jul 30 2018 at 00:02):
No, I don't think so - but they're obviously of particular interest. The main issue I think is that since the interpretation of meta.source is left to implementer discretion it's not a reliable source for that meaning.
Grahame Grieve (Jul 30 2018 at 00:06):
I'm not sure why that's true. If you see Resource.meta.source and it has a value, how would you interpret it differently to the "authoritative source for the value set"?
Rob Hausam (Jul 30 2018 at 00:08):
Well, because it says that it is "A uri that identifies the source system of the resource". I don't think that "source system" necessarily and obviously means the same thing as "authoritative source"? That's the basis of the concern.
Grahame Grieve (Jul 30 2018 at 00:09):
but the authoritative source is clearly 'the source system of the resource'. surely...
Rob Hausam (Jul 30 2018 at 00:17):
It doesn't really say that. It also says "The source may identify another FHIR server, document, message, database, etc." I think I would be most inclined to think that "source system" is "where I got it from" - which might not be conveying any idea of the original or current "authoritative" source at all (and there can only be one). If we added language that said that 'source' is actually intended to convey the notion of the current (not necessarilyy the same as the original) "authoritative" source (and not to be used for something else), then that would probably be fine.
Grahame Grieve (Jul 30 2018 at 01:49):
so I think that there' s a perspective problem here. We don't need to say 'this is the only use of the element' in order for that to be a valid use of the element, nor do we need to say 'this is the only use of the element' in order for the value set publishers to use it that way
Grahame Grieve (Jul 30 2018 at 01:50):
I'm not sure what the story is that shows why using .meta.source is a problem
Rob Hausam (Jul 30 2018 at 02:04):
I agree that it's reasonable to have further discussion about that. If we can state for ValueSet that this is the only expected use case for meta.source (it doesn't really matter what it might be used for with other resources), then it should work. If there is a need to express some additional use of "source" as well as the "authoritative source" for ValueSet (I'm not thinking of anything at the moment), then there would still be an issue because you can only have one.
Grahame Grieve (Jul 30 2018 at 02:05):
so the question isn't 'is that the only use' but whether any other use would be something that a value set author wanted to make as well. that's where I'm not seeing the problem
Rob Hausam (Jul 30 2018 at 02:10):
I think that's pretty much what I just said? As I said, I don't see a problem at the moment, either. Maybe we can assume that there likely isn't one and proceed accordingly. In that case we would need to document that understanding as the meaning of meta.source when used with ValueSet.
Peter Jordan (Jul 30 2018 at 03:30):
The quest for the single source of truth
Grahame Grieve (Jul 30 2018 at 06:34):
I guess what to worry about is whether parties decide that they can rewrite the .meta.source and use it as a last hop source rather than preserving it as original source.
Grahame Grieve (Jul 30 2018 at 06:36):
so we could add language at the general level that while overwriting a stated source is not illegal, systems SHOULD only rewrite the source when they have something to say about the provenance of the resource.
Rob Hausam (Jul 30 2018 at 11:17):
Something like that might work. But there really are three choices (at least) - original source, current "authoritative" source, and "last hop" source. It's the second that is the one of interest for this purpose, so the language would have to be pretty specific. Assuming that the original and current sources had diverged at some point (which is expected to be common), if anyone wanted to use either the original or "last hop" source for any reason there wouldn't be a place to put it.
Grahame Grieve (Jul 30 2018 at 11:18):
so copies taken from before the authoritative source moved would be just wrong - that's just how it is.
Grahame Grieve (Jul 30 2018 at 11:19):
you could use provenance to track the original source if you really wanted to track it after the authoritative source moves
Rob Hausam (Jul 30 2018 at 11:20):
right - on both counts
Grahame Grieve (Jul 30 2018 at 11:21):
and also provenance for last hop if you really wanted to capture it....
Rob Hausam (Jul 30 2018 at 11:46):
agree
I can come up with some language and we can look at it on the tracker issues call today
Robert McClure (Jul 30 2018 at 12:09):
tl;dr.
The point is that resource.meta.source should be about the particular resource in hand, say a valueset resource that is only an expansion. You'd want to know who actually did the expansion and we assume that resource.meta.source should be the local server. We need a different element that has the authoritative source for the value set definition - the CLD - likely the one that could have been used to create that resource expansion. Note that the valueset.id could easily be some old url that no longer is involved.
Rob Hausam (Jul 30 2018 at 12:46):
We could say that if the 'compose' element (the CLD) is present, then meta.source (if populated) is expected to be the current authoritative source for the ValueSet resource (which includes the definition). The authoritative source for the ValueSet resource would not be expected to include a specific expansion, so it wouldn't be stating or implying anything about that. If an expansion is additionally present (along with 'compose') in a ValueSet resource instance, then additional provenance that tracks the expansion could be included (but would not be required). The fact that the provenance is related specifically to the 'expansion' element in ValueSet would be specified in Provenance.activity (via the extensible binding or by a specific code for this purpose that could be added to provenance-activity-type).
Rob Hausam (Jul 30 2018 at 12:49):
That's at least a straw man from what I can see right now for how this might work.
John Moehrke (Jul 30 2018 at 13:28):
I have often wondered about meta.source. I have read it as meaning the source from which it was received. That might be the original source, but all that is known is that it was received from that source. That source might have received it from another source. That source might be the author.... Knowing where one received the data is an important piece of knowledge.
Rob Hausam (Jul 30 2018 at 13:32):
Actually, I think I would like to revise what I said slightly:
ValueSet meta.source (if populated) is expected to be the current authoritative source for the ValueSet resource (which includes the definition - even if the definition is not present in a particular resource instance). The authoritative source for the ValueSet resource is not stating or implying anything about value set expansions (even if the authoritative source itself publishes a particular expansion, which is not expected). If an expansion is present in a ValueSet resource instance then provenance that tracks the expansion specifically may be included (but is not required). The fact that the provenance is related specifically to ValueSet.expansion is specified in Provenance.activity (via a specific code for this purpose that may be included via the extensible binding or that could be added to provenance-activity-type).
I think that this (or something close to it) is what will be required if we use meta.source for representing the ValueSet authoritative source.
Rob Hausam (Jul 30 2018 at 13:35):
My understanding would have been generally the same as yours, John - that it is "the source from which it was received". So if we use it for the ValueSet "authoritative source" then we will have to be very specific about stating that (as I attempted above).
Robert McClure (Jul 30 2018 at 16:15):
@Rob Hausam I'm sorry, but this seems very convoluted and counter-intuitive. I'm also concerned, as Graham said he was way at the top of this thread, that you're crafting a one-off different approach to the meaning of meta.source for value sets. I also am concerned that a basic, fundamental functionality about the resource itself will require implementation of the provenance resource, something I don't think anyone is really doing yet.
I do not understand why there is pushback against something that is a core need for value sets and has been in the VSD from day one. Is FHIR valueset going to be conformant with VSD or not?
Rob Hausam (Jul 30 2018 at 16:30):
I'm just looking for a way to bring the points of view together. If this doesn't do it, I'm OK with that - it's part of the discussion. We already have extensions for valueset-expansionSource and valueset-parameterSource. I will suggest that we add a standard extension for valueset-authoritativeSource.
Grahame Grieve (Jul 30 2018 at 18:22):
I think that the expansion use case is helpful in illustrating the issue
Grahame Grieve (Jul 30 2018 at 18:24):
OTOH:
I do not understand why there is pushback against something that is a core need for value sets and has been in the VSD from day one. Is FHIR valueset going to be conformant with VSD or not?
Grahame Grieve (Jul 30 2018 at 18:25):
there has been no pushback against the requirement. But value set does not have to have this as a core element to be conformant with VSD.
Grahame Grieve (Jul 30 2018 at 18:29):
so I went looking at our current extensions to see whether any other resource had anything like this, and ran into the extension http://hl7.org/fhir/StructureDefinition/valueset-sourceReference which is defined at build.fhir.org/extension-valueset-sourcereference.html
Grahame Grieve (Jul 30 2018 at 18:29):
is this the same thing? if it's not, what is it? And isn't the definition at variance with the type?
Grahame Grieve (Jul 30 2018 at 18:31):
and there's also http://hl7.org/fhir/StructureDefinition/valueset-trusted-expansion
Grahame Grieve (Jul 30 2018 at 18:31):
is this different? how?
Grahame Grieve (Jul 30 2018 at 18:32):
And finally, is there anything about this requirement that is value set specific?
Robert McClure (Jul 31 2018 at 13:41):
So the VSD has the following for source reference:
Definition: reference to prior work used as a basis in authoring of this Value Set
Description: This text is intended to act as a citation to work done elsewhere that is not part of the current stewarding process where the referenced source is in some way a basis of the current Value Set Definition.
Usage Notes: This may refer to other Value Set Definitions, research articles, or other resources. This is not intended to document uses of the Value Set Definition, for this, see Section 5.2.2.3.7 below. For example, the identifier for a Value Set Definition that was cloned to begin the work on this Value Set Definition, or a pointer to a published article that describes appropriate concepts. There may be multiple source references.
Data Type: ST
Cardinality: 0..*
I will say that the usage note statement of "This may refer to other Value Set Definitions,..." was not thought to be a reference to the authoritative source for this entire value set definition. This was planned to be information that was critical for crafting the value set definition. I personally see the authoritative source as something quite different: it is the known official source as specified by the official steward, and not a partial basis for the final content, which was the intent of this element. If no one wants the source information as defined, then I would rather we remove this and make a new element because changing the meaning would make this inconsistent with VSD.
Rob Hausam (Jul 31 2018 at 14:03):
@Robert McClure Do you agree with adding a valueset-authoritativeSource extension for this?
Robert McClure (Jul 31 2018 at 14:06):
yes, I am fine with this as an extension
Rob Hausam (Jul 31 2018 at 14:08):
Sounds good. I'll add that as the proposed resolution.
Michael Lawley (Aug 03 2018 at 04:53):
I have also interpreted meta.source as "where this specific rendering of the resource was generated", so I'm uncomfortable with it being used to convey what is effectively provenance.
Which leads to the question of why the Provenance resource isn't the appropriate approach?
Grahame Grieve (Aug 03 2018 at 05:24):
it is
Grahame Grieve (Aug 03 2018 at 05:25):
but authoritative source isn't actually provenance in the classic sense, if you read the definition carefully. In fact, I think it's badly named
Rob Hausam (Aug 03 2018 at 12:51):
We still have to approve it. What's a better name?
Grahame Grieve (Aug 03 2018 at 13:02):
citation?
Lloyd McKenzie (Aug 03 2018 at 14:38):
That's likely to be confused with stuff in RelatedArtifact which is used for literature citations
Rob Hausam (Aug 03 2018 at 14:39):
agree with Lloyd
Grahame Grieve (Aug 03 2018 at 19:20):
what makes it different from literature citations?
This text is intended to act as a citation to work done elsewhere that is not part of the current stewarding process where the referenced source is in some way a basis of the current Value Set Definition
Lloyd McKenzie (Aug 03 2018 at 20:26):
If that's what it is, then use the existing element for it.
Grahame Grieve (Aug 03 2018 at 20:43):
extension, actually
Eric Haas (Aug 04 2018 at 19:18):
what exising element or extension are you referring to? I made this one that may work... http://build.fhir.org/extension-event-relatedartifact.html
Grahame Grieve (Aug 04 2018 at 21:25):
oh hmm I thought we had defined one for all resources. maybe we should do that to that one...?
Carol Macumber (Aug 06 2018 at 18:57):
@Robert McClure Do you agree with adding a valueset-authoritativeSource extension for this?
+1, would be nice if this could be defined for all resources instead of just valueset specific.
Grahame Grieve (Aug 06 2018 at 20:44):
so the definition, the name, and the discussion are all at odds with each other. Not encouraging me to do anything for ValueSet let alone all resources. The definition as it stands matches an element defined on resources like PlanDefinition - we could define an extension for this and bring it into a core element in R5
Last updated: Apr 12 2022 at 19:14 UTC
