Bahmni and the CIEL dictionary

The purpose of this post is to give the latest status for whether/how one can use the full CIEL Concept Dictionary with Bahmni. [For a discussion of using parts of the CIEL dictionary via OCL, see other threads.]

For years, it was impossible to use CIEL with Bahmni because (1) CIEL is distributed as a SQL dump and doesn’t support local modifications, and (2) Bahmni required use to configure concept sets and concept classes to control the layout of form entry.

Today Bahmni includes a graphical Form Builder which stores form designs as metadata, and doesn’t require you to configure forms in the concept dictionary, so a large blocker to using the CIEL dictionary is now removed.

However Bahmni does still require certain concepts to be present that are not in CIEL.

Diagnoses

Bahmni requires a “Visit Diagnoses” concept set like this (from the Bahmni demo, though some of these members are optional…):

Whereas the CIEL Visit Diagnoses concept looks like this:

Disposition

Bahmni requirements are described described here. You need a Disposition concept, a Disposition Notes concept (optional), and a Disposition Set concept, with appropriate mappings to org.openmrs.module.emrapi. CIEL does not have these.

Others?

I assume there are other concepts that Bahmni requires and CIEL does not provide. Can anyone post a followup listing some of them?

1 Like

One priority issue that maybe @akanter and @raff can address on the CIEL side: Bahmni uses openmrs-core 2.1.x, but CIEL is only distributed up to 2.0.x. Can we publish CIEL for 2.1.x also?

More concepts expected by Bahmni’s default/demo install: (list is not exhaustive, also some of these may not be required if certain features are turned off)

  • “All_Tests_and_Panels” (a set that should contain LabTest and LabSet concepts)
  • “Dosage Frequency” (I need to research what this is and why it is used instead of the order_frequency table) " Dosage Instructions" (set that contains things like Before Meal, After Meal, Before Bed)
  • “Impression” (specified here), maybe for radiology?
  • “Stopped Order Reason” (reasons you may choose when stopping a drug order)
  • “Consultation Note” (free-text note you can capture on the Consultation tab of the Consultation screen)
  • “Lab Order Notes” (free-text note you can write for each lab test or panel ordered)

Hi Darius,

Can’t we use concepts from CIEL and also define our custom concepts and use them? Implementations may need various different concepts that are not present in CIEL. Some of those concepts can be very custom too. How can we handle them?

OCL allows you to combine CIEL concepts with locally created or maintained concepts. CIEL recommends that concepts are proposed to CIEL as there is a chance that there will be duplicates created, or that local concepts may not comply with good editorial policy, etc. However, for now, there is no reason that with OCL you can’t have local concepts, too.

Good question! I forgot to mention in my first post that in this thread I’m talking about using the complete CIEL dictionary.

The primary way that people get the CIEL dictionary today is by downloading a complete SQL dump from dropbox, and overwriting their concept* tables. This makes it impractical to have your own local concepts and also take updates to CIEL. And in this thread I’m just looking at that “take all of CIEL” workflow.

In the bigger picture, we would like to use OCL so that (1) an implementation can take a subset of CIEL combined with their own custom concepts (using a Collection), and (2) implementations can start by forking a “Bahmni starter set”.

I wrote about this a year ago in another thread (Using OCL to Manage Bahmni Concepts) but sadly we have not made much visible progress since then.

This was also discussed a couple days ago in a thread started by AMPATH here: What is workflow OCL uses for updating a local OpenMRS implementation? - #7 by darius

I’ve heard anecdotally that the OCL Subscription module for OpenMRS is currently broken, because it has not yet been updated to handle some recent changes in OCL. And I think that @raff was going to be looking into that. Rafal, any comments on (a) whether things are broken, and (b) when/how they might get fixed?

I was able to run the scripts and produce a 2.1.x version of CIEL, so I’m no longer blocked on this.

But as we’ll soon be doing a (LTS) Platform release in the 2.1.x line, we’ll need to start having a CIEL release for 2.1.x. @raff do you have time to update the scripts for @akanter?

Sure, I can assist Andy with releasing CIEL for 2.1.x as well. I thought we didn’t have changes to concepts model between 2.0.x and 2.1.x though…

The OCL subscription module does work. Last week I released a new version with a small fix for concepts missing description. The module is currently being tested by a team in Kenya and we may release more fixes in coming days.

At least some changed_by and date_changed columns have been added to concept tables:

Notes from the Birds of a Feather session at OMRS17:

Bahmni and OCL Birds of Feather Session

Abhinav- 2018 create thinner size of Bahmni in vertical programs (NCDs, etc.). Want to access a set of concepts to support the vertical. Want to have an editor be able to build a collection from CIEL and have Bahmni download it from OCL. Eventually would like to have forms distributed. OCL would need to be able to support drug formulations. Pilot implementation in Jordan MSF (defined 10K concepts)

Sanjay- same use case but include NCD like Mental Health & Diabetes quality management. Used in secondary referral facility. Do we use UUID or concept_id

Deepak- Currently using concept_name to aggregate different servers. There is an endTB dictionary of 2500-3000 concepts shared with 25 sites. But there are 15-20 implementations with completely different concept dictionaries. Possible health has 9000 concepts. Perhaps 1000 have CIEL maps. Need to cover all of First three digits for ICD-10-WHO reporting for IMS (insurance management system)

Darius- we need a clean subset to start new implementations, but we also need to have a process for migration of other sites (lesser priority). Need someone to build starter sets in OCL to exercise the process. Need to be able to “fork” copy core concept set to allow modification to update the SET (mostly add, but perhaps also remove). Pull changes not push them. Want to be able to have a collection of collections and not rely on CIEL’s set of sets approach. What are the missing concepts from

Jeremy- Interested in concept proposal methodology with updating. Need to have it visible to CIEL and would be nice to see the forms where it is used. Also interested in surgical procedures. Is there a starter set for surgical procedures.

Tim- Asked whether a subscription module could subscribe to more than one collection. Better to have reconciliation and duplicate checking done at the OCL level so not a need to have a subscription module be able to subscribe to more than one OCL collection. How does OCL help with data output to DHIS2, etc.? Discharge forms have diagnoses, operations performed, complication of anything that was done, and discharge status.

Required functionality content is one category, and subsets of content based upon vertical use cases. Latter should be based on frequency distribution or some value of use.

Examples:

  • Bacteriology
  • Discharge Status
  • Stopped Order Reason

Possible Health has added columns to the concept tables. Need to think about how data gets anonymized.

To summarize what I think is the current state (as of Jan 11, 2018): in order to use the full CIEL dictionary with Bahmni, there are two imperfect approaches:

  1. Install the complete CIEL dictionary one time by running the SQL dump you get from dropbox. Then you create necessary Bahmni concepts on top of that.
    • Problem: you will not be able to take CIEL updates (because these would overwrite your custom Bahmni concepts)
  2. Subscribe to the complete CIEL dictionary using the OCL Subscription module. Then you create necessary Bahmni concepts on top of that.
    • Problem: I don’t know if the OCL Subscription module can successfully do this. (Basically, treat this as running beta software.)

(In either case you would want to use the Forms 2.0 technology from Bahmni 0.90, and not the earlier concept set-based forms approach.)

1 Like

Just wanted to publish an UPDATE (27-Apr-2023). Bahmni LITE now ships with CIEL Dictionary (got from OCL as a zip file) and imported into Bahmni using Initialiser Module. You can see Bahmni with CIEL Dictionary in action in any of our Bahmni LITE environments here: https://bahmni.atlassian.net/wiki/spaces/BAH/pages/3037757441/Bahmni+Lite+Environments

The OCL Zip is present in Bahmni clinic-config folder (used by Bahmni LITE for clinics) here: clinic-config/masterdata/configuration/ocl at main · Bahmni/clinic-config · GitHub

2 Likes

This is great news! Thank you!! Is there a way to see which version of CIEL was loaded into the app (versus looking in the zip file)?

I don’t think there is a way to know which version of CIEL is running in Bahmni, unless the CIEL dictionary itself has some “concept” that mentions the version :slight_smile:

Right now, the date of upload of the zip file (and zip file name) are the only way to know.

CIEL_v2023-01-26.20230128014809.zip

There is a global property that we set in OpenMRS which contains the version (when done via SQL) but do not know if we are doing so with the OCL export file.

It gets tricky with OCL because collections (what we actually support) can support concepts loaded from multiple versions of a source and multiple sources. There’s still versioning (and you can probably look up specific versions for concepts in the openconceptlab_items table), but it’s at the level of individual concepts, rather than the whole concept dictionary.

Perhaps there’s an enhancement to be done to at least be able to report the loaded collections in some user-visible way, though…

I see. I thought Bahmni was loading the entire source. If it is a collection, then there should be a way to show the version of the collection. Let me talk with Jonathan tomorrow…

@akanter - I checked. There isn’t any such global property in Bahmni/OpenMRS. There are some global properties set for openconceptlab, but none of those will answer this question (last time sync from OCL).

Maybe we need a concept in CIEL dictionary which is called: CIEL.version, CIEL.dateUpdated, etc… which can be used to inspect a system and check which CIEL dictionary was downloaded. Will be useful in general in distributed EMR scenario, where they pull periodically from a central OCL server.

Well, the above global property is what the old SQL method used to set. Will have to talk to @suruchi and the OCL team to see what seems to make sense with the OCL method…

2 Likes

We don’t have the notion of a version in OpenMRS concept_reference_source and it doesn’t seem like we’d want to make entries in our source table as source-specific. The approach that seems most robust and would align with FHIR would be to move toward referencing concepts by source + version + code.