Stream: terminology
Topic: Naming System versus Code System
Mark Kramer (Mar 09 2021 at 14:26):
There have been several discussions here about the use of NamingSystem versus CodeSystem. I might be off base, but it seems like one important point has been overlooked. In my view, a naming system is a literally a system of naming, i.e., a set of rules on how to name new things. An example is HGVS (Sequence Variant Nomenclature). It is a recipe for naming that is used to generate new names on the fly. For example, for protein substitution variants, the name-creation formula is:
Format: “prefix”“amino_acid”“position”“new_amino_acid”, e.g. p.(Arg54Ser)
“prefix” = reference sequence used = p.
“amino_acid” = reference amino acid = Arg
“position” = position amino acid subtituted = 54
“new_amino_acid” = new amino acid = Ser
As a true _system of naming_, there is no database of codes. There are an infinite number of possible codes. It is up to the user to follow the naming rules to communicate the variant.
In contrast, coding systems like SNOMED or LOINC need a central authority to mint new codes for each new concept. It is certainly true that coding systems follow internal rules, but two users confronted with a new concept separated by time and space cannot come up the same code.
Potentially, it is the ability for a user to create codes that forms the central distinction between a code system and naming system. Code systems do not have this capability, and thus, must have a pre-determined set of codes. Naming systems do not need a pre-determined set of codes, since codes not by fiat, but by applying repeatable formulas.
Under that point of view, a single system should not be represented by both a NamingSystem and CodingSystem. Not denying there will be gray areas, it is one or the other.
Does that make sense?
Lloyd McKenzie (Mar 09 2021 at 14:31):
CodeSystem defines the rules for post-coordination. NamingSystem is purely about "hey, this system exists, here's the URI/OID/v2 code and how to translate". While it might also summarize the rules around code expression, those would be sourced from the CodeSystem. NamingSystems ware never allowed to define post-coordination rules that aren't defined in the base CodeSystem.
Mark Kramer (Mar 09 2021 at 16:57):
- Wouldn't you put alternate business identifiers for a CodeSystem in CodeSystem.identifier? Why carry the weight of an additional NamingSystem resource?
- Why should the entity you describe as "hey, this system exists..." be called a "NamingSystem"? Here's an example of that term is normally used: https://www.nature.com/articles/d41586-021-00105-z
Lloyd McKenzie (Mar 09 2021 at 17:19):
NamingSystem is a very simple resource. Its purpose is just to look up systems for identifiers and code systems. If we didn't need it for identifiers, it's possible it wouldn't exist. However, given that translation is often done by systems that have no need for information about the actual CodeSystem and NamingSystem is much lighter-weight, it makes sense to allow it to be used for both.
Lloyd McKenzie (Mar 09 2021 at 17:21):
'NamingSystem' is the best name we could come up with. It's not normative, so in theory we could rename it, but it's pretty widely implemented so we'd need a very good reason (i.e. a much more compelling name)
Mark Kramer (Mar 09 2021 at 18:19):
What should I do with a real "system of naming"? Again, I'm talking about something that has no explicit codes whatsoever. If not NamingSystem, what?
(It seems like a shame to use NamingSystem as a bucket of business identifiers for a CodeSystem and waste that name when CodeSystem.identifier seems perfectly up to that task. In other words, if you have a CodeSystem defined, why-o-why-o-why do you need a NamingSystem to further describe that CodeSystem?).
Lloyd McKenzie (Mar 09 2021 at 18:29):
If you're using a CodeableConcept, Coding or code, then there's an implicitly a CodeSystem. You don't necessarily have to have a CodeSystem instance available, but there has to be one.
Lloyd McKenzie (Mar 09 2021 at 18:30):
For CodeSystems, NamingSystem is either a limited subset of the information in the CodeSystem instance, or is the only thing available because there is no full CodeSystem resource
Mark Kramer (Mar 09 2021 at 18:48):
I don't understand.
I want to bind a CodeableConcept to any code that is valid in a naming system (system of naming). You don't know the codes in advance, but any given code can be validated using the rules of the naming system.
How do I do that in FHIR?
Lloyd McKenzie (Mar 09 2021 at 18:51):
If you're sending it in a CodeableConcept, it must be a code. The rules are defined in a CodeSystem, not a NamingSystem. All that NamingSystem does is allow you to map between the OID and the URI.
Mark Kramer (Mar 09 2021 at 18:55):
It is a shame we have a NamingSystem resource but we don't using it for naming systems, and we force naming systems to be misrepresented as code systems.
Mark Kramer (Mar 09 2021 at 18:57):
"All that NamingSystem does is allow you to map between the OID and the URI." <-- This information belongs in CodeSystem.identifier
Peter Jordan (Mar 09 2021 at 19:33):
The NamingSystem resource is for identifier management - CodeSystem identifiers being just one kind of identifier. It includes attributes (preferred and type properties) that are not present in the identifier data type and these attributes facilitate performing operations such as determining the preferred identifier of a particular kind ($preferred-id) and translation ($translate-id - upcoming in R5) from one kind (e.g. OID) to another (URI).
From a practical perspective, I've found it to be the most efficient way to map OIDs used in CDA documents to URIs for FHIR Resources in a couple of national projects - so this is not just theory. However, if I didn't have this kind of requirement, I'm not sure if I would create NamingSystem resources for Code System identifiers as I always identify them via their URL - however, I would still use them for managing other kinds of identifiers as they contain a lot of metadata (description, publisher, jurisdiction, usage, etc.).
As you can imagine, there have been extensive discussions on this topic in the Vocabulary WG over the past few years! Suffice to say that - despite the fact NamingSystem replicates some of the properties of CodeSystem -sufficient additional value was discovered in NamingSystem for it to be used extensively in the UTG IG.
Mark Kramer (Mar 09 2021 at 19:57):
CodeSystem.identfier.type is already available, and together with an extension (e.g., CodeSystem.identifier.extension:preferred), you could easily put all the information in one place. I realize Vocab already is quite far down this road, but using NamingSystem seems unnecessary and confusing. I think you should be using NamingSystem for what it sounds like. IMO.
Lloyd McKenzie (Mar 09 2021 at 19:58):
If you're sending a code in code, that code must be defined by a CodeSystem - end stop.
Peter Jordan (Mar 09 2021 at 20:30):
identifier.type (http://hl7.org/fhir/valueset-identifier-type.html) is different from NamingSystem.type and NamingSystem.kind. IMO, creating an extension on CodeSystem.identifier would be more difficult and, again from practical experience, it's easier to get the preferred identifier or translate identifiers using NamingSystem , rather than CodeSystem resources - given that these operations don't work on instances. As to what I should be doing, I don't even use CodeSystem.identifier on Terminz (i.e. I use the id property for the instance and the url property as the canonical identifier).
Michael Lawley (Mar 09 2021 at 20:59):
All this being said, a terminology server that properly supported HGVS would need to understand the grammar and the set of atoms/terminals that the grammar uses. There's currently no standard way to define these in FHIR.
Lloyd McKenzie (Mar 09 2021 at 21:01):
Right. We said there's no way to standardize representation of post-coordination syntaxes. IETF language codes, UCUM, SNOMED, CPT - every single one of these behaves quite differently.
Mark Kramer (Mar 10 2021 at 19:59):
@Peter Jordan I compared many instance of CodeSystem to corresponding instance of NamingSystem. NamingSystem covers almost exactly the same ground as CodeSystem, and having two resources is confusing and unnecessary. They could easily be combined, and I can show you how if you'd like.
Peter Jordan (Mar 10 2021 at 20:15):
@Mark Kramer . Whether, or not, the NamingSystem resource is required for the management of Code System identifiers is a question for the implementer community to decide. However, whatever the outcome of that debate (and I suggest that you discuss this with the Vocabulary WG if they are willing to spend time re-litigating this topic, yet again), Naming System definitely IS needed for the management of other Naming System kinds (nb. identifiers) - there are R4 production systems using this resource, as well as some of the FHIR tooling, so IMHO petitioning for its removal is a waste of time.
Mark Kramer (Mar 10 2021 at 20:32):
Ugh.
Lloyd McKenzie (Mar 10 2021 at 20:53):
If we were only dealing with CodeSystems, NamingSystem wouldn't exist. However, we must have NamingSystem for identifier systems, and it turns out that it solves a bunch of issues if you stick the relevant subset of data in a NamingSystem instance for code systems too.
Lloyd McKenzie (Mar 10 2021 at 20:54):
In practice, CodeSystem doesn't have a 'standard' way of distinguishing amongst URLs, OIDs and 'string' identification schemes to tell you which of them is 'preferred', so there's a tiny bit of functionality NamingSystem has that CodeSystem doesn't, but the main reason for duplicating the CodeSystem content into NamingSystem is so software that's translating OIDs to URLs or vice versa only has to look one place.
Lin Zhang (Mar 11 2021 at 00:03):
Do both a CodeSystem and its NamingSystem instance need to co-exist within the same FHIR Server in order to be conformant?
Lloyd McKenzie (Mar 11 2021 at 00:09):
Nope. Nor do both need to even exist. And you might have multiple copies of either on different servers
Lin Zhang (Mar 11 2021 at 00:27):
Alright, Thanks, @Lloyd McKenzie :big_smile:
Ted Klein (Mar 11 2021 at 17:13):
In HL7 THO (HL7 Terminology, maintained using UTG process) we are using NamingSystem for a special case we needed to solve - easy tracking and documenting of multiple CodeSystem urls used as canonical URLs - sometimes they are changed, some valid in some times but not others, etc. It solves a bunch of problems that using Provenance to track it proved to be very unsatisfactory.
Lin Zhang (Mar 12 2021 at 03:54):
@Ted Klein A little bit like preferred term and synonyms for a concept, right?
Ted Klein (Mar 12 2021 at 15:24):
No actually. In opposition to our fervent hopes and prayers, we are finding that MANY code systems have more than one identifier in a particular technology (OID, URI, etc). Some change over time (are replaced), some are active at certain times concurrently (some financial systems used widely in the US do this with a 3 month overlap during update cycles), correction of errors, etc. Many Use Cases. It turns out that without a single registry fully integrated that makes this clear and documented and machine processable, problems ensue. So there are similarities to how concepts are handled, but major differences. The Vocabulary WG is still working through all the policy details to fully lay all this out.
Lin Zhang (Mar 12 2021 at 17:11):
It's also been an annoying problem for us. For us in this country, the difference is there is no formal team/group/organization to work on it yet. That is to say, there is no identifier/oid/etc available to refer to.
Lin Zhang (Mar 12 2021 at 17:14):
So we're looking forward to the WG's solution.
Last updated: Apr 12 2022 at 19:14 UTC
