Stream: implementers
Topic: about canonical data type
Michael Calderero (Mar 11 2020 at 03:45):
Hi All,
I'm trying to confirm whether or not the canonical data type (i.e. http://build.fhir.org/datatypes.html#canonical) can contain a relative url or it should be an absolute url always. It seems odd to me for a canonical to contain a relative url, as in this example: http://build.fhir.org/questionnaireresponse-example-ussg-fht-answers.json.html
In that example, the QuestionnaireResponse seems to point to the Questionnaire resource id itself and not to its url.
Grahame Grieve (Mar 11 2020 at 03:46):
http://hl7.org/fhir/references.html#canonical-fragments
Michael Calderero (Mar 11 2020 at 03:58):
Sorry I don't understand. The QuestionnaireResponse points to an external Questionnaire, not to an internal one
"questionnaire": "Questionnaire/ussg-fht"
Assuming the referenced Questionnaire has the definition:
"url": "http://abc", "version": "1"
I was expecting the QuestionnaireResponse questionnaire property to contain
"questionnaire": "http://abc"
or
"questionnaire": "http://abc|1"
Grahame Grieve (Mar 11 2020 at 03:59):
then you're right.
Michael Calderero (Mar 11 2020 at 04:03):
So the example QuestionnaireResponse is wrong? Or is a canonical property allowed to contain relative url references to other resources by their resource id? If yes, what are those cases?
Grahame Grieve (Mar 11 2020 at 04:04):
example is wrong
Grahame Grieve (Mar 11 2020 at 04:05):
only case where relative urls are allowed is references to contained resources
Michael Calderero (Mar 11 2020 at 05:32):
Thanks.
Some more questions: Suppose I have the following Questionnaire:
id: xyz url: http://abc version: 1 name: myquestion
and QuestionnaireResponse:
id: qr1 questionnaire: "http://abc"
I suppose the following searches would work and return me QuestionnaireResponse with resource id qr1?
[baseurl]/QuestionnaireResponse?questionnaire=Questionnaire/xyz
[baseurl]/QuestionnaireResponse?questionnaire.name=myquestion
[baseurl]/QuestionnaireResponse?questionnaire=http://abc
[baseurl]/QuestionnaireResponse?questionnaire=http://abc|1
Grahame Grieve (Mar 11 2020 at 05:47):
2 and 3 yes. I don't think that #1 works, and #4 is not right
Lee Surprenant (Mar 11 2020 at 11:43):
[deleted] my mistake
Lee Surprenant (Mar 11 2020 at 11:51):
https://www.hl7.org/fhir/search.html says:
For canonical references, servers SHOULD support searching by Canonical URLs, and SHOULD support automatically detecting a |[version] portion as part of the search parameter and interpreting that portion as a search on the business version of the target resource.
Lee Surprenant (Mar 11 2020 at 11:52):
so it seems like #4 SHOULD work on some servers, although I'm not sure why the spec has a SHOULD here...
Lloyd McKenzie (Mar 11 2020 at 14:23):
Agree that #4 looks like it should work. @Grahame Grieve, what's wrong with it?
Note that #2 is suspect because there's no requirement that Questionnaire.name be unique - within any context.
Grahame Grieve (Mar 11 2020 at 19:54):
whats' wrong with 4 is that I don't think there's any assigned meaning to using a versioned canonical reference in a reference like that
Lloyd McKenzie (Mar 11 2020 at 22:43):
So we haven't defined search for versioned canonical URLs?
Lloyd McKenzie (Mar 11 2020 at 22:43):
Is that something we can/should do?
Grahame Grieve (Mar 11 2020 at 22:48):
we have on the url itself, but not if it's a reference like that
Guillermo Rdguez Glez (Mar 20 2020 at 16:36):
We are building an ordering platform for lab tests, allowing practitioner to order tests from Quest Diagnostics, LabCorp and others.
We are following the IG to model our catalogs but encountered a problem when trying to create a link between the PlanDefinition (service) and the ActivityDefinition (procedure):
The link is made using a canonical reference. This poses a problem since we are using Quest’s masterfile and the links between services and procedures are local references, we are not sure whose responsibility is it to create those urls nor what rules should we follow. If they were regular references it would be easy, we just map the masterfile to PlanDefinitions and ActivityDefinitions, but as it is, we don’t know what the links should be.
The examples in the IG use local references and according to Grahame those are wrong.
Can you please show us an example of a proper canonical url for a case like the ones in the IG examples or point us in the right direction?
Thanks in advance
Lloyd McKenzie (Mar 20 2020 at 17:09):
@Bryn Rhodes
Bryn Rhodes (Mar 20 2020 at 22:12):
So the canonical is a global, version-stable identifier for the artifact. Here's an example of a WHO Antenatal Care Contact Schedule referencing a Contact Plan Definition. I would think in this case the canonical's would be the base URL of the steward (Quest) + /PlanDefinition/<name>, or /ActivityDefinition/name, and then when you reference, if it's a version-independent reference, just the canonical, if it's a version-specific reference, then <canonical>|<version>.
Guillermo Rdguez Glez (Mar 23 2020 at 14:45):
Thanks @Bryn Rhodes , in the case of Quest, it defines different CDC per labsite(TMP, MIA, NEL, ...), with lab services identifiers that may or may not match across other labsites, so, I am not sure including labsite code in the canonical url may be a good idea because it becomes too specific(not global for quest procedures), nor using the identifier when same procedure may have different identifiers on different labsites.
Example:
Panel: 10010
Name: TORCH PANEL, CONVALESCENT
LabSite: NEL
what should be an accurate canonical url for this case?
http://www.questdiagnostics.com/ActivityDefinition/10010
or
http://www.questdiagnostics.com/NEL/ActivityDefinition/10010
keep in mind each Quest lab service identifier is labsite specific, each labsite manages its lab services catalog, so, we can say, Quest needs labsite in addition to lab service identifier in order to unambiguously resolve labservice.
Thank you for helping, in advance!
Guillermo Rdguez Glez (Mar 24 2020 at 20:35):
@Bryn Rhodes can you help me on that :point_up: please?
Peter Muir (Mar 26 2020 at 21:34):
I defer to Bryn, but adding a comment. As you have noted, labs need unique identifiers for their test panels and components since LOINC , CPT, etc are not specific enough, but that identifier will vary across Quest sub lab entities/locations. Also the Name would not be consistent across different sub lab entities. As a suggestion ,consider http://www.questdiagnostics.com/ActivityDefinition/NEL/10010 where ActivityDefinition could be LOINC rather than just name (since need to consider units such as mass/volume vs Moles/volume, etc). Thus searching for a specific LOINC could pull irrespective of LAB entity (NEL 3 char identifier) and yet have have the required unique ID.
Guillermo Rdguez Glez (Mar 27 2020 at 19:30):
@Peter Muir I don't understand if you are actually recommending to avoid using LOINC or recommending it. I am so sorry :disappointed: . Or are you recommending using both, LOINC(when available) and specific LAB identifier? Notice 10010 is the lab service identifier inside specific LAB. What do you mean with name? I don't understand if you are recommending to change "ActivityDefinitin" with a LOINC, or LAB/quest-id combination at all. Who am I supposed to use LOINC in order to compose an accurate ActivityDefinition canonical url. Should I keep a separate catalog for each specific quest lab(NEL, MIA, ...). I really appreciate your help. Thanks in advance.
Lloyd McKenzie (Mar 27 2020 at 21:36):
For canonicals managed by Quest, I'd use the Quest ids, not LOINC. It's entirely possible that Quest might have multiple ActivityDefinitions (with different codes) that share the same LOINC value. And of course there might be some that that won't have a corresponding LOINC code at all. In theory, LOINC might eventually define ActivityDefinitions themselves (which of course would have canonicals based on the LOINC codes). The Quest ActivityDefinitions could point to those using the 'instantiates' property. In the meantime, they can also link to the relevant LOINC using one of the codings in ActivityDefinition.code.
Last updated: Apr 12 2022 at 19:14 UTC
