Use of OCL in a French language clinic

We’re just in the process of deploying Bahmni and due to French being the primary language, we were thinking that utilising the CIEL / PIH / MSF OCL data would make more sense and aligning to what is already there, rather than creating our own and reinventing the wheel.

I’m happy to trawl through each data set to see which is going to be the most complete i.e., it has suitable English and French entries; but I’m not really sure where I should be focusing my time / effort on in respect to which items I should review. For example, diagnosis terms, drugs, general metadata etc.

We have a custom built system at the moment which has all our drug data (Drug Name, Quantity, Dosage Form, etc.), but I’m not clear whether the OCL data coming in will set some of the metadata like “dosage form” for example. What we’re conscious of is doubling up of information etc., so I am trying to understand what does import via OCL so if needed I can do a data matching exercise.

@akanter @ball

These are the OCL sets I’ve been looking at (apologies if my terminology is wrong!), but I’m still learning so not sure exactly which components within each repository I should be focusing my time on.

https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/

https://app.openconceptlab.org/#/orgs/PIH/collections/PIHEMR_Concepts/

https://app.openconceptlab.org/#/orgs/MSF/collections/

I think it would make more sense focusing on the content you need and then looking to see about translations. It is relatively easy to add them if the French is missing. You can create a dictionary from any of the sources you have listed, but the CIEL source is likely to be primary if you want to start somewhere. Medications are probably the least you have to worry about since the names are often the same. CIEL does have a lot of brand name synonyms but O3 uses the drug table, I think, for the UI order basket so that would likely be custom anyway. We can have a separate conversation about drugs, so if you want to share your custom drugs I can take a look. Diagnoses and Procedures/Labs are probably the most important, and the small sets of things required by the UI such as drug forms our routes… Let me know.

I’m not sure if Bahmni is fully on O3 yet, so not sure how much difference that makes?

Happy to share the list of drugs, what’s the best way to do that? It’s 725ish items and I’ve used AI/ML translation to give a rough idea of what some items are in English as the source is 100% Francais.

Agree, diagnoses and procedures/labs are where we want to leverage the most, but the default OCL (CIEL) data the Bahmni install comes with has quite a lot of gaps in translations that doing it manually will be a lot of work so I’m hoping that by doing a fresher cut it will be less gaps….

Thank you for your insights.

For reference, here is what Bahmni is using in the default data set (3 years old).

But as an example… if I look in their GitHub, then this matches the Drugs List you provided to us to review:

However, it had French translations there for some items on the extract we were given (but there’s no French on the drug list above in the default data). Where did it pull the translations from? Items such as dosage form and concept / generic name, they’re additional fields compared to what drugs.csv has, so does it pull that data in from CIEL?

So, I think it is important to distinguish between the drug table and concepts which are drugs. The Drug table doesn’t have a locale field and so the drug table is intended to be used like a formulary subset for a particular server. That means that “French names” are either French branded names or perhaps French spellings of generic drug names. The current datamodel has the drug entries mapped to the concept table where the ingredients are stored. The CIEL database has brand names and french translations in the concept table. You could potentially use the crossmap between drug and concepts to get the translations and then create your own drug table entries. However, there is no guarantee that the specific formulation you want (brand + strength+form) is available unless you start with the drug row. I’d be interested in seeing you drug table entries….

Noted, still trying to get my head around that component. Happy to share, any thoughts as to how best? Will it let me attach via a PM? There’s nothing sensitive in there, but just from a data control perspective the clinic likely wouldn’t want me just posting publicly I would suggest.

You can either PM or use my email ask2164@cumc.columbia.edu

You’ve got mail.

@daniel1 Partners In Health uses drug initializer files in English OR Spanish (but unfortunately not French). We have different supplies/protocols in each country where we work. Here are some examples of English drug lists:

As @akanter points out, the concept names have various languages (locales), but the OpenMRS data model only handles a single name for each drug.

Here’s an example of a concept (class=drug): https://app.openconceptlab.org/#/orgs/PIH/sources/PIH/concepts/89/

OK, so if I play back what you’re both saying then, we should use the CIEL OCL data and then for our list of drugs we have, we would load them in and map each one back to the drug that CIEL provides? Then, where there isn’t a match, that’s where we create one?

Well, I’d want to create a concept in CIEL if you are missing one, or add a French translation to an existing one if it is missing… so that’s why I wanted to scan your list. We are thinking of producing a shared drug table as well, but this will really be a big superset… but they should have standard code maps too which is why people need CIEL’s help…

I’m not if the data provided has helped give you any further insights. One other thing to note, is that this is essentially starting from scratch as the implementation is being done to replace the current paper based, manual processes, so essentially from a case management perspective there’s little data to go from and therefore we’re looking to leverage/set the baseline from what CIEL (or MSF?) provides.

If that is the case, then the most important thing would be to do a landscape analysis and see what actually is needed by the users. Either through sampling the existing paper records, or some other database/report which would have the drugs/variables recorded. There is a lot of great information in the OpenMRS community about the dangers of coding forms alone. @hamish has some nice slides about the form vortex which can suck you down. The essential piece is to have everyone on the same page and the goal being clear… which is not to computerize a form, but rather achieve some clinical outcome, etc. The forms are usually tied to reporting requirements which are real, but the use of the information to take care of patients, or manage resources, etc. are what people care about.

FWIW, the Initializer CSV format supports adding a column like Display: fr (or Display: en) which can set the translation of a specific drug, although I can’t guarantee that the Bahmni UI will use this. Drugs are tied to concepts so, under some circumstances where the concept has a French translation, you may see that.

That’s an awesome feature and news to me @ibacher . In the database, does the “Display” column set the drug.name field?

@daniel1 PIH uses source but not collections (ignore those). This is the appropriate source: https://app.openconceptlab.org/#/orgs/PIH/sources/PIH/

Thanks, so it shows 5,260 items with a French locale out of 8,333 items, which suggests it’s probably going to be quite comprehensive. As the owner of the data, how would you say it compares to CIEL’s data set and do you have a view on which is likely to better meet our needs?

No. The database table (and Drug object) still only support a single name. There’s a feature in the UIFramework that allows overriding the display name for metadata. We’ve extended that to be available in more places, including the REST API.

CIEL’s dictionary continues to be the gold standard.

The magnificent Andy continues to improved on CIEL for the entire OpenMRS and OCL communities. PIH tries to be a good citizen and provide translations (French, Spanish, and Haitian Kreyol) back to CIEL. Any new PIH concept which is not in CIEL, is suggested to CIEL along with translations.

I hope newer implementations start with CIEL and modify their source/collection to match their workflow. The PIH dictionary has good ideas for business logic, drug lists, diagnoses for specialties, and lab tests. You are welcome to use ideas or clone anything. The CIEL dictionary is too large for our clinical needs AND the PIH dictionary pre-dates CIEL. Otherwise we would use CIEL. When possible, our code uses CIEL mappings so others can use a CIEL dictionary with our drug list and forms.

Brilliant, thank you - that’s most helpful.