Designing a Medical Record App for the NHS
Date posted
20 November 2014
Reading time
12 Minutes
Designing a Medical Record App for the NHS
In January 2013, the Secretary of State for Health Jeremy Hunt set the challenge for the NHS to 'go 'paperless' by 2018, to save billions, improve services and help meet the challenges of an ageing population'.
In Evolve we strongly support Jeremy Hunt's initiative and have been digitising patient records in the NHS for 5 years. While the benefits are universally understood and recognised there is one problem introduced by a paperless strategy that in many cases is stifling adoption by clinicians. That problem is portability. Paper for all its faults can be picked up and transported wherever you are going, something which suits the working patterns of clinicians in the NHS - whether they work in acute settings, deliver care in the community or provide front line ambulance services. But ironically, the applications designed for these clinicians are typically desktop-based, quite often making them inaccessible at the point of care and restricting clinicians who strive to deliver the best possible levels of patient care.
We quickly recognised this problem and in 2011 set out to build a mobile version of Evolve, our Electronic Medical Record (EMR) product, helping to give clinicians back the portability benefits of paper, but combined with all the other advantages of an electronic medical record. This blog outlines our journey, describing the major decisions we had to make when designing our app, which ultimately has resulted in Evolve for iPad?, a native app for Apple iPad and iPad Mini, currently in the hands of clinicians at 19 Trusts throughout the UK and collectively being used to view over 1 Billion patient documents.
End Users Scope
The first thing we needed to understand was who was going to use our app. Within the NHS there are huge number of roles ranging from clinical admin staff all the way though to senior clinicians. Usability was a key requirement for us and we did not want to design a 'Swiss Army Knife' app; one that tries to cater to everyone's needs, but ultimately pleases very few. So we spent a lot of time with our existing Trusts to understand who exactly needed to use the app ensuring that every single feature we designed was deliberately crafted with a specific and named group of users in mind. Other groups of users can still use the app, but as it is their secondary device or they use it on an infrequent basis, the app is not optimised for them. Even today as we add new features to our app, we refer back to this work and are very deliberate in our approach, ensuring that any new feature will add value to the users that app is designed for.
Clinical Scope
Once we had a profile of who was going to use the app, we worked with these users to understand how they would use the app and in what clinical settings. This allowed us to segment the scope of our app into the three areas outlined in the image below. We decided to build online first, followed by a subsequent offline release, but in hindsight I would recommend an offline first strategy, for 2 reasons:
- Firstly, connectivity is a real challenge, even in settings were you expect to have network access. Many hospitals have Wi-Fi black holes and the presence of 3/4G cannot be relied upon when working in the community.
- Secondly, building offline with seamless synchronisation is hard. It took us about a year to build offline. The results are incredible, but it was a huge challenge - complicated by extending an app designed for online access. Had we started with offline, a number of key building blocks would have been in place from the beginning providing a simpler platform to extend.