Stream: terminology
Topic: Implementing multiple CodeSystems to support a ValueSet
Joe Jordan (Jul 23 2020 at 13:43):
I’m looking to support the US Core Condition Code ValueSet (https://hl7.org/fhir/us/core/ValueSet-us-core-condition-code.html) on a UI I’m developing. We are trying to figure out how to meet the criteria of providing the end user with searchable access to both SNOMED and ICD9 and ICD10. I believe we have a handle on getting SNOMED into our FHIR server, however the additional requirement to support ICD9 and ICD10 has us spinning a bit. Has anyone added ICD9 and ICD10 as a CodeSystem to their FHIR server? Ideally we’re looking to build one field where the user can enter text or a code number and it returns a subset of results to choose from. Are we on the bleeding edge, or has someone implemented something like this successfully and can help guide our way? Thanks in advance.
Rob Hausam (Jul 23 2020 at 18:59):
For the tx.fhir.org server that we use for the FHIR spec and IG builds, we haven't fully implemented ICD-9-CM and ICD-10-CM (or the other ICD variants) due to the difficulty in getting a complete source for the codes (the published files from CMS/NCHS don't enumerate a large number of the leaf codes, typically including the 7th character, which are required to be valid for use). If you do have a source for all of the needed codes, then, at least theoretically, you could create a (massive) value set containing all of SNOMED-CT, ICD-10-CM and ICD-9-CM and use that in a suitable FHIR terminology server and use $expand?filter=xxx to do a type-ahead search. I'm not sure if anyone else has actually done this, but I think it should be doable (if the terminology server is sufficiently robust).
Christof Gessner (Jul 23 2020 at 19:20):
Germany and WHO use ClaML and our experts at BfArM have quite some experience with pitfalls in importing/exporting ClaML. One test case being the upload to the EU eHDSI term server (non-FHIR for now) @Christine Haas
Michael Lawley (Jul 24 2020 at 03:02):
We generally import ICD10 as a CLAML -> FHIR CodeSystem path
However, the idea of mixing classification codes (ICD9/10) with clinical terminology (SNOEMD) in a UI sounds like a horrendous user experience and a recipe for really low quality data.
Do you really need to allow entry of all those things, or just accommodate receipt of data from other systems that may use any of those code systems?
Grahame Grieve (Jul 24 2020 at 05:22):
Depends on context; I routinely mix them in developer ide tools. And perhaps this a patient tool?
Joe Jordan (Jul 24 2020 at 13:14):
Michael Lawley said:
We generally import ICD10 as a CLAML -> FHIR CodeSystem path
However, the idea of mixing classification codes (ICD9/10) with clinical terminology (SNOEMD) in a UI sounds like a horrendous user experience and a recipe for really low quality data.
Do you really need to allow entry of all those things, or just accommodate receipt of data from other systems that may use any of those code systems?
My understanding is that if we want to implement the Condition US Core requirements to the letter, the input field for Condition Code must support SNOMED, ICD9 and ICD10. It does not sound, however, that this is feasible to implement at this time, in part due to the issues @Rob Hausam mentioned in even obtaining a complete set of ICD data. Right now we're leaning toward supporting just the SNOMED codes and revisiting at a later date.
Joe Jordan (Jul 24 2020 at 13:27):
Grahame Grieve said:
Depends on context; I routinely mix them in developer ide tools. And perhaps this a patient tool?
We're implementing a practitioner-facing interface where they can create care plans for their patients. One of our requirements is that the practitioner must assign a condition to the patient care plan, and we've been looking to support US Core in our resources wherever we can, so here we are. Do you have a data source to resolve the data availability problem @Rob Hausam mentioned? Any other tips or guidance in our attempt to meet this particular data requirement?
Grahame Grieve (Jul 24 2020 at 20:37):
then I do agree with Michael; the validation rules allow ICD-9 | ICD-10 | SNOMED for historical purposes. It's a bad rule to drive your clinical design, which should be informed by proper SNOMED design principles
Robert McClure (Jul 25 2020 at 17:59):
@Grahame Grieve is correct, it's also to support multiple sources with data generated for different use cases. Creating new data with a clinical use case should focus on SNOMED CT and then deal with mapping if aggregating with other sources.
Last updated: Apr 12 2022 at 19:14 UTC
