Stream: implementers
Topic: Condition Codesets
Joanna Gaskill (Aug 15 2017 at 15:59):
All of the FHIR resource sample codesets seem to favor SNOMED but it seems like other codesets could also be used, for example, using ICD codes for conditions. Is this considered acceptable in FHIR or would that mean our condition resources would be non-compliant? We do a lot of functionality around suggesting the coding of specific ICD codes to help doctor's optimize the data capture of diagnosis that can be submitted to CMS or other insurers during comprehensive diagnostic visits and because these diagnosis are intended to be submitted in claims, ICD is the preferred codeset. However, we would like to be able to share the data we captured via FHIR with EMR systems and other consumers. My concern with mapping to SNOMED is that we would want to both capture and display the data as ICD so I would be capturing ICD mapping to SNOMED and then mapping back to ICD when I go to render to our end users. This seems like it has a high likelihood of getting slightly different results after the two step mapping which would be concerning. Thoughts?
Eric Haas (Aug 15 2017 at 16:15):
See the definitions for binding strength here: http://build.fhir.org/terminologies.html#strength
The bindings are associated with various degrees of flexibility as to how closely the value set should be followed
Rob Hausam (Aug 15 2017 at 16:39):
Yes, most of the SNOMED CT bindings are example, which means just that - you can use those bindings, or you can use a different one (such as ICD) that you prefer. That is the case for Condition.code and many other places. Often SNOMED CT may be a good choice for obtaining a reasonable set of codes to use for the element (that's why it was chosen as the example), but you are not required to use it if your requirements or preferences dictate something else - or you could use it in combination, like coding in both ICD and SNOMED. If you did that you might consider coding in SNOMED (as it's richer and more fine-grained clinically) and then mapping to ICD, rather than the reverse. But you could carry both codes in the CodeableConcept data type so you wouldn't have to worry about the reverse or two step mapping issue that you described - you would always retain the original ICD code.
Lloyd McKenzie (Aug 15 2017 at 19:03):
By policy, the FHIR base specification will never require SNOMED codes to be used - as SNOMED is not a free code system and we try quite hard to ensure that implementers of FHIR aren't forced pay licensing fees. The strongest we'd ever get is "preferred" and even that's quite rare for SNOMED value sets. Realm-specific implementation guides may be tighter though. I believe US-Core requires SNOMED for condition codes, though it allows for supplemental codes for conditions that SNOMED doesn't cover.
Rob Hausam (Aug 15 2017 at 19:04):
Yes, that's the intent (and I believe we've been consistent with it in the core spec).
Paul Knapp (Aug 15 2017 at 22:44):
Agreed, and the granularity of codesets also matters, so you will find that financial exchanges, and therefore resources, favour ICD while clinical may favour SNOMED.
Last updated: Apr 12 2022 at 19:14 UTC
