Community Consultation: URLs vs References

In an earlier post, I asked for community for comment on changing some elements from uri to Reference:

For the conformance resources, change all elements of type uri where they will always point to a Conformance resource to type Reference(XX).  This will include changes to StructureDefinition (GF#12902)

We received some feedback, and have just revisited the issue. The feedback made it clear that there are 2 different issues on the table here:

  • When you refer to content outside the resource, must the content refer to an actual FHIR resource? or is it allowed to refer to something else (like a PDF)?
  • When you follow the reference, should you actually look it up like a URL? or should you treat it as a canonical reference and look it up by URL on a terminology service or a registry?

After considerable discussion, we agreed to make a set of changes that are much more pervasive to the specification, but actually make less change to implementations. Specifically, we propose:

  • Define two new types of URI called “canonical” and “url”.
  • canonical is an URI (IRI, URL, absolute or relative that refers to a FHIR resource by it’s canonical URL (e.g. that has a .url element). This type allows allows version (using canonical versions)
  • url is always a literal reference (used in a few places including Attachments)
  • References don’t contain canonical URLs anymore (currently this allowed)
  • Canonical works like reference in that: you can specify aggregation, targetProfile, and _include (which means that you’d see canonical(PlanDefinition|ActivityDefinition))
  • uri would still be used where the target of a reference might not be a URL. The Lookup pathway is unspecified (either canonical or literal)

The following elements would have their types changed:

  • StructureDefinition.baseDefinition = canonical
  • ElementDefinition.type.code = uri
  • ElementDefinition.type.profile = canonical
  • ElementDefinition.type.targetProfile = canonical
  • ElementDefinition.constraint.source = canonical
  • ElementDefinition.binding.valueSet[x] = canonical, uri
  • CodeSystem.valueSet = canonical
  • CodeSystem.supplements = canonical
  • ValueSet.include.valueSet = canonical
  • ImplementationGuide.package.resource.source[x] = [think about it]
  • ImplementationGuide.package.resource.exampleFor = canonical
  • ImplementationGuide.global.profile = canonical
  • CapabilityStatement.instantiates = canonical
  • CapabilityStatement.implementationGuide = canonical
  • CapabilityStatement.rest.searchParam.definition = canonical
  • CapabilityStatement.rest.compartment = canonical
  • CapabilityStatement.rest.resource.profile = canonical
  • CapabilityStatement.rest.resource.supportedProfile = canonical
  • CapabilitStatement.rest.operation.definition = canonical
  • CapabilityStatement.messaging.supportedMessage.definition = canonical
  • CapabilityStatement.document.profile = canonical
  • SearchParameter.derivedFrom = canonical
  • SearchParameter.component.definition = canonical
  • OperationDefinition.targetProfile = canonical
  • OperationDefinition.binding.valueSet[x] = uri | canonical
  • OperationDefinition.base = canonical
  • OperationDefinition.inputProfile = canonical
  • OperationDefinition.outputProfile = canonical
  • OperationDefinition.param.binding.valueSet = uri | canonical
  • QuestionnaireResponse.questionnaire = canonical
  • Questionnaire.derivedFrom = canonical
  • Questionnaire.options = canonical
  • MessageDefinition.base = canonical
  • MessageDefinition.parent = canonical
  • MessageDefinition.replaces = canonical
  • MessageDefinition.focus.profile = canonical
  • MessageDefinition.allowedResponse.message = canonical
  • GraphDefinition.profile = canonical
  • GraphDefinition.link.target.profile = canonical
  • Meta.profile = canonical
  • ExampleScenario.workflow = canonical
  • ConceptMap.source[x] = uri | canonical
  • ConceptMap.target[x] = uri | canonical
  • ConceptMap.unmapped.url = canonical
  • TerminologyCapabilities.expansion.definition = canonical
  • TerminologyCapabilities.expansion.profile = canonical.

(note that this list only includes changes to infrastructure resources – other resources will also be affected)

Given that this is the second consultation on this issue, and that time is running tight, we’ll only open this consultation for a week – comments must be in by CoB Monday 26th February

2 thoughts on “Community Consultation: URLs vs References”

  1. +1 on cleaning up the URI / URL stuff, but the write-up is still potentially confusing as your list of affected properties still refers to “uri” but the write-up above defines “​canonical” and “url”.

    Previously I have suggested that all elements that were called “url” but were actually typed as URI should be renamed to be what they are: “uri”, but with this proposal it seems like it might be viable and actually useful to get the naming right – with changing the .url elements to .uri or to .canonical.

    Like

    Reply

Leave a comment