Stream: implementers
Topic: Coding.system
Josh Mandel (Apr 25 2016 at 18:23):
https://www.hl7.org/fhir/datatypes-definitions.html#coding says:
Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should de-reference to some definition that establish the system clearly and unambiguously.
Is the expectation that this "some definition" has some particular format? Developer have been a bit confused by this language. There's no intended requirement of pointing to a https://www.hl7.org/fhir/namingsystem.html, I hope.
Grahame Grieve (Apr 25 2016 at 18:49):
Should point to a CodeSystem now. Agree that language needs updating now that we have formal definitions
Josh Mandel (Apr 25 2016 at 19:34):
So is the following still true?
Represents a "System" used within the Identifier and Coding data types.
From http://hl7-fhir.github.io/namingsystem
Grahame Grieve (Apr 26 2016 at 00:32):
yes
Josh Mandel (Apr 26 2016 at 02:54):
Wait, so how is this different than CodeSystem? I don't see any mention of CodeSystem on the NamingSystem page (or vice versa).
Grahame Grieve (Apr 26 2016 at 02:55):
The relationship between codeSystem and NamingSystem is not simple, and needs to be described.
Josh Mandel (Apr 26 2016 at 02:56):
OK. Do we have a clear recommendation for which (if either) a Coding.systemought to dereference to, in an ideal world?
Grahame Grieve (Apr 26 2016 at 02:56):
generally, though, the documentation has not been updated for the introduction of CodeSystem. It's purely a time limitation - the technical consequences of the CodeSystem change were all I had time to deal with before the Montreal freeze
Grahame Grieve (Apr 26 2016 at 02:56):
(8 weeks solid labour)
Grahame Grieve (Apr 26 2016 at 02:56):
well, either and/or both.
Josh Mandel (Apr 26 2016 at 02:57):
Fine (I'll count that as a"no" for now, and will try to educate myself in the meantime.)
Grahame Grieve (Apr 26 2016 at 02:57):
It references a 'code system' - which may be described by either a naming system or a code system
Josh Mandel (Apr 26 2016 at 02:57):
Do we anticipate that both will stick around?
Grahame Grieve (Apr 26 2016 at 02:58):
I thought NamingSystem might be narrowed in scope to exclude code systems, for simplicitly, but Lloyd showed that this is not the case. I don't expect that there's an easy resolution that sees NamingSystem go away or refocus
Josh Mandel (Apr 26 2016 at 02:59):
Thanks. I'll read the docs and see if I still feel like this is crazy :-)
Grahame Grieve (Apr 26 2016 at 03:00):
they serve different purposes. But the purposes overlap, which is a problem. It's certainly wroth talking about, and there may be some resolution - we haven't looked at deeply.
Rob Hausam (Apr 26 2016 at 03:02):
Yes, having them overlap, without any clear way to decide which to use, would be a problem.
Rob Hausam (Apr 26 2016 at 03:02):
What was it that Lloyd showed?
Grahame Grieve (Apr 26 2016 at 03:03):
don't remember and my mind is fried. @Lloyd McKenzie can dig it up
Josh Mandel (Apr 26 2016 at 03:16):
Yes, I'll look forward to this too when Lloyd's around.
Lloyd McKenzie (Apr 26 2016 at 15:50):
NamingSystem allows linkage of a given CodeSystem to all the identifiers that might be used for it - URIs, OIDs, etc. And also indicates which of those should be used in which circumstances. It may also provide basic advice about how codes or identifiers should be sent over the wire (e.g. removing separators, case, etc.) We *could* put all of that into CodeSystem, but it's really a separate function. Plus, when you're looking for NamingSystem type information, you really don't want to bring down all the codes.
Lloyd McKenzie (Apr 26 2016 at 15:50):
(That's what I remember of the reasons, anyhow. Possible I've also forgotten something :))
Chris Grenz (Apr 26 2016 at 16:04):
+1 to @Lloyd McKenzie 's description. I _think_ it's the intention that a system with a NamingSystem defined could be queried by its aliases. @Grahame Grieve @James Agnew @Ewout Kramer - do your servers handle identifier/code system aliases in search?
Grahame Grieve (Apr 26 2016 at 16:24):
our servers do what's in the spec. What do you mean specifically?
Chris Grenz (Apr 26 2016 at 16:27):
If there's a NamingSystem resource for LOINC that lists http://loinc.org and urn:oid:2.16.840.1.113883.6.1 as aliases, are these equivalent searches?
[base]/Observation?code=http://loinc.org|123
and
[base]/Observation?code=urn:oid:2.16.840.1.113883.6.1|123
Lloyd McKenzie (Apr 26 2016 at 16:27):
Do you mean searching for a match on a LOINC code using an alternate URI? That's not required as part of the spec and I don't know anyone who does this. Technically someone searching by anything other than the "approved" URI is non-conformant. However, that doesn't mean you couldn't choose to support it anyhow.
Chris Grenz (Apr 26 2016 at 16:27):
Yep - exactly what I'm asking...
Chris Grenz (Apr 26 2016 at 16:28):
Is there any conversion to the "canoncial URI" as in ucum units for Quantities?
Grahame Grieve (Apr 26 2016 at 16:29):
I don't support that, though it's possible that I could
Grahame Grieve (Apr 26 2016 at 16:29):
though it would have some interesting challenges....
Chris Grenz (Apr 26 2016 at 16:29):
Seems to make sense if we're going to provide a place to document aliases...
Chris Grenz (Apr 26 2016 at 16:30):
Especially in the enterprise use cases where terminologies may or may not be quite so well defined and identifiers may...um...evolve.
Grahame Grieve (Apr 26 2016 at 16:31):
well, there's 2 different things here:
- an operation on naming system to return possible equivalent URIs
- the server just doing the switch internally
Grahame Grieve (Apr 26 2016 at 16:31):
the second is less obviously useful to me - I search for loinc, and get back some resource with no LOINC code in it...
Chris Grenz (Apr 26 2016 at 16:32):
Currently we implement this in search handling by adding an OR block to the systems using the aliases.
Grahame Grieve (Apr 26 2016 at 16:36):
well, I would too - it would be less efficient but not much. But I'm more interested in the surprise factor here
Chris Grenz (Apr 26 2016 at 16:40):
Use case (that I currently have): I've got converted v2/v3 data with OIDs and am combining that with native FHIR data with URIs. I don't control either data set. As a result, I'm going to have both naming systems in my instance data...would be nice to not make all the clients deal with this. Also, the clients may not know when I add another source with yet another system alias...
Ewout Kramer (Apr 26 2016 at 18:17):
So, is a CodeSystem one concrete manifestation out of a more abstract "set" of systems representing a single "NamingSystem"?
Chris Grenz (Apr 26 2016 at 18:17):
Don't think so... a CodeSystem is-a NamingSystem, no?
Grahame Grieve (Apr 26 2016 at 19:08):
I think it's true at some level, but not true at the object level
Chris Grenz (Apr 26 2016 at 19:09):
Right...from a instance granularity though, 1 CodeSystem = 1 NamingSystem
Grahame Grieve (Apr 26 2016 at 19:10):
well, that should be the case, but there are cases for >1 on ether side
Chris Grenz (Apr 26 2016 at 19:10):
That makes me nervous...I'll wait and watch I guess
Grahame Grieve (Apr 26 2016 at 19:18):
yeah I don't know that I like it either. most of them arise from degnerate processes, but you can't stop that from happenin
Rob Hausam (Apr 26 2016 at 19:57):
I think that Lloyd's explanation makes sense. But I want to see how the ramifications play out - particularly with search (as Chris described).
Last updated: Apr 12 2022 at 19:14 UTC
