FHIR Chat · Reference and uri when referencing resources

Stream: implementers

Topic: Reference and uri when referencing resources

Lloyd McKenzie (Feb 05 2018 at 22:26):

Today, FHIR-I agreed to re-open GF#12902 which had agreed to replace all appearances of uri as a reference mechanism with a choice of uri|Reference([appropriate resource type(s)]) based on late feedback from implementers who objected to the change. Issues to figure out include:
- Can a Reference include a canonical URL or only a server-specific URL? (Current policy says "yes", but some implementers were surprised about that)
- Can a Reference include a canonical URL with a "|[bus-version]" appended? Current policy doesn't enable this, but some want it
- If we just use uri and not Reference when pointing to other resources, how do we resolve the following issues:
-- Control over what types of resources can be referenced (including the ability of profiles being able to constrain what can be referenced). This includes the ability to make clear which "real" resources can be referenced (e.g. StructureDefinition, Questionnaire, PlanDefinition), but also the ability to allow/prohibit pointing to PDFs, word documents and any other non-FHIR artifacts that are also legal as a URI
-- Support for traceability when a "contained" resource points to its parent or is pointed to by its parent via uri rather than Referencesuch that the invariant requiring that contained resources point to or be pointed to by their container can still be tested

The decision here will impact many resources - essentially all resources that point to infrastructure or other defininitional/knowledge resources (including Questionnaire, PlanDefinition, ValueSet, etc.) We'll be taking this up on the FHIR-I call next Monday. Feel free to join us or share your thoughts here.

Lloyd McKenzie (Feb 05 2018 at 23:33):

My thoughts:
The outcome of this should allow us to do the following:
- Ensure that the base resources make clear whether a URI can resolve to a non-FHIR artifact, a FHIR artifact or both. If it can resolve to a FHIR artifact, it should be clear which artifact type(s) can be resolved to
- It should be possible for profilers to constrain a reference such that it they can control which resource(s) the reference is allowed to point to and/or whether referencing a non-resource is permitted or required. (Being able to constrain the mime-type of the target resource would be useful too.)
- When referencing resources, profiles should be able to use the standard mechanism to indicate whether the reference can be contained, bundled and/or referenced and the validator needs to be able to enforce those references
- References to definitional/infrastructure/knowledge resources need to be able to point to and from contained resources and the validator must support such references when confirming that the contained resource is properly referenced.
- It needs to be clear when and where canonical references and canonical version references can be used (and ideally have profiling control of that too - e.g. "this must point to a version-specific questionnaire canonical URL"
I expect these behaviors fall with in the 80% for most systems dealing with definitional/infrastructure/knowledge resources, but I'm open to arguments that they're not. (In any event, I'd expect validators for the reference implementations and profile authoring tools we endorse to support them.)

John Moehrke (Feb 06 2018 at 19:09):

what about Reference.identifier? how does it factor into this? I fear asking about Reference.display...

Lloyd McKenzie (Feb 06 2018 at 19:17):

It does suggest that if you want to point to a definitional artifact by business identifier rather than uri, that there'd be a need for Reference rather than uri as the data type. And yes, the absense of Reference.display when you just have a uri is a bit problematic too. It's hard to generate narrative if you don't have a display value to indicate what Questionnaire a response is for or what protocol an order is following or what value set an element is constrained to.

Ewout Kramer (Feb 15 2018 at 16:30):

Can a Reference include a canonical URL or only a server-specific URL? (Current policy says "yes", but some implementers were surprised about that)

I don't know whether "yes" means the first or the second option - but in my mind the references (with a small 'r') between conformance resources are done using "canonical urls", which aren't necessarily resolvable. One of these is StructureDefinition.url, which definition reads:

"An absolute URI that is used to identify this structure definition when it is referenced in a specification, model, design or an instance. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this structure definition is (or will be) published"

On the referencing side, we have for example ElementDefinition.type.profile, which definition says:
"Identifies a profile structure or implementation Guide that SHALL hold for the datatype this element refers to. Can be a local reference - to a contained StructureDefinition, or a reference to another StructureDefinition or Implementation Guide by a canonical URL. "

These definitions represents the mind shift that has been going on in the core team: in DSTU1 these (canonical) urls were actual addresses, and we said back then that they MUST resolve. This, however, is unmaintainable. These StructureDefinitions (and other conformance resources) may move from repository to repository, the original organization may go out of business or merge with another organization, be renamed etc. In every case, the canonical url may become unresolvable at a later moment. It therefore becomes more important to have a canonical url that represents a logical, more pertinent identifier than an actual physical location. The current definitions -as far as I interpret them- stress the fact that they are /identifiers/ in the first place, and references second.

This is adequately expressed in our models currently, since these references are now uri's. Changing them to References expresses an intent that does not align with this mindset, as far as I can see.

If you read http://hl7.org/fhir/references.html#canonical, this section /again/ stresses that resources may travel from location to location and that (to quote the section) "The canonical URL serves as a stable logical identifier".

Can a Reference include a canonical URL with a "|[bus-version]" appended? Current policy doesn't enable this, but some want it

I think http://hl7.org/fhir/references.html#canonical says this is true for our current "uri" coded canonical references. If (which I am not in facor of) we would change these to References, References would also need to accept the |[version] notation.

If we just use uri and not Reference when pointing to other resources, how do we resolve the following issues:
-- Control over what types of resources can be referenced (including the ability of profiles being able to constrain what can be referenced). This includes the ability to make clear which "real" resources can be referenced (e.g. StructureDefinition, Questionnaire, PlanDefinition), but also the ability to allow/prohibit pointing to PDFs, word documents and any other non-FHIR artifacts that are also legal as a URI

This sounds like a minor usecase to me personally, and I wonder whether this warrants the big change this GF tracker item is proposing.

-- Support for traceability when a "contained" resource points to its parent or is pointed to by its parent via uri rather than Referencesuch that the invariant requiring that contained resources point to or be pointed to by their container can still be tested

This is a good point, although I think we can alter the invariants to make this work "canonically" too. Not sure.

Patrick Werner (Feb 15 2018 at 16:33):

i think switching from uri to uri|Reference([appropriate resource type(s)])would be a great idea, we currently having a problem because of uri in Attachment and not be able to replace the temporary uri during a transaction: https://chat.fhir.org/#narrow/stream/implementers/subject/Reference.20file.20from.20Attachment/near/127232

Ewout Kramer (Feb 15 2018 at 16:34):

Yes, good that you mention that point! But couldn't that be fixed by just doing that in Attachment? That does not seem to be a canonical uri?

Patrick Werner (Feb 15 2018 at 16:38):

For our usecase, adding reference to Attachment would fix the the issue, correct. I just mentioned it as it is a related issue. The proposed switch would also solve our problem. We also would be happy with adding reference to Attachment.
As we want to prevent redundant work, should we add a tracker item for our issue and link it to the reopened item?

Simone Heckmann (Feb 15 2018 at 17:30):

True. Using _include to return the binary with the search results wouldn't work either!

Lloyd McKenzie (Feb 15 2018 at 18:06):

@Ewout Kramer Don't worry too much about the specific proposed change that was agreed to in GF#12902. Instead focus on the use-cases. There's a need to be able to control what type of artifacts are pointed to, do _include, _revinclude, identify whether the content is to be bundled/contained/referenced, identify profiles that will apply to references (and validate that those profiles hold), etc. All of the requirements that we have for referencing regular resources still apply when we reference infrastructure resources. What's different is that we want to be able to make references by canonical (and sometimes business-version-specific canonical) URLs.

Lloyd McKenzie (Feb 15 2018 at 18:07):

One of the powers of FHIR is that StructureDefinition and ValueSet, etc. are resources that behave like any other resource. We need to ensure that they do behave like any other resource.

Grahame Grieve (Feb 15 2018 at 20:51):

on the subject of attachment: it's a different subject, but changing attachment to a reference won't help with _include. And the transaction thing - servers should be fixing attachment.uri in a transaction

Grahame Grieve (Feb 15 2018 at 20:52):

as for canonical URLs: Reference is currently allowed to contain a canonical URL. @Ewout Kramer seems to think that it shouldn't but i don't know what grounds there are for that. Logically, at least, local registries are caches for canonical URLs. We don't make rules about caches, especially, no rule that you can't resolve any Reference(X) through a cache

Lloyd McKenzie (Feb 15 2018 at 21:21):

@Grahame Grieve Do you agree that the behavior of references to knowledge resources/infrastructure resources should be able to do the same things as we do for other resources - _include, contain, profiling inclusion/validation of references, etc.? (Obviously with the recognition that the use of canonical references and version-specific references adds extra capabilities/complexities that don't exist for other clinical/administrative resources.)

Grahame Grieve (Feb 15 2018 at 21:37):

not sure. for instance, I would not expect _include to be very useful in a typical canonical reference context

Lloyd McKenzie (Feb 15 2018 at 21:38):

Give me the Questionnaire along with the QuestionnaireResponse; Give me the ValueSets along with the StructureDefinition; Give me the ActivityDefinitions along with the PlanDefinition.

Grahame Grieve (Feb 15 2018 at 21:40):

quite often they would not be on the same server

Lloyd McKenzie (Feb 15 2018 at 21:40):

Maybe

Lloyd McKenzie (Feb 15 2018 at 21:41):

The canonical definitions, perhaps not. Local cached copies, quite often would be though.

Grahame Grieve (Feb 15 2018 at 21:41):

"The name of the search parameter which must be of type reference" .... but I suspect _include would work on canonical URLs on my server anyway

Ewout Kramer (Feb 16 2018 at 12:38):

as for canonical URLs: Reference is currently allowed to contain a canonical URL. @Ewout Kramer seems to think that it shouldn't but i don't know what grounds there are for that. Logically, at least, local registries are caches for canonical URLs. We don't make rules about caches, especially, no rule that you can't resolve any Reference(X) through a cache

I was aware it could (we do this locally in batches), but these are turned into http references after processing. I do think it's surprising to our users that References would just contain identifying canonical urls, and not be physical references, that is true.

Ewout Kramer (Feb 16 2018 at 12:40):

@Chris Grenz @Eric Haas @Rick Geimer @Sean McIlvenna @Marten Smits @Alexander Henket @Brian Postlethwaite @Thomas Tveit Rosenlund @Jens Villadsen @Simone Heckmann @John Moehrke @Jose Costa Teixeira @Richard Townley-O'Neill @Bryn Rhodes @Michel Rutten.

You are invited to take a look at this normative change to StructureDefinition!

Lloyd McKenzie (Feb 16 2018 at 15:37):

(And ValueSet and CodeSystem and PlanDefinition and most other knowledge and infrastructure resources - anything that points to something potentially by a canonical URL.)

Ben Spencer (Feb 16 2018 at 15:38):

would it make sense for canonical URLs to go into Reference.identifier instead, with some kind of system meaning "this is a canonical URL"?

Lloyd McKenzie (Feb 16 2018 at 15:45):

We could. Or we could have a boolean for "isCannonical" or a variety of other solutions. The key is having the ability to do with canonical references what we can do with regular references and the ability to differentiate between references to resources and references to other things.

Eric Haas (Feb 16 2018 at 18:46):

@Grahame Grieve what are we supposed to look at?

Grahame Grieve (Feb 16 2018 at 20:01):

I'm not sure. there's GF#12902, and then there's my request for comment at https://onfhir.hl7.org/2017/12/21/fhir-r4-ballot-community-consultation/ and then there's Ewout's comments in this thread

Ewout Kramer (Feb 19 2018 at 15:22):

would it make sense for canonical URLs to go into Reference.identifier instead, with some kind of system meaning "this is a canonical URL"?

We could, but that's only one part of the equation, but what to do about the references to these urls/identifiers? Should that be uri/Reference or [uri|reference]?

John Moehrke (Feb 19 2018 at 15:41):

Im not sure what the proposed change is at this point. I do agree with all the various problem definitions... Identifier vs URI vs URL ... so close, yet so far apart...

Grahame Grieve (Feb 19 2018 at 22:41):

Reopening for consultation one last time:

Grahame Grieve (Feb 19 2018 at 22:42):

https://onfhir.hl7.org/2018/02/19/community-consultation-urls-vs-references/

Richard Townley-O'Neill (Feb 20 2018 at 05:55):

Are these right?

What canonical does can be done in a roundabout way using Reference.identifier.value with Reference.identifier.system="urn:ietf:rfc:3986"

What url does can be done in a round about way with Reference.reference. But Reference.reference lets you also specify aggregation, targetProfile, and _include, while url does not.

Grahame Grieve (Feb 20 2018 at 06:02):

canonical: yes, but the rules around it are not there
url: no, because Reference must point to a resource (or something that would be a resource). url doesn't have to

Richard Townley-O'Neill (Feb 20 2018 at 06:12):

Michele Mottini (Feb 20 2018 at 14:30):

Sorry, late to the party, but what _is_ a canonical URL?

John Moehrke (Feb 20 2018 at 14:33):

see detail in the article https://onfhir.hl7.org/2018/02/19/community-consultation-urls-vs-references/

Michel Rutten (Feb 20 2018 at 14:39):

I like the proposed change. Canonical url's are very fundamental to FHIR, so it makes perfect sense to introduce a new datatype "canonical" to provide a clear and unambiguous definition of this special concept (vs. regular "uri"). Of course this breaking change will have some impact on existing logic, however it seems manageable and I think the benefits are worth it.

Michele Mottini (Feb 20 2018 at 14:43):

Ah got it, thanks @John Moehrke (I missed http://build.fhir.org/references.html#canonical)

Chris Grenz (Feb 20 2018 at 16:09):

Glad we're addressing this - it's one of the few areas we just went rogue in our implementation to avoid the ambiguity. Can someone clarify what's happening with the Reference type with this change? For example, ElementDefinition.binding.valueSet[x] currently allows valueSetReference. Would this be eliminated in favor of valueSetUri and valueSetCanonical?

Chris Grenz (Feb 20 2018 at 16:10):

I thought the critical distinction before was Reference was a declaration of intent to resolve to a FHIR resource whereas uri was a free-for-all.

Chris Grenz (Feb 20 2018 at 16:12):

Also, how does this impact the parsability rules here: http://build.fhir.org/references.html#literal ??

Chris Grenz (Feb 20 2018 at 16:14):

Do canonical's have to be in a FHIR normal form?

Lloyd McKenzie (Feb 20 2018 at 17:33):

@Chris Grenz We have a full enumeration of all the changes for the infrastructure resources in the updated change proposal. But yest, valueSetReference gets toasted in favor of valueSetCanonical. And we'll still have valueSetUri.

Lloyd McKenzie (Feb 20 2018 at 17:34):

Canonicals don't have to be in FHIR normal form. E.g. "http://loinc.org" is the canonical for the LOINC CodeSystem. And you could have "http://loinc.org|201801" (or whatever LOINC's version numbering system is - too lazy to look it up :))

Grahame Grieve (Feb 20 2018 at 20:02):

Also, @Michael Lawley has made a comment: https://onfhir.hl7.org/2018/02/19/community-consultation-urls-vs-references/#comments

Grahame Grieve (Feb 20 2018 at 20:02):

FHIR-I must consider the comment...

Lloyd McKenzie (Feb 20 2018 at 20:12):

A question: if an element with a type of "canonical" can point to multiple resources (e.g. Questionnaire, PlanDefinition or ActivityDefinition), is there a need to be able to communicate the "type" of resource being referenced, or should we just expect the recipient to search against all possible types. If there is such a need, do we make this a complex structure or add an extension? If a complex structure, do we make the type required?

Lloyd McKenzie (Feb 20 2018 at 20:12):

(Note that canonical URLs can't be reliably parsed to extract the resource type.)

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

where does this arise?

Lloyd McKenzie (Feb 20 2018 at 20:15):

Procedure.instantiates would be one place. EventDefinition.type.profile would be another (StructureDefinition vs. ImplementationGuide)

Grahame Grieve (Feb 20 2018 at 20:17):

I don't know about instantiates. EventDefinition.type.profile I can't imagine why you'd need to know which type without needing to resolve the content anyway

Lloyd McKenzie (Feb 20 2018 at 20:19):

Yes, you'll need to resolve. But to resolve, right now, you'll need to do a search of your caches for both StructureDefinition and ImplementationGuide

Grahame Grieve (Feb 20 2018 at 20:20):

shouldn't- canonicals can never conflict between types. Just do all at once

Lloyd McKenzie (Feb 20 2018 at 20:21):

That presumes you have a common cache across all types. If you're doing it as a search where URL=[canonical], then you're going to have to search multiple endpoints.

Lloyd McKenzie (Feb 20 2018 at 20:21):

I'm fine with us saying "that's ok". I just wanted to make sure we discussed and agreed.

Grahame Grieve (Feb 20 2018 at 20:23):

you can do

GET [base]?url=[canonical]&_type=StructureDefinition,ImplementationGuide

Lloyd McKenzie (Feb 20 2018 at 20:28):

If the server supports that, sure.

Lloyd McKenzie (Feb 20 2018 at 20:31):

The set of possible resources is presumably much narrower than we have for Reference where there's a not-small number of places where we allow Reference(*). I expect that canonical will likely be constrained to 3-4 resource types max. And the vast majority are limited to only 1. So it's legitimate for us to say that cross-resource searching is expected and acceptable.

Grahame Grieve (Feb 20 2018 at 20:32):

so we should document that and otherwise say that if you think that it matters, there's always extensions

Grahame Grieve (Feb 20 2018 at 20:34):

with regard to Michael's comments: After some thought, I could actually deal with the renaming personally; I'd just make an alias in the reference implementations and not worry about it otherwise.

Grahame Grieve (Feb 20 2018 at 20:34):

but it's not scratching an itch that i have

Lloyd McKenzie (Feb 20 2018 at 20:50):

So ValueSet.url has a type of uri - and that's actually what we want. It doesn't have to resolve. Where I believe that the new "url" type is expected to resolve. At the same time, we still want to leave ValueSet.url named as it is because we want to encourage the use of urls

Elliot Silver (Feb 20 2018 at 20:59):

The fact that canonical urls don't have to reference FHIR resources, or live under [base]/[resourcetype] means, in my mind, that canonical urls can't be the target of a Reference. I see canonical urls as closer to a type of identifier (which might end up being resolvable), than as a type of reference.

Peter Jordan (Feb 20 2018 at 22:42):

A couple of questions. Firstly would the proposed new data types ('canonical' and 'url') be classified as Primitive Types or Complex Types? Secondly, in the list of proposed changes to element data types, I don't see any where the type is to be changed to 'url' am I missing something or are there other use cases for creating a 'url' data type?

Grahame Grieve (Feb 20 2018 at 22:46):

primitives. Attachment.url will be changed to url. Bryn says there's some elements in the CDS resources that will be changed too

Elliot Silver (Feb 20 2018 at 23:01):

Why are some elements changing to canonical | uri? Are you expecting some of the referenced instances (they all look to be ValueSets) to not have canonical uris?

And again why are canonical uri not just identifiers?

Grahame Grieve (Feb 20 2018 at 23:06):

a few things, the references are not only to ValueSet resources. Like the binding value sets

Grahame Grieve (Feb 20 2018 at 23:06):

and same answer again ;-)

Peter Jordan (Feb 20 2018 at 23:17):

Adding 'url' as a (sub) type of the existing 'uri' data type makes sense to me. However, I have doubts as to whether 'canonical' sits at that level of abstraction - it's really a specific (sub) type of 'url' rather than an immediate sub-type of 'uri' - and I'm not sure if exposing it as a data type will result in better outcomes than declaring that a given 'url' data type shall contain a canonical representation.

Grahame Grieve (Feb 20 2018 at 23:20):

canonicals do not have to be urls. they can be uris

Lloyd McKenzie (Feb 20 2018 at 23:26):

And when they use the [canonical]|[version] syntax, they almost certainly won't resolve.

Peter Jordan (Feb 20 2018 at 23:40):

Well both the Community Consultation page and the section on versioning in the specification ultimately point to the term 'Canonical Url' - but, either way, I don't see how creating a primitive data type of 'canonical' will ensure that a unique reference is placed in any given element .

Grahame Grieve (Feb 20 2018 at 23:44):

as opposed to some flag on the element definition? what would be different?

Peter Jordan (Feb 21 2018 at 00:09):

A flag on an element definition isn't a (very) late breaking change for implementations.

Elliot Silver (Feb 21 2018 at 00:28):

a few things, the references are not only to ValueSet resources. Like the binding value sets

Why aren't these ValueSet resources? Will the documentation be clear not to use uri if there is a ValueSet resource?

Lloyd McKenzie (Feb 21 2018 at 00:28):

It's more about the behaviors for "Canonical" being very different from the behaviors for "uri" and "url". With canonical, you can do _include, you can specify targetProfile and can set aggregationMode like you can for Reference. With url you can't (though there's a separate discussion exploring allowing _include in a different way for url).

Lloyd McKenzie (Feb 21 2018 at 00:29):

It's not a valueset resource if it's a web page - like we point to for the Mime type code system.

Lloyd McKenzie (Feb 21 2018 at 00:30):

We certainly prefer real ValueSet instances. But even in the core spec there are times when we can't because the content just isn't published in a way that allows computational representation in a maintainable/sustainable way.

Grahame Grieve (Feb 21 2018 at 00:31):

saves us from boiling the ocean

Elliot Silver (Feb 21 2018 at 00:34):

OK, I shouldn't have focused on ValueSet. What I should have asked is, where do we need canonical | uri? The web page example given by Lloyd works for canonical. I don't see a problem with the binding value sets having a canonical url. So, where is uri needed?

Grahame Grieve (Feb 21 2018 at 00:35):

"The web page example given by Lloyd works for canonical" - uh, no it doesn't. it's not actually a value set

Grahame Grieve (Feb 21 2018 at 00:36):

but all the places where we proposed canonical | uri are all value set references

Elliot Silver (Feb 21 2018 at 00:37):

Why isn't it a value set? What's an example of someplace that needs uri?

Grahame Grieve (Feb 21 2018 at 00:38):

because it's a web page that describes a code system and a grammar for building valid codes. We won't have a value set for it

Lloyd McKenzie (Feb 21 2018 at 00:40):

canonical must resolve to a real resource. url resolves to something that isn't a resource (PDF, web page, JPEG, MS-Word document... :))

Lloyd McKenzie (Feb 21 2018 at 00:41):

canonical is like Reference, except with Reference you can do a direct GET. With canonical you need to parse the string to split the URL and version and then do a search against candidate resource types in your local cache and if you don't find it, then do a query against the base URL with the version (if any)

Elliot Silver (Feb 21 2018 at 00:41):

Oh. That wasn't clear earlier.

So what canonical maps to is different than what, eg., ValueSet.url maps to?

Lloyd McKenzie (Feb 21 2018 at 00:42):

canonical maps to ValueSet.url plus possibly ValueSet.version

Elliot Silver (Feb 21 2018 at 00:42):

OK, but ValueSet.url doesn't need to map to a ValueSet resource (although it's polite if it does).

Lloyd McKenzie (Feb 21 2018 at 00:42):

So you search your local/cached set of value sets for a match. If no luck, you try local registries and if still no luck you hit the ValueSet.url which should ideally resolve.

Elliot Silver (Feb 21 2018 at 00:47):

canonical must resolve to a real resource. url resolves to something that isn't a resource (PDF, web page, JPEG, MS-Word document... :))

canonical is like Reference, except with Reference you can do a direct GET. With canonical you need to parse the string to split the URL and version and then do a search against candidate resource types in your local cache and if you don't find it, then do a query against the base URL with the version (if any)

So you search your local/cached set of value sets for a match. If no luck, you try local registries and if still no luck you hit the ValueSet.url which should ideally resolve.

The first statement there doesn't match the following two. The first says that canonical must resolve; the later two says it may.

Grahame Grieve (Feb 21 2018 at 00:49):

if it doesn't resolve to a resource, it's an error

Grahame Grieve (Feb 21 2018 at 00:49):

where as with URL, if it doesn't... it might be a problem

Grahame Grieve (Feb 21 2018 at 00:50):

or it might not be a resource.

Elliot Silver (Feb 21 2018 at 00:54):

So, I have a ValueSet.url. And whether I reference that in OperationDefinition.binding.valueSetUri or in OperationDefinition.binding.valueSetCanonical depends on whether the thing at that url is a ValueSet resource?

Grahame Grieve (Feb 21 2018 at 00:58):

if you have a ValueSet.url, then you would use valueSetCanonical

Elliot Silver (Feb 21 2018 at 00:58):

DICOM is defining ValueSets for all their context groups, like CID 29 Aquisition Modalities. The ValueSet.url is set to the webpage of the DICOM spec where that context group is defined. Linked from that page is the ValueSet, along with the context group in other formats, e.g., IHE SVS. Can the ValueSet be referenced by canonical or by a uri element?

(see http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_29.html)

Peter Jordan (Feb 21 2018 at 01:02):

canonical maps to ValueSet.url plus possibly ValueSet.version

I believe that it was agreed in NOLA, that ValueSet.url should contain the 'single source of truth' for the ValueSet (current version unless a specific, and alternative, version is also passed in the request). It does not necessarily point to the instance of the Value Set on the server that 's the subject of the request (i.e. my server might contain some of the HL7 FHIR value sets, but the SSOT is an HL7/FHIR server).

Grahame Grieve (Feb 21 2018 at 01:03):

in your case, Elliot, you would use canonical, since there's a valueset that exists with that url as it's ValueSet.url

Elliot Silver (Feb 21 2018 at 01:04):

But it doesn't resolve -- which you said is an error.

Peter Jordan (Feb 21 2018 at 01:08):

BTW: is ValueSet.url still going to be of data type uri ?

Grahame Grieve (Feb 21 2018 at 01:15):

yes

Grahame Grieve (Feb 21 2018 at 01:16):

I'm not sure what you mean 'doesn't resolve' - it resolves by a different path

Elliot Silver (Feb 21 2018 at 01:19):

So to use a canonical value, there must be an "official" resource defined, but it doesn't have to exist at the url listed in the canonical value?

Grahame Grieve (Feb 21 2018 at 01:23):

yes

David Hay (Feb 21 2018 at 20:09):

need to be explicit in the spec what 'resolve' means...

Robert McClure (Feb 21 2018 at 22:04):

@Grahame Grieve @Peter Jordan Peter is correct about what I thought we decided on Valueset.url - this was the SOT "universal identifier" for the resource, and it may not "FHIR resolve = pass back the resource". Is this a change from that understanding? @Elliot Silver example from DICOM does not "FHIR resolve" by my definition at all. The fact that some other url will FHIR resolve is immaterial to the the fact that the url in valueset.url provides useful information to the human reader. I must be very lost here...

Grahame Grieve (Feb 22 2018 at 06:14):

I don't think we have changed anything. I'm not sure where the confusion comes from

Ewout Kramer (Feb 22 2018 at 09:49):

with regard to Michael's comments: After some thought, I could actually deal with the renaming personally; I'd just make an alias in the reference implementations and not worry about it otherwise.

What the scale of the change - this is about changing names of elements to "uri" (instead or "url")? Don't think we have many of those?

Grahame Grieve (Feb 22 2018 at 09:51):

I'd change them to canonical not uri. I don't really like the change. But I could deal with it personally

Ewout Kramer (Feb 22 2018 at 09:56):

Hi Robert, no, we don't change behaviour or this "universal identifier" - in fact Valueset.url and StructureDefinition.url etc are not touched by this change at all. So, you are not lost, nor do you have to change your understanding.

What we have done is made more explicit which elements in other resources are _referring_ to this Valueset.url and StructureDefinition.url. Right now, in R3, you had to just know (and it was not always documented). We're now "flagging" each of the places where we refer to such a universal identifier (which we call canonical uri), so developers know they have to resolve it indirectly, not by going to a physical location (e.g. including the hostname etc.).

Lloyd McKenzie (Feb 22 2018 at 16:19):

So the proposal would be to change "CodeSystem.url : type=uri" to "CodeSystem.canonical : type=uri"?

Lloyd McKenzie (Feb 22 2018 at 16:21):

I could live with it too. It adds precision at the cost of sylables and makes the spec a bit more high-brow. Aesthetically, my leaning is to stick with url. We should however make sure that the short description and full definition use the word "canonical".