Need for instantiatesUri in addition to instantiatesCanonical?

Several resources such as CarePlan, MedicationRequest, Communication, etc contain both an instantiatesCanonical reference element and an instantiatesUri uri element. Could anyone clarify why the instantiatesUri element is needed? In general all of the reference targets also include a uri element to link to the external canonical source.

instantiatesCanonical will point to the “url” element of a formal resource - and you should expect to be able to resolve it to a FHIR resource instance. instantiesUri should still point to a protocol or questionnaire, but it’s not expected to be represented as a FHIR resource. It might be a PDF, a web page, a link to a Word document or something like that. If you don’t think that’s sufficiently clear in the spec, feel free to submit a change request.

Understood but that wasn’t quite what I was asking. If you have a CarePlan resource and want to link to an external plan definition you can either do so directly through the CarePlan.instantiatesUri element, or indirectly through a CarePlan.instantiatesCanonical reference to PlanDefinition with the PlanDefinition.url element set.

I guess my real question is what is the use case for CarePlan.instantiatesUri? When would you want to set that element as opposed to putting the URI on the target resource? Is it just to avoid the hassle of needing to create an instance of one of the canonical resource types if all you need is a URI, or is there some other reason?

If you’re pointing to a FHIR resource instance, always use instantiatesCanonical. If you’re pointing to a website or PDF sitting somewhere or some set of instructions from a medical journal, you use instantiatesUri. instantiatesUri is only for cases when the target isn’t expressed in FHIR and it’s not practical/feasible to have someone try to convert it and expose it as FHIR.

1 Like