Requirement for model change in OpenMRS to accomodate a new field [result status] synced back from OpenElis

ApplicationName:OpenElis Version :0.91-22


This thread is to discuss the new requirement, one of the clients has brought up, w.r.t syncing back a newly introduced drop down value from OpenElis to OpenMRS.

The Original requirement was to add an additional drop down column to the results screen allowing user to select one of the options as test status. This will be recorded by the application for reporting purposes. Below given are the steps to navigate to the screen. The test will be rejected at openElis side stating one of the reasons mentioned in the new dropdown and the clients expects the results to be synced back to OpenMRS.

It is observed that there are no appropriate tables/Columns available at the OpenMRS end for capturing this dropdown value when synced from OpenElis.

Need help/suggestions/solutions from the community, to address this requirement. Sample page developed as a POC for the client, showcasing the proposed dropdown and its values is attached to this thread.

@angshuonline @binduak @snehabagri @vmalini @mksrom @srivathsala @akhilmalhotra

There is a CIEL concept designed to capture this: 163725 Test Status. What are the dictionary items expected by OpenELIS?

@buvaneswariarun this can be recorded as an obs, or what have you got in mind?

Was thinking in similar lines. The client also wants this field to be pulled up for reports, we are also thinking in the lines of model changes or any other unused fields related to Samples that can be used for holding these values.

Will look in to the There is a CIEL concept designed to capture this: 163725 Test Status.

This is already part of the OpenMRS model: obs.status

The equivalent in FHI: Observation.status

Ideally, the possible answers in CIEL’s Test Status (163725) would align to the possible values for FHIR’s observation status value set and these would be the same as the possible values of OpenMRS’ obs.status attribute.

While it appears to have been added relatively recently (I can’t remember when we added it to the model), the obs.status field may have been designed to support observation status codes of HL7 v2, which are pretty closely aligned with FHIR’s values and the CIEL concept. I think it may have been added recently enough to expect to hold FHIR’s value set.

Any efforts that further align OpenMRS’ obs.status with FHIR’s Observation.status would be the right direction.

In short, the very purpose of the obs.status column in the OpenMRS model was to reflect the status of an observation from the filler’s perspective; in this case, whatever the lab reports as the status for the test result.