The current Results Viewer page in the OpenMRS patient chart requires several improvements:-
CRITICAL - Timestamp Inaccuracy: Results are displaying incorrect timestamps. Since results time stamps for these results are different, shouldn’t we have 2 columns or have a slot for the time stamp? In the given example,
Haemoglobin result time ought to be 8:45 AM (not 8:40 AM).
Serum Glucose result ought to be 8:54 AM (not 8:40 AM).
The system currently displays a single generic timestamp for all test results added on the same day, regardless of when each individual test result time. This is inaccurate as each test result should display its own specific time. For example, the Haemoglobin was processed at 8:44 AM while Serum Glucose was processed at 8:54 AM, but all are currently showing the same timestamp (8:40 AM).
Test Panel Consolidation: Currently, identical tests appear in multiple panels (e.g., Hemoglobin appears twice, Serum glucose appears three times in different panels). Should we consolidate duplicate tests into a single, well-organized panel?
Trendline Improvement: Date Format - The ISO format date (2025-04-11T05:40:52.000+0000) is not user-friendly. It should be reformatted to match the format used in the application (e.g. 11 Apr 2025).
Perhaps we omit the timestamp altogether? The initial version of this view was similar to what you’re suggesting. The problem that created is that the information in the view was no longer “dense”. So we end up with 7 or 8 columns each of which is blank for only one result. Probably date / time is not the right thing to use as a column for a results view that’s built like this.
Time is an important consideration here, though. It probably makes sense to render what’s rendered in the chart in the table rather than the timestamp, but we shouldn’t drop time altogether.
What you’re seeing in this view are not panels, but classifications of test types. This is a very important distinction.
Since we have one section for Hematology and then a section for Blood Work that contains Hematology and both are selected to be displayed, you get multiple copies of the CBC displayed. By either checking just the results under “Hematology” or modifying the configuration—which separately includes both Hematology and Bloodwork as “top-level” concepts—to only include one or the other, the duplicates would go away.
What we’re seeing here is a result of configuration rather than a bug in the application.
Thanks Ian, i guess the test type classifications as you rightly put it is a non-issue then. For the timestamp in the individual test view, are you recommending that we drop that in the column?
The system currently displays a single generic timestamp for all test results added on the same day, regardless of when each individual test result time. This is inaccurate as each test result should display its own specific time. For example, the Haemoglobin was processed at 8:44 AM while Serum Glucose was processed at 8:54 AM, but all are currently showing the same timestamp (8:40 AM).
What does ‘processed’ mean here? We should make clear to the user whether it’s when the specimen was collected or when the result was posted? HealthIT.gov recommend showing when the specimen was collected. We should make this clearer to the user if that’s what we’re showing
2. Test panel consolidation
This duplication is intentional. Each test instance is intended to be identified by it’s timestamp. I think you’ve raised a good flaw in the design though: we could do a better job of communicating visually that Hemoglobin is a second instance of the same test previously displayed as part of the Complete Blood count.
3. Trendline improvement
The proposed change brings the implementation closer to the design intention, thanks for that
Thanks @cduffy regarding the timestamp inaccuracy, i actually meant the time when the result was posted. I guess specimen collection time would make sense where we have an LIS in place but that is not the case here (I might be wrong). @ibacher ?
As for the tests classification, improvements in design would be highly appreciated.
Well, in either case, we’re using the encounter timestamp rather than a timestamp associated with the obs and this does matter, since its only specimen collected during a clinical encounter where the encounter timestamp is likely to be right. But if I place an order for a lab test where the specimen is collected at the lab, the “collection date” is whenever the sample is collected at the lab.
I don’t think the presence or absence of a LIS is relevant. The important date is always the date/time the sample was collected whether the result is returned electronically, via paper and entered via a form or any other mechanism. The date the result was entered is, at best, secondary information.
FWIW, I don’t necessarily think that it’s wrong that Haemoglobin and Serum glucose display the same timestamps since those two could’ve been determined from either the same sample split or two samples drawn at the same time. I don’t even necessarily think it’s wrong that the timestamp would correspond to the encounter timestamp (since a blood draw might be performed as part of a clinical visit).
Thanks for this detailed perspective @ibacher —it really helps clarify the distinction between encounter-driven timestamps and true specimen collection timestamps.
I agree that in cases where specimens are collected independently at the lab (outside of a clinical encounter), relying solely on the encounter timestamp can misrepresent the actual collection time. As you’ve pointed out, the critical piece of information is when the sample was collected, regardless of whether results are returned electronically, entered manually, or passed through an LIS.
Also, good point about results like Hemoglobin and Serum Glucose potentially sharing timestamps—it’s true they could originate from the same blood draw or from multiple samples taken at the same time, which makes identical timestamps reasonable in some contexts.
