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.

Design Decisions Once we had a clear understanding of the end user and clinical scope, we started working out how we were going to build our app, and unsurprisingly this involved making a number of significant decisions. The image below summarises many of these, the first of which was whether to build a native, web or hybrid app. We had an unflinching desire to deliver the best possible user experience to the clinicians using our app. As we were dealing with patient records that needed to be stored on the device for offline access, security was a fundamental requirement; but we didn't want to build a highly secure system and compromise on usability or performance. We strongly believed the only way to guarantee all of these quality attributes was through a native app. However, the decision to build a native app quickly posed another major question which platform would we use? At the time we felt Windows 7 was not a fit for purpose mobile platform and Blackberry was very much a platform in decline, so it was a face-off between iOS and Android. There were a lot of conflicting opinions, both internally and externally, but I was convinced that iOS offered us the best platform to deliver on our commitments around security, performance and usability. I believe Apple are unique in many ways; notably they have a singular focus on usability but in parallel have designed the iOS platform with security at its core, all the way from low-level hardware and firmware features to protect against malware and viruses up to high-level OS features preventing unauthorised use, that importantly, are implemented in a way that does not compromise the user experience. This tight integration between hardware and software is something Android cannot compete with the huge variety of Android software versions combined with an equally huge collection of devices would, in my opinion, make it extremely difficult for us to honour all of our core design principles. In addition, Apple has made it easy for enterprises to manage and control all their devices, have fostered a strong eco-system for health based apps and importantly, they build devices that clinicians want to use, helping reduce many traditional barriers regarding the adoption of technology. Looking back now, our decision to support iOS is probably the best decision we have made in the last 3 years not only has iOS enabled us to deliver on our core design principles, but Apple have continued to innovate and advance iOS, opening up possibilities we never even imagined back in 2011. The recent release of iOS 8 in particular has introduced a range of features including HealthKit, Single Sign-on and Inter-app Communication, all of which we will serve as building blocks for us to continue to innovate which in turn will help clinicians deliver better and more timely patient care - something I'm incredibly excited and proud to be a part of.