[A lot of the Background section is the same as MVP for using OCL to manage Bahmni concepts. If you read that, you can skip straight to the “plan” section here.]
Background on dictionary management
“Concepts” are at the core of the OpenMRS platform, and being able to configure the system’s clinical content via user-controlled metadata makes Bahmni and OpenMRS very powerful. That is the key to making lots of the system configurable by non-programmers.
It is (deceptively) easy to create new concepts, and this allows implementations to get up an running fast, but the long-run management and maintenance of a concept dictionary is much harder, in ways that are not evident as you get started. It’s easy to create a concept that will look correct on one form, but harder to think about how to model it for reuse on multiple forms. It’s easy to skip the work of mapping a concept to other standard terminologies, but this is a required step if you’re going to use those concepts for decision support, or be able to exchange data with external systems and HIEs. (An implementation should know that Systolic Blood Pressure is 271649006 in SNOMED CT, and 53665-6 in LOINC, but they shouldn’t have to spend their own time figuring this out.)
In the long run, maintaining a high-quality dictionary requires a significant time investment, and most implementations find this hard to justify on their own.
Every implementations does need to be able to create concepts to capture the local variation inherent to healthcare, but the vast majority of concepts that an implementation uses are not unique, and they would be much better off using a shared dictionary for most concepts, and only maintaining a small part of the dictionary on their own.
One weakness in Bahmni is that we have coupled “form building” and “dictionary management” too tightly. Today, when doing a new Bahmni implementation, an implementation engineer works with facility staff to create a spreadsheet of concepts, and loads this into their implementation. This works well at first glance (people are good at collaborating on spreadsheets) but it’s not a good way of capturing a concept’s synonyms, or its mappings to standard terminologies, and it doesn’t help make subsequent implementations faster to do.
A better vision
In a better world, there would be a shared space where:
- a few “authorities” (like CIEL) invest in creating high-quality curated concepts
- Bahmni and other large-scale implementers create convenient subsets of (1), e.g. “WHO essential medications (structured for OpenMRS)” or “Diagnosis Starter Set for PIH Implementations”
- Individual implementations can create concepts specific to their own needs
- Individual implementations compose their specific dictionary by taking over 90% of their concepts from (1) and (2), and the rest from (3).
The Open Concept Lab (OCL) is a tool that wants to provide that shared space, and preliminary work has been done to create an OCL Subscription module for OpenMRS. Both OCL and the subscription module are in a beta stage, but ThoughtWorks and OpenMRS are investing time to get them ready for widespread use.
Building forms will become a separate step, which depends on the new Form Builder tool being worked on in parallel, so we mostly don’t discuss it here.
Actors
- Managers of one Bahmni installation
- one per Bahmni implementation, will typically work for the hospital/MOH/NGO
- Implementation Engineers who set up and maintain a Bahmni installation
- Bahmni IE team
- IEs at implementing partners
- tech lead for self-service implementers
- Coordinators of multiple Bahmni installations
- core Bahmni Team
- Implementation Partners
- Large-scale self-service implementers (e.g. PIH medical informatics team)
- Clinical and Program Domain Experts (who are specifically interested in Bahmni)
- domain expert contracted to build content for a clinical area for a Bahmni project
- domain experts at NGOs (e.g. PIH clinicians)
- Terminology Experts (not specific to Bahmni)
- @akanter, @judy, and others at CIEL
Our plan
Implementers should use a purpose-built Terminology Management Service (OCL) to manage concept dictionaries for Bahmni implementations. This will replace using spreadsheets and the OpenMRS concept dictionary screens. (We recognize that in practice, changes still sometimes need to be made on the ground, when offline, but we hope to minimize this.)
OCL should be seeded with high-quality curated, relevant content, which includes:
- (a) concepts
- primarily maintained by terminology experts and domain experts
- Bahmni implementations should prefer CIEL, though other dictionaries may arise in domains not well covered by CIEL
- (b) drug formulations
- some maintained by terminology experts and domain experts, e.g. WHO essential meds
- some maintained by coordinators of multiple implementations, e.g. Ayurvedic Meds for Bahmni implementations in India
- (c) starter sets, and collections, drawn from (a) and (b)
- primarily maintained by coordinators of multiple implementations
The content ecosystem would look something like this:
Then, the workflow of an IE doing a single implementation is:
- Pick the appropriate starter sets for the implementation’s context (80% of content)
- may decide to fork the starter sets, or to include them by reference (forking allows removing unwanted concepts from the implementation copy)
- Review current state of content with the implementation and identify gaps
- Pick additional concepts from curated sources like CIEL (10% of content)
- Propose new concepts to CIEL, when the implementation timeline permits it
- Create any missing concepts, for site-specific requirements, or if timeline doesn’t permit waiting for CIEL (10% of content)
- Create forms based off of these concepts
The IE would repeat this workflow iteratively with hospital stakeholders. (In practice, in early iterations new concepts will be proposed to CIEL, while in later iterations a time crunch may prevent this.)
Embedded in the ecosystem describe above, it would look like this:
Gaps
OCL, OpenMRS, and Bahmni do not currently support all the workflows we need to carry out this plan. High-level gaps we see are:
OCL Gaps
- Support “OpenMRS Validation” of OCL sources and collections, so that users don’t inadvertently create concepts or dictionaries they cannot import into OpenMRS/Bahmni [in progress]
- Good UX for the “search for a concept (preferring CIEL), and add it to my collection” workflow
- Tool to review current state of a collection (e.g. using SNOMED or ICD-10 maps to help visualize the semantic space being covered)
- “Propose a concept” workflow
OpenMRS Gaps
- Subscription module support for collections
- Subscription module support for loading a downloaded artifact (e.g. ZIP file) rather than live sync
Bahmni Gaps
- Use the OpenMRS OCL Subscription module to load concepts during deployment
- new Form Designer technology so that we don’t need implementation-specific concepts to achieve desired visual layout
Next Steps
The immediate next step we are pursuing is to work on an MVP to cover the highest-priority gaps. This is described at MVP for using OCL to manage Bahmni concepts
We don’t have further steps mapped out yet, but we welcome:
- input into and suggestions about this approach
- individuals or groups willing to contribute to further development of OCL
- Bahmni and the rest of the OpenMRS Ecosystem will really benefit from this!
- OCL is a Python/Django stack, and you can reach out to me or to @paynejd privately if you are interested in contributing.