Category Archives: Software Development

The Future of Applications

I was recently passed a link to an interesting paper from Accenture “The Future of Applications – Three Strategies for the High-velocity, Software-driven Business”. This paper is directed at a general business audience, but has much of relevance for the digital health world and in particular resonates with the points I was trying to make in my recent blog  “Would you like to build Health and Care Software 100 times Faster?”

Picking up a few key points from Accenture:

“The fact is, many companies are trying to compete in the world of social, mobile, analytics and cloud with applications that were designed for another era. Monolithic applications are often built from the ground up— slow to implement and slow to change. “

Very true of the systems in health and care, not just the big megasuites, but most of the applications in use today.

“What’s needed is a new way to build software—faster, flexible and more liquid—with reusable components that allow for rapid assembly of applications in support of dynamic business needs. This approach requires modular architectures……”

In the context of health and care this sounds very much like openEHR.

The other two other key points the paper makes: The need to build intelligent applications and to build and nurture  [open] ecosystems also seem to provide further support for the work I’ve been in with colleagues in NHS Englands Code4Health Programme.

There is much more in the Accenture paper which is well worth reading and thinking about how we can apply its recommendations in the context of health and care. You will find the paper on the Accenture web site here.

Would you like to build health and care software 100 times faster?

I’ve written before about openEHR and how I think its time has come. I been talking to lots of people about openEHR and it’s clear it takes a while to really understand its power – It took me 15 years. In this blog I try and summarise what I think makes it different and special. If you are new to openEHR I suggest you read this first and then go to my previous blog and  for more detail.

OpenEHR is not a piece of software it’s an open specification from which software can be built. It has it roots as a way of creating electronic health records, but can be used to build records across the whole of the health and social care domain.

Its key benefits are:

  • It enables those designing systems to work at the information level rather than at the level of a particular technology separating
    • “content” – the domain of the clinician or social care professional
    • from “technical infrastructure” – the domain of the software engineer
  • enabling both to concentrate on their own domain without needing to worry about the complexity of the other.
  • It’s independent of any particular vendor or technology – There are multiple implementations from a number of vendors, built on various technologies, including open source options.
  • There is a vibrant global openEHR clinical community creating archetypes (the building blocks of openEHR), which are generally “open source” and can thus be freely shared, used and adapted. See Wooland’s  Cat for more on this 
  • There is an active vendor community which supports the clinical content development and a number of examples of implementation at scale, mainly outside the UK where it was invented!
  • The specifications are amazingly rich. There is very little than its creators have not covered including:
    • Interoperability, openEHR makes it easier to achieve interoperability than not.
    • Multilingual support and language independence
    • Federated multi-vendor implementations, with cross vendor querying
    • Complex access control capabilities
    • Intermittently connected devices
    • Versioning and backward comparability
    • Cybersecurity
    • Privacy protection and consent management
    • Terminology bindings

However, the most remarkable and powerful feature of openEHR is its ability to support new requirements with minimal changes to systems. To support a new requirement it is simply necessary to create new archetypes. These will be immediately deployable, storable and queryable; will not require any database schema changes, won’t affect parts of the system not connected with the new requirement and won’t break anything – This means that new requirements can often be deployed in hours rather than months. Let me explain further:

New requirements generally mean new information has to be collected and stored. Anybody, who has worked at the database level will know how problematic this can be. You have to modify the database schema, modify existing tables, maybe create new ones and then migrate data from the old schema to the new. In a database of any complexity it’s easy to break things and can require the rework of lots of software unconnected with the new requirement. While modern databases have tools that can help developers avoid schema changes like the plague and when they do consider them, the rework and testing required means that changes will be expensive and slow if they happen at all often leaving people with no recourse than another  Feral System

Supporting new models of care means being able to meet new requirements 10 – 100 faster, by utilising openEHR’s ability to incorporate changes simply by creating new archetypes, the large preexisting set of open source archetypes, its openAPIs we can now achieve this.

If you not looked an openEHR already then I suggest you do and if you loked at it a while ago I suggest you look again.

This video produced by Dr Wai Keong Wong (@wai2k )provides a useful introduction to openEHR

Feral Systems (or I’ve got a great big Access database)

In my work, both within NHS England and as a judge in the EHI awards I have come across a number of promising bits of home grown software development in NHS organisations. Also as I talk to people in the NHS find that as well as these publically acknowledged systems that there are many others that are often a unknown beyond the project or service that use them and typically invisible to IT departments. On Director of ITC of a teaching hospital of my acquaintance who went looking and found many hundred such systems and was sure he hadn’t found them all and termed them “feral systems” comparing them to the feral cats that also infested his hospital.

The hundreds of “Feral Systems” in an average large hospital represent a goldmine of knowledge and innovation that could be harness in the design of digital systems that really work, but as they are today they also create a massive technical debt and create safety, governance and reputational risks for the organisation in which they are used.

We have to enable these developments to continue without too much interference but we need to make it as easy to do this in ways that are as  safe, scalable, interoperable and sharable as it is currently with those tools and approaches that are not. 

There are two things I’m involved in that I think can help, The first is the NHS England Open Source Programme and the second is HANDI and in particular HANDI  HOPD

Typically these developments have been by people who are amateur software developers with other day jobs in the NHS (clinical, management or IT) who are not professional trained in Computer Science or Software Engineering. They have produced these, typically small programmes or apps, because they are frustrated by the ability of their enterprise systems to meet their specific needs in a timely manner and because they understand what’s needed and have the skills and the modest resources needed to just do it.

In general these programmes are written with no intention that they should ever be used anywhere other than in the author’s own immediate environment or that anyone other than the original development team (often a team of one) will ever need or want to delve into the source code to maintain or develop the software. They are produced using whatever tools are to hand using whatever techniques the author is familiar with. Historically this was often Microsoft Access or Excel with some VBA, increasingly it is with some easy to use web or app development stack. PHP, Javascript, Python, Ruby etc. This work is typically done in blissful ignorance good software engineer practice and governance requirements, but in the intended context of use this matters hardly at all.

These developments are often great, because the author is very close to the user (probably they are one of the users) knows exactly what’s needed in their environment and is on hand to rapidly deal with bugs, support issues and enhancement requests.

This approach has much positive aspect but raises many serious issues.

1)      Stuff that could be really useful in other places lies undiscovered and in any case is not actually in a fit state to be easily used and developed elsewhere if it is discovered. (see also my piece “Making the most of NHS IPR” )

2)      There are multiple people doing similar things who would achieve even more if they knew about each other and had a way of working effectively together. Judging the EHI awards I saw lots of examples where I knew of other similar work of which the entrants were unaware and even multiple entrants independently doing similar things unaware of the others.

3)      These systems tend to grow, because their developer is so close to and responsive to user needs, such that systems originally intended to do just a few limited things becomes the mainstay of the IT supporting a unit or service and it all falls apart when the original author moves on.

4)      These systems are typically written to do just what’s seen as essential and pay scant attention to security, information governance and interoperability issues. This is fine initially but is a major source of future problems and exposes the organisation to significant risk and the response of senior management and IT Departments is often to try and shut these things down on the rare occasions they find about them.

The last thing I want to do is inhibit this sort of development as it is a massive potential source of innovation and a great way to get frontline staff engaged in the development of digital systems but I do want to make it easier for them to create systems that are safe and interoperable and help make any innovations that have value available to the wider community as a sustainable product. I’m also keen to help ensure that when the problem has already been solved or partially solved elsewhere that people know this and that when multiple people are working on the same problem that they are encouraged to think about teaming up.

There are two things I’m involve in that I think can help, The first is the NHS England Open Source Programme and the second is HANDI and in particular HANDI  HOPD

Open source is a natural way do collaborative projects and ensure good work is available to others. In many case developers have no desire to commercially exploit their IPR, but there are also lots of ways to build successful commercial enterprises around open source products. If you want help and advice on creating open source software or taking an existing product where you or your organisation own the IPR email the team and I or one of my colleagues will be very happy to help you whatever your ambitions are for your product (see also see my blog piece “What makes an Open Source community?” 

HANDI-HOPD is the HANDI Open System Demonstrator and will give you access to enterprise quality components, tools and knowledge sources to help you build prototype apps in a way that will address many of the interoperability, orchestration and governance challenges that are otherwise really hard to deal with, with minimal effort. It can also provide free compute resources in the Cloud with free access to knowledge sources and test data in a realistic simulated environment where you can create and refine your app and engage with a community of other likeminded people. HANDI-HOPD is vendor neutral and agnostic as to whether your business model is proprietary or open source. It’s strictly for experimentation and non-operation use with test (fictitious) data but because it’s based on open standards apps developed on the HOPD should be easily transportable to one of a number of production environments (offered by our partners and others) for operational use or your own live environment if you support the same open standards.

Making software functional, desirable, safe, robust, scalable, maintainable, interoperable and fit for collaborative development requires skills and knowledge that most gifted amateur developers don’t have (and in many cases don’t have the time or inclination to acquire). Indeed, many IT professionals in the NHS, whose expertise lies in implementation and support or more traditional development approaches, and many of the commercial organisations currently service the NHS don’t have these skills either. However, there are a few organisations working with the NHS and more outside who do know how to meet these challenges (in particular some of the successful Enterprise Open Source companies offering more generic and commodity products) and  some specialist SME currently servicing open source projects in the NHS. It is critical that we identify these organisations, find ways to get them effectively engage in the NHS and increase the capacity and capability of those that are already engaged. The NHS England Open Source Team are keen to hear from organisations that think they have the skills required.

However, as well as NHS England Open Source and HANDI there are many organisations who can provide advice on basic things you can do to help ensure your software has these desirable characteristics and for those who want to find a commercial partner who can help you address these issues, help you deploy, support and develop your own or others open source solutions we can also help – We are also interested in hearing from both commercial and social enterprises that are able to provide such services or want to better understand the opportunity to do so – Please email either or

HANDI-HOPD provides a safe simulated environment to easily develop the sort of tools that typically get designed as feral systems, but the standards and approaches used make them safe, scalable, interoperable and sharable with minimal overhead. HANDI-HOPD itself does not provide a hosted environment for operational deployment, but actually uses the technologies that can  (Elastic Cloud Computing, Software and Platform as a Service (SaaS and PaaS) and Docker Software Containerisation) and we know other will mirror these with Internet and N3 Hosted Operational service. This creates the opportunity to create a simple app in a few hours on the HOPD and deploy it at scale in a few minutes on a laptop, data-centre, private or public cloud and it many case for small scale use this first tier of service will be free to us.

Lets herd those feral cats!



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:

  • 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 ProformaArden 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 and OpenClinical 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.



What makes an Open Source community?

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.




A Pilot Site for NHS VistA – Please?

Moving the open source agenda require that NHS Trust submit Expressions of Interests (EoI) for open source projects under NHS England’s £260 million Technology Fund by the deadline on 31th July.

Over recent weeks I’ve been persuaded that there would be real value for the patients, the NHS and the UK health informatics industry in the creation of a UK version of an open-source EHR, and VistA would be a good place to start.

This represents something of a volte-face for me and I’ve spent the weekend breakfasting on my diminishing collection of headgear.  The reason for this change are explained, at length, elsewhere on this blog and I summarise them briefly below, but first I want to cut to the main reason for this piece – Identifying some NHS Trust or Trusts willing to make an Expression of Interest (EoI)  by the deadline on 31th July.

NHS England’s publicity around the fund have made it very clear that they would welcome a bids based on open-source in general and VistA in particular, but they rightly understand that the strength of a VistA development lies in its’ ability to drive clinical engagement from the grassroots – as it has demonstrated in a number of US and overseas implementations and it’s willingness to drive this forward will depend on Trusts coming forward NOW with appropriate EoI’s.

My previous negative position on VistA was based on a profound disagreement with the position of the Campaign for  NHS Vista which envisages VistA as a single EHR system for the NHS.  Simply, in my view,  a “Better way to do the wrong thing” and a lack of understanding about the direction of travel of the global VistA community, who I now discover are working towards a vision of an open digital care ecosystem which aligns with mine and that of many others in both the open-source and established vendor community and who have a strong appetite to work with others to create this ecosystem.

I suspect than many in NHS Trusts still have the misconceptions that I  recently harboured and I would not wish these to result in a failure of Trust to seize the opportunity offered by the Tech Fund.

Trusts who engage with this vision for NHS VistA do not need to buy-in to the vision of VistA as a single system and will not need to abandon systems that are already working successfully for them and in their broader health and care communities.  Rather, in the short-term, they can look to the rapid provision of some key functionality based on well proven clinically developed software and the immediate availability  open interfaces (SMART , MWDS and  OpenMWDS) that will enable developers of all sorts to connect the latest innovative apps and encourage the development of many more using the latest technology. In the longer term we expect to see VistA evolving into open digital care ecosystem alongside other open-standards and open-sourced based initiatives already making progress in the NHS. NHS VistA, therefore, is not a single rigid system imposed on Trusts but a powerful and flexible system; a digital core that enables each Trust to optimally configure its healthcare IT platform to meet its individual needs.

Trusts who adopt VistA can also expect to have access to the support of a range of commercial service providers who will be able to provide a “service wrap” and warranties around the implementation and ongoing support of VistA.

The key issue today is for Trusts to make an EoI. This urgent first step is not onerous and you don’t need fully formed plans, but the recognition that there’s a better way to achieve the goals we all share. The process that follows an EoI  is such that there will be an opportunity to develop the detail, obtain support from both the open source community as well as NHS England and link with others who express collinear interests. An EoI, is just that and a Trust would be free to decide not to proceed if it subsequently discovers it is not appropriate for their local use or needs.

What’s critical is making the EoI so your Trust is in the game and eligible for support from the Technology Fund. I and others in the VistA community stand ready to provide pro bono help to Trusts in submitting an EoI.

At this stage NHS VistA is likely to most attractive to Trusts who are at the early stage of their digital journey and want something that will help them accelerate their progress. Trust who already have a committed path to the “Clinical 5″ ( PAS, order communications, coded letters, scheduling and e-prescribing) beyond PAS are not likely to benefit from what VistA can immediately offer.  The expectation is that initial versions of NHS VistA would sit on top of existing a Trusts existing PAS (avoiding the disruption, risk to income and many of the localisation issues that PAS replacement creates) interface with the existing LIMS (Lab systems),  RIS/PACS (imaging) and Pharmacy systems that nearly all trust already have (although VistA can offer these application if required).

My thoughts are that the focus should be on delivering enough VistA functionality to support ePrescribing and nursing observations the two application most likely to create “Safer Hospitals and Safer Wards”, for individual Trusts, the public,  patients and frontline staff to tell us where the priorities lie.  Again, the beautiful thing about an open source approach is that the development community can respond quickly with examples and reference implementations.  We know we can win before the heavy investments are made.

Finally,  just to summarise why I think this is a golden opportunity.

  • VistA and open-source in general are a market disruptor that will help drive value and openness. We can simultaneously improving health delivery and care and creating commercial opportunities for the UK digital health sector.
  • Open-source naturally encourages clinical engagement and agile usercentered design. VistA already has influential champions in the UK clinical community (both at a very senior level and amongst future clinical leaders) which will help achieve the clinical engagement that has so far eluded most outside of primary care.
  • VistA is the most functionally rich and best proven  of any of the currently available open-source EHRs.
  • The VistA community shares a common vision with many in industry and the NHS to create an open digital health ecosystem. Working together will enable us more easily to tap into the massive investment the US recently made and to the intellectual resources of the global VistA community. The successful creation of such an ecosystem would be good news for the NHS,. UK plc and the vendor community. I have many positive discussions in the last few days that make me think there is a real appetite for this both sides of the pond and substantial work towards this is already underway.

If you are working in a Trust that you think might benefit from NHS VistA do consider making an EoI to secure your place in the game get in touch if you want to discuss your options or need some free consultancy to help complete the EoI email me and either I or a another volunteer from the community will be in touch to try and help.


Time for Zero-Tolerance

I heard the blindingly obvious statement at the recent Intellect stream of BCS HC2013 Conference in Birmingham that “If you give people software that makes their life easier then adoption is not a problem” Given the clear truth of this statement, I wonder why so many “designing” and procuring NHS IT Systems manage to deliver systems that make life more difficult for frontline staff undermining the quality and service they are able to offer patients.

If we are to get the benefits proposed by those promoting a paperless NHS this has to end and we have to introduce a regime of Zero-Tolerance for systems that make life more difficult for frontline staff.

How do we do this? I have some suggestions:

  • Transparency – Let’s encourage NHS Staff to name and shame systems that make their life more difficult, with reviews and rankings published with maybe some new categories in the EHI Awards for good design and something akin to the “Golden Bull Awards” for the worst examples. Let’s be honest, when the Emperor has no clothes, too often I hear positive comments about NHS IT systems in front of senior management which evaporate when you talk to frontline staff in private. Both sides are to blame here, management can’t be expected to recognise the problem when they are continually told that the “heap of crap” they ask staff to use is “powerful fertiliser” and senior managers need to reward those who bring them bad news.

The work of Psychiatrist Dr Joe McDonald, who is one of the most insightful observers of UK Health IT, with could provide a good start as could ideas from NHS Hack Day about a broader NHS Bugs reporting system.

  • Participation – We need to engage in agile user centred design that allows developers to truly understand and deliver against frontline end-user needs. This means embedding domain experts and end-users and their customers/patients in development teams through the entire product life-cycle (but not for so long that they “go native”) and careful testing of software in real situations with realistic data.

We also need to involve frontline staff in procurement decisions, but not in the tokenistic way that often happens, at the very least they need a veto and ideally it should be they not IT departments or senior management making the final choice.

  • Design – Design, design and more design. Good design ensures form-fit-for-function and should create software that is lusciously desirable, highly functional and which adapts to and remembers users’ needs and preferences. Design needs to be all pervasive. Software code should be finely wrought, poetically beautiful and lovingly commented adhering to clear and consistent coding standards. Workflows should careful designed to provide efficient process flows and be capable of adapting to real-world variation in process. Information presentation should apply the science of information design and excellent graphic design. User-interface design should similarly apply both science and art, to create interfaces that are beautiful, intuitive, accessible and safe. Good design requires input in the development process from technical, creative and human-factors designers. There is a wealth of literature and experience to help system designers if they just go and look for it.
  • End the dataset mentality – Except in exceptional circumstances only the information that is necessary and appropriate to the delivery of optimal care of the individual patient should be collected. This includes information to support both clinical and supporting business processes and the measurement of outcomes, but not data for purposes which can’t directly contribute to good outcomes for the individual patient. This information varies from patient to patient and encounter to encounter and can’t be useful expressed as a mandatory minimum data set. Data sets are never minimal but inevitably fail to include information that will be critical in some cases. The quality of data collected under duress which has no value to those collecting it, will be poor as users will guess it or make it up if it is not immediately to hand making it worse than useless for the purposes for which it was included in the dataset in the first place. Users have a natural investment in quality of data that affects the ease with which they can do a good job and typically such data is information rich and secondary uses can in general be better satisfied by using only such data. However, in exceptional cases where there is a strong downstream benefit from the collection of additional data this need must be “sold” to users who should also be provided with regular feedback that demonstrates that efforts are worthwhile.

While there is massive potential in using data collected routinely for secondary purposes, those doing so must always be aware of the risks of using data for purposes other than those for which it was collected. If those entering data don’t know about the other ways data they are entering will be used they can’t help ensure that it is also fit for these purposes. I would not go as far as the eponymous Dutch health informatician who coined Van de Lei’s law, “Data should not be used other than for the purposes for which it was collected”. However, it is important to understand the many data quality issues associated with health data  and the risks of using data beyond the “Hawking Horizon

One way of mitigating these risks is to inform those who collect data how it will be used and to feed back to them the results of its use. This will not only encourage them to consider how they can make fit for these secondary purposes, but will also mean you are more likely to be alerted when you draw conclusion that those close to the data know they do not support.

  • Finally of course Zero Tolerance – Zero tolerance for systems that make life harder for frontline staff, zero tolerance for those who fail to involve frontline users in design and procurement decisions and zero tolerance for the dataset mentality and most of all zero tolerance for poor design.