Building PEACH Cancer🛠
For the past 5 months, we have been working on the PEACH Cancer project — a platform for doctors and healthcare professionals with the aim of improving productivity and data accuracy within the NHS.

Today, we want to share with you how we built our prototype and what we learnt along the way!

What is PEACH Cancer?

At it’s core, PEACH Cancer is an interface to patient data. Its aim is to replace paper records in the NHS. The idea is it that doctors can retrieve and update patient data in one federated system, ensuring that details are never out of date.

Compare that to how things work now, with patient data being entered on paper forms and then emailed or faxed (…yes, faxed…) from hospital to hospital.

A day in the life of an NHS doctor 😱

Obviously, this is a pretty big task, and it’s success relies heavily on its reception by doctors. Hence, the need for a lightweight prototype application which we can use to demonstrate the potential benefits of the system and green-light the development of a production ready application!

What have we built?

We have built a demonstrative platform based on the cancer multidisciplinary team (MDT) meeting, which enables access to the underlying patient data.

Home page

Our prototype provides a couple of core features…

User Roles

In any medical application, access roles are important and this was one of the core requirements of PEACH Cancer. To do this we added a role identifier to each user. That identifier could then be used to limit access to parts of the app — ensuring confidential data was not leaked.

{

id: null,

role: null,

openEHRSessionId: ‘’,

firstName: ‘’,

lastName: ‘’,

loading: false,

error: false

}

So we can model users like this, and upon login hydrate this with user-specific data. When attached to the Redux reducer we can use this data throughout the UI and in business logic, such as deciding whether a user can view a particular part of the dashboard.

Jobs List

A convenience and organisational feature which keeps a log of a user’s tasks which have been assigned through the system.

Scheduler

A neat way of visualising, creating and updating meetings.

Case Preparation

The ability to access and update patient details in preparation for the MDT.

Technology

Our prototype is a full-stack javascript application, making use of the Electrode.io framework. We chose this framework primarily for it’s simplicity. The ability to use a single language on both front- and back-end was awesome! Additionally, it is an opinionated framework, which has helped mitigate bikeshedding within our team 🙃

In addition, React’s component based model works incredibly well when building complex UIs. Additionally, when coupled with Redux, handling complex application state becomes incredibly manageable.

Deployment

We deployed our app to Azure. Initially we had some problems, specifically with asset loading. After failing to debug the issues internally, we reached out to the Electrode.io team for help which prompted us to initialise an Azure virtual machine.

Still to do

Clearly, what we have here is just a prototype. This wouldn’t be suitable for production for a variety of reasons — security being just one.

We hope to extend this proof of concept in the following ways

Improved UI — sounds unimportant, but UX has proved itself to be incredibly important to the success of software. Our application could benefit from work on both the visual cohesion of the application, and user feedback from the UI when an action is performed.

Security — currently, security is just a check that the user’s role === admin. Obviously, this is really flimsy, and easily hackable. An easy improvement to this would be to store user details on the backend, and identify users with a JWT (or something similar).

Additional Features — a live chat component would be really useful for collaboration on the system.

Our Team

Ben Hadfield | Julien Nahum | Sim Zi Jian
['Ben Hadfield']
['Nhs', 'Healthcare', 'Software Development', 'Prototype', 'Health Technology']