Tag: product

  • An introductory guide to digital healthcare products

    There is a wide and occasionally bewildering array of software used by patients and clinicians in the NHS. This is a short, introductory reference guide to illustrate the range. It is by no means comprehensive so any critique or additions are well received. I hope it’s useful to some.

    Clinical system: If you are new to healthcare, one of the immediate things you encounter is the primacy of the clinician and the concept of clinical safety. A clinician is someone with a medical qualification who treats people i.e. a doctor, nurse, paramedic, dentist, pharmacist, or midwife. ‘Clinical system’ is a broad term that is used to refer to the software that supports clinical activity i.e. the act of treating patients in a healthcare setting. When software is considered to be clinical it means it is subject to legislation such as clinical safety standards (as defined under the Health and Social Care Act 2012) or the Medical Device Regulations. This means clinical systems must be able to evidence their safety through testing and by explaining their approach to clinical risk management.

    Clinical systems are the bread and butter of healthcare and this is where most of the health IT money goes. They can range from specific standalone systems for a specific purpose like a Radiology Information System/Picture Archiving and Communication System, to care pathway-specific dealing with, say, cancer. A care provider chooses these based on its needs then often integrates them into a core enterprise system, more on which below. There could be over 100 in a given hospital.

    Patient administration system (PAS): used in hospitals, this describes the software that manages administration of patient interactions. This includes things like: the hospital’s patient index with patient demographic details, appointment booking functionality, checking patients in and out, scheduling and workflow type stuff, referral management, payments. Notably, PAS’s are distinct from being clinical i.e. they do not typically store or process clinical information about patients. Pretty much every care setting has something akin to a PAS, it’s just that the term is synonymous with hospitals. Because of the way PAS’s in acute settings have evolved to meet very specific NHS-y needs such as national data returns or payment processing, it makes it a niche market with higher barriers to entry.

    Electronic Patient Record (EPR): self-explanatory in some respects, as this refers to the digital manifestation of the patient’s healthcare record. EPRs are everywhere, although the term itself is most closely associated with hospitals. This is mainly because in hospitals there is a historic distinction between the care record and the PAS, and because other care settings have EPRs that are already called other things. These days EPR systems often do heavy lifting for both the patient record and various jobs previously undertaken by the PAS, as part of the trend to enterprise approach. EPRs can also go by the name EHR, or EMR. The market leaders in the UK are Cerner and EpicIt is apparently not cheap to install an EPR. Leeds Teaching Hospitals built their own, starting in 2003. Many sensible people on all sides of the political divide think that the patient data layer should be separated from the enterprise applications, and more who suggest it should be nationally owned. This is not going to be easy.

    GP IT Systems: these are the main software systems used by GPs, and are really an EPR for the GP setting. They have a whole range of features from appointment booking and management, prescription management, to generation of letters and storage of data. Crucially, they store your GP medical record, allowing GPs to code entries and enter free text information regarding your consultations, conditions or medications. The GP record is particularly important in NHS terms because the way the NHS is structured means it is de facto the main record for your healthcare. It stores correspondence between your GP and hospital or other provider. The systems also automatically pump data to NHS Digital for aggregate, statistical use. There are 4 GP system suppliers in England which are TPPEMISVision and Microtest.

    Clinical decision support system: commonly abbreviated to CDSS, this is a tool that is often embedded as a feature within types of clinical systems. It typically forms a series of questions that can be asked of a patient in order to help a healthcare professional (either clinically trained or not) assess the patient’s condition. You can see a CDSS in action on 111.nhs.uk in which patients themselves access the NHS Pathways CDSS. Pathways’ underlying clinical information makes a risk assessment based on the combination of answers provided. It’s essentially a corpus of medical knowledge with the “one thing per page” design principle applied. CDSS’s can be either for diagnostics or triage. Diagnostics is where the tool is actively trying to suggest possible illnesses whereas triage simply assigns a level of risk to direct a patient to the appropriate clinician or care setting. The former is governed by stricter regulations, but this is a bit of a false distinction in my view as a triage system is still making some guess at what the problem might be, in order to assign a risk score. As well as online, CDSS is used by phone operators e.g. on 111, or at the front door of emergency departments. Very specific CDSS can also exist to support clinicians in highly specialist settings e.g. to help doctors select the right chemo dosage in cancer treatment.

    Online consultation systems: these are relatively new on the scene, and are systems in primary care to enable GP-patient interaction to happen remotely. They comprise a number of features that support this. Online consultation is often conflated with video consultation. While the former does encompass video consultation, the terms are not wholly interchangeable because online consultation also encompasses things like form-based triage (i.e. the patient fills in a questionnaire about their symptoms and this is sent to the practice); 2-way messaging between the practice and patient; and symptom checking using a CDSS. Examples are eConsultAsk my GPEngage Consult.

    Personal healthcare record (PHR): PHR is an umbrella term for a digital healthcare record that is owned and administered by the patient themselves. It’s not clear to me yet how much this term is understood beyond a core group of wonkish types like me who work in digital healthcare delivery and policy. A PHR may combine clinical information from various sources, but crucially they also allow the patient to submit information themselves either through manual data entry or via wearables. NHS Digital maintain a working definition of a PHR on their website. Some examples are Tiny Medical AppsPatient Knows Best or Apple Health.

    Computer Aided Dispatch (CAD): This is the system that supports 999 control centres in the management of telephone calls into the service and the coordination of staff and vehicles in support of the calls. It also supports CDSS modules to help triage calls. Ambulance services will also often have a separate EPR for their patients. As the urgent and emergency care sector evolved as its own sector through the advent of the 111 service, so too did the case management tooling. So now equivalent products are available in 111 to queue and manage calls, undertake referrals, update records and perform triage. And some are used across both 999 and 111. In NHSD we have broadly referred to these as Encounter Management Systems but this is not a widely used term. Examples are ClericAdastra.

    Internet pharmacies: also known as ‘distance selling’ pharmacies in commissioner language. These are pharmacy services that fulfil prescriptions by delivering them to your house as opposed to requiring you to go to the pharmacist. They tend to have web or native apps that enable you to manage prescriptions accordingly. Examples are EchoPharmacy2U.

    Patient portals: as much as it pains me to write this heading, this is nonetheless still a term that is oft used in the NHS. It refers to any application either browser-based progressive web app or native app that enables a patient to interact with an underlying clinical system. Usually this is so the patient can see their records, book and manage appointments, and manage their medication. There are a ton of these for both primary and secondary care.

    Wellbeing: there is a massive market for wellbeing apps which support everything from diet, mental wellbeing, sleep. For a browse of some examples it’s worth a look at the NHS Apps library. I’ve not really given them the full treatment here because I know little about them and they aren’t typically transactional in the same way the other examples are.

    Having set all of this out, a few thoughts on healthcare products.

    • The boundaries around the different types of products are very fuzzy. e.g you will get PHRs that have some features of online consultation tools; or EPRs that do the work of a PAS. This sometimes makes it hard to know what to buy, and exacerbates the challenge of ensuring interoperability between systems. i.e. it’s a bit confused, in a similar manner to the organisation of our health institutions as I have blogged before.
    • Somewhat unlike central government departments (in my experience at least) the NHS and its staff are entirely comfortable with the concept of ‘services’. The clue is in the name I suppose. But there is very little discussion of services in the context of digital delivery, except at the national level with things like PDS and e-RS. You rarely hear the term ‘product’ compared to say ‘system’ or ‘tool’, and the closest you get to service is probably ‘digital care pathway’ which is kind of getting there but can miss the real fundamentals.
    • This proliferation of product types means there are lots of places that patient data can be held, hence the massive focus on interoperability in the NHS, and the importance of point 6 in the Future of Healthcare.

    Hopefully this is helpful to digital healthcare workers new and existing. As above, I welcome any additions or comments.

    The views expressed here are all mine and not those of my employer. Thanks to Kate Gill for her fact checking and examples. This was originally published on Medium on 1 May 2020.

  • 10 things policy can learn from product

    Six months ago I made a career pivot from policy making to product management. The roles require a similar mix of empathy and politics, so I feel I’ve taken to it reasonably well. Alongside a deep understanding of Internet-enabled technologies, a notable difference is how much and how effectively product management makes use of specific tools and methodologies to solve problems.

    So here are ten techniques I would bring into a policy team if I went back. If any of the terms don’t make sense, Ben Stevens from the Home Office has posted a handy glossary.

    1. Work in sprints. Choose a time period of 1 or 2 weeks to help give structure to the team’s work. Get everyone together at the start of the sprint and agree the things you are going to focus on completing in that time, remembering that new tasks will come in too. This is called sprint planning.
    2. Hold ‘stand-ups’ over the course of the sprint, and ‘retrospectives’, and ‘show and tells’ at the end of it. Don’t be spooked by the language. These are just meetings, so not exactly an alien concept to policy makers. There’s no need for me to repeat better guidance elsewhere on this, except to endorse how useful they are as an ensemble.
    3. Get a wall. Every team needs a wall. I managed a major house renovation last year and even had a wall (this is not a joke). At its simplest this is expressing a task on a Post-It note, fixing it to a nice flat surface that people can gather around, and moving the tasks through columns labelled ‘doing next’, ‘doing now’, and ‘done’. Do this, and then feel the energy and sense of achievement coursing through the team as they deposit card after card in the done column at each stand-up.
    4. Create genuinely multidisciplinary teams. I spent some time shadowing my mentor who works on NHS.UK Alpha a few weeks ago. It’s a full-blown agile team, replete with product manager, delivery manger, content writers, designers, and developers. Having such expertise around a table enabled them to do magical things, like designing the key features of a GP look-up service, in record time. My experience of policy is usually hierarchical group of something akin to project managers. Other experts tend to be in a box somewhere, wheeled out for special occasions. It also now seems amazing to me that design thinking in policy is still seen as the cutting edge while it’s de rigeur in digital.
    5. Make it someone’s explicit responsibility to knit the team. The mantra goes, “the unit of delivery is the team”, and commensurate effort is placed in getting that team working brilliantly together. My experience working in policy teams is that if they are working great, then great. But if they are not, the response is usually a shrug and sporadic suggestions for ‘more social events’. Digital methodology encourages constant communication between the team using stand-ups. It celebrates successes through show+tells, and does a thorough job of learning from failures through retrospectives. The result is a team completely aligned around an objective, with everyone feeling they are part of something important, and fantastic pace of delivery. Tasks fall to the team not individuals. This reduces risk of single point of failure.
    6. Separate responsibility for day-to-day delivery with big picture and vision. In digital there are overlapping and complementary roles called product manager and delivery manager. The former focusses on macro issues: vision, roadmap, stakeholder management. The other focusses on micro issues: unblocking the obstacles the team faces day-to-day, and doing the team coaching I describe above. This structure recognises something important about our minds being poor at doing two things at the same time. It’s very effective.
    7. Try out some new collaborative tools. Digital teams more naturally have their fingers on the pulse of internet-enabled tools to facilitate team communication, prioritisation, or collaboration. I know IT systems can create barriers to this; but in an age where everyone has a smart phone it’s not hard to find workarounds. If you had to pick any, for me it is Slack. There’s a bit of a backlash against Slack at the moment (Slacklash?), but frankly I’m still at the crest of the wave of appreciation that sees how much more efficient than email is at enabling team interaction.
    8. Prioritise properly. Product recognises you can’t do everything, so have a plethora of techniques for deciding what comes next. Do a few things well rather than lots of things mediocrely, and be rigorous in your approach to choosing which those things should be.
    9. Clap more. Digital teams religiously clap their teammate’s or others’ presentations. This is not only courteous, but sends the presenter away with those few extra endorphins that make it all seem worth it.
    10. Be agile. Note the small ‘a’. My simplest interpretation of this is understanding that for almost everything, your first answer could well be wrong. Doing something and then testing it is better than trying to get it perfect first time. As long as it is labelled as such, it is fine to say something is a prototype or early version and will be iterated, improved, or even binned.

    None of these suggestions are especially complicated. But they can be tough to implement in teams unfamiliar with the language and culture. Digital teams should help with this where they can, as forming good habits should not solely be the preserve of digital. They should be for everyone.

    I’d be delighted to give my novice advice to any policy makers, so do get in touch if it would help. Hat tips to LisaMatt, and Kylie for product coaching, and Benji for delivery management advice.

  • Continually improving our intranet

    No digital product is ever perfect or finished. Even a site that is 90% cheaper than its predecessor, and boasts a user satisfaction reaching post-launch heights of 80%. My challenge as the new product manager for the Department of Health’s intranet is to build on that daunting baseline, and carry on the great work of my predecessor, Kylie Mulholland. Revisiting lessons learned from the intranet’s first development seemed a good place to start.

    Over the summer we ran a discovery phase to understand how people were responding to the new site. We found that overall, users much preferred the new product to what came before. However, they would still like to find things more easily through either search or navigation, particularly the things that help them do their job. These findings were borne out by analytics data: video conferencing arrangements consistently appear among the site’s top search queries. The discovery also revealed unmet needs on the editorial side, where content owners and editors wanted a more streamlined publication process.

    Last week we brought together  a multidisciplinary agile team to begin a new period of development. We work in several organisations and multiple locations; Whitehall, Old Street, and as far as Atlanta, Georgia, so online tools like Slack, Basecamp, and Talky are helping to keep us connected with each other and our users.

    Stubborn on vision; flexible on details

    Our first step was to draft a set of high level goals for this phase of development, which support our overall vision of making the DH intranet the best in government. As ever, we welcome feedback.

    1. Users can find everything they need and access the services they want
    2. The intranet is accurate and trusted
    3. The intranet is easy and quick to update
    4. The intranet encourages user engagement
    5. The intranet meets the Digital Service Standard

    Borrowing a method from the Government Digital Service, we then built a prototype roadmap. This exercise forced us to think about what we would have to learn or prove if we wanted to achieve our goals. For instance, to show that “users can find everything they need”, we need to first find out what users are looking for, and then show, using data, that our improvements actually do help users find those things more easily.

    We also identified and prioritised the big themes emerging from the discovery and mapped them against a rough timeline of development sprints. These included search and navigation, events, content management, and sign-in.

    Finally, we used the roadmap to map out: our users, the wider ‘system of systems’ that support the intranet, our most important stakeholders, our assumptions, and any dependencies. This helped surface challenging questions early on. Our prototype roadmap is on display in Richmond House and will help us communicate to stakeholders what we are doing, why, and broadly when.

    Our first sprint

    Before we get going on new features, the team are first reviewing and cleaning the code base, fixing bugs along the way, and by the end of the week we’ll have it back in GitHub.  Making things open makes them better and from next week any organisation can take our code and ideas and start to build their own intranet sites, according to their own users’ needs.

    I’ve learned a lot in my first weeks in product management. It has not taken long to experience the tension between user needs (what evidence suggests end users of the product want to see) and business needs (what other stakeholders would like their users to see). This forces you to ask some pretty fundamental and philosophical questions about the real purpose of the ‘thing’. I’ve also learnt that getting the right policy, process, and governance around the product may be at least as important as the product itself. Finally, I’ve sensed that many digital folk think that intranets are the devil’s work! It’s our job to prove them wrong.

    Originally published on the Department of Health digital team blog.