In our OpenMRS implementation, we use the "Chief Complaint " concept set to capture chief complaints, including fields like Chief Complaint Coded, Chief Complaint (text), Duration. However, for specific complaints which we are not sure in advance—such as psychiatric, fever, or cardiac issues—we need to collect additional structured details without disrupting the current workflow.
We are thinking of to extend "Chief Complaint " with a new member may be ConVSet for example, “Chief Complaint Extension,” featuring optional sub-concept sets as memebr like:
Our plan is by using OpenMRS observation groups (<obsgroup>), these details will link directly to the relevant complaint, keeping data structured and simple.
Feedback Request:
Does this make sense or any issue with this, Has anyone implemented a similar chief complaint extension in OpenMRS? How did you approach it, and what challenges did you encounter? We’d love your insights or suggestions as we refine this!
tl;dr you approach using sets & obs groups sounds like a good approach.
Typically, capturing problem-specific histories of present illness (e.g., capturing specific details for someone presenting with chest pain, different details for someone presenting with fever, etc.) would be done using problem-specific templates. In OpenMRS, these would be forms.
Ideally, we’d have a form engine that was not tied to encounters, so you’d have the choice of implementing these problem-specific templates within an encounter form or in a widget specific for gathering histories. In its current state, you’d probably need problem-specific variations of encounter forms.
When creating problem-specific forms, the best practice for scale & data modeling would be to have concepts for the various details using obs groups as you suggest, including all possible answers in the concept definitions and restricting the answers used in the form definitions. Bahmni-based implementations lack the abstraction of forms separate from the concept dictionary (i.e., forms are directly tied to the concept dictionary), so you may be forced to create duplicate concepts for forms that need different subsets of answers.
For example, if you want Max Temp and Fever Pattern for fever details on one problem-specific template but only Max Temp on another, we’d prefer to re-use the same concept and restrict possible answers in the forms. This way, when doing reporting/analysis, you only need to look at one concept. In Bahmni implementations, you might need Fever Details 1 and Fever Details 2 with the form-specific answers and any reports/analysis looking at fever details across forms would have to navigate all the variations of the concept.
I would recommend keeping the detail concepts and their children as generic as possible (e.g., “Pain details” instead of “Chest Pain details”) to promote re-use and avoid an explosion of effectively duplicate concepts collecting the same information. Then the problem-specific concept sets need only enumerate which of the generic detail concept sets should be used for that problem.
I would recommend keeping the detail concepts and their children as generic as possible (e.g., “Pain details” instead of “Chest Pain details”) to promote re-use and avoid an explosion of effectively duplicate concepts collecting the same information. Then the problem-specific concept sets need only enumerate which of the generic detail concept sets should be used for that problem.