COMMENT
Te road to the National Digital Platform Building a health and care system block by block and avoiding the costly IT procurements of the past
BY DR ALISTAIR HANN Chief Technology Officer, NES Digital Service
Building a National Digital Platform for health and social care data is a huge undertaking, and in a recent blogpost, NES Chairman David Garbutt asked,“Where do we start – which route should we take through the landscape of systems?” We have now started building the platform to make health information available across and health and social care - this is our chosen route. Te national digital platform is a huge thing
to tackle – making sure that citizens and the workforce have access to all the information they need at the point of care, whether it was originally recorded in a hospital, GP practice, or at home. Tat means getting information in and out of thousands of systems. We could start by moving all the data in those thousands of existing systems into the new platform. Te problem with that is it would take a lot of time, cost a lot of money, and at the end we might not have what we needed. Tat type of delivery approach has been
taken by many public sector IT projects in the past – years of procurement producing a set of requirements the size of a telephone book, and when the solution is delivered for tens or hundreds of millions of pounds, the world has moved on. Unfortunately, that is typically compounded by a decade of lock-in until a new system can be introduced (assuming that is possible, given systems often lock-in knowledge and data). In the time between procurements, punitively expensive change requests can be made - although there are many instances of vendors refusing to make changes or even fix bugs. Tere are alternative approaches. Henrik
Kniberg has blogged about a diagram he uses. It shows two approaches to delivering a car – the first is built in stages (a wheel, then wheels on a chassis, then a body, and finally a steering wheel) and the customer doesn’t have any- thing useful until the very end. In the second approach, each stage of development ships something useful: a skateboard, then a scooter, bicycle, motorbike, and finally a convertible. Every one of these is a better way of getting
34 | FUTURESCOT | SPRING 2019
from A to B, and at each stage something is learned – e.g. without handles a Skateboard is quite unstable, so the scooter has handles. Every step delivers something that solves the problem and we learn from every step. We are taking the same approach - rather
than the lengthy, expensive public sector IT procurements of the past - building a series of small applications, that build out the func- tionality of the platform. Tat way we make something that improves the quality of care from the very first delivery, and we can learn from that before we build anything else. Te first of the applications we are building
is to help people communicate how they wish to be treated if they are unable to communi- cate in an emergency. Tere is a new process being adopted across the UK called ‘ReSPECT’. Borrowing from their website: "ReSPECT is a process that creates person-
alised recommendations for a person’s clinical care in a future emergency in which they are unable to make or express choices. It provides health and care professionals responding to that emergency with a summary of recommen- dations to help them to make immediate deci- sions about that person’s care and treatment. ReSPECT can be complementary to a wider process of advance/anticipatory care planning. Te plan is created through conversations
between a person and their health profes- sionals. Te plan is recorded on a form and includes their personal priorities for care and agreed clinical recommendations about care and treatment that could help to achieve the outcome that they would want, that would not help, or that they would not want.” Te way that a ReSPECT plan might currently be implemented can be challenging – the respect plan would start as a paper form that was filled in by hand. It would then be scanned in to be part of the ‘digital’ clinical record, then a copy would need to be printed out and put in the house. If a small change was needed, a whole new form would need to be filled out, scanned and printed. In the event of an emer- gency, how would paramedics know whether there was any form, where to find it, and whether it was the most up to date copy? To implement an effective version: this plan
needs to be available in an emergency, regard- less of where someone is (e.g. home or hospital) and regardless of the role (e.g. paramedic, emer- gency medicine consultant). Te plan is created and contributed to by health professionals across care, not just GPs, so it needs to be pos- sible for people with different roles to write to the document from different places in care such as a hospice or care home. People are likely to want to let their relatives know that such a form exists and what their wishes are, so they may want to be able to access the form themselves online and show it to people close to them. All these things are achievable with the new
platform, which at its core is a patient-centred record that can be accessed and contributed to across care, and by citizens themselves. Te amount of information being captured in the ReSPECT plan is quite modest – the paper form is only two pages of A4 long - but by delivering it, we are creating something much bigger: that first version of the national platform, with a person-centred record shared across care in Scotland. We will then work to expand the function-
ality, for example, by making the application cover other types of ‘Anticipatory Care Plan’ and care plans for chronic conditions. Each time, we can do this by delivering a little bit more functionality, and learning from the feedback we get, before going further. In parallel, we can start using the platform to support other health and social care applica- tions in the process of development, that also need to be able to read and write to a national patient-centred record. As a bonus, because we are using a standard
called openEHR, we can re-use data across these plans – avoiding re-entry of data. It also means the data is portable between different systems, and the clinical knowledge to build them is in the public domain – moving us away from some of the other challenges of current systems that were mentioned above. Tis modest application is the start of our
route towards a full platform, that takes us away from the challenges of existing systems, and we will learn from every step we take. l
https://scottishdigitalhealthblog.nes.digital
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36
