The encounter location history sections of the portal get quite hard to parse when there have been multiple locations in the encounter e.g. inpatient transfers.
The location field is just a list of locations, it isn't clear what order this is and which location is the current one (if any)
The location status field showing active,completed,completed,completed seems redundant, if it is needed it would be better if it just showed a single 'active' if any location is active and otherwise a single 'completed'. A better place to put this may be next to the location field e.g. York Hospital: 11 (active)
The location period is the main reason I am making this. The periods are in descending order but the start/end is in ascending order so to read it gets quite messy. The periods also show duplicates if the transfer is instant which may be worth removing.
The simplest fix to this would be to just put lines to split the sections so at least it is easier to see that they get grouped and maybe number them
3: start <last period start>
2: start <2nd last period>
end <2nd last period>
1: start <3rd last period>
end <3rd last period>
It would be neater to me if the fields could be combined potentially like below in a single 'location history' section:
1: Admitted to
<Location 1 name>
on <period 1 start> (completed)
2: transferred to
<Location 2 name>
on <period 2 start> (completed)
3: transferred to
<Location 3 name>
on <period 3 start> (Active)
(if all completed) Left at <period 3 end>
Hi Marc,
That's looking a lot better, thanks very much
Hi Nick,
This has been developed and will be released into the sandpit and staging environments for user testing this evening.
All being well, we will promote to the production environment next Thursday.
This change will also include an update to display participant information more gracefully.
Hi Nick,
Thanks for raising this. I have promoted it to our backlog to be reviewed and prioritised.
Second this Idea from a Notts Care Record perspective … nearly all our test users have highlighted this as an issue/bug. Those users are not familiar with how the FHIR data is structured, so they did not intuitively realise that the Locations, Location Statuses and Location Periods were in in order, and therefore the nth status/period related to the nth Location text. Generally most users are only interested in the current location (or the most recent one, if discharged).
At least one of our trusts sees this a such a significant issue, that they have decided to only provide the most recent location as per of their data provision project.