Stream: terminology
Topic: URI protocol
John Snyder (Apr 21 2020 at 17:38):
Are there plans to update the web protocol for the URI's listed on http://hl7.org/fhir/terminologies-systems.html from "http" to "https" in the near future?
The reason I ask is because the Inferno test tool is returning a failed test when the https protocol is used in the URI. I don't believe this is a valid test failure, but I believe Inferno is based on what is published on this page.
Rob Hausam (Apr 21 2020 at 17:58):
No, the intent is for the canonical urls to remain as "http:", as they are documented on that page. For canonical urls it doesn't seem necessary (or desirable) to specify the secure protocol (as usually there's a redirect and how it's handled is server dependent).
Rob Hausam (Apr 21 2020 at 17:59):
And we don't intend for the canonical urls to change.
Lloyd McKenzie (Apr 21 2020 at 18:17):
The primary purpose of canonical URLs is not to resolve. Also, as it becomes unnecessary to distinguish by URL whether data will be secured or not, formally declaring https will be unnecessary. If a server (for some strange reason) decides that queries of a terminology must be secured, most systems can automatically retry with https if http fails
Michael Lawley (Apr 21 2020 at 21:02):
To be pedantic, It's not necessary (or desirable) to change because these are URIs (identifiers), and not URLs (locations).
Whether, how, or if you can resolve a URI is irrelevant to its meaning or intended use as an identifier.
Reece Adamson (Apr 22 2020 at 15:31):
@John Snyder could you share a little more information about the test you're looking at in inferno? I'd like to investigate a little more, although we might want to move this conversation over to the #inferno stream.
John Snyder (Apr 22 2020 at 16:07):
@Reece Adamson
I don't know how to move this to the inferno stream other than to repost it?
I talked to our QA person and the test that are failing are The test for Observation Body Height Tests,Observation Blood Pressure Tests,Observation Body Weight Tests.
the part of the response that is failing is this section where you can see that we use "https://loinc.org" as the system.
{
"resourceType": "Observation",
"id": "187f92da-2246-46a6-a3b6-dde820a17575",
"status": "final",
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "vital-signs",
"display": "Vital Signs"
}
]
}
],
"code": {
"coding": [
{
"system": "https://loinc.org",
"code": "8302-2",
"display": "Body height"
}
]
},
Reece Adamson (Apr 22 2020 at 17:00):
Thanks for the details that's really helpful! I'm guessing inferno is throwing an error because the codesystem is not an exact match to that which is fixed in the profile. I'll look into whether its a little too strict when validating terminology (and it probably is), but I think this specific error doesn't have to do with that.
I tried to validate the resource( https.json ) against the HL7 validator with:
java -jar org.hl7.fhir.validator.jar https.json -version 4.0.1
and see a warning related to this and also it looks like the terminology isn't validated because of the https:
Information @ Observation.code.coding[0] (line 23, col2) : Code System URI "https://loinc.org" is unknown so the code cannot be validated Warning @ Observation.code (line 22, col12) : None of the codes provided are in the value set http://hl7.org/fhir/ValueSet/observation-vitalsignresult (http://hl7.org/fhir/ValueSet/observation-vitalsignresult), and a code should come from this value set unless it has no suitable code) (codes = https://loinc.org#8302-2)
I'm surprised that its only a warning here because at least from the language in the spec ElementDefinition.fixed[x]:
Specifies a value that SHALL be exactly the value for this element in the instance. For purposes of comparison, non-significant whitespace is ignored, and all values must be an exact match (case and accent sensitive). Missing elements/attributes must also be missing.
I imagine the code should be an exact match so I'd expect an error there if its wrong, but even if I make the code incorrect it is still a warning (but that's a different topic).
My main question is this:
Does this mean that a uri ( specifically the url protocol portion) does not have to be an exact match when fixed by ElementDefinition.fixed[x]? At least based on the ElementDefinition.fixed[x] definition it seems like everything that's not whitespace should matter.
Thoughts on this @Lloyd McKenzie or anyone else? I could be totally out of my gourd here.
Robert McClure (Apr 22 2020 at 18:20):
Per the external code system page at FHIR (v4 but it's consistent) the identifier for LOINC does not have https. That is the error and conformance testing is correct to catch this.
Rob Hausam (Apr 22 2020 at 18:28):
Yes, the system uri needs to be http://loinc.org.
Reece Adamson (Apr 22 2020 at 18:48):
Thanks, I appreciate the explanation!
Michael Lawley (Apr 23 2020 at 04:14):
More generally, URIs (as used to reference CodeSystems, ValueSets, etc) are essentially magic numbers - they have to match exactly; they have no other semantics, you cannot extract any meaningful information by parsing them, etc etc.
That they are _sometimes_ human (or geek)-readable and/or resolvable by treating them as URLs is a happy convenience, but should make NO difference to whether a given resource is valid.
This is why, while the URL http://LOINC.ORG is equivalent to the URL http://loinc.org, the URIs http://LOINC.ORG and http://loinc.org are not equal .
Last updated: Apr 12 2022 at 19:14 UTC
