FHIR Chat · MDC question · terminology

Stream: terminology

Topic: MDC question

Grahame Grieve (Sep 22 2017 at 21:55):

I'm working with Brian to write a page for MDC codes like we have for SNOMED, LOINC etc.

Grahame Grieve (Sep 22 2017 at 21:57):

one interesting question has come up. An MDC concept has several possible representations:
- an integer value ("147842")
- which actually consists of 2 parts, high 16 bits and low 16 bits: 2.16770 where '2' is a partition to tell you what type of code this is
- an assigned string mnemonic: "MDC_ECG_HEART_RATE"
- a display: Heart rate as measured by an ECG device

Grahame Grieve (Sep 22 2017 at 21:57):

Ideally, in a Coding, you'd have this:

Grahame Grieve (Sep 22 2017 at 21:57):

coding": [{
"system": "urn:iso:std:iso:11073:10101",
"code": "MDC_ECG_HEART_RATE",
"display": "Heart rate as measured by an ECG device"
}]

Grahame Grieve (Sep 22 2017 at 21:59):

.. but there's a problem: Codings like this are generally built by general purpose gateway devices that interact with devices using a different protocol that uses the integer value, and that may communicate with new devices for which it does not know the integer -> mnemonic translation in advance

Grahame Grieve (Sep 22 2017 at 21:59):

so these devices couldn't produce that form, and so it seems like we'll have to have this:

Grahame Grieve (Sep 22 2017 at 21:59):

coding": [{
"system": "urn:iso:std:iso:11073:10101",
"code": "147842",
"display": "Heart rate as measured by an ECG device"
}]

Grahame Grieve (Sep 22 2017 at 22:00):

but human users like the MDC_ECG_HEART_RATE as much more readable than than 147842, so a user proposed this:

Grahame Grieve (Sep 22 2017 at 22:00):

coding": [{
    "system": "urn:iso:std:iso:11073:10101",
    "code": "147842",
    "display": "MDC_ECG_HEART_RATE: Heart rate as measured by an ECG device"
  }]

Grahame Grieve (Sep 22 2017 at 22:01):

that doesn't sit so well with me as a mis-use of display... any comments?

Grahame Grieve (Sep 22 2017 at 22:03):

@Brian Reinhold - drawing your attention to this thread

Eric Haas (Sep 22 2017 at 22:11):

Provide a FHIR code system that provides the CodeSystem.concept.code as the integer and the alternatives in CodeSystem.concept.designation and let the implementers decide which to use based on their implementation. Any one is fine as far as FHIR is concerned. Agree that the display is not the place for tacking on the alternates designations.

Grahame Grieve (Sep 22 2017 at 22:22):

yes the CodeSystem will provide all the information. but you don't get to decide what to use in code

Eric Haas (Sep 22 2017 at 23:29):

You can't put whatever designation floats your boat in ValueSet.compose.include.concept.codeor coding.code? I thought that was was the whole designation thing was for. Is this explained anywhere in the spec or the VSD?

Grahame Grieve (Sep 22 2017 at 23:33):

designations are alternate displays not alternate codes

Eric Haas (Sep 23 2017 at 02:05):

ok I got turned around on that element definition. thanks for the clarification

Rob Hausam (Sep 23 2017 at 06:19):

We may need to think about allowing for the possibility of multiple codes that can be used to identify a single concept. This is not the first time that we've seen this. V3 does it in some instances. One example is in V3 RouteOfAdministration, where both of the codes NASINHLC and NP are active and are used to represent the same concept (internalId = 14618). In the FHIR representation of the V3 RouteOfAdministration code system (4.3.2.112) it turns out that NASINHLC is the only code that is being displayed, and the equally valid code NP is not. Since we don't have a mechanism at present to identify concepts other than by their codes, that may make some sense, but it's arbitrary, and for full and completely accurate code system representation this probably should be addressed. I do agree with not overloading display or designations for this purpose.

Grahame Grieve (Sep 23 2017 at 06:26):

well, we need to do something about alternate codes then. I've been meaning to get around to do something about synonyms, but never have

Grahame Grieve (Sep 23 2017 at 06:26):

glad it's come up now

Rob Hausam (Sep 23 2017 at 06:32):

Yes. One way I think we might consider handling this is to represent all of the unique valid codes and provide a ConceptMap with both the source and target specifying the same code system and indicating the codes within the code system that are equivalent (i.e. that represent the same “concept").

Grahame Grieve (Sep 23 2017 at 06:41):

well, the CodeSystem resource is purposefully concept based, not code based.

Rob Hausam (Sep 23 2017 at 06:50):

That's true. But presently a concept has 1..1 code. We certainly could (and possibly should) address it there. I just offered the ConceptMap solution as something that might achieve nearly the same result using a currently available mechanism. But if we want to allow multiple codes for a concept then that would be an even better match for the MDC and V3 use cases (and any similar ones).

Grahame Grieve (Sep 23 2017 at 06:52):

there's 3 things we could do
- change code from 0..1 to 0..*
- add an extension for additional codes
- define how to use a designations to define additional codes as opposed to additional displays

Grahame Grieve (Sep 23 2017 at 06:52):

I don't favour the first option

Rob Hausam (Sep 23 2017 at 07:13):

Using an extension may make sense, but I'm not entirely sure. There are only a fairly small number of instances of multiple codes for concepts in V3. But with MDC this seems pretty ubiquitous (and it also was previously with SNOMED CT, with the CTV3 and legacy SNOMED Int. codes that formerly were included). And I'm not sure how you should decide which ones of the multiple codes should be "additional" and therefore in the extension and which one should be selected to be the "code" (although maybe it doesn't matter?). At least in the V3 and MDC cases the codes seem normally to all be equally valid and not necessarily prioritized. For "designation", the way that we've always used it within HL7 is referring to display terms, so I don't think that I'm likely to be in favor now of trying to repurpose it to also include the notion of a "concept designation". But I do agree that we could do any of these three things.

Lloyd McKenzie (Sep 23 2017 at 13:50):

0..1 code + extension or designation implies that one code is primary. I don't think that's true. What's the downside of code being 0..*?

Paul Schluter (Sep 23 2017 at 17:44):

coding": [{
"system": "urn:iso:std:iso:11073:10101",
"code": "147842",
"display": "MDC_ECG_HEART_RATE: Heart rate as measured by an ECG device"
}]

In an IHE PCD DEC message, the heart rate observation identifier would be sent as 147842^MDC_ECG_HEART_RATE^MDC.  Both IHE PCD and PCHA/Continua WAN interface (based on IHE PCD DEC) use the "context-free" numeric identifier that incorporates the partition (2) and 16-bit offset within that partition (16770), typically expressed as. 2::16770 in  later IEEE 11073 standards.  A non-zero context-free numeric code indicates that the concept is an approved and published IEEE 11073-1010X nomenclature term, and the numeric code alone is sufficient (but the IEEE 11073 'REFID' MDC_ECG_HEART_RATE is often sent in IHE PCD DEC messages to provided to facilitate clarity).  During early prototyping and testing of messages and prior to approval and publication of new terms, the proposed REFIDs are used, and since they are unapproved terms, they are sent with a zero numeric code, e.g. 0^MDC_ECG_OUR_NEW_TERM^MDC.  This allows meaningful prototyping and vetting of new terms during the pre-Connectathon and Connectathon, and facilitates early testing at least a year (or longer) before IEEE 11073-1010X balloting commences.  I would strongly recommend supporting this practice, although I agree with you that treating the IEEE 11073 'REFID' as a display string is somewhat abusing the original purpose of the second component of the HL7 V2 CWE datatype.  I believe it would be highly desirable to have an officially sanctioned way of transmitting the assigned string mnemonic, such as an IEEE 11073 'REFID', a LOINC short or long common name, etc. that could facilitate human readability and debugging provided that that the (non-zero) numeric identifier code would always take precedence.
The IEEE 11073 nomenclature also supports the concept of a 'REFID-synonyms' where an additional REFID may be defined that is equivalent to the originally proposed REFID, reflecting a slightly different 'semantic arc'.  Both are listed together in the same table cell and the containing table row that defined all other parts of the term are identical, including the all-important numeric code.  Fortunately only a small number of these have been defined and we have adopted the convention of using the REFID order in the table cell in the published standards (e.g. preferred listed first) to facilitate a more deterministic reverse-translation from the numeric code.

Grahame Grieve (Sep 23 2017 at 20:30):

I feel that there's 2 main consequences : it's a big change, and there's no way to indicate which is primary

Grahame Grieve (Sep 23 2017 at 20:35):

thanks @Paul Schluter (though that was hard to read because you used to ` to stop it from wrapping)

Grahame Grieve (Sep 23 2017 at 20:36):

but it shows that these are not synonyms - they provide semantics which relate to the concept definition process

Grahame Grieve (Sep 23 2017 at 20:36):

I think they are properties of the codes, not designations, and that the correct implementation is either:

Grahame Grieve (Sep 23 2017 at 20:37):

coding": [{
"system": "urn:iso:std:iso:11073:10101",
"code": "147842/MDC_ECG_HEART_RATE",
"display": "Heart rate as measured by an ECG device"
}]

Grahame Grieve (Sep 23 2017 at 20:38):

or

coding": [{
"system": "urn:iso:std:iso:11073:10101",
"code": "147842",
"extension" : {
  "url" : "some URL to be defined",
  "valueCode" :  "MDC_ECG_HEART_RATE"
}
"display": "Heart rate as measured by an ECG device"
}]

Lloyd McKenzie (Sep 23 2017 at 22:00):

If there isn't a primary, it's appropriate that there's no way - the others require the designation of a primary, when that might not be the case. If there were a primary and it mattered, there are a number of ways we could mark it as such if we went to 0..*.

Grahame Grieve (Sep 23 2017 at 23:05):

so I had a quick look through the various implementations. Given that true synonyms are rare (mostly, alternative codes have additional implications, or arise through post-coordination grammar), I very strongly think that we should leave code at 0..1 and define a specific property for actual synonyms.

Lloyd McKenzie (Sep 24 2017 at 03:15):

And in the case of true synonyms, which code gets placed in "code"? (And can we be confident that that choice won't have any impact on value set expansion?)

Rob Hausam (Sep 24 2017 at 14:20):

Currently CodeSystem.concept.code is 1..1, so every concept must have a code. If we don't think that's true we could make it 0..1 or 0..* The term "synonym" has typically been applied to descriptions/designations, not to codes. If we want to use the similar idea for codes, too, then I think we may need to make the difference clear - maybe "code synonym"? I also agree with Lloyd that it's appropriate to not force the notion of designating a "primary" code when it's not present in the code system - there isn't a "primary" code in V3, for example. And we do need to think about this for value set expansions. In the V3 RouteOfAdministration example that I mentioned, there's no reason other than arbitrary choice that I know of why NASINHLC should be returned and NP is not. So it's seeming to me that the cleanest way to handle this would be to make concept.code 1..* (or 0..*), even though it is a big change. If we're going to make the change, now is obviously the time to do it.

Joel Schneider (Sep 25 2017 at 10:26):

+1 for making concept.code 1..* (or 0..*) -- (gory details regarding HLA Nomenclature, OID 2.16.840.1.113883.6.341, omitted ...)

Alexander Henket (Sep 25 2017 at 12:10):

Not happy with a pick and choose situation. Settle on one and provide a conceptmap for the other. Just like ISO 3166 alpha-2. We have a number of systems with mnemonics + integer codes, but we just choose what to use. Letting users mix and match whatever they feel like, is asking for it

Russ Hamm (Sep 25 2017 at 13:58):

Just a reminder that the internalId is not to be used for anything other than V2 vocabulary maintenance. It is not to be used for uniquely identifying the concept - I assume you were just referencing it to illustrate your point.

Eric Haas (Sep 25 2017 at 14:32):

I am not for code 1..* This is interop purgatory. Like Alexander said we pick one, make half the users unhappy and move one and I did not understood why concept map would not work. Also as I understand From Paul's comment above he wrote in Hl7 V2 speak '147842^MDC_ECG_HEART_RATE^MDC Code'. Which obviously has the code as is the integer and the display is the concatenation of mnemonics. So I am back to my original assertion that the MDC_ECG_HEART_RATE is an alt designation or display.

Lloyd McKenzie (Sep 25 2017 at 14:40):

How do we "pick one"? The code system exists. There is no primary. When we represent it in CodeSystem, the conversion software has no way to choose which one is primary. And multiple systems could convert and expose the same code system. We don't want them to do so differently. I agree that synonym codes suck, but we can't make them go away by dictat.

Eric Haas (Sep 25 2017 at 14:42):

@Rob Hausam What does the VSD say about synonym codes besides being sucky?

Rob Hausam (Sep 25 2017 at 19:53):

OK. I don't think we're coming to any consensus on this so far. Particularly with that in mind, I think that the ConceptMap solution for this that I proposed earlier and that @Alexander Henket and @Eric Haas just spoke in support of may be the best way to go. It doesn't actually require a change to the spec and it doesn't force selection of a "primary" code when there isn't one designated in the code system, but it should provide the necessary functionality in the relatively small number of cases where this is needed. It does it in a different way than we've been used to in V3 or elsewhere, but I think it should work. And @Russ Hamm is correct that I mentioned the V3 internal id to illustrate the situation, not as a recommendation for any use in data instances. And, to @Eric Haas's last question, I don't think VSD has anything to say or any rules about this, as it's a spec for value sets and this is a code system issue (but which does get exposed in value sets, of course).

Alexander Henket (Sep 25 2017 at 20:02):

If a codesystem happens to have 2 or more codes for the same concept, it is not-interoperable by design. The FHIR CodeSystem repesentation of that codesystem (note difference in capitals) SHOULD be about interopability. The codesystem may fail to choose but the CodeSystem should not.

The user may choose the alternative codes in his UI all he wants, but on the wire you don't want or need both codes. ConceptMaps should handle the conversion. So I mostly agree with you Rob, but I disagree that the CodeSystem should not pick a primary code for the wire. If a CodeSystem doesn't have more than 1 code, then it effectively states what the primary code is as ValueSets derive from it.

Grahame Grieve (Sep 25 2017 at 20:44):

How many code systems don't have a primary? I'm not aware of any, and I think that moving the decision from 'when you choose how to represent the code system' to 'when the engines work with the code system resource' is making the problem worse not better. @Joel Schneider why did you think this was relevant to HLA?

Alexander Henket (Sep 25 2017 at 21:55):

Well if the codesystem already tells you what is primary, then we're golden and deciding on what goes into 1..1 code is straightforward. I was under the assumption that the problem was that the codesystem did not say that and people were trying to copy that idea into CodeSystem by allowing multiple concept.code elements. -1 for that idea.

Grahame Grieve (Sep 25 2017 at 22:43):

y. -1. I expect that all the other terminology service developers will agree @Michael Lawley @John Gresh @Yunwei Wang (others I can think of not already in the thread)

Michael Lawley (Sep 25 2017 at 22:57):

One might argue that SNOMED CT doesn't have a primary. It is quite possible for two differnt codes to be modelled identically in different extensions (eg AU and SE). (Also, a non-primitive concept is always equivalent to a corresponding post coordinated expression).
I'm not convinced that ConceptMap is appropriate here - you would expect $subsumes and $closure (and code:below etc) to behave appropriately for both 147842 and MDC_ECG_HEART_RATE.
Lexical inequality is not the basis for code non-equivalence, although this assumption seems to be baked in to a great deal of software (and mindsets :)

Grahame Grieve (Sep 25 2017 at 22:59):

technically, there's a difference between 2 concepts with identical definitions and a single concept with 2 different codes. I think that the SCT extension space is a case of the former, not the latter (because they'll have different life cycles going forward)

Grahame Grieve (Sep 25 2017 at 23:00):

I should not that a post-coordinated grammar presents a whole new set of ways for a concept (as opposed for a CodeSystem.concept) to have multiple representations

Michael Lawley (Sep 25 2017 at 23:09):

Yes, agreed that two concepts with same definition is different to one concept with > 1 code representations, but I'm not sure that, technically, a post-coordinated expression is different.
It seems to me that the gap here is being able to express, in a FHIR CodeSystem, that a concept has > 1 code representations, or that two concepts are inherently equivalent.
I'll add here that SNOMED CT does include the notion of alternate identfiers (eg CTV3IDs) which map onto this case of single concept, multiple equivalent codes, albeit with a kind of implicit primary-ness for the SCTID

Rob Hausam (Sep 26 2017 at 02:37):

Unless I missed it, I haven't seen anyone take issue with my assertion that the V3 vocabulary machinery does allow multiple codes for a single concept, and for the active codes (however many there may be) for the concept none is designated as being primary. I have seen this "feature" both displayed in RoseTree and in the MIF XML and have used it myself on at least one occasion in a V3 harmonization proposal (and it was implemented, not rejected). I'm not advocating that is the way that it should be, but I am saying that is the way that it is. On top of that, this is in our own V3 vocabulary (not just some poorly behaved external system), and so far the FHIR implementation of the V3 code systems does not fully represent this. We can change the V3 rules to disallow multiple codes per concept going forward, or we can do something different in FHIR that does allow us to represent it, as we've been discussing, or I suppose we could even say that V3 doesn't matter any more - but I think that we will need to do something. If I've misstated anything, I'm more than happy for it to be corrected, as then maybe we wouldn't have to deal with it - @Lloyd McKenzie?

Lloyd McKenzie (Sep 26 2017 at 03:33):

2-character vs. 3-character vs. numeric country codes is another example (depending on whether you treat that as one code system vs. two). If two concepts have the same definition, then I'd say they're the same concept. If you do concept-based inclusion, it would be wrong to include one and exclude the other.

Ewout Kramer (Sep 26 2017 at 09:24):

I'd like to understand the difference between a CodeableConcept with multiple Codings with a single code and one Coding with multiple codes...it may not be obvious to everyone (it's not to me in any case!)

Joel Schneider (Sep 26 2017 at 14:27):

@Grahame Grieve Regarding HLA nomenclature, for some concepts the nomenclature defines an "optional" expression suffix. In those cases, it doesn't designate a primary code for the concept, as the suffix is optional.

Using a ConceptMap mechanism to represent the equivalence of suffixed and non-suffixed codes might be workable, but would be awkward. It would require the CodeSystem to repeat the same concept, and would also require use of a separate resource (ConceptMap) to define equivalence mappings.

Adding a new CodeSystem property (e.g. CodeSystem.allowsMultipleEquivalentCodes) to inform the implementation of the presence of concepts with CodeSystem.concept.code cardinality other than 1..1 could reduce the general impact of changing the cardinality of CodeSystem.concept.code.

Eric Haas (Sep 26 2017 at 14:52):

Based upon Lloyd's comment above maybe we should indeed treat these cases as separate codesystems. Instead of a new codesysem property you would know by the codesystem which codes you are using and each codesystem would have a single code. Downside is a lot of redundancy and need to use concept mapping resources. But there is always going to be a penalty for supporting multiple codes for the same concept.

Joel Schneider (Sep 26 2017 at 15:50):

In the case of HLA nomenclature (see also OID 2.16.840.1.113883.6.341), organizing the suffixed and non-suffixed codes into separate CodeSystem resources would raise an additional question about having multiple CodeSystem resources associated with the same OID Identifier.

Yunwei Wang (Sep 26 2017 at 15:51):

I don't like the change to 1..* either. Also, how does the 80-20 rule apply here? So far I see three code systems having multiple code for one concept: V3, Country code, MDC.

Grahame Grieve (Sep 26 2017 at 20:34):

@Joel Schneider can you provide an example?

Joel Schneider (Sep 26 2017 at 20:35):

@Grahame Grieve HLA-A*01:01:01:02N == HLA-A*01:01:01:02

Joel Schneider (Sep 26 2017 at 20:40):

both notations are valid nomenclature, and have equivalent meaning

Joel Schneider (Sep 26 2017 at 20:46):

For HLA, it would be possible for a client to strip off the suffix and use the code that way. Without CodeSystem.concept.code 1..*, it looks like defining a CodeSystem resource containing only the non-suffixed codes would be easier/better than the other workarounds discussed so far.

Joel Schneider (Sep 26 2017 at 21:27):

@Eric Haas If separate CodeSystem resources are created to handle multiple codes for the same concept, would they all have the same CodeSystem.url?

Grahame Grieve (Sep 26 2017 at 21:40):

what suffixes are possible? this looks like post-coordination grammar to me

Joel Schneider (Sep 26 2017 at 21:53):

So far, the possible suffixes to HLA allele names are N, L, S, C, A, or Q.
http://hla.alleles.org/nomenclature/naming.html

An additional post-coordination grammar, "Genotype List String" (or GL String for short), is used for describing ambiguous and/or diploid, etc. HLA results.
https://www.ncbi.nlm.nih.gov/pubmed/23849068

The documentation for LOINC code 77636-9 contains some simple examples of GL string notation.
https://s.details.loinc.org/LOINC/77636-9.html?sections=Comprehensive

Lloyd McKenzie (Sep 27 2017 at 03:38):

The problem with the 80% rule is that it applies to supporting "extra" content. The challenge here is that with a code system that has synonyms, there's no consistent canonical way to express the codes within the resource. We can't have computer systems pick a primary code when there's no primary code to pick. We could say "pick one at random", but I'm only comfortable with that if the choice has no impact on the computable behavior - and right now, I don't believe that's the case.

Robert McClure (Sep 27 2017 at 04:24):

A couple of comments. First, @Eric Haas , Rob was correct that the VSD does not give guidance on code system specifics, but it is consistent with Core Principles correctly noting that code systems can have concepts with multiple Concept Representations. BTW, A Concept Representation is a unique identifier for a concept within the span of the code system. SNOMED CT actually has many of them, including the fully specified name. They do identify one as primary - the "code" but we should understand that not all concept representations are codes.

I'll weight in here and say that I'm not in favor of allowing a code system in FHIR to exist without at least one concept representation - yes a code. Code systems EXIST to provide persistant identified meaning to curated concepts for data analysis and exchange. If you don't have something that can be identified as a concept representation then I suggest you don't have a code system, you have a list. That means the FHIR code system "code" must be at least 1..x

Given that I, along with the rest of you, can cite many examples where there are multiple valid concept representations in the code system, clearly suggests that in FHIR, code must be 1..* and to be honest, I am confused why this is so hard to accept and manage. Even if there are code systems that do not officially designate one of the concept representations as "primary" I'm confused as to why this results in the house of cards falling down. Remember you are dealing with a code system and you need to have access to code system information to use the codes. If an implementer gets a code/code system pair they don't understand because they chose to only include one of the multiple allowed codes for that code system in their environment, then they need to seek more information. Am I missing something here?

Michael Lawley (Sep 27 2017 at 04:26):

FWIW, here is the reference to the support for additional codes in SNOMED CT - https://confluence.ihtsdotools.org/display/DOCRELFMT/3.2.4.+Identifier+File+Specification
It appears that the documentation has been clarified from earlier versions and that now these alternate codes behave much more like equivalence maps

Michael Lawley (Sep 27 2017 at 04:28):

@Robert McClure I think the "house falling down" scenario is the simple (incorrect) assumption that unequal codes implies inequivalent concepts.

Grahame Grieve (Sep 27 2017 at 06:54):

no, it's an understanding that allowing more than code per concept means that at every operation, every server gets to ask 'which code now' and that will cause lots of confusion. Further, in almost all the examples cited around multiple codes for a concept, the codes are not synonyms, they have implicit semantics

Grahame Grieve (Sep 27 2017 at 06:54):

so far, the only case of genuine synonyms that have been quoted is the few places in v3 where we defined synonyms, and that's manageable

Joel Schneider (Sep 27 2017 at 14:20):

HLA-A*01:01:01:02N and HLA-A*01:01:01:02 are genuine synonyms (same concept). Absence of one or the other from the FHIR CodeSystem would be a stumbling point for interoperability.

Eric Haas (Sep 27 2017 at 15:07):

is hla a defined set of enumerated codes or like ucum an algorithm to construct the codes?

Lloyd McKenzie (Sep 27 2017 at 15:09):

What's the difference in implicit semantics between a post-coordinated vs. pre-coordinated SNOMED-CT code?

Joel Schneider (Sep 27 2017 at 15:10):

HLA nomenclature is a defined set of enumerated codes. A new "release" (version) is published every 3 months.

Joel Schneider (Sep 27 2017 at 15:12):

Hmm, the HLA nomenclature also defines meaning for shortened names, but those are only derived from fully-specified names, not constructed from scratch.

Bob Milius (Sep 27 2017 at 17:27):

fwiw, HLA nomenclature is curated by humans and maintained by IPD-IMGT/HLA (https://www.ebi.ac.uk/ipd/imgt/hla/)

Robert McClure (Sep 27 2017 at 17:56):

@Grahame Grieve I'm really not following something here.

Why would a server have to ask "which code now" every time? It should be able to handle multiple codes for a concept. If it can't, fix the server because code systems can have multiple concept identifiers. Full stop. Yes, it's not most code systems but it certainly happens. Yes, I'm not a programmer but is this basic requirement impossible to manage?

I'm also worried that some of the words you all are using are confusing me. I think of a synonym as "a word or phrase [<RCM> a description] that means exactly or nearly the same as another word or phrase in the same language." So these would be multiple descriptions for the same concept. You all seem to be using "synonym" to also include multiple codes for the same concept in a code system. Is that correct?

And I'm not understanding:

so far, the only case of genuine synonyms that have been quoted is the few places in v3 where we defined synonyms, and that's manageable
What do you mean by "where we defined synonyms"?

Grahame Grieve (Sep 27 2017 at 21:04):

What do you mean by "where we defined synonyms"?
we did that in v3 - defined more than one code for some concepts. I think that there's 4 or 5 of them all across v3

Grahame Grieve (Sep 27 2017 at 21:06):

Why would a server have to ask "which code now" every time?

cause I looked through my implementation to see. When the operation is 'is this code valid' or 'what concept does this code represent' then of course having more than one code is fine. But there's lots of places in the build tools, the IG builder, the terminology server whether a concept is selected, and my logic uses a code to represent the concept. Having more than one means my code has to pick one... and that's when it's a problem.

Grahame Grieve (Sep 27 2017 at 21:08):

as far as synonyms go, we are using it in relation to multiple codes for the same concept. I've only ever heard it used that way (and see ISO 760). I've not heard it used in regard to designations, or at least, if was being used that way, I didn't pick up on it

Rob Hausam (Sep 27 2017 at 21:09):

Hmm, I think exactly the opposite in regard to the the use of "synonym", Grahame. I think I can find documentation for SNOMED CT that supports that in regard to designations/descriptions, for sure.

Grahame Grieve (Sep 27 2017 at 21:11):

who would have that that terminologists would be unable to agree to their terminology about what they do?

Rob Hausam (Sep 27 2017 at 21:12):

Of course :)

Rob Hausam (Sep 27 2017 at 21:20):

This is the first hit from Google on "snomed ct synonym":
https://confluence.ihtsdotools.org/display/DOCGLOSS/Synonym
I don't think this general understanding is limited to SNOMED CT.

Peter Jordan (Sep 27 2017 at 21:20):

What's the difference in implicit semantics between a post-coordinated vs. pre-coordinated SNOMED-CT code?

Primitive or fully-defined concepts? (with apologies to Monty Python).

Lloyd McKenzie (Sep 28 2017 at 04:09):

If something is a primitive, then I don't think it can have an equivalent post-coordinated expression?

Peter Jordan (Sep 28 2017 at 07:27):

If something is a primitive, then I don't think it can have an equivalent post-coordinated expression?

Probably not, unless someone creates a post-coordinated expression in one version of SCT and in a subsequent edition a new primitive concept is introduced which is equivalent to that expression. Extremely unlikely, as one would expect post-coordinated expressions to represent fully-defined concepts, but perhaps not impossible.

Rob Hausam (Sep 28 2017 at 12:35):

Agree with Lloyd. You can set the definition status of a SNOMED CT post-coordinated compositional grammar expression to either "equivalent to" (===) or "subtype of" (<<<). If an expression has the same set of defining relationships as a pre-coordinated concept, a classifier/reasoner won't treat them as equivalent unless the expression is "equivalent to" and the pre-coordinated concept is "fully defined". This may help a little: https://confluence.ihtsdotools.org/display/DOCTIG/4.5.+Primitive+and+fully-defined+Concepts

Peter Jordan (Sep 28 2017 at 21:20):

Thanks Rob, that makes the theory clear. From a local perspective, what happens in practice, when people start to create post-coordinated SCT expressions, remains to be seen!

Robert McClure (Sep 29 2017 at 17:43):

@Grahame Grieve If your confusion about what a synonym means for concepts is due to us terminologists, I appologize, but in every document I've ever seen, including every description of a code system I've seen, the word "synonym" is used to describe descriptions/terms and never identifiers. I'm not sure what ISO standard you want to quote, but I can't find what ISO 760 is but it seems to be a general thing. I do see the word "synonymous identifiers" in Core Principles used consistent with it's english definition, to indicate that the identifiers are meant to represent the same idea, but you should not say the various identifiers are synonyms of each other. They would be considered alternate identifiers for the concept.

As for having to choose an identifier when more than one is available when a tool needs to insert a code into an instance, yes you would have to have a way of choosing. Seems you have come up with acceptable solutions in FHIR when faced with ambiguity so I'm surprised this one is confounding you. I think your usual answer to this sort of thing is "it's up to the server" and while I would hope that choice can be influenced by some process, I'd have to live with this as I've done elsewhere. I'd suggest that in storing multiple concept identifiers, we would want to indicate a primary, as has been discussed. If the primary is defined by the code system, you are set. If it is not, the it would be the terminology server job to pick one and indicate which one it is desgnating as primary in the capability statement. This should be true for any representation of a code system in any FHIR environment.

Eric Haas (Sep 29 2017 at 18:08):

In a vacuum the implementer will choose the "alternative identifier" to use. So how would an Implementation Guide define which to use? Do we need to indicate it in the ValueSet binding? E.g., use alternative identifier A from code system B and alternative identifier C from code system D. If define primary identifier in the code system can the Valueset trump that with its own selection for the use case? arrrgh total pain to deal with this.

Grahame Grieve (Oct 03 2017 at 05:47):

should have said ISO 704. been a while...

Grahame Grieve (Oct 03 2017 at 05:47):

00704-Terminology-principles-and-practices.PDF

Richard Townley-O'Neill (Oct 03 2017 at 05:49):

@Grahame Grieve
The PDF is broken. :(

Grahame Grieve (Oct 03 2017 at 05:49):

I'd really like to stick with a single designated preferred code. it really is simpler for everyone. and where code systems define additional identifiers, mostly they are not truly alternative identifiers. Truly alternative identifiers is a very edge case

Grahame Grieve (Oct 03 2017 at 05:51):

so after all this discussion, I'd still prefer to stick with primary code, and have either an extension or a structure for additional identifiers, each with a code.... but no, that's what property should be used for. et's just define a property for true synonym, and then specific code systems - MDC, for instance - can define additional properties like semantic identifier

Grahame Grieve (Oct 03 2017 at 05:52):

indeed the PDF is broken. my source is corrupted. Shame.... 704 is a model of clear thinking about terminologies that we should all know

Lloyd McKenzie (Oct 03 2017 at 06:24):

I don't understand the assertion that "mostly they are not truly alternative identifiers" - what examples do we have that aren't truly alternative identifiers? pre and post-coordinated codes in SNOMED are alternate identifiers for the same underlying concepts, aren't they?

Grahame Grieve (Oct 03 2017 at 07:20):

well, no. they represent the same concept but they are not actually truly substitutable. they have different implementations. As do snomed RT identifiers, and MDC semantic identifiers. And UCUM case insensitive codes - it makes sense to say 'do(n't) use them'

Grahame Grieve (Oct 03 2017 at 07:21):

you can argue that i could've use 'truly alternatives' but I think you should get my meaning

Grahame Grieve (Oct 03 2017 at 11:53):

00704-Terminology-principles-and-practices.PDF 00704-Terminology-principles-and-practices.PDF

Grahame Grieve (Oct 03 2017 at 11:53):

found i

Lloyd McKenzie (Oct 03 2017 at 18:18):

I don't know what you mean by "they have different implementations". They're two strings - two codes. How they get implemented by the back end - whether it parses them or even understands that one is post-coordinated and one isn't may vary and doesn't impact whether they're the same concept or not. You are free to use whichever you like to represent the concept. However, valuesets can be constructed that constrain which particular codes are permitted. And that's true for all synonyms.

Rob Hausam (Oct 03 2017 at 19:38):

A request - for clarity, can we use a different term besides "synonym" for the "multiple equivalent codes for a concept" case? As I think has been pointed out, in most of the terminology world "synonym" is understood as referring to alternative descriptions for a concept. If we want to use "synonymous codes" or "equivalent codes" or something like that for this "multiple equivalent codes for a concept" case, then I'm fine with that, but I think that we should avoid referring to both situations in the same way without distinguishing the one that we intend. Those of us who are significantly engaged in the discussion can probably keep it sorted without much difficulty, but I think it's likely to cause quite a bit of confusion for others more on the periphery if we aren't clear in our use of terminology!

Rob Hausam (Oct 03 2017 at 19:45):

I think we have to follow the practices that are established by the code systems that we are using. If one (or one type) of a set of multiple equivalent concept codes/identifiers is defined as being "primary", then by all means we should use that. But in the cases (which, rare or not, do exist) where a code system doesn't define one of the set of codes as "primary", then we shouldn't demand it and force ourselves or anyone else to make an arbitrary choice.

Richard Townley-O'Neill (Oct 03 2017 at 23:56):

On 'primary' codes, How about this as a policy?

Where there are alternate codes for the same concept, FHIR specifications SHOULD nominate a preferred code. This simplifies reading resource instances. The preferred code may be the code system's primary code for the concept.

Richard Townley-O'Neill (Oct 03 2017 at 23:58):

There is a 2009 version (3rd ed) of ISO 704, which was reviewed and approved unchanged in 2017.

Joel Schneider (Oct 04 2017 at 01:37):

Incidentally, the 1998 desiderata paper discusses a notion of redundancy, which includes synonymy:

In controlled vocabulary parlance, redundancy is the condition in which the same information can be stated in two different ways. Synonymy is a type of redundancy which is desirable: it helps people recognize the terms they associate with a particular concept and, since the synonyms map to the same concept (by definition), then the coding of the information is not redundant. On the other hand, the ability to code information in multiple ways is generally to be avoided. However, such redundancy may be inevitable in a good, expressive vocabulary.

It also notes:

As vocabularies evolve, gracefully or not, they will begin to include this kind of redundancy. Rather than pretend it does not happen, we should embrace the diversity it represents while, at the same time, provide a mechanism by which we can recognize redundancy and perhaps render it transparent.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3415631/

Rob Hausam (Oct 04 2017 at 02:39):

Yes, that's what we're dealing with here.

Grahame Grieve (Oct 04 2017 at 03:24):

I don't think it is. After the discussion we've had here. This is about duplicate concepts, not duplicate codes for the same concept

Lloyd McKenzie (Oct 04 2017 at 05:31):

How can "FHIR specifications" nominate a preferred code for a code system? FHIR specifications don't define the code systems. And multiple specifications may independently refer to the same code system and potentially make different choices - which would cause significant grief.

Lloyd McKenzie (Oct 04 2017 at 05:32):

I don't understand the notion that we're talking about duplicate concepts. A pre-coordinated code and it's post-coordinated equivalent are both symbols for the same concept. Same meaning. Same definition.

Grahame Grieve (Oct 04 2017 at 05:42):

the desiderata is talking about duplicate concepts

Grahame Grieve (Oct 04 2017 at 05:42):

And multiple specifications may independently refer to the same code system and potentially make different choices - which would cause significant grief.

so apparently it's better to delegate that grief to run time.

Grahame Grieve (Oct 04 2017 at 05:43):

that's what you're saying

Richard Townley-O'Neill (Oct 04 2017 at 05:51):

@Lloyd McKenzie
My comment is about value sets: where a code system has alternate codes for the one concept, the FHIR specification SHOULD prefer one.
As to implementing this idea, this could be done by leaving values out of value sets; another possibility is to use invariants. There may be other ways.

Richard Townley-O'Neill (Oct 04 2017 at 05:53):

Maybe core should not have preferences here, maybe only implementation guides should.

Rob Hausam (Oct 04 2017 at 10:47):

The Desiderata excerpts that Joel provided are talking about two different types of redundancy: (1) synonomy, or multiple descriptions for a concept - which is stated as desirable (and I agree); and (2) duplicate concepts - which is not desirable, but is accepted as inevitable and needs to be managed.

Rob Hausam (Oct 04 2017 at 11:04):

Lloyd's statement that "A pre-coordinated code and it's post-coordinated equivalent are both symbols for the same concept" may or may not be correct, depending on perspective. Is a post-coordinated expression an identifier (symbol) or a definition? Actually, it is (or can be) both - so, as noted above, the duplication needs to be recognized and managed.

Lloyd McKenzie (Oct 04 2017 at 13:45):

The grief of code systems with multiple codes/concept exists. And it's an essential part of really important code systems like SNOMED CT, so it's hard for us to say "don't do that" and have any hope of it sticking. If there was a way we could consistently and algorithmically determine a "primary" code in such situations and we could be confident that designating one as primary wouldn't change behavior around the use of the other alternatives, I'd be fine with that. But I haven't heard proposals that would do that. What I'm hearing is "pick one arbitrarily, doing so will impact software behavior and we don't care because synonym codes makes life hard". I don't think that's a reasonable approach to the problem, particularly when multiple codes per concept is not as rare a thing as it's being asserted it is.

Rob Hausam (Oct 04 2017 at 14:33):

Yes - I agree with Lloyd.

Eric Haas (Oct 04 2017 at 17:29):

I am unclear whether the ValueSet resource then inherits the multiple code designations too ( and push the problem to the implementation).

I proposed earlier and will repropose a heavy weight solution. Designate a unique code-system with its own uri for each code designation ( 'alternative identifer') and each would be identical except for the designated codes used. Plus a set of one-to-one concept map for each of the code designations. For example the SnomedCT concept IDs as one FHIR code system representation with the uri =http://snomed.info/sct and the old legacy codes ( I forget their official names) as a uri = http://snomed.info/legacyas another FHIR code system representation. Then at least is clear in an instance of a resource which code designation is being used. This is super heavy and redundant but it solves the problem of figuring out which codes are being used by an implementer. It does not address post coordination and I am ignoring that for this proposal. At least a starting point in discussing a lighter weight solution like an extension. ( which doesn't address the issues of how to figure out which alternative identifier is being used).

Lloyd McKenzie (Oct 04 2017 at 17:36):

If a value set enumerates codes, only those codes are permitted. If a value set defines contents by expression, the expression will determine what's included. By default, all equivalents would be. However, if there's a filter that says "no post-coordinating codes" or "3-character only" or something like that, then that will impact what's in the expansion.

Eric Haas (Oct 04 2017 at 17:39):

So if I were cerate a VS to include all the codes in 'codesystem multi' which had 3 alternative codes I would inherit the
( in my eyes) the problem of alternative identifiers.

Eric Haas (Oct 04 2017 at 17:41):

unlike people computers hate options... :-)

Rob Hausam (Oct 04 2017 at 17:46):

Agree with Lloyd. The "heavy weight" solution that you suggested, Eric, would work for the case of the SNOMED CT SCTID vs. legacy vs. CTV3ID situation that you described. In that situation most of the concepts (it used to be all of them) have one of each of the three types of ids. But that doesn't fit with the V3 situation, where only a small number out of the whole set of concepts actually have multiple codes, and when that does occur the different codes aren't distinguished by a different "id type" that can be discriminated to decide in which code system they should be placed. I do think that using ConceptMap may still offer something that could help us work with this, if we choose to go that way. In that case, we would just treat each distinct code as if it was representing a separate concept (staying with the 1..1 code per concept paradigm) and then declare in the ConceptMap that one or more of those codes are actually considered as equivalent within the code system. Then, if you need that level of detail you could have it, and if you don't care about it then you could ignore it and you still wouldn't be missing any of the codes that you (or anyone else) might want to be using.

Lloyd McKenzie (Oct 04 2017 at 17:58):

@Eric Haas Yes. Which you already do with SNOMED. If you say "all SNOMED CT procedure codes", that includes both the pre-coordinated and post-coordinated codes.

Rob Hausam (Oct 04 2017 at 18:17):

Right. And you will only know if a particular post-coordinated expression is a member of the value set by validating it ($expand is not likely to return any post-coordinated expressions in most cases, or to guarantee returning any particular ones).

Grahame Grieve (Oct 04 2017 at 20:30):

servers are allowed to return post-coordinated expressions from $expand, should that be appropriate - and my server does for UCUM. Not for anything else though

Grahame Grieve (Oct 04 2017 at 20:31):

it is rare for there to be true duplicates that are not semantically or operationally differentiated. So far, only a few v3 codes is the only case I know of.

Rob Hausam (Oct 04 2017 at 20:40):

Yes, I agree that servers are allowed to do return post-coordinated expressions from $expand - I was saying that typically that isn't very likely. UCUM may be an obvious exception, though. It's a little hard to imagine (at least for me at the moment) how you would do it or why you would want to try to do it for SNOMED CT compositional expressions generally - but I expect there could be some specific cases where that might prove to be feasible and useful.

Grahame Grieve (Oct 04 2017 at 20:45):

yes. it is hard. but there's a way to construct a value set where you specify a snomed code and ask for variations based on (for instance) laterality. I've not implemented it or had anyone ask for it, but it could be done as things stand

Rob Hausam (Oct 04 2017 at 20:46):

Yes, that's one of the specific cases I was alluding to.

Rob Hausam (Oct 04 2017 at 20:51):

And I agree that V3 is the only case that I'm thinking of where there are true duplicate codes that are not semantically or operationally differentiated. Unfortunately, we (HL7) created that situation even though there's probably not any really good reason that we had to have it. But, since we do have it, we have to figure out what to do with it in FHIR, and I don't think you can reasonably and reliably prioritize or exclude codes that are valid and active. Personally, since it's for this apparently one-off V3 case and there are only limited instances of it even in V3, it seems to me that using ConceptMap might be a feasible approach which would allow us to keep concept.code cardinality at 1..1 and still allow representing and using all of the valid, active codes in the code systems and value sets.

Rob Hausam (Oct 04 2017 at 21:12):

If we want to put through harmonization proposal(s) to inactivate all but one of the multiple codes in each case where they do occur in V3, then eventually the ConceptMap solution could simply go away (and there wouldn't be any effect on the spec itself). Unfortunately, the V3 machinery only allows codes to be 'active' or 'inactive' - there is no 'deprecated' status for codes, as there is for concepts. So it would take longer to get there, but we could at some point get to the state of "only one active code per concept" for the V3 vocabulary.

Lloyd McKenzie (Oct 04 2017 at 21:37):

I don't understand "semantically or operationally differentiated" when we're talking pre vs. post-coordinated. Certainly there's no semantic difference. And operationally, whether pre and post-coordinated are differentiated or not depends on the system.

Lloyd McKenzie (Oct 04 2017 at 21:38):

There's no difference to value set definition behavior for v3 synonym codes than there is for pre vs. post-coordinated SNOMED codes. Value sets can still include or exclude the codes.

Grahame Grieve (Oct 04 2017 at 21:47):

whether the server can handle post-coordinated or not, post-coordinated codes are operationally different

Rob Hausam (Oct 04 2017 at 21:55):

I believe "semantically or operationally differentiated" means like SCTIDs vs. legacy SNOMED identifiers vs. CTV3 ids for SNOMED CT concepts - they have a clear separation and a different business purpose.

Rob Hausam (Oct 04 2017 at 22:04):

Lloyd, I think there are significant differences between v3 "synonym codes" and pre vs. post-coordinated SNOMED "codes" - although they all can be used as identifiers for a concept. The V3 codes are all string values that are explicitly assigned for a specific (single) concept (and all V3 concepts are pre-coordinated). SNOMED CT compositional expressions, on the other hand, are definitions of a concept (as well as potentially identifiers for it) which are not pre-assigned in most cases by the code system authority and cannot be determined whether or not they are equivalent to one or more pre-coordinated concepts or other post-coordinated expressions except via validation (i.e. through normal form transformation and comparison or classification by a reasoner).

Rob Hausam (Oct 04 2017 at 22:12):

I do agree that there is no semantic difference between pre-coordinated codes and post-coordinated expressions, once that determination of semantic equivalence has been made (as above). And I also agree that they aren't different in regard to value set definition behavior and that value sets can include or exclude any of them based on how they are defined.

Grahame Grieve (Oct 04 2017 at 23:10):

ok, so, to sum up where I think we are:
- there are a number of different code systems that define more than one code to represent the same concept
- in a few rare cases, they are genuinely alternative codes
- but in most cases, they are operationally different (SCT expressions, UCUM case sensitive, MDC signififers, 2 letter vs 3 letter country codes, more generally expression variants), and value sets and services need to treat them differently
- the only machinary we have at present for dealing with this is a flag on the code system resource that declares that there is a post-compositional grammar in play (but no definition or reference to definition; we assume that implementers of the code system will discover this information out-of-band)
- we could press-gang ConceptMap into service here, but... it's odd. it maps between concepts not codes, and basically means that you would have to declare duplicate concepts in the code system, then map them as identical in a separate resource

Grahame Grieve (Oct 04 2017 at 23:16):

what I think we should do is add a list of alternate codes, along with a type signifier on the alternate codes, with an extensible value set binding where the value set contains codes for
- equivalent alternative (e.g. true duplicate)
- equivalent expression
- case insensitive & case sensitive variant (use which one based on whether code system as a whole is declared case sensitive or not)

And where code system can define their own additional types

Grahame Grieve (Oct 04 2017 at 23:18):

yes, this proposal requires that a code system chose a primary. And for the V3 codes, we should choose which are primary. That's a UTG question; I'll make a list of all cases like this. But choosing a primary means that all terminology servers will expand implicit value sets the same. Which I believe is a useful and important outcome. it also means that value sets can specify, when defined extensionaly, which code that should be used - by default, the primary, but if they want, one of the other codes.

Grahame Grieve (Oct 04 2017 at 23:18):

I can draft this up for vocab call to consider tomorrow.

Rob Hausam (Oct 05 2017 at 00:01):

OK, let's do it. Actually, it just occurred to me that we might want to consider both approaches. I think your suggestion is pretty clearly the way to go in the majority of the cases where you can straightforwardly determine a primary code and can clearly separate the different code types according to use. But maybe we should consider the ConceptMap approach for the V3 case with relatively few instances and true code equivalence with no systematic way to determine a primary.

Grahame Grieve (Oct 05 2017 at 00:07):

perhaps. we should fix v3 up anyway - I can't think that the current situation is actually good for anyone

Rob Hausam (Oct 05 2017 at 00:08):

I agree - we should fix it, and have a way to deal with it in the meantime.

Lloyd McKenzie (Oct 05 2017 at 03:30):

Codes are just strings. In an extensional value set, whether a code is post-coordinated or not is irrelevant. They're only operationally different in intensional value sets

Lloyd McKenzie (Oct 05 2017 at 03:32):

I don't understand how "we" can choose a primary - when "we" don't know all the systems that will be used in production apps that might have synonym codes.

Lloyd McKenzie (Oct 05 2017 at 03:33):

We can set a rule that says that the first alphabetic code in an equivalency list is primary, but we can't have it be a human-mediated choice because HL7 isn't a central clearing-house for doing that.

Grahame Grieve (Oct 05 2017 at 05:37):

we don't. whoever builds the code system resource does. And if you think that's bad, I don't see why it's better to delgate that to the operational systems

Lloyd McKenzie (Oct 05 2017 at 20:45):

You're presuming the CodeSystem resource will only get built once. But that's unlikely. Lots of people will handle the conversion - and use the URL that's been registered for that code system. But if there's no algorithmic mechanism, they might make different choices about "primary".

Grahame Grieve (Oct 05 2017 at 20:51):

they might. but delegating that to later in the process isn't going to make it better.

Lloyd McKenzie (Oct 06 2017 at 17:18):

I don't understand why there needs to be a primary at all. From a value set perspective, codes are either in or out. If there are 3 equivalent codes that are in, so be it.

Senthil Nachimuthu (Oct 06 2017 at 18:03):

I don't understand why there needs to be a primary at all. From a value set perspective, codes are either in or out. If there are 3 equivalent codes that are in, so be it.

It seems Lloyd is talking about duplicate (synonymous) concepts within a codesystem and Grahame is talking about multiple code types?

Lloyd McKenzie (Oct 06 2017 at 18:47):

I'm talking about any situation where there are multiple code symbols for a the same concept. (Same concept includes situations where multiple equivalent concepts are defined). That includes things like 2-character vs. 3-character, case-sensitive vs. case-insensitive, pre-coordinated vs. post-coordinated as well as places where there's simply multiple codes for a given concept for any other reason.

Senthil Nachimuthu (Oct 06 2017 at 19:14):

I'm talking about any situation where there are multiple code symbols for a the same concept. (Same concept includes situations where multiple equivalent concepts are defined). That includes things like 2-character vs. 3-character, case-sensitive vs. case-insensitive, pre-coordinated vs. post-coordinated as well as places where there's simply multiple codes for a given concept for any other reason.

Thanks for clarifying. I understand what you mean. But in most use cases, the value set implementer would want to have just one code type in the value set expansion because the client applications cannot handle multiple code types. We also have use cases where the implementer wants a specific designation type in the value set. Is there a recommended approach when there are such additional constraints on value set members?

Rob Hausam (Oct 06 2017 at 20:31):

Grahame has coded his suggestion for how to deal with this in FHIR in the current build at http://build.fhir.org/codesystem.html - look at CodeSystem.concept.alternate. This does require selection of a "primary" code to populate concept.code. For multiple code types, that can be handled with concept.alternate.kind. We need to take a look at this and see how it does (and doesn't) meet the needs that have been brought forward (and others we may not have thought of yet).

Lloyd McKenzie (Oct 07 2017 at 02:12):

Implementers enumerating the value set can get exactly what they wish. Implementers expanding the value set can filter if the code system gives them the properties necessary to differentiate.

Lloyd McKenzie (Oct 07 2017 at 02:14):

My problems with picking a primary are as follows:
- if a code system doesn't specify a primary, then value sets shouldn't pick one either without effort. If a code system has two codes for a concept and the concept is intensionally included, then the value set needs to include both codes - it shouldn't exclude one based on the arbitrary dictats of whoever encodes the code system in FHIR. I do not see a downside to both codes being in the value set - certainly not one that outweighs the downside of a code being arbitrarily excluded by someone not designing the value set.
- if multiple people encode the same code system in FHIR, we have no way of ensuring they will pick the same primaries.

Rob Hausam (Oct 07 2017 at 17:47):

I agree with all of those points, Lloyd. I would change one thing you said slightly, to "If a code system has two or more codes for a concept and the concept is intensionally included, then the value set needs to include all of the codes, unless the value set definition is written to exclude specific codes or code types" (which we should be able to do). The idea of a "code type" isn't something that we have currently, other than CodeSystem.concept.alternate.kind which Grahame has added in the current build. But I agree with you that I don't like forcing the selection of a "primary" code even when that doesn't exist in the code system, which the "alternate codes" proposal does. Plus, in cases where there are multiple codes per concept the "primary" code can legitimately have a "type" (e.g. the SCTID in SNOMED CT), and the "alternate codes" proposal doesn't provide a way to represent that.

Rob Hausam (Oct 07 2017 at 17:56):

I've added GF#14013 to deal with this, and we'll need to get it on the Vocabulary agenda soon - probably either on the main Vocab call on the 19th, or on a separate Vocab FHIR call (we're planning to start these calls ASAP).

Grahame Grieve (Oct 07 2017 at 20:02):

need to start them ASAP yes

Grahame Grieve (Oct 07 2017 at 20:03):

I'm not following the argument about picking a primary... you can't ensure that implementers will pick the same primary, so the solution is to not pick a primary... which just means that servers will need to pick a primary later in the process. I cannot see how this is better

Grahame Grieve (Oct 07 2017 at 20:04):

also, as it is, CodeSystem.concept.code is the internal identifier that is required to be unique. That's part of why I feel so strongly about taking the primary away.

Grahame Grieve (Oct 07 2017 at 20:04):

I note that no one here who actually maintains a server or code system infrastructure has spoken in favor of multiple codes...

Grahame Grieve (Oct 07 2017 at 20:10):

further, if you say that unless otherwise specified, the alternate codes are part of the expansion, then it doesn't matter which is chosen as the primary. So you should just stop obsessing about that

Rob Hausam (Oct 07 2017 at 22:04):

I'm not actually following why the server must, in all cases, actually pick a "primary" code and use it as an "internal identifier". I think that's going to be code system and server dependent. If they choose to, servers can implement code systems that don't declare a primary code for a concept. They will just choose some other "internal id" for the concept, and that doesn't matter from the FHIR API perspective because what we care about there is not the "internal id" but about the the codes that are actually being sent on the wire. Since all of the codes within the code system are required to uniquely identify a concept, we don't actually need to make one of them "special" in that regard as the "primary code" in order to accomplish that. To deal with the "alternate" codes being sent on the wire is also a change that is going to require additional coding by implementers, so I'm not sure that keeping code as 1..1 because of the implementer burden is really going to end up being all that strong an argument.

Rob Hausam (Oct 08 2017 at 14:24):

A problem that I can forsee with making CodeSystem.concept.code 1..* is the need to have a type/kind and probably also a status associated with each instance of a code. We've been discussing the need for the type/kind in regard to the various SNOMED CT identifiers and the 2 vs. 3 character vs. numeric identifiers for country codes, etc. V3 also has a status for codes that is independent of the concept status (possibly you could avoid dealing with that by allowing only the active codes to be represented, but maybe not?). In order to represent the type/kind and status of a code I think we would be looking at making CodeSystem.concept.code itself a complex element (or adding something like CodeSystem.concept.identifier with CodeSystem.concept.identifier.code and also the type/kind and status elements below it). Unless there's another reasonable alternative way to do it, that would definitely be a pain for implementers to have to deal with, and I don't think we should go there.

So I think that we should choose between Grahame's suggested approach using CodeSystem.concept.alternate (and we may need to think about dealing with the code status there, too) and the ConceptMap approach. Or maybe we should consider trying both approaches, particularly since using ConceptMap doesn't require any further substantive changes to the spec (we would just need to make it clear in the documentation that source and target can be the same code system/value set). I think that using ConceptMap might work pretty well for the V3 case, where there are only a relatively small number of instances of multiple codes and there is no obvious primary code to choose. But the concept.alternate approach I think will work better for the cases like the different types of SNOMED CT identifiers and possibly the country codes (although there I'm still not sure which of the three types is "primary"?). SNOMED itself has already done something similar by moving the CTV3 and legacy SNOMED "alternative" identifiers into a separate mapping reference set, so I think that's a precedent that we can follow in that case.

Lloyd McKenzie (Oct 08 2017 at 14:27):

I'm most comfortable with the ConceptMap approach because it has no need for "primary" to be identified.

Rob Hausam (Oct 08 2017 at 14:41):

Right. The one issue that I'm not sure the ConceptMap approach can deal with (at least not yet) is how to specify the different identifier types in the cases where that applies (e.g. SNOMED CT, country codes, etc.). But I think we could probably deal with that pretty easily by adding something like ConceptMap.group.element.kind (or type). That shouldn't break current implementations and ConceptMap is currently at maturity level 3, so that seems pretty doable. You could also end up needing a quite large number of maps in some cases, since each map is considered to be unidirectional. But that's probably manageable.

Lloyd McKenzie (Oct 08 2017 at 14:45):

Well, if we treat each code as a concept, then the identifier types could be handled through concept.property, no?

Rob Hausam (Oct 08 2017 at 14:47):

Yes, that should work. I believe that had occurred to me at one point, but it slipped my mind when I wrote that earlier. Actually, CodeSystem.concept.property is obviously the sensible place to specify the identifier type (ConceptMap wouldn’t make sense for that).

Lloyd McKenzie (Oct 09 2017 at 06:15):

Why is there a need to pick a primary code at all?

Rob Hausam (Oct 09 2017 at 06:47):

I'm not sure that there is a need to pick a primary code - but there is a need to distinguish the identifier types (as above).

Grahame Grieve (Oct 09 2017 at 09:24):

there's a need to be able to identify a concept

Rob Hausam (Oct 09 2017 at 12:28):

yes - there's no question about that

Lloyd McKenzie (Oct 09 2017 at 13:45):

So if we treat every code as a distinct concept and then indicate that certain concepts are identical, does that not meet our objective? (Though my leaning would be an extension that just provides repeating lists of code tupples rather than needing the overhead of a full concept map)

Rob Hausam (Oct 09 2017 at 14:24):

Yes, I think that does meet the objective. The problem I have with using an extension is that I think this is well within the 80% of requirements for terminology services to be able to fully support available and commonly used code systems. We've just managed to skirt it until now by using de facto "primary" codes and at times not fully representing the code system content.

Lloyd McKenzie (Oct 10 2017 at 03:49):

Ok, then add a 0..* CodeSystem.synonyms element with a 1..* CodeSystem.synonyms.code

Lloyd McKenzie (Oct 10 2017 at 03:49):

(i.e. it doesn't have to be an extension if we think it's in the 80%)

Grahame Grieve (Oct 10 2017 at 11:27):

umm, have you actually looked at the build? And, btw, we agreed earlier in the thread that 'synonyms' are not the right word

Eric Haas (Oct 10 2017 at 15:32):

Looking at the build - I think the only types that are useful are alternate and deprecated.

• Already an element for case-sensitive codes
• Practically speaking - how would one enumerate all the compositional equivalents in a code system beyond the simplest?

I'd propose as an alternative instead:

• 0..* alternateCode and
• 0..* supersededCode

no problemo nominating a primary code either.

Rob Hausam (Oct 10 2017 at 16:45):

CodeSystem.concept.alternate.kind currently is 1..1 with an extensible binding to the codesystem-altcode-kind value set. Other code system defined types/kinds like 'CTV3ID' for SNOMED CT and 2 or 3 character country codes may also need to be represented. Granted, most or all of those may be rather obvious on inspection of the codes themselves. But for writing value set definitions and generating expansions it would be best (and probably essential) to have an explicit type or property that can be referenced. Using the ConceptMap solution we can already do that with CodeSystem.concept.property, as Lloyd pointed out. But with CodeSystem.concept.alternate it seems that we would probably need either 1..* cardinality on 'alternate.kind' or a separate (optional) 'alternate.property' or 'alternate.type' element, and then the value set machinery would need to handle it in both places.

Eric Haas (Oct 10 2017 at 17:04):

those would be kind= alternative or in my proposed structure ... alternateCode

Eric Haas (Oct 10 2017 at 17:04):

machinery would need to be updated to handle them yes.

Rob Hausam (Oct 10 2017 at 17:09):

right - but I was also suggesting that "alternative" won't be sufficient by itself - you'll also need to be able to explicitly specify "CTV3" or "2-character", etc., based on the particular code system

Eric Haas (Oct 10 2017 at 18:14):

... since a codesytem uri is no longer sufficient .... So now we would need to add a way of selecting the code extensionally in ValueSet and use the valueset extension in Coding....

Lloyd McKenzie (Oct 10 2017 at 18:58):

The problem with concept.alternate is it require picking a primary code - unlesss all codes will list their alternates. I'm not ok with any solution that requires picking a primary code. The proposal had been to list alternates as a sibling to concept - so list all your concepts and then say "and by the way, these different code collections mean the same thing"

Grahame Grieve (Oct 11 2017 at 15:40):

of course ctv3id etc are needed - that's why the binding on alternate.kind is extensible. I'm not sure I follow why changes are needed to property

Grahame Grieve (Oct 11 2017 at 15:41):

nor do I follow why we would have a sibling to concept for this

Grahame Grieve (Oct 11 2017 at 15:41):

nor do I see why there's any problem with picking a primary code

Lloyd McKenzie (Oct 12 2017 at 11:52):

Picking a primary code is a problem because it will change behavior and because different people converting the code system might make different choices. If the author of the code system hasn't designated a primary, FHIR should never require that. If an author has designated a primary, that can be distinguished with a property.

Grahame Grieve (Oct 12 2017 at 12:07):

i am at this point confused about why you are so intent about this. What behavior do you think it will change?

Lloyd McKenzie (Oct 12 2017 at 12:08):

I don't want any possibility of expansions behaving different based on whether a code was designated as primary or not

Rob Hausam (Oct 12 2017 at 12:10):

And my corollary question is, if having a primary code is not expected or intended to change behavior, then why would it be important to require it?

Rob Hausam (Oct 12 2017 at 12:22):

I would like to spend some time talking about this today on the Vocab FHIR call. We'll timebox it, but maybe we can arrive at the point of making a decision next week on the main Vocab call (or the following one).

Grahame Grieve (Oct 13 2017 at 03:18):

because the primary code serves as the unique identifier internally. It's that unique identifier that I feel strongly about. If you say that expansions default to include the alternate codes, then which is indicated as primary doesn't make any difference to the expansion

Lloyd McKenzie (Oct 13 2017 at 15:53):

But there's no such thing as a primary code in some code systems. If your implementation depends on primary codes existing, then the implementation is broken. If we just say "all concepts have exactly one code, some sets of codes are identical", you should have what you need to implement because every concept will have exactly one identifier. But no-one will have to choose primaries

Rob Hausam (Oct 14 2017 at 00:04):

That's why, of the available options, I think this is the best approach to take. It will do what's needed, plus it won't require us to make substantive changes to the spec to make it work.

Grahame Grieve (Oct 14 2017 at 20:03):

I think this is a huge step backwards; we've been trying to move to a concept based system. Why define all the designations and properties more than once?

Lloyd McKenzie (Oct 14 2017 at 20:38):

Because that gives you your single element to resolve. The other possibility is we say that concept have 1..* codes and you can reference with any one of them.

Grahame Grieve (Oct 14 2017 at 20:40):

because that is broken too; only some of the codes are suitable as a unique reference. As for " If your implementation depends on primary codes existing, then the implementation is broken": says a non-implementer.

Lloyd McKenzie (Oct 15 2017 at 02:09):

You can't force primaries to exist just because they make implementation easier. It's absolutely possible to implement when a single concept can have multiple codes. There are two ways we can manage that - code = concept, and we duplicate properties and representations or concept = multiple codes and you deal with the fact that multiple codes could be referring to the same concept.

Last updated: Apr 12 2022 at 19:14 UTC