(fix) O3-5309: Use observation-level reference ranges for trendline chart and display

[BlessedAmrita]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work is based on designs, which are linked or shown either in the Jira ticket or the description below. (See also: Styleguide)
• My work includes tests or is validated by existing tests.

Summary

This PR fixes the trendline to show the same reference range as the results table. It now uses the observation ref range first and in case it's not there it falls back to the concept range (as the prev code)

Screenshots

After fix:

Related Issue

https://issues.openmrs.org/browse/O3-5309

Other

[VeronicaMuthee]

Hey @BlessedAmrita, looks good to me per the attached screenshots. Kindly add Ian and Dennis as the reviewers

[BlessedAmrita]

@denniskigen @ibacher Please review this PR, thanks!

[denniskigen]

It'd also be great to add some coverage for computeTrendlineData in a unit test. This test validates the critical bug fix - ensuring that observation-level reference ranges are properly propagated to the TreeNode, not just formatted as a string:

// trendline-resource.test.tsx
import { type OBSERVATION_INTERPRETATION } from '@openmrs/esm-patient-common-lib';
import { type TreeNode } from '../filter/filter-types';
import { computeTrendlineData } from './trendline-resource';

describe('computeTrendlineData', () => {
  it('propagates observation-level reference ranges to the returned node', () => {
    const tree: TreeNode = {
      display: 'Root',
      flatName: 'Root',
      subSets: [
        {
          display: 'Hemoglobin',
          flatName: 'Hemoglobin',
          units: 'g/dL',
          hiNormal: 9,
          lowNormal: 5,
          obs: [
            {
              obsDatetime: '2022-05-01T00:00:00.000Z',
              value: '8',
              interpretation: 'NORMAL' as OBSERVATION_INTERPRETATION,
              lowNormal: 10,
              hiNormal: 12,
            },
            {
              obsDatetime: '2023-05-01T00:00:00.000Z',
              value: '9',
              interpretation: 'NORMAL' as OBSERVATION_INTERPRETATION,
              lowNormal: 12,
              hiNormal: 16,
            },
          ],
        },
      ],
    } as TreeNode;

    const [node] = computeTrendlineData(tree);

    expect(node.range).toBe('12 – 16 g/dL');
    expect(node.lowNormal).toBe(12);
    expect(node.hiNormal).toBe(16);
  });
});

[ibacher]

I think that this ticket may need some more thought before we jump to implementing this. The problem is that I don't know that there's a good mechanism to determine the reference range for a time-series of values, and that's because each observation in the time series could have a separate reference range depending on various factors like:

• Is the patient pregnant?
• Which piece of equipment was this test run on?

Because of these sort of factors, while it's easy to put together a range for the individual observation, it's not really possible to sensibly do this with a set of observations unless they all happen to have the same reference range.

The long and the short of it is that I think the more correct thing to do is to remove the attempt to display a range here at all and simply let the trends speak for themselves.

[BlessedAmrita]

I've updated this PR to align with the current app logic per Dennis's review, but I'm happy to defer to whatever you both decide regarding the feature's direction!

[denniskigen]

Agreed. Because the backend snapshots whatever criteria-based range happens to be active when each observation is saved, you can’t reliably derive a single “true” range covering an entire time series—those per-observation ranges reflect changing patient context (pregnancy status, equipment, new lab calibration) and even data-entry timing.

The safest, least misleading option is to stop presenting a global range in the trendline header and instead let the per-point interpretations (color/tooltip) speak for themselves. That way we avoid implying a stable corridor that may never have existed and eliminate the risk of comparing apples to oranges when the underlying ranges differ.

Also, once we do get the tooltips wired up with the per-value reference ranges, it probably makes sense to also add a column to the Results table at the bottom of the modal including those per-value ranges.

[BlessedAmrita]

Latest Change:

[BlessedAmrita]

Also, should I update the test file to align with this new logic (i.e. using the concept-level ranges for the header)...?
Proposed change in trendline-resource.test.tsx:

From:

expect(node.range).toBe('12 – 16 g/dL');
expect(node.lowNormal).toBe(12);
expect(node.hiNormal).toBe(16);

To:

expect(node.range).toBe('5 – 9 g/dL') 
expect(node.lowNormal).toBe(5);
expect(node.hiNormal).toBe(9);