The PatientCare electronic patient record system is a web-based application accessible across NHS Wales that records diagnostic, treatment and interventional treatment. It is underpinned by SNOMED-CT, a modern sophisticated and comprehensive terminology system that acts as the ‘lingua franca’ to provide algorithmic understanding and dynamic functionality. While the main functionality is available via a web-based portal, users can also interact with the software using bespoke iPhone and iPad applications.

It has resulted in clinical information becoming available immediately at the point-of-care. The neuro-inflammatory team used to use paper notes with filing cabinets full of brown folders; now they are paper-free. It records not only a prospective longitudinal narrative, acting as a customer-relationship-manager, but records both clinician-derived and patient reported outcome measures. In addition, while fundamentally it is a system to support the direct care of patients, it additionally supports the dynamic real-time aggregation of data for service management.

Finally, it supports the registration and management of clinical research projects, managing consent and access privileges using a finely-grained security model. This allows the recording of deep clinical phenotypes combined with a record of biological samples such as plasma, serum, DNA and cerebrospinal fluid. As such, we not only know that the serum was taken from a patient with, for example, epilepsy, but we also know how that biological sample was taken on the same day as a generalised tonic-clonic seizure.

I have been building this system since 2009. This blog post is an overview of the functionality available and the underlying design principles.

---

1. Start with a problem

When designing clinical information systems, the priority must be to solve a problem. It is therefore vital to understand and frame the problems, work on making those problems as generic as possible without losing functionality, and plan for a phased iterative development in which early designs are built with future needs in mind.

One important problem we face in hospital medicine is an understanding of our patients and their outcomes. You might be surprised to know that my own organisation knows how many patients attend outpatient clinics, but they have little idea why they were seen, what had been done or how they have fared. Indeed, there are now ongoing projects to record patient outcome measures from patients when their appointment letters are sent to them, but how can anyone interpret those data without an understanding of the problems those patients face?

Example problems might include:

• How many patients with [Parkinson’s disease] in Wales?
• How many patients with [epilepsy] refractory to two drugs?
• Who might be eligible for this new [treatment / research project / intervention]?
• Who of my patients is taking [methotrexate] and need monitoring?
• Tell me when any of my patients with [epilepsy] attends A&E.
• Tell me when my patient loses 5% of their body weight compared to weight at diagnosis.
• How do patients fare after having a [ventriculo-peritoneal shunt] procedure?

This information is actually available, but it will generally be recorded in individual patient notes. The only way of knowing how many patients we see with Parkinson’s disease for example would be to task someone to go through the paper records or outpatient letters and manually count them up. Therefore, while this information is available, it isn’t accessible at the point of care or in any format that permits dynamic, real-time monitoring and understand of our clinical services.

The PatientCare EPR supports solving all of these problems, but does so by creating a generic solution applicable to a wide-range of clinical problems.

---

2. Move to a model

Once you know the problems that need to be solved, it is tempting to start thinking about how your clinical information system is going to look and behave. However, you should instead consider your high-level functional requirements and the model of the world that will support those requirements. I write about clinical modelling in my Domain-driven clinical design document but essentially a model is an abstraction of reality. Clinical modelling requires both time and collaboration, between experts in the problem domain and experts with the required technical skills.

I suggest dividing clinical modelling into three related steps:

1. Modelling data within a medical record
2. Modelling processes and workflow relating to a medical record
3. Implementation of a clinical model into a workable and practical solution.

These three steps should be considered separately but are dependent on one another and inherently depend on the functional requirements. In designing clinical information systems, a data model may change infrequently or a design may even be correct in perpetuity; a systolic blood pressure recorded using a cuff on the right arm of an individual will always be a systolic blood pressure recorded using a cuff on the right arm of an individual. However, a model of the processes of care will likely change more frequently as a result of changes in working practices and service design, and an implementation may change even more frequently as a result of new technologies and devices. As each step is dependent on each other, modelling must be an iterative work with feedback loops between all steps rather than performed in sequence by different members of the team. An implementation cannot be designed without consideration of the data structures and processes that leverage the data within those structures and a model cannot be designed unless it is practical and efficient to perform an implementation. It also follows that clinical modelling must be performed by a team of individuals with a range of skills including those with important domain knowledge such as health professionals as well as those responsible for the design and implementation of the resulting software such as technical architects and software developers.

However, as part of this iteration, I don’t suggest trying to do detailed planning. Historically, the health service has developed software by providing detailed requirements and planning systems in detail with the stages of development build using a Gantt chart. Advocates of such an approach suggest that this lowers risk and maps the process of development from initiation to final deployment. The use of a Gantt chart typically creates a project plan that looks like a waterfall, and so this is typically termed the “waterfall model”. Instead, I would advocate a more agile and iterative approach in which the three related steps of clinical modelling listed above are used as part of a series experiments in order to test those models and our assumptions and ensure that what will be created will actually be valuable.

---

3 Example requirements

It might be useful to consider some examples of functional requirements and the data required to solve those problems.

Support the derivation of incidence and prevalence of a range of rare diseases

Given this task, we might consider first how to calculate incidence and prevalence and decide that we need:

• a list of patients, including dates of birth and death
• their current and previous addresses and the dates on which they moved.
• a method to map addresses to wider geographic areas, such as health authority boundaries
• a record of diagnoses and the dates of both diagnosis and onset.

With these data, it is conceivable that we can generate incidence and prevalence data for any disease at any time point.

The PatientCare EPR has underpinned our local multiple sclerosis epidemiology projects for many years. At the touch of a button, I can generate incident and prevalence data. Here is an example:

Send an alert when one of my patients with MND loses 5% of their body weight

• a list of patients
• a record of diagnoses and the dates of both diagnosis and onset.
• a way of identifying motor neurone disease whether the patient is recorded as having “MND” or a subtype such as “progressive bulbar palsy”.
• a longitudinal record of body weight
• a method to track clinical users and handle notifications

The PatientCare EPR does this dynamically and presents the information in a dashboard, but also sends me an alert when it recognises a patient has lost weight:

Show me how this patient with multiple sclerosis is doing compared to their peers

• a list of patients
• a record of diagnosis and the dates of both diagnosis and onset.
• a longitudinal record of disease outcome, perhaps generic, perhaps disease-specific, perhaps both.

In this image, progression of disability for the whole cohort is shown (dotted lines indicated median and centiles) with an individual’s progress overlaid. In addition, my colleagues can dynamically change the inclusion and exclusion criteria that defines the cohort. For example, a man presenting with multiple sclerosis at the age of 35 can be shown against other men presenting between age 30 and 40 to easily see how the individual is doing compared to their peers.

Record patient encounters such as telephone calls and allow team-working

• a list of patients
• a list of teams
• a list of users
• linkage between patients, teams and users in order to support team working and understand who is involved in the care of whom
• security access control to use that linkage to decide on patient record access

The PatientCare EPR now records thousands of messages every month. Users can choose to receive emails when a message is sent, with the software sending messages with patient identifiable information if they have an NHS email account but only a notification if they have registered with a non-NHS account such as their university email.

---

4. Solving our problems

It is clear that many of these functional requirements are generic and widely-applicable, irrespective of disease, treatment or intervention. Indeed, why limit comparing a single patient with their peers based only on diagnosis? Instead, consider how one might design systems that allow such comparisons based on other characteristics, such as a particular type of procedure, an admission under a particular specialty or an outpatient appointment.

A focus on the user interface means that when one broadens the scope of a problem, it is possible to create complexity and confusion. However, broadening the scope of a problem at a domain-model level often simplifies our work, by providing insight into how one requirement is in fact closely related to another. Defining the appropriate scope of a problem is therefore critical to create usable, workable and valuable clinical information systems.

Essentially we need to build an information model representing the data and the relationships between those items of data. Such modelling requires an understanding of the “nouns” in healthcare as well as the processes (the “verbs”) that represent actions on those nouns.

However, no solution exists in isolation. Instead, any clinical information system must interoperate with other systems within a wider health enterprise, either within a single organisation or, increasingly, across organisations. There is now increasing momentum towards open architectures in which healthcare data can be represented in a standardised fashion and I have written about openEHR, HL7 FHIR and SNOMED-CT in my data standards blog post.

SNOMED-CT

I have previously also discussed SNOMED-CT in detail (in discussing the importance of cohorts, in releasing an open-source SNOMED-CT terminology server and in using SNOMED CT to understand meaning).

Essentially, SNOMED-CT provides two key features that underpin solving many of our clinical problems.

Firstly, it provides a terminology, a list of terms representing clinical and non-clinical concepts. Therefore, rather than users typing “MI” or “myocardial infarction” or misspelling “mlutiople sclerosis”, it allows the mapping of user entered information into concept identifiers.

Secondly, it provides an understanding to the computer what those concepts actually mean. This allows computer code to understand that “multiple sclerosis” is a type of “demyelinating disease” for example. The relationships within SNOMED-CT essentially provide a database of clinical semantic knowledge.

These two features mean that SNOMED-CT is a powerful tool in creating modern clinical systems that can not only provide powerful functionality to allow users to record problems, diagnoses and other information but also exchange that information with other systems within the enterprise.

So how do I use SNOMED-CT within PatientCare?

Here is a screenshot recording SNOMED-CT in the clinic. For each click, the terms “Injection of botulinum toxin” and the brand (e.g. “dysport”) are recorded within an information model that also records who injected, when and how much.

Importantly, users do not know they are entering SNOMED CT codes when they use these electronic forms.

If you would like to see a demonstration of entering clinical information in this way, try my online demo application. It is very simple, but it shows you how entered free text can be mapped quickly and efficiently.

---

5. Design for the future

When I sat down to design the architecture that underpins the PatientCare EPR, I planned for a future in which I would combine multiple disparate sources of information to build a complete picture of a single patient and groups of patients.

I viewed the overall flow of data like this:

As I write, I now have completed almost all of the modules required in this schematic. I don’t yet have any apps on any app store for patients to use directly, but am piloting clinic-based applications to record patient-reported outcome measures and consent to research.

As a result, we are now able to see a combined view of data from multiple sources:

Here we see a patient’s seizures together with their drug regime over time. This is not computerised decision-making, but the computer making the right information available at the right time.

Here we see the structured data recorded for a patient with Parkinson’s disease. Instead of trying to capture data from free-text, we record structured data in an efficient way and then generate our summary correspondence from that:

I have added a complete REST API to allow other applications to liberate the data held within the PatientCare EPR to authorised users or their agents, but there are very few other systems that have adopted either a standardised information model or terminology. The clinical documents that are created are not simply binary blobs of data with unstructured information, but carefully modelled documents with links to the users, the locations, the type of encounter, the diagnoses, medications and procedures, coded and structured. Unfortunately, there are few other systems that can leverage that information yet.

In this video, I build an electronic consent form within the web-based EPR. An iPad application connects to the EPR using a REST API, downloads the consent form and information about a research project and, while recording patient outcomes directly from the patient, also asks them whether they want to sign-up. Their consent and their outcome measures are then immediately sent back into the EPR and are incorporated into the generated clinical correspondence.

The last video demonstrates the working of the EPR in the motor neurone disease clinic.

Statistics

• Over 60,000 lines of code
• 9 years of “spare time” development (evenings and weekends)
• 3000 clinical encounters recorded every month by hundreds of users for direct patient care and clinical research
• Over 20,000 patients and their outcomes
• Running on a Linux server sitting in an NHS Wales data centre.

My future plans

I have worked single-handedly on this software for many years but now find myself turning away people who want to use the system as I do not have time to add new functionality and offer support outside of Wales. I have dabbled with outsourcing and subcontracting development work but I would really love to work with others on solving problems in healthcare using information technology.

Therefore, if you are interested in business development or a partnership or are an IT developer who doesn’t simply want to work on a contract basis, but is interested in what I’m trying to do, I’d be interested in hearing from you. I have some recurring income from the software (from the NHS) which can pay for part-time salaries in the short-term but I think the goal would be to work on seeking investment and then really trying to grow the business. Perhaps it is better as a social enterprise, a charity or a for-profit company. I’m open to ideas. Let me know!

Mark