I wanted to pull you all into a discussion we are having regarding upgrading the bacteriologyResultsControl to flag specimens that have a smear but no culture. Could you take a look the conversation here? (This is a pull request from a developer’s fork into the endtb fork of bahmniapps… if we merge in this request, next step would be to issue a pull request from the endtb fork against the main bahmniapps repo).
Particularly, we’d like to get your thoughts on the questions David Oh posted on that thread:
From a domain perspective, whether it makes sense to build functionality around smear/culture results into Bahmni
Apart from modifying the display control in BahmniApps, whether there is an alternative approach to accomplish the same functionality
smear and culture results (and the fact that they’re both taken from the same initial sample) are clinically-meaningful thing that makes sense to build into Bahmni, and the OpenMRS module.
smear and culture are not only about mTB but can be done for other bacteria, in other clinical areas. The time that you grow a culture would depend on which bacteria/virus you’re looking for (and TB is very much on the long side)
in a resource-rich care environment, you’d always (?) do a smear and a culture together, but I don’t know if this always happens in resource-limited settings
So I think it does make sense to build in the idea that you’d expect a culture result in X days after the smear, but you should be able to configure (a) whether we want to flag “missing” results (e.g. in case some implementation does not do a culture for every smear) and (b) how long to wait before flagging.
Thanks @darius! If do we build the idea of smear and culture results into Bahmni, is it okay/best practice to code against a concept directly referencing it by short name like we are doing here, or is there a better way?
Short name seems like brittle thing. Do you instead want to identify the concept by reference terms (in combination with FSN)? and/or by other metadata? Btw, from 2.0 onwards, concepts can have attributes define. That might help.
Or It might be better to have a mapping in an external properties file?
So we added this to express more information about concepts. The APIs expose the attributes, but we haven’t leveraged it in Bahmni yet.
Some thoughts we had
In Bahmni, we often uncessarily group concepts. this can be just done using an attribute. e.g. Sample.
So imagine metadata mgmt for ELIS, they can just inspect the concept and find out whether the same type is blood.
Ranges - in openmrs numeric concepts have reference ranges but they are not contextual to age or gender. Although we debated that its probably best to have this modelled in openmrs (conceptRanges).
References - if you want to link a concept to another (this is not done yet).
programs - the workflow requires a concept, but there is no additional meta data (apart from program attribute that we introduced) to describe more about the workflow or states (which are also tied to a concepts)
There are probably many more use cases - but I think the challenge is determining how best it can be done, or how to model a certain behavior depending on such metadata.
Also agreed that short names are brittle and would not be my preference at all… in our (non-Bahmni) PIH EMR OpenMRS distro we use concept reference terms, and that would probably be my first choice.
I was more wondering if there was an existing pattern to follow (even if not ideal and to be re-assessed long term) just to complete this specific story. Sounds like no?
About referencing concepts by name, this can definitely lead to issues in a multi-locale setup.
See the thread ‘Is it possible to upload other language concept in Bahmni?’ from here.
Extending support to reference terms is certainly a good idea.