Stream: implementers
Topic: Mental model for canonical references
Ivan Dubrov (Dec 16 2020 at 21:56):
Somewhat theoretical question, when we talk about canonical references, should resource type be implicitly or explicitly provided? When I'm asking some registry to resolve canonical resource, I have three options:
- I can explicitly tell the registry type of the resource I am looking for.
- Resource type be implicitly inferred from the reference itself. For example,
http://hl7.org/fhir/StructureDefinition/PatientimpliesStructureDefinition. - Registry can resolve any canonical resource without even knowing its type (and then I can validate I found type I wanted).
So far in APIs I've been building (both internal and external), I sort of assumed #1: you ask registry to resolve resource and you give it both canonical reference and resource type as well.
#2 I don't think is correct, primarily due to "fragmented" canonical references.
For example, http://fhir.example/CodeSystem/seasons#full-valueset could be a ValueSet stored inside CodeSystem, but you cannot tell it is ValueSet from looking just at the URI alone. Also, what about non-URL references, like urn:uuid:5f82d9e2-8e84-4916-a9e7-3b7abf64720d? Is that okay to have such a canonical reference (say, for testing purposes)?
At the same time, I saw systems rejecting canonical references if they cannot parse resource type from it (https://launch.smarthealthit.org/ is one such system, it wanted to parse my QuestionnaireResponse.questionnaire reference). My interpretation is that this is not correct behavior, though.
Lately, I'm starting to think that maybe #3 is the correct model: canonical reference is supposed to be globally unique, and registry should be able to search resource of any type (then maybe validate that type it found is what client expected).
However, #3 cannot be expressed in FHIR search API if resource type is not explicitly known: you cannot do ?url=<url> as url is not defined for Resource. Even in R5 where we have an explicit CanonicalResource, I don't think one can search it via CanonicalResource?url=<url>.
To workaround this, so far I've been using pattern like ?_type=StructureDefinition,<list every possible canonical resource>&url=<url>, for looking up canonical resource without knowing its type, but it probably won't work for every FHIR server (I so happened to have FHIR servers I have control over, so wasn't an issue).
#1 also has issues with fragmented canonical references and FHIR search API as well: you either have to search for contained resource like ValueSet?url=<reference with fragment> (see this topic for the context) or you have to search for its container without knowing its type: ?url=<reference with fragment stripped> so you can later get the contained resource.
René Spronk (Dec 17 2020 at 08:10):
AFAIK it's #3 ; the recommendation / best practice is to include the resource type, but that's not a requirement.
Last updated: Apr 12 2022 at 19:14 UTC
