Integrating ICD 11 Disease Classification into UgandaEMR

Question: @METS is implementing mortality surveillance through data collection and reporting on the Medical cause of death to support the National efforts towards reducing deaths. The cause of death has been coded using the International Classification of Diseases (**ICD 11**) with automatic submission from the facility directly from the facility to the national reporting system(DHIS2).

What is the easiest way to deal with these over 35000 concepts from ICD 11 without manually creating them into our data dictionary?

For those that have included ICD 11, what has been the easiest way to include it into our distribution.


From a concept paper we are working on: ICD-11-WHO

  1. The new version of ICD by WHO now includes an ontology and compositional structure.
  2. In addition to the foundational codes, there are extension codes which can be appended to the foundational codes to add specificity. In this use case, it acts like a post-coordination terminology.
  3. When post-coordinated, it is unclear how large a code may become which can create problems for application developers.
  4. WHO is requiring ICD-11 to be accessed only via an API from a WHO server.
  5. The post-coordinated codes can be confusing, particularly when queried. There is no obvious mapping between ICD-11 and SNOMED, particularly if the codes are post-coordinated.

Because of this, and the licensing restrictions which makes it difficult to map existing legacy dictionaries to ICD-11, using ICD-11 now will be a challenge. CIEL intends to map existing concepts to ICD-11 to maintain continuity (and to allow analytics using SNOMED, etc.).

Which ICD-11 codes you create also depends on the use case. The linearization used for mortality reporting is not the same as what is needed for clinical classification. Post-coordination would create a combinatorial explosion. Perhaps there is a way to get a prevalence / frequency distribution of which codes are being sent over a period of time, and use that as a way to prioritize the mapping/creation of dictionary concepts.


@solemabrothers I think the fastest thing and the easiest to maintain over time would be to use OCL for this. @jamlung does OCL offer ICD11 yet? I see there’s a WHO-ICD-11 source on OCL but it looks empty (here).

However, @solemabrothers if ICD11 is not easily accessible via OCL’s existing libraries, here is another easy option: if you can get a csv-version of ICD 11, you could simply upload that to your distribution’s /config folder under the /concepts folder (example here from the RefApp). Note this workflow requires the Initializer Module (documentation on how Iniz helps with concepts here). I can’t speak to ICD-11 licensing issues but this is a very practical workaround. The great thing for you as an implementer with thousands of sites is that Iniz unpacks your distro config in a standardized manner so you can rest assured that your distribution config will be standardized consistently accross your sites. (This is the main reason we use Iniz so much for how we set up the O3 RefApp these days.)

In general I usually recommend that folks use OCL (and subsequently the /ocl folder like the RefApp here) but this /concepts folder work-around is a very fast option.

Data quality caution: Speaking of over 35,000 concepts though: Please be aware that this will likely create very long drop-down lists for your users. I have personally seen clinicians intentionally click wrong ICD codes because they get so annoyed trying to find the right one while patients are waiting for them, that they will just click a sort-of-related one just to get done with the field. E.g. if a a clinician needs a code for “Chest Pain, Cause Not Yet Diagnosed” but can’t easily find this, they may just click a code related to heart stuff, like “Cardiomegaly” - this is a very different condition and of course will impact your data quality. This is why I have personally avoided importing all of CIEL’s 50,000+ concepts into the RefApp and instead have opted for a pick-and-choose-carefully approach. But, if your country or region’s policy requires all 35,000 codes, then you can try to make the code-finding user experience as easy as possible, e.g. with really good searching experience for providers.

Good luck and let us know what you end up choosing, there are many folks who are in a similar situation with being asked to support ICD-11 :slight_smile:


@grace looks like the easiest option is indeed to use the concepts folder along with the CSV files to ensure that these concepts are imported.

The concepts are indeed very many and as a solution, we have implemented an auto complete functionality within the form to ensure that the clinician does not have to scroll through all the available options within the dataset.


@grace @solemabrothers OCL unfortunately does not offer ICD-11 yet, although we are working with WHO to get that into OCL. I don’t envision the content being usable in the near future though.

Everything else in Grace’s reply above sounds right though - definitely should be cautious about long dropdowns!

I’d also point out that WHO is asking that you use their API to search ICD-11, so you wouldn’t want to have a dropdown or stored list of ICD-11 codes (which could be old). The challenge is that the ICD-11 code itself would not be mapped to a concept_id in the OpenMRS dictionary. I think you would probably try to use the same method that Bahmni used for SNOMED coming from a SNOMED server. If the concept doesn’t already exist, add it to the dictionary. However, you can follow all my concerns about that method in the Bahmni/SNOMED discussion. We still haven’t addressed any analytic use cases or clinical use cases. If we just want it for cause of death, then it probably is OK just to capture a single ICD-11 code but have the app call out to their API and then store it as a stand-alone concept in the OpenMRS dictionary. This probably deserves a full discussion!

1 Like