I’ve had a few discussions recently about the principles we (try) to apply when building new documents in our EPR (acute provider with several specialist services).
Embarrassingly these have been held between various ears rather than written down. This is a non-exhaustive, no particular order first pass at trying to put this right!
1. The document serves the patient and the user, not the organisation. Data entry should allow users to efficiently and clearly record their thinking and the information this supports / explains this. Anyone reading the note should be able to understand what was happening, what was done, and what needs to happen next. Nothing more.
If a document supports downstream audit or operational understanding then this is a bonus. If it’s a driving factor it’s a problem.
Doctors and nurses want to look after the patient, not a target / CQUIN…..
2. Better doesn’t always mean faster. If it does, then this is fantastic. However the greatest efficiency in digital health records comes from the totality of information available, not from shaving a minute here or there on the time it takes to write up an admission.
Time taken and clicks needed should not be ignored, but if a new document / process takes as long as the previous whilst returning more meaningful and reusable information then comparing solely on time to complete is not fair.
Quality matters, quality helps the patient, quality leads to efficiency for all users.
3. An EPR is not an implementation tool. Harm happens in healthcare and we have a responsibility to minimise this. However, putting in a new document or making a few fields within an existing document mandatory is (as an isolated act) almost certainly never going to achieve this. Documentation supports desired processes and behaviours but cannot enforce them. People working in healthcare are smart and motivated. Trying to replace professional judgement will only create workarounds.
4. Clinical documents are part of a workflow, not the workflow. When designing and building documents we need to think about where these sit in an overall process / user journey. Other than completing the document you’re building, what else does the user have to do or achieve to support patient care. Understanding where and when the document sits in relation to these other tasks will inform it’s content and may also help you find opportunities to make life easier for the user.
Process maps are often drawn in sequence but delivered in parallel – a well designed document helps this happen.
5. Show don’t tell. Long notes filled with repetition can obscure the most pertinent information. A mature EPR is fundamentally an expensive relational database. Using this power to show users information at the point that they make their entries is helpful. Reproducing this supporting information in the printed output of the entry is just noise.
If the output of a document doesn’t support an assessing clinician deliver patient care in both controlled and emergency situations then the output isn’t right.
6. Nudges work. Like it or not we have all been conditioned to respond to visual input cues. Twitter gives a small box, not a digital A4 page. Experiment with the size and positioning of text fields in documents to encourage the ‘right‘ amount of text. A small box that expands may make the document look accessible and neat, but may also encourage the user to limit detail where it is more important. The opposite also applies…
7. Reuse, reduce, recycle. Documentation can become unmanageable when it overfits to each individual service or condition within. Having an admission document for medicine, surgery, orthopaedics, renal, spines, respiratory etc creates a mess, burns development resource and can confuse users resulting in important information being missed.
Wherever possible develop generic documents with a common core that serves all users. Reuse components between documents to further build familiarity. Only when there is agreement about what constitutes a de minimus piece of documentation that all services will accept should customisation even be considered.
8. Don’t ask impossible questions. This should seem obvious but seems to be ignored more than is reasonable. If a document prompts a user for information that they won’t or can’t know then this is often a marker that the document is serving the wrong person.
A good example here is asking staff to predict a patient’s length of stay (to the exact date!) at the point of admission. Not only does this fail a ‘real world behaviour‘ test (people typically estimate using ranges not point predictions), but in doing so it creates excessively noisy information, undermining the likely reason for including the question.
Discharge planning is important for the patient (so getting this right serves point 1), but here we need to dissect how this information best serves them. For us, a bit of rough and ready analysis showed that predictions were highly accurate for same day discharge, very good for a 24-48 hour window, ok-ish when out to 72 hours and a random number generator beyond this. Helpfully, the capacity teams typically worked on, at most, a 48-72 hour planning timeframe. We now bucket estimates in these ranges, reducing cognitive load on users and improving data quality.
Looking at documents in use and critically examining for gaps, workarounds or fields that promote garbage answers is vital to allow informed iteration and improvement.
9. Integrate, don’t segregate. Good healthcare is delivered through multi-disciplinary teams, so we need to build documents and structures that reflect this. The idea that there are specific documents for doctors, nurses, pharmacists, physiotherapists, dieticians, intensivists etc does not speak to the holistic care of the patient. Yes, different staff groups will use documents with different frequencies, but all staff need to be able to easily access the information recorded without feeling they are straying “out of their lane“.
This final principle seems to be a reasonable acid test of our overall success in applying the others. If our documents serve the user, fit into workflows, share information without bloating output, and reuse components then an integrated record should be a natural endpoint. This, therefore, feels like both an over-riding principle and a goal.
I’m sure I’ve missed things. I’m sure lots of this can be improved. I’m sure some of this is wrong. This is a v1 note and I’d love to hear thoughts on how to make this better.