What makes a good listing?
Producing a listing of patient activity is one of the most common ad-hoc requests hospital analysts receive. On the face of it, it’s a simple thing to do - write a SELECT, put the output in Excel, and the job’s a good-un.
That being said, the colleague who requested the listing may well be planning to spend a lot of time working with the output. Perhaps they need to resolve a data quality issue for every patient on the listing, or conduct a clinical audit on every piece of activity. So it’s worth taking the time to think about what makes a good listing.
Here are my thoughts:
- Understand precisely what activity needs to be included. It’s not always obvious how to transform the request you receive into a precise SQL clause. If in doubt, verify the specific filters needed with the requestor.
- Only include fields which are relevant to the request. Side-scrolling through dozens of columns is not a good experience.
- If the user will be looking up each record in a front-end system to perform an action, give them the identifiers they will need to use in the first columns of the listing. Avoid including any database identifiers which are not shown in front-end systems. If they have to be included, place them on the far right of the listing.
- Make field names human-readable. Prefer “Appointment Date” to “Att_Dt”. If the user might be unfamiliar with the standard definitions for metrics like length of stay, clarify them in the field name, for example “Length of Stay (midnights)”.
- Format dates and times appropriately. Does the time matter, or is it just noise? Will the user need to filter for particular weeks or months?
- Order the listing appropriately for its intended use. It often makes sense to order the listing by the date or location of the activity, or by the team that carried it out.
- Group related fields together. In particular, put fields that the user might want to compare next to each other.
- Document the listing. Include an explanation of what activity is included in the listing, and why.