Finding one number in a whole record
Most discussion of record design is about entry. But entry happens once per item and retrieval happens continuously, and the retrieval experience in most systems is markedly worse than the entry experience.
Retrieval is the neglected half
The typical task is not to read a record. It is to find one value, or to see how one thing has changed, within a document that may contain decades of material. That is a lookup task, and lookup tasks are dominated by the design of the index rather than the design of the content.
Systems that do this well tend to have invested in three unglamorous things: a search that behaves predictably, a results display that gives enough context to choose without opening, and a tabular view organised on time.
Search has to be predictable before it is clever
Clinical search has an unusual requirement: the user frequently knows exactly what they are looking for and needs the system to find precisely that, not something related. Fuzzy matching, synonym expansion and relevance ranking are all helpful for exploration and actively harmful when they silently reorder or omit exact matches.
The practical resolution is to make exactness visible and controllable, to show what the system understood the query to mean, and never to return a result set without indicating what was excluded. A search that quietly drops results teaches people not to trust it, and they will go back to browsing, which is slower and which the system will never see.
Results are a display problem
A results list that shows only titles forces the reader to open items to evaluate them, which converts one task into many. Showing the date, the source, the type and a fragment of the matching content usually lets the reader choose correctly without opening anything.
Grouping matters as much as ranking. Results clustered by type or by period can be scanned structurally; a flat list ordered by an opaque relevance score can only be read top to bottom.
The flowsheet does most of the work
The tabular time-series view is quietly the most valuable display in the field. It puts time on one axis and measures on the other, which makes change visible without any interaction at all, and it inherits a well-tested design from paper.
Its failure modes are known and avoidable: columns that change width as data arrives, so the eye loses its place; misaligned decimal points, which defeat magnitude comparison; headers that scroll away, leaving a field of numbers with no labels; and pagination that breaks a series across screens so that the comparison the view exists for cannot be made.
Time is the primary axis
Almost every retrieval question in a record is temporal - what is the latest, what changed, what was true then. Interfaces that treat time as a filter applied to a list make that question harder than interfaces that treat time as the organising structure and everything else as an attribute.
This is a structural choice rather than a visual one, and it is made early. It is also the choice that most reliably distinguishes a record that can be read from one that can only be searched.