Reducing risk: how risky are your clinical record workflow systems?

So.... to the “whole other blog” referred to in last month’s post.When was the last time you audited your document workflow systems?

So.... to the “whole other blog” referred to in last month’s post.

When was the last time you audited your document workflow systems?

Most practices will have converted their old paper-based system into an electronic system what probably seems like ages ago. In the past electronic systems tended to mirror older paper-based processes but they have evolved over time. Often refinements have been made as a result of a GP or receptionist noting something that’s not worked effectively – clarifying things, understanding capabilities and limitations of systems and so on.

Consider the following MDDUS case:

A GP views a letter on the practice system from the local hospital about a patient. The letter explains that the patient had been attending a hospital consultant but has now been discharged. It requests that the practice follow the patient up within a month with a further blood check, as they have been started on new medication. The letter also instructs that a possible change in medication dosage should be enacted if required, dependent on the nature of the blood results.

The GP notes that three actions are required:

1. Contact the patient to ask them to make an appointment with the treatment room for one month’s time.

2. Change the patients’ repeat prescribing record to include the new medication.

3. Update the clinical history within the patient record to include the new diagnosis noted in the letter.

Put aside the risks associated with second action being delegated - that’s for another day. So far so good?

Not so good in this particular case

In this practice the system allows documentation of all required actions but it is limited in that only one action request can be active within the workflow at any time. Each action has to be dealt with before the next and each type of action is also delegated to a different member of the admin team.

In this particular case the first action request is forwarded to the member of the team responsible for updating patient summaries. In a different week this would work out fine as the turnaround to the next member of staff and the other required actions would happen within a day or so. Unfortunately, the individual responsible for updating patient summaries is off on long-term sick and, due to the perceived ‘non-urgent’ nature of her role within the workflow, no-one picks up on her tasks for just over three months.

In this case the delay is identified, the practice gets in touch with the patient straight away, apologises and ensures proper follow up with happily no harm having occurred. But the outcome could have been different, and in our experience at MDDUS supporting GP claims, it often is.

Each practice will have different systems in place for dealing with electronic workflow of hospital letters and results. All of them have the potential to fail and so it is important to understand:

  • Limitations: the capabilities and limitations of the software.
  • Consistency: the consistency with which processes are followed across the team.
  • Prioritisation: whether prioritisation of activities is necessary and how this is ensured.
  • Understanding: whether everyone understands their role and the importance of this.
  • Flexibility: what should happen when someone is part-time or on leave.
  • Responsibilities: what each individual team member’s responsibility is in relation to their part of the system.
  • Documentation: whether decisions, messages and actions taken are recorded and available to other users.

Discussing these factors as a team can ensure you minimise the risk of a patient coming to harm and the practice receiving a claim or complaint.

Sharing knowledge about risks is important and so it would be good to hear your own stories, particularly any experiences of near-misses and ideas of how your practice has identified and mitigated risks within your own workflow systems.