Stream: terminology
Topic: NamingSystem
Lloyd McKenzie (Apr 07 2020 at 16:30):
@Robert McClure Moving as suggested:
Robert McClure said:
Rob Hausam Grahame Grieve Lloyd McKenzie Ted Klein Carol Macumber NamingSystem needs to be discussed in vocab ASAP. It seems to me we need to restrict the use of namingsystem to very few use cases (honestly I think it should disappear), open up the use of codesystem to include how it is used in the majority of cases now which is as an artifact created by a FHIR "designer" to represent something they need but do not control, and then clean up the documentation. IMHO I think we need to use codesystem for a wider range of situations then our documentation currently indicates. We might want to move this discussion (again) to terminology stream?
NamingSystem is essential for identifiers - we can't possibly get rid of it. We can and should explore how it should be used for code systems. It's true that CodeSystem can be used in place of NamingSystem for pretty much all purposes, though CodeSystem does not support everything NamingSystem can do, namely distinguishing preferred from alternate URLs, OIDs and other identifier schemes (e.g. LN for LOINC in v2). It's also a rather heavy (and somewhat awkward) resource for systems that only care about converting OIDs to URLs and vice versa as they switch between CDA and FHIR - which is one of the primary purposes of NamingSystem. It's particularly awkward given that CodeSystem can't be used for that purpose for identifier systems - where conversion between OIDs and URLs is also needed.
If we want to stake out a position that metadata about code systems is always managed using CodeSystem and NamingSystem instances (for code systems) are only created for identifier conversion, I'm happy with that. (Which would mean that external code systems in UTG should be represented using CodeSystem and also that we should also publish minimalist NamingSystem instances for all CodeSystems in UTG, but perhaps not surface them except as technical artifacts - i.e. no index pages, but perhaps links from the CodeSystem pages.
Robert McClure (Apr 07 2020 at 18:39):
@Lloyd McKenzie Your response is what I thought might be true wrt the identifier requirements therefore perhaps we focus it's use there, and use codesystem everywhere else. As for being a bit heavy-weight when capturing the various identifiers for a code system - I think it would be "heavy" only when we are not representing all the information that actually may be available for that code system. I see that as a point in time situation that can change with time. I think this would also solve the original issues noted at the beginning of this topic. Thoughts?
Lloyd McKenzie (Apr 07 2020 at 19:43):
There are some systems that could care less about the code system semantics - they just care about identifier translation. My leaning is to say CodeSystems SHALL be represented using CodeSystem and SHOULD have an accompanying NamingSystem to support identifier translation.
Grahame Grieve (Apr 07 2020 at 21:07):
I don't wholly agree with either of these. I think that CodeSystem identifiers should be used to describe known approved ways of identifying the code system, and NamingSystem should be used for people to document other things they used that aren't official
Rob Hausam (Apr 07 2020 at 21:10):
This is a good topic to discuss on a Vocab call. We could start with a discussion on the FHIR Tracker Issues call this week (Thursday 3:30 - 5:00 PM Eastern), if we can get sufficient participation. More time will likely be available on the Tracker calls than there will be on the Main calls (same day/time on alternating weeks).
Robert McClure (Apr 10 2020 at 16:32):
So I missed the FHIR Tracker call and if this was discussed, I'll give the minutes a look-see. But I don't see how not caring about code system semantics can mean they will understand there are two different types of resources and when to namingsystem versus code system. I have to say that makes no sense. My whole point is that we should put as much as we can into code system so most folks don't need to understand the unique need for namingsystem. When are we going to drive this issue to ground?
Rob Hausam (Apr 10 2020 at 16:38):
Most of the documentation for the call is in the trackers - particularly FHIR-20478 for this topic.
Lloyd McKenzie (Apr 11 2020 at 02:16):
@Robert McClure NamingSystem instances are small and lightweight. If you don't care about the codes or any of the code system rules and just need to convert OIDS -> URIs or vice versa, NamingSystem is a much more appropriate mechanism. Needing to retrieve a CodeSystem is extremely heavy-weight. It also seems of questionable value to create a CodeSystem instance when all you know are identifiers and a name.
Robert McClure (Apr 11 2020 at 14:29):
@Lloyd McKenzie You seem to be significantly discounting the additional "weight" of having to program for a different resource to do something a single resource implementers must already code to support simply to allow for a smaller transported set of code. I don't agree with this logic and would like to see implementer support for your way of thinking. In leu of obtaining that, I think we need to severely restrict NamingSystem and use CodeSystem instead.
Lloyd McKenzie (Apr 11 2020 at 17:00):
You're assuming implementers who care to map ids will bother to code to support CodeSystem. A decent portion of those who are focused on conversion won't bother. And even if they do also support CodeSystem, it's likely to be handled in a completely different space. They will have to support NamingSystem to convert identifier systems. I don't understand why we should restrict NamingSystem. So long as the focus is purely on identifier lookup and conversion, I see zero harm in exposing code systems as NamingSystem (potentially in addition to CodeSystem, which should be used for any terminology services functions). What harm are you seeing?
Peter Jordan (Apr 11 2020 at 22:54):
I have an implementation requirement to translate both Instance Identifier OIDs and Code System OIDs to FHIR uris - when converting NZ ePrescription CDAs to FHIR Resources. To date, the most efficient way I have found to do this is by using the NamingSystem resource - that efficiency would be increased if we added a $translate-id operation to that resource Jira FHIR-26837. However, given that CDA->FHIR may well be a common use case, I would be interested to see how others, such as the C-CDA on FHIR Group, view this - @Rick Geimer
I fully understand the wish to keep as much information about a Code System as possible in that resource, but using it for identifier translation looks like overkill to me and NamingSystem, I believe, is a better fit for that requirement.
Robert McClure (Apr 12 2020 at 15:22):
My thinking is that codeSystem should have the different identifiers used for a code system. If I'm understanding you, you are saying that NamingSystem will also, and only, contain those identifiers also. I suspect you are saying that it would be common to not create codeSystem resources for code systems that have multiple identifiers. I just don't understand why that is more efficient.
@Peter Jordan help me understand your use case because if it's using NamingSystem to align identifiers for CDA documents and FHIR resources that align, I'd agree that is a good use. SO perhaps we are in agreement that we use codeSystem for any code system information and NamingSystem for non-code system identifier alignment tracking?
Lloyd McKenzie (Apr 12 2020 at 18:35):
It would be common to not create a CodeSystem if you know nothing about the CodeSystem other than the identifiers. If you have no information about the codes, who maintains them, where they can be found or anything else, having a CodeSystem instance isn't super useful, though there's nothing that says you can't have one. The point is that for systems that only care about identifier translation (and there are a decent number of those), making them support CodeSystem in addition to NamingSystem is unnecessarily complex. I'm pretty sure that Peter's use-case is to do identity translation for both codes and identifiers. It's completely appropriate to use NamingSystem (and only NamingSystem) for that use-case.
Peter Jordan (Apr 12 2020 at 21:18):
Correct, I do need to translate both codes and identifiers. I also need to use both CodeSystem and NamingSystem resources and I don't view that as a problem. NamingSystem gives me more information about a Code System identifier than is currently available in the CodeSystem resource and an easier mechanism for identity translation. Plus, as Lloyd says, that mechanism can also be used for identifiers. Long live NamingSystem!
Last updated: Apr 12 2022 at 19:14 UTC
