Monthly Archives: March 2014

Digital Health Ecosystem, Featured, NHS Policy, Open Source, Software Development

Code4Health

5 Comments

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:

 

Actors
Actors

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:

  • Software
  • 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.

 

 

Analytics, Featured, Innovation, IPR, NHS Policy, Open Source, Ramblings, Software Development, VistA

What makes an Open Source community?

4 Comments

There has been a lot of interest in the role of Open Source software in the UK over recent months, initially stimulated by NHS interest in the American VistA Open Source EHR, but now taking on a broader scope including some of the exciting home grown initiatives.

Included amongst these are a number of projects that started in a closed source environment, where the IPR owner has decided to shift to an Open Source model. From a narrow technical perspective making software Open Source is easy – You just make release it under a recognised Open Source licence and make it freely available for download. However, Open Source is about much more than the licensing model and much more needs to be done to achieve the benefits of Open Source than what the Open Source community disparagingly call a “Code Dump”.

Open Source is about an approach and philosophy that at its’ heart believes that by creating a community who can freely use and contribute to a product that we can create better software and release new commercial and social value not available from other approaches. Open Source enshrines some import  freedoms and principles which defined and maintained by the Open Source Initiative  that also provides guidance on licences that meet these principles.

To be effective an Open Source community has to be diverse and well supported; containing all of those stakeholders needed to ensure a sustainable business model for the products’ ongoing development and use in which no single entity has effective monopoly control and requires governance structures around a particular distribution or version of the source code (often called a “Distro” in the Open Source world) so that users can have confidence in the safety, security and quality of that Distro including changes and new contributions made to it by the community – Something that is particularly important in context of health and care software.

Stakeholders include:

  • Those that gain financial value from the existence of the Distro – These might be organisation that use the software or the data it generates (like the NHS, researchers and other health and care commissioners and providers) or organisation that sell services to community made possible by the existence of the Distro (including developers, implementers and maintainers) – It is this group of stakeholders who will be the main source of resources to sustain the development and use of the Distro.
  • End users of systems and those who they seek to serve using the software – It is only by involving end users in an agile user-centred design processes that we can build systems that truly unlock the potential of digital technology – Too often the poor design of tools that people are expected to use is a barrier to doing what’s important. In the context of health and care this means involving frontline clinicians, other health and care professionals, managers and administrators – Their needs are often not well understood by policy makers, senior management and IT departments. Most important of all it means working with patients, service users and their informal careers who are too often the victims of poor service resulting from poor design.
  • Academics and technologists who are able to educate the community with regard to those things they know that might enable the community to improve the Distro and/or the effectiveness of its deployment and help the community critically evaluate it use. This might include ensuring that the community is aware of existing and emerging standards, technology and theoretical frameworks of potential value to the community.
  • Policy makers and senior management who need to understand how the Distro can be deployed to improve services and how such use can both shape and support policy.
  • A vibrant market of individuals and organisations who can provide a range of services to support the development, implementation and use of the system as well as relevant add-on products and services. This market should ideally include individual consultants and contractors, SMEs, social enterprises and large global system integrators. It is vital for the health of the community that there is a competitive market in the products and service needed to improve, deploy and exploit the Distro so that user organisation have a choice of who they contract to provide these service.

The Distro needs a custodian, owned and controlled by the community, who will promote nurture and protect the Distro, provide mechanisms to encourage, manage and quality control changes and improvements to it by the community and commission the delivery of enhancements and other services on behalf of the community.  The custodian needs to set and maintain source code and documentation standards and ensure that documentation is available of a sufficient quality to enable a competent developer without prior knowledge of the product to work with the source code and ideally should be able to provide additional guidance and training to enable those who want to work with the software to be able to so as quickly as possible.

A key aim of the custodian is to try and keep the community together on a common Distro. Too often, short-term pragmatism results in changes to source code somewhere that breaks something somewhere else creating a “fork”in the source code tree. While some limiting forking might be healthy if too many users “fork off” the benefits of Open Source are diminished. Avoiding this requires that the custodian provides support for people to make changes to meet their needs without breaking things important to others, in a rapid agile and responsive way. However, making changes in this way will still be slower, in terms of achieving immediate local priorities, but doing so has damaging medium and long-term sequelae. The custodian has to close the gap between the two approaches and educate developers about  the benefits of doing things for longer term benefit.

Additionally , the custodian has a role in providing assurance and warranties to users that deployments based on the Distro support by organisations accredited by the custodian will be safe and secure to deploy in live health and care settings.

Enabling the custodian to deliver its’ responsibilities will require that it is funded by the community to do so. To facilitate this the custodian is probably best constituted as not-for-profit Community Interest Company (CIC) whose control is vested in the community such that no single class of stakeholder can determine its’ actions.

If we can build effective communities then the wider introductions of Open Source software in the NHS as part of a mixed economy alongside proprietary products will help drive better value and front line user engagement and commitment  across the board, just dumping source code under an open source licence (or worse some bowdlerised licence) will not.

 

 

 

Design, Digital Health Ecosystem, NHS Policy, Ramblings

Food England?

Leave a comment

Listening to the Nuffield Health Policy Summit http://www.nuffieldtrust.org.uk/live/health-policy-summit-2014 Lots of interesting stuff from Phil Collins of the Times. Talking about “command and control”, “integration and competition” and “patient centred service design”

Perhaps it would help to think of the NHS as a supply chain?

Supply chains are complex adaptive systems which consist of a large number of participants of very variable size and power. There is little or no overall control or management of the system (although individual elements may be and should be tightly managed) and the participant simultaneously compete and corporate.

Left alone supply chains just work, tamper with them and they break in unexpected and unpredictable ways. Consider how the UK food supply system works without “Food England”.

Clinical Safety, Information Governance, Innovation, NHS Policy, Open Source, Privacy and Consent, Ramblings

“Wicked” Barriers to Innovation and Adoption

Leave a comment

Sometimes we just have to JUST DO IT! In the NHS we have too high a tolerance for inaction and too little tolerance for honourable failure.

I’ve just come back from the Healthcare Innovation Expo in Manchester, where there was much talk about the need to encourage innovation. I’m all for that but I think it’s widely agreed that the problem is not innovation but getting innovation that works widely and rapidly adopted.

I’m trying to help NHS England do some innovative things with Open Source and we made lots of progress over the two days at Expo, but I again encountered examples of two of the wicked barrier to innovation and its’ adoption.

I call these things “wicked” because they are both things that are genuinely important and that we must properly consider, but they also represent two of the most effective spanners that those who feel threatened by the innovations of others can throw in the works to slow down adoption.

They are:

  • Clinical safety
  • Evidence

Don’t get me wrong clinical safety is important and I support the application of standards like ISB0129, which I think is actually well put together and does a good job of encouraging a proportionate approach to clinical safety. What gets my goat though is the way in which clinical safety can be used as excuse for not doing things differently. I wouldn’t mind so much if we knew that current systems and processes were safe, but the fact is that we know they are probably not and I don’t see a good case for slowing down innovation longer than is necessary to be confident that they at least marginally reduce harm. Too often “the Best is the enemy of the Good” and the paradox is that the laudable desire to ensure that responsibility for clinical safety is nailed down and hazards are properly assessed and managed makes it desirable, to some, to stick with current systems and process where the hazards are not well understood or managed, but where nobody’s head is on the block if things go wrong.

Similarly with evidence, we should of course seek evidence to support that what we plan to do will be effective in achieving whatever it is we hope to achieve, but again bleating “where’s the evidence” is a great way to throw a spanner in the work for those who lack a more cogent reason for objecting to a particular course of action. Again, I’m particularly irritated as we sometimes have little evidence that what we currently do works well and more often have evidence that it doesn’t so why not try something different. I’m also concerned when people ask for evidence for things that have not done before. Clearly, if we have not tried something before we can’t have direct evidence of its effect and the more innovative an idea is the more difficult it is to find proxies for direct evidence. Sometimes we just have to rely on professional judgment, faith or plain old gut feel and just do it. We have to take this route if we want innovation and adoption but we also have to recognise that we might be wrong, evaluate what we do and “Fail Fast”. We also have to ensure that we don’t castigate those who try and innovate when they fail, as long as they fail as fast and with as little harm as is reasonable practical; sadly in the NHS we have too high a tolerance for inaction and too little tolerance for honourable failure. Given the challenges we face we know inaction will inevitably lead to catastrophic failure and have encourage people to, at least, do something.

You can read more about barriers to innovation in my blog “What Entrepreneurs Want” over on the HANDI web sitenovation