Stream: implementers
Topic: saving postcoordinated code in Coding datatype
Simone Heckmann (Mar 21 2017 at 17:52):
We're currently profiling the Condition resource for usage with ICD-10 (german modification).
ICD-codes can have additional Symbols like "*" (secondary diagnosis), "+" (primary diagnosis) and (but that's a particular thing to Germany) also symbols for laterality and verification status.
So, whenever we're storing or communication these codes using the Condition resource, we'd resolve these extra symbols to references between Conditions (linking secondary to primary), values for bodySite or verificationStatus.
Condition.code would only have the bare ICD-10 code without the extra symbols, as this is the only part that's valid in the ICD codesystem.
However, some systems may not be able to resolve the symbols and for some particular usecases, systems may wish to communicate the postcoordinated form of the code additionally .
We were thinking about extending the datatype' Coding' to have an additional field for the postcoordinated form. But since Postcoordination occurs in many CodeSystems and certainly more countries than just Germany, creating a national extension doesn't sound like a good idea.
How do others (SNOMED people?) resolve this? Is there already an extension for this?
Grahame Grieve (Mar 21 2017 at 20:33):
the code itself contains the expression
Simone Heckmann (Mar 21 2017 at 21:04):
Not sure I unterstand what you mean.
We have e.g. "C50.3 V L"
V meaning it's a provisional diagnosis, L referring to the left body site.
In our CodeSystem http://fhir.de/CodeSystem/icd-10-gm/2016 only the code "C50.3" is a valid code.
So we'd create the following resource:
<Condition xmlns="http://hl7.org/fhir"> <clinicalStatus value="active"/> <verificationStatus value="provisional"/> <code> <coding> <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/> <code value="C50.3"/> </coding> </code> <bodySite> <coding> <system value="http://fhir.de/CodeSystem/kbv/s_icd_seitenlokalisation"/> <code value="L"/> </coding> </bodySite> </Condition>
But some usecases (e.g. billing) require just to have the original string "C50.3 V L", so the systems involved would have to assemble and dissemble the string from the resource all the time, so we're wondering if it wouldn't be easier to include it in the resource, so systems can pick whether they want the structured version or just the "string".
We've been thinking about repeating the coding with a different codesystem. But a codesystem in which "C50.3 V L" was a valid code would have to contain all permutations of ICD-10 codes and its additions. Wouldn't that be weird?
Grahame Grieve (Mar 21 2017 at 21:18):
Coding.code is allowed to contain any valid expression defined by the Code System. If you read the definitions for UCUM, SNOMED, and ICD-10, you'll see that they allow various forms of post-coordination in the value. You just have to describe the grammar somwhere - and we don't say that you have to describe it computably
Grahame Grieve (Mar 21 2017 at 21:20):
and there's no need for a code system resource to contain all the permutations - in the CodeSystem, you just set compositional = true, and that says that there's some grammar that applies
Simone Heckmann (Mar 21 2017 at 21:27):
oh! that's convenient. thanks :)
Stefan Lang (Mar 21 2017 at 21:33):
To make that complete: it is not necessary to have the grammar somewhere in a computable manner, but it is definitely necessary for that grammar to define computable rules, right?
Stefan Lang (Mar 21 2017 at 21:34):
E.g. for the ICD-10 qualifiers it might define that every qualifier has to be separated with spaces, so that "C50.3 V L" would be correct, but "C50.3VL" or "C50.3V L" would be formally incorrect
Simone Heckmann (Mar 21 2017 at 21:44):
So that means that in FHIR "Measles complicated by otitis media "B05.3† H67.1*" is actually not two Conditions referencing each other (H67.1 "dueTo" B05.3) but in fact just one Condition with a postcoordinated code?
Grahame Grieve (Mar 21 2017 at 21:45):
those are isopmorphic statements of the same concept
Lloyd McKenzie (Mar 21 2017 at 21:48):
The multi-resource variant allows you to convey a lot more though. So you'd choose to use one resource vs. two based on whether you think of them as two assertions or one.
Stefan Lang (Mar 21 2017 at 22:04):
@Grahame Grieve So basically getting certain axis out of postcoordinated codes is beyond the scope of FHIR and left to the application's capabilities to parse them?
We had a discussion about that last week here in Germany and actually found a number of use cases where queries like "show me everything that happened to the patient's left side of the body" may make sense. This is why we put that separately into bodySite.
Simone Heckmann (Mar 21 2017 at 22:18):
@Lloyd McKenzie: I'm not thinking about assertions at all. I'm thinking about how to define a profile to ensure interoperability across the country :)
But as you say: Which representation is correct depends on the UseCase. But since diagnosis have the nasty habit of crossing UseCases, we have to figure out a way to accommodate all. So I'm still hanging on to the idea of having both the "clean" code with the semantic of the additional symbols mapped to other fields as well as the embellished code...
Stefan Lang (Mar 21 2017 at 22:21):
+1 for Simone's clarification
Simone Heckmann (Mar 21 2017 at 22:22):
Also: there's at least one embellishment we have to parse and map, since the Symbol "A" means "refuted" which modifies the meaning of the resource.
Grahame Grieve (Mar 21 2017 at 22:25):
the idea of the terminology server interface is that you can delegate these problems cleanly to the terminology server
Grahame Grieve (Mar 21 2017 at 22:25):
I'm happy work with you to add this code system to my terminology server
Simone Heckmann (Mar 21 2017 at 22:29):
Thank you for the offer! However, until we can do that, we have to figure out what the actual rules are. The way ICD-10 is used seems to be more folklore than Terminology :)
Grahame Grieve (Mar 21 2017 at 22:29):
it's always useful to get clarity
Simone Heckmann (Mar 21 2017 at 22:37):
But still: Assuming we delegate all validation and search logic to the Terminology server, we'd still have to be aware of all modifying characteristics of the postcoordinated code. I wouldn't expect every system that just displays the diagnosis to consult a terminology server to figure out if it's confirmed or refuted.
Grahame Grieve (Mar 21 2017 at 22:37):
that's why we have a status element. it would have to be consistent
Simone Heckmann (Mar 22 2017 at 06:35):
ok, so I think our tendency is to purge the code from the additional symbol for verificationStatus (since we have to map that anyway) and the laterality (because it's trivial). Adding the grammar for these symbols to the icd-10 CodeSystems doesn't feel right, because these symbols and their grammar are specified by another authority.
What we could think about it to introduce an additional CodeSystem that's called e.g. icd-10-gm+kbv-codes that consists of ICD10 plus the added symbols.
But as fore the "pure" ICD postcoordination: I guess the question of whether to handle dagger-star-notation as one or two diagnosis is as universal as ICD. Has this been discussed in other groups as well? @Lloyd McKenzie @Alexander Henket ?
Grahame Grieve (Mar 22 2017 at 06:44):
vocab believed that it was a universal practice for ICD-10. But we also defined a specific code system for the ICO-10 german reslease: http://hl7.org/fhir/sid/icd-10-de
Grahame Grieve (Mar 22 2017 at 06:44):
we would like HL7 DE to describe that somewhere in the DE FHIR documentation. Rather than define a separate code system for post-coordination
Simone Heckmann (Mar 22 2017 at 07:40):
Ah, I didn't even know this site existed: http://build.fhir.org/icd.html
Will have some reading up to do!
Sure, if the standard already defines a CodeSystem for ICD-10-DE we'll use that URL.
Last time I checked, it didn't. But that may have been a while ago, when we first started discussing the topic.
Stefan Lang (Mar 22 2017 at 08:16):
http://hl7.org/fhir/sid/icd-10-de as a singular CodeSystem name is not sufficient, since per definition there is a complete new ICD-10-GM CodeSystem every year. So that would have to be http://hl7.org/fhir/sid/icd-10-de/2015, http://hl7.org/fhir/sid/icd-10-de/2016, http://hl7.org/fhir/sid/icd-10-de/2017 and so on.
But that's a different issue.
Stefan Lang (Mar 22 2017 at 08:34):
While looking into that, I found several issues:
1. https://www.hl7.org/fhir/terminologies-systems.html states that http://hl7.org/fhir/sid/icd-10-de has the OID 1.2.276.0.76.5.409 . But apparently due to improper text alignment there, the OIDs have been copied incorrectly to http://build.fhir.org/icd.html
2. 1.2.276.0.76.5.409 is not the OID for ICD-10-GM. It is the OID for ICD-10-GM from 2012.
3. Instead, as I said above, every year we have a new code system, therefor a new OID (and in FHIR: an new name), see: http://wiki.hl7.de/index.php?title=Kodesysteme
I suggest to create a tracker item for that, if anybody seconds
Simone Heckmann (Mar 22 2017 at 09:54):
Seconded for the correction of OIDs. As far as changing the version vs. changing the name/url of the CodeSystem with every new version, I think I have to put on my thinking helmet and contemplate the dependencies of ValueSet, CodeSystem, CodeableConcept and Code.version in Instance vs. CodeSystem.version of Codes and how it all impacts the ValueSet binding in Profile (which also have versions).
Stefan Lang (Mar 22 2017 at 10:15):
Grahame Grieve (Mar 22 2017 at 11:21):
what makes each new release a different code system? do they redefine the meanings of the codes?
Stefan Lang (Mar 22 2017 at 11:24):
Exactly. Sometimes they are re-defined, sometimes codes are added, changing the meaning of the XNN.9 code ("disease XYZ, other")
Stefan Lang (Mar 22 2017 at 11:32):
As you can see at http://wiki.hl7.de/index.php?title=Kodesysteme the same applies to other code systems like OPS, AlphaID, TNM, ...
So this is a very basic thing.
Grahame Grieve (Mar 22 2017 at 11:38):
I think that there's a clear difference between changing the intension of a code, and it's extension. In classifications, you see a, b, c, other, and then the meaning of 'other' changes if e is added.
Grahame Grieve (Mar 22 2017 at 11:42):
But I don't think that's true - the meaning of 'other' is driven by the value set, (it might be [a, b, other]). For this reason, I think that the typical interpretation of a classifications creating new code systems when additional codes are added and implicitly redefining 'other' or 'nec' is wrong.
Grahame Grieve (Mar 22 2017 at 11:42):
but also, real genuine redefinitions happen too
Stefan Lang (Mar 22 2017 at 11:44):
For the "other" thing - well, German terminologists say that these changes are equal to redefinitions.
But true, "real" redefinitions also happen
Stefan Lang (Mar 22 2017 at 11:45):
For example, from the Changelog of ICD-10-GM 2016:
C43.-
Bösartiges Melanom der Haut
REMOVED: Inkl.: Morphologieschlüsselnummern M872-M879 mit Malignitätsgrad /3
ADDED: Exkl.: Bösartiges Melanom der Haut der Genitalorgane (C51-C52, C60.-, C63.-)
Grahame Grieve (Mar 22 2017 at 11:46):
yes I know terminologists say that, as a dogma. But I think they're wrong because of value sets, and that they should re-evaluate. You can never interpret an 'nec' properly, unless you know the value set. and if you know the value set, then you know what the working meaning is - the definitions are in effect, deferred to the value set
Stefan Lang (Mar 22 2017 at 11:48):
Well, that might be an interesting discussion at some WGM ;-)
Still the real redefinitons exist
Stefan Lang (Mar 22 2017 at 11:51):
In the example above, an Inclusion is removed and an exclusion is added.
So what has been coded as C43.something in 2015 must be coded e.g. as C52 in 2016
Grahame Grieve (Mar 22 2017 at 11:59):
yes, that's a real change.
Simone Heckmann (Mar 22 2017 at 12:58):
IMHO, if we set the CodeSystem.needsVersion to "true" and all the instances carry the Version in coding.system (".../icd-de|2016") the semantic is clear even if it changes between 2015 and 2016
Simone Heckmann (Mar 22 2017 at 13:42):
@Grahame Grieve Regarding your offer: Does your Server allow having two distinct CodeSystem resources with the same logical url but different version and does it resolve the version-specific coding.system-url when validating instances?
Grahame Grieve (Mar 22 2017 at 20:00):
yes and yes
Simone Heckmann (Mar 22 2017 at 20:44):
why did I even ask? :D
Simone Heckmann (Mar 22 2017 at 22:19):
Since there's no example for dagger-asterisk on the icd-page:
What's suggested there means that the postcoordinated Code "B05.3† H67.1*"
would look like this:
<coding> <system value="http://hl7.org/fhir/sid/icd-10"/> <code value="B05.3† H67.1*"/> </coding>
...or does the sequence of the codes alone imply which is primary and which is secondary, so the dagger and asterisk can?/should?/shall? be omitted? This isn't really clear from the description.
@Rob Hausam ?
Rob Hausam (Mar 23 2017 at 10:05):
Our feeling was that the sequence is sufficient to unambigously specify the meaning and that the dagger and asterisk symbols can (and should) be omitted.
Rob Hausam (Mar 23 2017 at 10:06):
I thought that was described, but possibly not well enough, as you say.
Simone Heckmann (Mar 23 2017 at 11:20):
Ok, that's an issue then, because if you need the Dagger-Asterisk notation to e.g. pass the Code to a billing system, you can't just reproduce the original form, unless you are a Terminology System that's in the know about which Diagnosis use Dagger-Asterisk, and which don't (or !-Notation, which is specific to ICD-10-GM)
Stripping unneeded symbols would be far easier to compure if the UseCase requires it.
Rob Hausam (Mar 23 2017 at 17:10):
If then the dagger and asterisk symbols are specific to only particular contexts, and if they convey any semantic beyond simply the ordering, then that would be an issue. If so, it should be pretty easily solvable by simply expanding the description of the "syntax" to include the symbols within the string as you've shown. But if stripping the symbols doesn't cause any loss of information and they can be added back algorithmically as needed, then we can leave it as it is. We should figure out for sure which case it is.
Simone Heckmann (Mar 23 2017 at 19:36):
The problem we have with ICD-10-GM is this:
Exclamation mark codes: Optional codes
Exclamation mark codes are optional codes. They must never be used on their own, but only in addition to a primary code, i.e. a code not marked with * or !. Their purpose is to further specify the condition encoded with the the primary code.
https://www.dimdi.de/static/en/klassi/icd-10-gm/systematik/kategorie.htm
Due to this, we have two different kinds of combined code, distinguisted only by their Symbols.
Can you give us a little bit of insight on why you decided to collapse primary and secondary diagnosis in one resource rather than creating two Conditions with secondary referencing primary through the condition-dueTo-Extension?
Grahame Grieve (Mar 23 2017 at 19:40):
I don't think it's right to say that we made that decision. We made a terminology decision that if people wanted to do dual coding - as described by ICD-10 - then this was the syntax to do it. We were not addressing the question of whether 2 conditions would be be better.
Grahame Grieve (Mar 23 2017 at 19:40):
however my personal belief is that if all you have is a =n ICD-10 dual code, creating two conditions is unuseful overhead
Alexander Henket (Mar 27 2017 at 16:45):
To date we have never done ICD-10 in messaging that I know of (or it would have to be DFT^P03). If possible I'd like to keep it that way :-) Diagnosis codes are normally SNOMED-CT or ICPC-1-NL to us
Last updated: Apr 12 2022 at 19:14 UTC
