Dr Paul Miller: March 07, 2019
In our latest blog, Paul Miller talks about joining the team as one of the Clinical Leads for NDS.
In February, I started in my new role as one of the Clinical Leads for NDS. It’s great to get started as there is a lot to be getting on with! One of the first things I wanted to do was write this blog piece, as I know that explaining what we are doing is going to be really important.
Crucially, from my perspective, what changes with the NDS approach to clinical software is that people in all health and care communities become a critical part of the development process. I am hoping that I can explain why that is so important in the next few paragraphs.
Where have I been?
First off, I’d better fill you all in with some background about me. I am a GP, currently a partner in a practice in Paisley, where I have been for 12 years. Prior to that, I worked in the east end of Glasgow, then had a brief sojourn around Scotland as a freelancer with a good few months helping out a single handed practice in Airdrie. I have been working in health informatics for over 20 years, the last six or so as the Clinical Lead for SCIMP.
So what is the problem?
Well, over the course of my career, I have learned that to properly 'engineer' health records, you need actual health and care practitioners to contribute their knowledge to the technical designs. Otherwise, things just do not work.
This may strike you as obvious, and I tend to agree, although I think there is still an expectation that the big software suppliers can and should ‘do it all’ and we end users can simply reserve the right to be annoyed when they do not deliver!
The ‘all’ in ‘do it all’ is known as 'the stack'. It's all the parts of the system that suppliers provide, from the database, through to the design of the content, the applications we actually use, the reporting and analysis tools, the user management and even the use of the records by third parties. And many of our procurements are designed around this stack - going out to buy an off the shelf product in the hope and expectation that it can do everything we ask of it. History suggests that this approach frequently does not actually work.
It's the 'content' part of the stack that matters most to us as health and care practitioners, because without the content you cannot build the applications, or anything else. 'Content' here does not mean the actual records themselves, such as a clinical note about a patient with gout, a prescription for amoxicillin or a record of housing; but refers instead to what it is about these things that the computer system needs to store and process.
Some of that may be relatively easy for a software developer to work out. When we want to record a patient's weight, most people could guess that it will need a 'number' and a 'unit of measure' - '76 kg' for example. So far, so easy. But when users want to record things like 'allergies’, 'NEWS2' or ‘Child Protection Status’ can we really expect developers in supplier companies to work out what we mean, let alone what we actually need?
The approach many vendors take to this problem is to obtain some expert help to advise their development teams. They may get this from the customer, or they may have a medical team in-house that can help. Sure, this is better than nothing, but it does not actually solve the problem because one clinician’s opinion about what they need to know about, say, a ‘blood pressure' is unlikely to be the same for every other clinician in every other setting. So, how do you obtain enough opinions? How do you identify all the needed content? And what happens when things change?
This last question is the one that causes most grief. Clinical knowledge changes, and this changes what we need to record and how. Traditionally, we return to our software suppliers with a request for change, and often end up with a requirements bottleneck, slow or (worse) no progress to change and often at significant expense. The supplier may have to do a new content analysis, re-write their code, change their database structures, and redesign their applications.
So how can we fix this?
At NDS we are aiming to tackle this using the OpenEHR approach to clinical content design.
Where OpenEHR differs from other health record designs, is that the 'content definitions’ actively make use of expertise from end users and that these designs or ‘models’ are structurally separated from the underlying database. This means that when things change, as they always will, developers do not need to go back and re-write their database or hack new code simply to change the underlying model.
It also means that the clinical and social care experts can contribute to creating the content specifications, without needing to know anything about computer coding or database management.
This process needs the practicing experts to actually contribute, and that means you!
This is a challenge of course, because we all thought the software suppliers could do everything for us (they cannot) and because we are all quite busy seeing patients and clients! That means that to contribute, we will need to do a little bit of skilling up and also try to find the time to make this part of what we do.
The 'skilling up' you can try and do yourself, by searching out and reading more about OpenEHR such as Woland's Cat and OpenEHR but to be honest, I struggle to find a ‘Health and Social Care Practitioner's Guide to OpenEHR' as the techy guys seem to have been writing all the manuals! This then is something we can provide, and I'll blog more about this over the next few months.
Clinical Knowledge Manager (CKM)
The software we use for the content design is called' Clinical Knowledge Manager' (CKM). You can see it on the CKM website and even sign up as a reviewer.
We are going to need people across Scotland from clinical and social care backgrounds, and patients too, to help us manage this content. The content models will be a free resource for everyone in Scotland (and beyond) to use, and will form the foundation of the National Digital Platform that NDS is building.
CKM can be a bit overwhelming for new users, and particularly if you are new to the ideas of clinical modelling and OpenEHR, so over the next few months I will post to this blog with advice to help you start to contribute, and of course to keep you up to date with what we are up to.
I very much look forward to working with you all!
Thanks for reading.