Stream: conformance
Topic: Reference or uri for canonical reference
Ewout Kramer (Nov 28 2017 at 12:17):
During the FHIR-I call yesterday evening we discussed gforge issue GF#12902, which led us to notice that the specification is not consistent about how to reference from one conformance resource from another. In many places, we use the "uri" datatype, but in others Reference([your conformance resource here]) is used.
I expect this comes from our shift in thinking, slowly evolving from a world where all canonical references were a RESTful url, to the situation were they are rather more a symbolic identity.
We concluded that we needed to consult the broader community to move ahead, so please take a look at these examples and share your opinions!
- Capabilitystatement.profile (which is a reference)
- StructureDefinition.base (uri), OperationDefinition.base (reference)
- ElementDefinition.binding.valueSet[x] (both - with different interpretation)
- ElementDefinition.type.profile (uri)
- ElementDefinition.type.code (uri constrained by a valueset)
Eric Haas (Nov 28 2017 at 16:34):
"I expect this comes from our shift in thinking, slowly evolving from a world where all canonical references were a RESTful url, to the situation were they are rather more a symbolic identity." can you elaborate on what you mean by a 'symbolic identity'?
Ewout Kramer (Nov 28 2017 at 16:59):
I mean the canonical starts to be more of an opaque reference for which the context (say a validator in a registry) knows how to resolve it to an actual structuredefinition than that it is a RESTful url where the structuredefinition can be found. Does that clarify?
Lloyd McKenzie (Nov 28 2017 at 17:55):
Reference allows the use of canonical URLs (including versions) and has the benefit of making clear what resource you're pointing to and allowing the validator to resolve the reference as part of the validation process. So my preference would be to standardize on using Reference rather than uri.
Eric Haas (Nov 28 2017 at 19:30):
yes ty
Richard Townley-O'Neill (Nov 29 2017 at 00:41):
If we wish to focus on the idea that Reference follows "References SHALL be a reference to an actual FHIR resource, and SHALL be resolvable" (a comment in the Reference resource definition), this proposal makes good sense to me.
It seems that ElementDefinition.binding.valueSet[x]will stay as a choice of data types. Ugly.
Ewout Kramer (Nov 29 2017 at 08:57):
and allowing the validator to resolve the reference as part of the validation process.
That is true for both uri and Reference(). The only slight difference is that References suggest the validator may go out on the web to fetch the referenced StructureDefinition, which is less so with uri. But in practice, a validator will not go out on the web, but instead search for the given uri in a database of known structuredefinitions, on a filesystem etc, so all it needs is a uri to match the reference to one of the conformance resources in its "storage".
Lloyd McKenzie (Nov 29 2017 at 15:47):
Well, with a Reference, there's an expectation for resolvability to a resource. With a URI, there's no such expectation (a ValueSet uri could be an arbitrary website somewhere.
Last updated: Apr 12 2022 at 19:14 UTC
