A closer look at measurement
Why nearby encounters do not prove where a vital sign was taken
Understand how PulseTrellis displays encounter context without asserting an unsupported link to a selected vital measurement.
Two lists can share a screen without sharing an event
PulseTrellis displays a selected vital observation beside other recorded encounters. This layout makes available context easier to inspect. It does not mean the selected measurement belongs to the encounter nearest it on the screen or nearest it in time.
A relationship needs evidence in the records
Matching a measurement to a visit would require a supported relationship in the available data and a display that explains that relationship. Similar dates alone can be ambiguous. The current interface makes no such match and labels the encounter list accordingly.
Keep the counts literal
The observation count is the number of returned vital entries. The encounter cards represent returned encounters. Neither count establishes how many visits included measurements or how complete the source history is. This helps avoid turning a navigation aid into an unsupported coverage claim.
A clear extension point
A future operator could add explicit encounter linking when the data contract and source fields support it. That change should include tests for absent, ambiguous and unmatched references. Until then, the existing independent views preserve what the interface can actually substantiate.
Two categories through FinchNode, two views in PulseTrellis
The implemented connection requests vitals and encounters through FinchNode, alongside demographics. PulseTrellis keeps the resulting categories distinguishable in its interface. That choice supports contextual reading without manufacturing a relationship between entries.
Questions about this guide
Are all encounters connected to the selected measurement?
No. The current app explicitly avoids assuming that relationship.