Farewell to Ruthless Standardisation
“Ruthless Standardisation” was the failed mantra of the NHS National Programme for IT. The Programme is dead, but in some places this view still persist but it is time to consign it to history as something else that “seemed a good idea at the time” In a previous blog I said “Standards are a Barrier to Innovation” and I have taken to repeating this statement which tends to get a strong reaction often supportive but sometimes not. This statement is of course deliberately provocative and those who read beyond the headline will find that I not saying that standards are a bad thing, indeed I believe that applied appropriately that they are probably a good and necessary thing. It seems I’m not alone in these concerns and I was recently introduced to a blog from Prof. Enrico Coiera from last November which asks “Are standards necessary?” This is essential reading and provides a more erudite and evidenced perspective than my own. I’ve also been much influenced by discussion with my friend and colleague Dr Ian McNicoll who has spent more time in the standards swamp than me and who introduced me to the idea of a “Distributed Doocracies” as a new approach to developing clinical content standards. I conclude that to make progress we have to.
- End (or at least ignore) the religious wars amongst the Standards Tribes for the one true way and adopt a more polytheistic and pragmatic approach
- Learn from the processes that have allowed us to create the Internet, the Web and Wikipedia and apply them to health informatics.
- Apply the “Four Freedoms” of open source to the standards making process to create a “Shared Commons” of clinical content.
- Promote new ways of creating the accommodations we need to deliver interoperable digital health systems, based on distributed doocracies, which are accessible to and driven by frontline clinicians, supported by techies and informaticians.
In this blog I want to talk about the process of standards development and how I’m led to the conclusions above. I’ve become increasingly convinced that the process as currently applied to digital health and care is not fit for purpose and it is this rather the process that standards themselves that are a barrier to innovation. There are two problems with the process. Firstly, it’s too slow, changes are not possible in a responsive way forcing people to “do their own thing” to meet operational needs. Secondly, it opaque and inaccessible both to clinicians and innovative SMEs. Before considering these two points I want to differentiate between the technical and contents aspects of standards. The technical aspects deal with the format of data and might use representations like CSV, XML, JSON, etc. These are generally not a problem. If the content is equivalent it is usually easy to write mappings or transformations between them. The content aspects are where the problems lie, what do we mean by a blood pressure, an allergy, a diagnosis, a prescription? What elements make up these things and how do we represent them in ways that are unambiguous and computable. The domain expertise to answer these questions lies with experts in the clinical domain to which these concepts relate i.e. clinicians. Specialist clinical informaticians can support this process but even if they are clinically qualified they are rarely the domain expert. If you want expert input on, say, visual acuity you need to ask an ophthalmologist specialising in visual acuity. The problem is that the current process for standard settings and many of the tools that support it are not likely to engage the required domain expertise as those best able to provide it are generally more interested in clinical practice than learning the technicalities of things like UML, HL7 or RDF or sitting in interminable standards meetings waiting for the few minutes where they can make a valuable contribution. So the first problem is that we have to make the process accessible to frontline clinical experts. This means managing the process so they can engage only on those matters of specific interests to them and supporting them by tools that feel intuitive to a clinician with minimal training in their use. The second problem is that we have to make the process agile so that required enhancements to content standards can be made available in hours-days, rather than months-years. This requires two things: A move from top down control and a shift to a continuous process (rather than one based on review and publication cycles) this is analogous to what is known as continuous integration in the software development world. The third problem is that we have to make the process open, too many standards making bodies operate behind closed doors or raise barriers to participation by way of the cost of participating in the process or obtaining outputs. It is a scandal that formal standards from the likes of BSI, CEN and ISO which are funded by taxpayers are not freely available on the web and I was appalled to be asked to sign a NDA by BSI before joining a committee to develop standards for apps (I declined). The fact that it costs £232 to buy a copy of CEN 13606 from BSI is hardly going to encourage a microenterprise to find out if it might to be helpful to them (even if they can get it at half price by joining BSI for £189 pa at the microenterprise rate) – Standards development needs to be like open source software and licensed in a similar way to grant the “Four Freedoms” So how do we address these issues? Well the answer as ever is to follow the Internet which provides us with two great open, distributed models for reaching accommodations. The first is the way core Internet standards are developed, which is by way of RFCs. The clue to the approach is in the name “Request for Comment” Internet standards are those things, which for the moment, nobody is moved to make any comments about. RFCs cover “many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes, opinions, and sometimes humor(sic)” – The last is essential when trying to set standards. – Read the page my link points to it’s short and stuffed with wisdom. The second is the Wikipeadia editorial model and it’s a simplified version of this we need for clinical content and this is illustrated in the diagram below created by Dr Ian McNicoll.
This specifically relates to proposals for the creation and curation of clinical content models in the form of OpenEHR archetypes, but is equally applicable to any similar process. It has a number of key features like from AmazeLaw whic is built for lawyers. Archetype development is an open process that anyone minded to can watch and/or participate in.
- Archetypes can be used at any point a user considers them stable enough and fit for their purposes, but become standard at the point of “publication” at which point they become subject to strict version control and configuration management.
- The work and decision making is delegated to Editors working with a small number of reviewers and is fine grained operating at the level of a single archetype or small group of related archetypes. While anyone who wants to participate can at this level there would typically be a small number of active participants (<10 often fewer) who have specific expertise and interest
- Publication is a decision of the Editor who operates as a “benign dictator” subject only to the risk of a coup if they fail to satisfy the needs of users.
- There can be competing archetypes and archetypes can fork if users feel a need, but the aim of the Editor should be to create an “accommodation” that allows a rough consensus (the maximal data set + restraining template approach of OpenEHR makes this relatively easy to achieve)
- There is some loose overarching governance to enforce general principles and deal with dictators who cease to be benevolent, but there is no central body controlling the publication and approval of archetypes.
- Professional bodies and standards organisations are encouraged to provide guidance, nominate appropriately expert and interested individuals as editors and reviewers and to provide formal secondary endorsement of published archetypes but are not required to approve publication.
- There is a high level of vendor engagement, as these are the people that need to make archetypes work in the real world.
- Archetype and project Editors are supported and coordinated by a team of expert informaticains acting as Clinical Knowledge Administrators.
This general approach is proven as successful both in the very diverse world of Wikipeadia and the specific world of OpenEHR. Making this work requires the existence of an engaged community, appropriate governance and supporting tools. Here again OpenEHR provides a great model. Available tools like the Clinical Knowledge Manager are easy for clinicians to learn and use and provide an online community that can engage global clinical expertise and allow debate and discussion to support archetype development. The online approach removes the need for costly and time-consuming meetings and allows individuals just to engage in those things in which they have a specific interest. The OpenEHR tools as provide the facilities that the Techies need in a way accessible to them without the need for detailed clinical knowledge, provides the technical artefacts they need and supports good software engineering practice in relation to version control, configuration management and backward compatibility. So we know what needs to be done and have some proven examples of how to do it. So lets just do it.