Diagnoses list in use in Haiti

Hi Haiti community!

As we are starting our new hospital implementation in Northern Haiti, we are wondering what is going to be the best approach about maintaining a comprehensive list of diagnoses

I look into Haiti Core and there isn’t any bundle of diagnoses in there, therefore I was wondering what was used at both Mirebalais and in iSantéPlus? Is it simply the diagnoses out of the CIEL dictionary?

Cc: @nathaelf @ball @mogoodrich

@mksd The Haiti implementation includes concepts for diagnosis (1589), symptom (23), symptom/finding (38), and finding (282). These are all included in github (mds package).

These are a subset of the CIEL concepts since we limit to diagnoses that are possible in our health facilities (health clinic -> tertiary/teaching hospital) without overloading the users with choices.

https://github.com/PIH/openmrs-module-mirebalaismetadata/blob/master/api/src/main/resources/HUM_Clinical_Concepts-177.zip

2 Likes

Ah! That’s amazing, thanks @ball for pointing me so quick to your metadata resources, super useful. We will certainly check that MDS package out in the next week or two.

Do you know from the top of your head about how many diagnoses this is?

The reason I’m asking is because “usually” we would maintain this kind of metadata as a CSV that is then loaded with the Initializer module (example here). Unless its thousands of diagnoses of course…

(Cc @mksrom )

@mksd, I’ll let @ball clarify the number, but @mogoodrich and I are definitely interested in seeing if we can start leveraging Initializer more in general.

Mike

1589 diagnoses + symptom (23), symptom/finding (38), and finding (282)

Cool, thanks @ball. Ok, that’s a lot of diagnoses… :slight_smile:

@mseaton great, we have been really happy with it. We have used it in 4 implementations/distributions (1 Ref App + 3 x Bahmni), applying its underlying logic of the OpenMRS config strictly separated from the binaries. However this one is precisely a tricky case.

The thing is, it could work to load 2,000 concepts line by line with the Initializer but the initial loading would probably be painfully slow. You probably remember the base idea, such CSV will not reload until its checksum has changed. So everything is fine, until you decide to correct one typo in a diagnosis name in some locale.

This can be worked around by introducing a second CSV that would be used to bring changes and additions. But that would mean that the overall diagnoses are kept as two (or more) files. We could live with that, but that is not an amazing format to share and maintain a list of diagnoses across implementing teams. I guess.

On the other hand maybe those ~1,600 diagnoses hardly ever change, and all is fine. I wanted to look at the file history to get an idea about this but it seems that it was brought from elsewhere recently?

Remember, that patients have more diagnoses than just the number of ICD-10 codes. :slight_smile: I would be sure to use links to CIEL in those concepts, however, as although the medical concepts do not change (usually) the underlying codes DO change over time.

Hi @ball @mseaton bumping this here too just in case you happen to know:

@ball / @mseaton / @mogoodrich, while nailing TRUNK-5326 is important, what we simply need here is just a one off import ahead of exporting all those concepts as CSVs for the Initializer to process them. My SQL query is already ready.

Hence my question: would be possible for you to share a database dump made out of an instance that has loaded the MDS package in question?

@mksd, if I’m understanding you correctly, I think if we just give you a package with all the concept sources and you import that first, it should work… I’ll send you our package of all our concept sources, try importing that first…

Take care, Mark

1 Like

Fantastic @mogoodrich! Got it (by email). I’ll report back. Thanks a bunch.

@mksd Once you are able to see the diagnoses in the HUM_Clinical_Concepts package, you’ll see that there are various sets for clinical areas – outpatient, oncology, surgery, ncd, etc. You might want to minimize the number of concept sets for your implementation.

Ellen

1 Like

@ball / @mogoodrich:

Import completed

:slight_smile: I can start crunching some data.

Yes absolutely, looking into this now.

Thanks again!

Hi @ball,

So… there are 1,542 concepts imported altogether. That’s starting out of a database that had no concepts in the first place.

  • 1,542 concepts in total
  • 1,415 with an ICD-10 mapping

I haven’t looked into their concept classes yet, I’m likely going to limit myself to diagnoses here anyway.

Just to make sure I got things right, where did the 1,589 number came from then?

Hi @ball, so we’re getting closer.

I extracted the locale-preferred ‘fr’ name for each of the 1,367 diagnoses and I had to correct about 150 of them. I must have missed quite a few but at least that’s already some that are corrected.

For reference (and in disorder) I pasted them below. Many corrections are trivial such as missing accents, or misuse of articles (de vs du… etc). For some I went into CIM-10 Version:2008 to get a better naming altogether when I was doubting what I was reading.

Let me know if you would like to get those in a format that could help you propagate the edits on your end.

Cc @mksrom @zouchine

This is awesome! I can update these concept_names in CIEL. Some are perhaps additions (synonyms) but many of them are indeed replacements. However, there are some incorrect translations. For example: Difficulty walking should not translate to the French for “Difficulty walking, not elsewhere classified”. The meaning of the translation must match the english description exactly. Can you update the file and remove those that are not exact?

Thanks!

@mksd This is great. I’ll correct the French for the PIH dictionary. This proves the importance of community support for CIEL and contributing to the greater good. Bravo to you (and @akanter). I’d love if OCL could be used now to update these for our dictionary. Someday… In the meantime, I will do it manually. Will follow Andy’s lead about appropriate wording for diagnoses and not always using the ICD10 wording especially when it doesn’t match the English meaning.