In a recent blog post, I gave a whirlwind tour of some of the functionality within the PatientCare EPR. There is a lot I haven’t really mentioned and so, I thought I’d add some details over a few other blog posts.

A care plan is a document that sets out a patient’s future care and support. Patients should be fully involved in the preparation of such a care plan and ideally this plan should contain:

• what are the intended outcomes for a patient, including wishes and preferences.
• an assessment of the needs of a patient in order to achieve those outcomes
• how those needs are to be met by the agencies involved in supporting that patient

As such, a care plan should be individualised and specific for a single patient and will need to include plans for the care in a range of care domains, such as medical, nursing and social.

However, there are types of care plans aimed at different scenarios, such as an emergency care plan to document a plan of care should there be an emergency deterioration in a patient’s health. Such a plan would focus on ensuring that emergency unit staff know what to do and this kind of plan can be particularly helpful for patients with long-term health conditions.

Care plans within the PatientCare EPR.

I have built an emergency care plan registry within the PatientCare EPR.

The idea being that we could configure our emergency unit system to check for the presence of an emergency care plan via a REST API and ensure that caregivers have access to that plan in safely and securely.

Building individualised plans

Modelling care plans requires an understanding of the processes and workflow that create and maintain those plans. As such, it is not sufficient to simply model the data relating to a care plan.

For instance, care plans are typically collaborative documents in which multiple authors work to create a unified document. In addition, the users involved need to know the care plans for which they are responsible. Most importantly, how many of us have seen guidelines, protocols and care plans with an expiry date many months or years in the past? As such, it is vital that there are processes in place to identify out-of-date care plans and ensure that they are kept up to date.

Historically, healthcare professionals have relied on patients turning up in clinic in order to drive their healthcare. This is an outdated and inefficient way of running a health service. If we truly want a responsive service, we need to ensure that information technology is used to its fullest in order to enable care.

In this first screenshot, we generate a care plan. It is automatically populated by the contents of the emergency care guidance from any clinical services for which the patient is registered. I can add a number of users so for example, if I have a paediatric patient with epilepsy and nutritional problems, one section may the responsibility of a paediatric neurologist and the other a gastroenterologist.

Each user can edit or add new sections and order those sections:

which then populate the care plan document:

Users can choose the review date and the expiry date and users receive notifications when a care plan needs to be reviewed or signed.

Once a user signs off the document, the content is locked until either all users have signed it off, or someone unlocks the document. Only after all users sign off the document is it finally published to the repository:

But how can we do this for thousands of patients?

Care plans are particularly useful for those patients with complex needs and multiple co-morbidities. For such patients, it is easy to see how investing time and resource in preparing and maintaining emergency care plans can improve patient care in the event of an emergency. But how can we do this for all of the patients under our care?

Within the PatientCare EPR, all patients are registered to clinical services and projects by virtue of an episode of care. This episode may be lifelong for a long-term health condition, or short for an acute clinical service. As health professionals are registered with different roles to different services, this permits a finely grained security model in which only those staff involved in the direct care of that patient has access to the record.

Furthermore, this model provides a way of building dynamic care plans for all of the patients under our care. As such, the PatientCare EPR can automatically generate a default care plan individualised to that patient by virtue of that patient’s membership of different clinical teams.

Here I edit the configuration for a local Parkinson’s disease service. This will be used to automatically generate a care plan for the patients registered to that service.

I have built a REST-based API that looks for manually-created emergency care plan but, if that doesn’t exist and the clinical services are configured to have “automatic care plan generation” turned on, the system will dynamically generate a document for the use of emergency services.

In this example, I have linked to the Parkinson’s UK emergency care guidelines and emphasised that patients with Parkinson’s disease need their medications administered on time.