The Code for Health initiative and the idea of teaching doctors to code (disambiguation: I mean write computer software not learning to apply clinical codes to health records and other health data) is in my mind a really good idea but something that is capable of being badly misunderstood and misapplied with the potential to seriously back-fire. In this piece I’ll try and explain why I think it’s a good idea and how we can ensure it delivers that which its’ protagonists hope for and also some other ways which may be more appropriate for HCPs to become involved in designing digital systems and services.
In this blog I use the term HCP (Health and Care Professional) as shorthand for any professional group whose primary domain of expertise is health and/or care rather than IT. This group includes doctors, nurses and other clinicians, clinical scientists, social workers and other social care professionals as well as managers and commissioners, particularly those working at the frontline.
I conclude that it’s a good idea to teach those HCPs who wish to learn to code – not so they can become or replace professional developers and designers, but to create a more meaningful discourse between HCPs and digital professionals and to enable them build simple tools at the user interface level, while digital professionals concentrate on building robust systems that make this safe and easy. I also suggest that for many HCPs, engagement in the design of digital systems and services may be more appropriately achieved by enabling them to contribute their expertise in the development of clinical content and the user experience rather than teaching them to code.
So what’s my rationale for these conclusions?
Amazing things happen when you get people with different skills, ways of thinking and insights in the same problem space working together.
I’ve seen this many times in my career. In the early days of GP Computing in the late 70’s and 80’s more recently in the NHS Hack Days and on many occasions in between See this previous blog
I’ve tried to make it happen at other times and places and have both failed (as I did working inside the NPfIT) and succeeded (as for example with HANDI ) and I’m increasingly focusing my efforts in areas where I think I can help create hybrid vigour or heterosis
Central to the generation of heterosis is the creation of mutual respect, shared perspectives and common language to enable a meaningful discourse between the parties.
In the development of digital health and care tools and services there are five critical groups of actors who we need to engage in a meaningful discourse in the design and creation of digital health and care tools and services:
To facilitate this discourse we need to create some boundary objects – things of which each of the participants has some common understanding. The first and most important boundary object is the citizen/patient who in my model is both an actor and a boundary object. This is possible because all of the actors are citizens and have direct or indirect experience of being a patient and so from the outset can engage in a meaningful discourse about what a citizen/patient might want from digitally enabled health and care services. I’d also suggest that there are other boundary objects that it is useful to create. These allow each of the groups of actors to gain insights into the domains of the others, facilitating a meaningful discourse, building mutual respect and hopefully creating heterosis. There are many potential boundary objects that can be developed I’d like to concentrate of these:
- Care pathways
- Clinical content
- User interfaces and user experience
Code for Health is concerned with the first of these and is useful as it creates a boundary object between HCPs and the other groups of actors facilitating. Its aim should not be to make HCPs software engineers, but to help them develop a common language and understanding so that each understands and respects the contribution the other can make and to enable HCPs to be meaningfully engage throughout the life-cycle in the design, development and implementation of digital tools and services.
Next, creating an understanding of the issues associated with maintaining well-being and treating poor health and in particular the care pathways which we hope digital technology can enable and support will help those other than HCPs better understand the challenges to which they can apply their skills. So, for example teaching engineers to deliver care is equally as valuable as teaching HCPs to code.
Clinical content is perhaps the most promising boundary object with which we can most usefully engage HCPs in the creation of digital tools and services.
Clinical content represents the information and knowledge required to deliver health and care and consist of information models, care pathways and decision making rules The primary experts in this domain are the HCPs, the experts in the construction of the artefacts required to represent these things and the informaticians, while those with the expertise to build the tools to enable HCPs to engage in ways which hide the technical complexity are the engineers and designers.
Historically, the formalisms that enable clinical content to be represented in a computable form have been impenetrable to those without substantial training in information modelling and/or knowledge engineering (just look as things like Proforma, Arden Syntax, RDF or the Hl7 MIM ) making them inaccessible to frontline clinicians, and HCPs while many of those with the technical skills to use these things lack the clinical understanding needed to use them to best effect. The result has been that the control of clinical content has been left with a few High Priests versed in both the dark arts of Knowledge Engineering and Medicine who are often too remote from the front line to know what’s really needed. However, this is now changing with the creation of tools that allow mortals to engage in ways that are accessible to an ordinary IT literate clinicians and HCPs. Great exemplars of this are OpenEHR www.openehr.org and OpenClinical www.openclinical.net which provide intuitive tools to allow, respectively the creation and maintenance of electronic record and clinical decision support components by frontline practitioners while dealing with the technical complexities essential to the production of the technical artefacts needed by the engineers and designers to produce digital systems. This new generation of tools allows people to concentrate on their core competences knowing that the requirements of others will be met and provides boundary objects, enabling an ever more productive discourse between domains supporting effective user centred agile design by multidisciplinary teams.
Finally, creating functional and desirable user interfaces and user experiences is critical as without this good underpinning clinical content and well engineered components will not be enough to properly support the process of care. The key experts in this area are the designers and human factors specialists, but they need to work in close conjunction with HCPs who understand care processes and their supporting business processes. It is also important to work with citizens and patients who should be the beneficiaries, but are so often the victims, of digital tools that get in the way of HCPs trying to deliver safe, convenient and compassionate care. So this again is a key area where we maybe can make good use of HCPs as well as teaching them to code.
So in summary, we need heavyweight informatics, software engineering and design skills to deliver an open health and care ecosystem which allows HCPs to do much more for themselves in the creation of clinical content and at the user interface level without having to understand the technical complexities which have to be satisfied to allow them to do this safely, securely and easily.
This means teaching HCPs to use these tools and looked at this way, Code for Health is not just a good idea but essential.