Hi all, we are drafting what a more reliable and sustainable terminology service to the OpenMRS based on OCL and CIEL would look like to inform planning/roadmaps/resourcing/etc – and we’d like to get everyone’s input! The intention is to clarify what the OpenMRS community’s needs and expectations are, so that OCL/CIEL can better meet them. Hopefully more transparency around OCL/CIEL plans and roadmaps will improve each implementation’s ability to plan timelines, resources, etc. for your own terminology approach.
So, what is on your wish list for OCL/CIEL? And what requirements do you have going forward? Anything is game – a few areas to think about:
Availability of releases
Types of mappings available
Turnaround time for concept requests
Commitments to service reliability (uptime, etc.)
Availability of historical versions of CIEL
Support and troubleshooting
Downloads in other formats (SQL, JSON, XML, CSV, etc.)
Ability to create your own subsets
Creating your own custom concepts alongside CIEL
Offline installation of CIEL dictionary
It would also be helpful to know what version of OpenMRS you are using – is anyone still using v1.6 or v1.7 that needs access to CIEL updates?
Are there any specific challenges you have with respect to CIEL/OCL?
I just want to add my name to Jon’s request, and let you know that we are very much interested in your ideas here. Everyone needs concepts and a lot of you use CIEL in one way or another. We want to make this work better for everyone, so we really need your input! Thanks!
Create an OCL collection of concepts, associated mappings, concept sets and answers. This collection would be created from an OpenMRS 1.10 concept dictionary.
Propose new concepts for CIEL and the community.
Create and modify non-CIEL concepts (as required)
Add new and existing concepts to a collection
Add mappings (ie. “PIH:Malaria”, “LiberiaMoH:Anemia”, “org.openmrs.module.mdrtb:extra-pulmonary tb”) beyond standard medical terminology sources (ie. SNOMED, ICD10, LOINC).
CIEL continues to manage their dictionary along with the CIEL mappings which are used by reports, forms, and code
Deploy collections using OCL subscription module (?) to various implementations and/or software build environment
We currently are using OpenMRS 1.9 and 1.10, but hope to continue to upgrade.
Our challenge remains that OCL is not ready yet for our deployment pipeline.
We’ve put this on hold on the Bahmni side, partly waiting for more OCL progress, but our general idea is still that we want to do what I described a year ago in these topics:
I think that our MVP still is to make a centralized starter set of diagnoses for Bahmni, and then let new implementations fork this and make their own modifications. (And this set should be largely a subset drawn from CIEL.)
Looking back at my post from 1 year ago I wrote about existing gaps, and many of these have been addressed, and some I’m not clear on the status of:
OCL Gaps
DONE - 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]
DONE? - 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
DONE - new Form Designer technology so that we don’t need implementation-specific concepts to achieve desired visual layout