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 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 are better off using a shared dictionary for most concepts, and only maintaining a small part of the dictionary on their own.
(Concepts are also key to designing forms, but that depends on ongoing work on a new Form tool, and is out of scope for this discussion.)
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 state, but ThoughtWorks and OpenMRS are investing time to get them ready for widespread use.
Minimum Viable Product
For purposes of this conversation, ThoughtWorks has a team working on extending OCL, and we want to define the smallest possible piece of work that will allow the Bahmni team to use OCL to improve concept management. (This team is currently working on the must-have of doing OpenMRS validation within OCL, so that users don’t inadvertently create concepts that would be invalid to import into OpenMRS.)
I propose that the MVP is to manage a “Bahmni Diagnoses Starter Set” collection in OCL, so that an upcoming implementation can start from this set, and:
- get a better-curated list of diagnoses (as opposed to the hospital saying “just give me all of ICD10”)
- most diagnoses will come from CIEL, and have SNOMED mappings, synonyms, i18n, etc).
- the CIEL dictionary is already loaded into OCL, so there are good concepts around
- other early adopters (e.g. PIH) are starting to load their custom concepts into OCL
- the Bahmni team and PIH want to create useful subsets of OCL, and combine them with custom concepts
Scenario 1 - Creating “Bahmni Diagnoses Starter Set” Collection
- Coordinators of multiple Bahmni installations (BA/IE from core Bahmni team)
- Clinical Domain Expert (working with Bahmni team)
Scenario 2 - Setting up Diagnoses for a Bahmni Implementation
- Manager of one Bahmni installation (works for hospital)
- IE setting up a Bahmni installation
Scenario 3 - Including Implementation Diagnoses in Bahmni Deployment
To be outlined later.
We’d like to get people’s opinions about whether (a) this is the right MVP to focus on, and (b) whether the activity diagrams are correct.
If we go ahead, then we’ll start doing UX analysis of how to improve the UI for these workflows. (I believe they are currently supported but require too much clicking for someone to reasonably do at scale.)
Thoughts? Please share!