Category Archives: Design

It’s not about Open Source

Readers of the blog will know that I am an enthusiastic supporter of open platforms and was pleased to be able to contribute to the recent publication of “Defining an an Open Platform” by the Apperta Foundation. Assiduous readers will have noticed that the eight principles in this document are a evolution of those that first appeared here 18 months ago in 2016.

I had thought that “Defining an Open Platform” makes it clear that open platforms are agnostic with regard to software licensing and IPR. However, I’m receiving comments where people continue to conflate open platforms and open source.So to be clear:

Open platforms are about open standards they are not about and do not require open source software.

An open platform can be created without a single line of open source code or indeed without a single line of proprietary code if that’s what those building it want. While, in practice neither of those extreme choices is either likely or desirable both are possible.

Open platforms are about standards and while these standards will often be, but are not always,  “open source” the software that implements them need not be.

The core principle  of an open platform is that access to data and services on the platform is via a set of open APIs that accept and return data in an open, shareable and computable format. Definitions of these APIs need to be open so that any willing party can freely implement them. As long as all participants in a open platform ecosystem conform to these APIs both applications and data are portable and vendor lock-in is no more, irrespective of whether components and applications are open source or proprietary.

Today, most large scale implementations of open platforms (e.g. that in Moscow) consist primarily of proprietary applications running on a proprietary platform – Moscow uses the Marand openEHR Clinical Data Repository and the Forcare implementation of IHE-XDS, both are proprietary implementations of open standards. The key difference is that Moscow can, and indeed has, switch out these proprietary products and replace them with an alternatives if a vendor fails to deliver performance or value.

There are of course open source alternatives to these proprietary products and the existence of these is important in ensuring proprietary vendors stay true to the standards. It’s also true that proprietary implementations often contain open source components (many of which come from the proprietary vendors themselves who understands the wisdom of sharing and open sourcing certain components.)

My expectation is that successful open platform ecosystems will be a mixed economy of open source and proprietary components and applications. I think it more likely that economically sustainable open source models will emerge in relation to platform infrastructural components than for applications However, there is nothing in the definition in “Defining and Open Platform” that mandates an open source.

Open Digital Platform Challenge Fund

Many  will be aware of the proposal that Tony Shannon and I have been promoting to persuade the decking to allocate 1% of the money they plan to spend on an “Open Digital  Platform Challenge Fund” to stimulate the development of an open digital ecosystem based on open standards.

We have had a positive response so far and will shortly be presenting out plans to the NHS CIO and CCIO. We want to be able tell them that there are enough people and projects committed to an Open Digital Ecosystems to make good use of the money we are asking for and give then a good idea of the projects that might come forward if they take up our suggestion.

To this end we have been asking people for expressions of interest via this link . We are looking for expressions of interests from people who support the approach and the specific standards laid out in our document. In not onerous to fill in the form which does not imply a fixed commitment just a general indication of interest.

If you have not already done so I’d urge you to let us have your ideas

Full details below

 

Globe (1)

Untitled drawing

1) Executive Summary

An NHS open digital platform challenge fund will stimulate the development of an open platform in the NHS. Open digital platforms are independently forecast by McKinsey and Co to reduce the delivery of care costs across the NHS by 11%. They will support widescale entry and growth of suppliers into the market, injecting innovation at all levels of service delivery to support improved care outcomes for our patients.

In the context of an NHS struggling through a perpetual winter, open digital platforms present a realisable opportunity to massively stimulate new ways of working, process innovation and a new digital health and care market, based around services. This is independently forecast by McKinsey and Co who predict a positive financial impact in excess of 11% across the whole of health and social care.

By creating an open digital platform and a move towards a services market, the NHS opens up the market to innovative commercial and social enterprises who presently have great difficulty breaching the significant barriers to entry. At the same time it creates an environment where health and care professionals can readily create, contribute and share new digital tools to support transformational new models of care, radically improving the care outcomes of our patients and building a sustainable care ecosystem that is fit for the future.

There is little disagreement that platforms represent the future for digital health. Rather the present debate is about who should own them, and how and when they will emerge. The “status quo” retains the closed platform frameworks, introducing open interfaces for exchange of information. This provides a short term stimulus, supporting improvements in patient care and operational efficiencies. However in the longer term, by seeking to control the rules of engagement and restricting the mobility of data, the retention of closed platform frameworks will stifle competition, impede innovation, and continue to drive-up costs.

Open digital platforms are a radical alternative that overcome the serious shortcomings of closed platforms.
They present the most assured approach to achieve consistent, long term and affordable growth in innovation-led service transformation across the complexities of health and social care. They will enable the full competitive aspects of market supply to be exploited, with associated benefits of the injection of innovations on a massive scale. For this reason, open digital platforms are manifestly in the interest of both the NHS and its patients.

The purpose of the proposed Open Digital Platform Challenge Fund is to stimulate the development of an open platform ecosystem through kick-starting the creation of open platforms, building on work already well underway, and the development of exemplar applications to exploit them.

We propose that the fund is created through diverting 1% of the investment each year in NHS digitisation into the challenge fund. This fund would be made available via an annual open competition in the form of relatively small awards to innovative organisations (public, private and third sector). The selection of projects will be balanced to stimulate and develop an open ecosystem of shareable and reusable applications to service across health and social care. We are inviting submissions of expressions of interest into this Open Platform Fund. In so doing, we will gauge the wider interest in this Open Platform fund proposal to then quickly bring these related responses to the attention of both NHS Digital and NHS England by the end of February 2017 and seek the related funding.

2) Current Situation

To introduce this bid for funding we need to review the current situation with important context on the bigger picture issues that are at play. We need to acknowledge and understand the current mediocre state of health IT, as an immature and problematic market with mixed/relatively poor value for money and results seen from billions of £ and $ of investment from the UK to the US and elsewhere.

We also need to recognise the related digitisation of the NHS has been over promised and under delivered for some considerable time. Compounding this people/process/technology problem is the ongoing and perpetual winter faced by the frontline in the NHS that is in the news.

We restate the need to continue the critical push towards more personalised, integrated care at home and in the community to meet the 2020 vision. This clearly requires an underpinning patient centred infrastructure to do so. Last February Jeremy Hunt announced £4.2 billion for NHS Health IT. In the last 18-24 months while there have been plans in the form of Integration Pioneers, Vanguards, Local Digital Roadmaps (LDRs), Sustainability Transformation Plans (STPs), there has been little/no allocated funding to date to make these happen.

In Autumn 2016 we were able to read and digest the latest review of the NHS IT, authored by US physician Dr Bob Wachter. Dr Wachter built his reputation as establishing the hospitalist as a medical specialty in the US. In recent years he has become a fearless and honest critic of the state of Healthcare IT in the US, with his book “Digital Doctor : Hope, Hype & Harm at the Dawn of Medicines Computer Age” (2015) exposing the real mediocre state of the health IT market in the US. The book and related opinion pieces on the state of health IT industry he explains some of the real problems with the current supplier market is clear. In a New York Times Op Ed piece on “Why Health Care Tech Is Still So Bad” (2015) he highlights that

“In today’s digital era, a modern hospital deemed the absence of an electronic medical record system to be a premier selling point…That hospital is not alone. A 2013 RAND survey of physicians found mixed reactions to electronic health record systems, including widespread dissatisfaction. Many respondents cited poor usability, time-consuming data entry, needless alerts and poor work flows”.

However in the NHS, Dr Wachter’s recent review led to funding being provided to “digital exemplars” all of which are a small group of hospital trusts in the NHS who will invest in those very same health IT monoliths. While understandable as a means to “do something”, rather than nothing, given the state of affairs is understood, it is sadly limited in its thinking and perpetuates the usual tactics that we have seen in the NHS IT for years, i.e. investing in the same 20th Century monoliths of old. We know that doing the same thing over and over and expecting different results is futile.

Simply put, if a small elite are getting the focus of funding for investments in 20th Century health IT monoliths over the next years then inequity within the system will increase, while original ideas in the sector to bring care into the modern era will decrease.

We have been left asking where has the requirement for integrated person centred care gone, that is ingrained in the other plans that NHS and local authorities have been working towards with STPs and LDRs etc.

What is sorely missing is the open patient centric platform that Dr Wachter looks forward to and that healthcare awaits. As this is a glaring omission, our paper recommends a focussed investment towards that end as part of a bimodal strategy for NHS IT at this challenging time.

3) What can be done

The changes required are radical, if we are to simply survive, yet alone thrive in the years ahead. We know we need a mix of people + process + technology changes. We know too that the leaders of the NHS understand and value the role of innovation and the crucial role of information technology in achieving same.

3.1) The role of an open platform

For some time now leading thinkers on both sides of the Atlantic, in the NHS and indeed the US has been calling for a move towards a more open platform approach. From within the US market, the establishment of Healthcare Services Platform Consortium aims to address the mediocrity of the “big 6” monoliths and the concurrent problem of the thousands of small unrelated vendors.

“EHRs are becoming commodity platforms. The winner will be the EHR vendor that provides the best platform for innovation – the most open and most extensible platform.”

In this we wholeheartedly agree and concur with our US colleagues.

We believe there is now a compelling case for a small but useful investment in Health IT from the bottom up, to the princely sum of 1% of the planned £4 Billion NHS IT expenditure, aimed deliberately at the integrated, patient centred care vision of Personalised Care 2020, based on the principle that all projects should aim to leverage elements of a common open platform.

4) 1% Case for an open platform

We are making a case for an investment of just 1% of available NHS IT funds to offer a way forward to improve the care of 99% of the population. To do so we have highlighted Dr Watchers analysis and writings to focus on the key problems and issues we seek to address;

Usability

“This principle of user-centered design is part of aviation’s DNA, yet has been woefully lacking in health care software design.

Interoperability

“[There are] Political obstacles to overcome, put in place mostly by vendors and healthcare systems that remain reluctant to share.”

Vision for patient centred care

“In essence, there will no longer be an EHR in the traditional sense, an institution-centric record whose patient portal is a small tip of the hat to patient-centeredness. Rather, there will be one digital patient-centered health record that combines clinician-generated notes and data with patient-generated information and preferences. Its locus of control will be, unambiguously, with the patient.”

So in order to address these real issues and support the national ambitions – usability, interoperability and patient centred care we will use the investment fund available to benefit the broader public. We wish to draw attention to that part of the population who could be better served by the NHS with an improved patient centric platform today. We are also mindful of the need to support;

  • Prevention, Self care and management
  • GP patients
  • Community Care Patients
  • Mental Health Patients
  • Social Care

We look to the leadership provided by the Gov UK Digital Service standard to highlight the principles to underpin the approach we commend.

Pursue User Centred Design & Agile Development

Leverage Open Source & Open Standards

In our work to date (on the Ripple programme and Code4Health platform based on openEHR) we have deliberately pursued these principles to useful effect and recommend them to others who wish to transform healthcare with information technology. We welcome wider scrutiny of our open platform work to date. Our work and the leading work of others (such as the Endeavour Foundation and the INTEROPen CareConnect API Collaborative) in this field, leads us to believe there is now a real, significant appetite for wider and deeper moves towards an open digital platform in the NHS.

By creating an open digital platform ecosystem, the NHS opens up the market to innovative commercial and social enterprises who presently have great difficulty breaching the significant barriers to entry. At the same time it creates an environment where health and care professionals can readily create, contribute and share new digital tools to support innovative new models of care.

We firmly believe that a small but focussed 1% investment can deliver against some of the key challenges in Personalised Health and Care 2020 on an open service oriented platform- to stimulate the public & private sector. An open healthcare platform fit for the 21st Century.

 

5) What is an Open Platform?

Platform based architectures power the internet, with the platform providing the plumbing (the infrastructure, data and services) that applications need, freeing the application developer to focus their efforts on their application without the need to build the infrastructure it needs to operate. Platform approaches speed development, make applications more robust and interoperable and open up a new services market in healthcare IT, where suppliers compete on services and the value they add rather than on the proprietary nature of their software.

An Open Platform is based on freely available open standards, so that anyone can play. As no one party can control the platform – they must collaborate – just like the Internet.

An Open Platform has the following characteristics:

  • Open Standards Based – The implementation should be based on wholly open standards. Any willing party should be able to use these standards without charge to build an independent, compliant instance of the complete platform;
  • Share Common Information Models – There should be a set of common information models in use by all instances of the open platform, independent of any given technical implementation;
  • Support Application Portability – Applications written to run on one platform implementation should be able to run with either trivial or no change on another, independently developed;
  • Federatable – It should be possible to connect any implementation of the open platform to all others independently developed, in a federated structure to allow the sharing of appropriate information and workflows between them;
  • Vendor and Technology Neutral – The standards should not depend on particular technologies or require components from particular vendors. Anyone building an implementation of the open platform may elect to use any available technology and may choose to include or exclude proprietary components;
  • Support Open Data – Data should be exposed as needed (subject to good information governance practice) in an open, shareable, computable format in near to real-time. Implementors may choose to use this format natively in their persistence (storage) layer of the open platform itself or meet this requirement by using mappings and transformations from some other open or proprietary format;
  • Provision of Open APIs – The full specification of the APIs (the means by which applications connected to the platform a should be freely available.

The key to an open platform is the definition of a set of standard interfaces (APIs) to the range of services that might be provided on a platform defined by an open process that all interested parties can participate in (like Internet standards) and that are freely available for all to use.

While it may be encouraged, not all elements in an open platform need to be open sourced. We believe that “infrastructural” components that are generic, reusable and utility like (e.g see Appendix 1 below) should be open sourced, while the overlying applications do not necessarily need to be open sourced, as long as they leverage open data models and offer open APIs.

6) Why an open digital platform?

We have seen across all sectors how platforms are changing the way people lead their everyday lives, from how we communicate and interact, how we travel and where we stay, how we manage our finances to how we shop, to name but a few. Platforms transform. An open digital platform supports:

  • Unconstrained innovation – ideas and ambitions can be shared by people across the office, street or globe
  • Collaboration – clinicians and care professionals inherently want want to share their good work with the rest of the medical world.
  • Alignment to medical science progression, been based on the spread of ideas – health IT can do the same.
  • “Publish or perish” culture of modern medicine demands that healthcare advances are laid open for scrutiny by our peers
  • Grassroots progress – Complex adaptive systems require decentralized control so people can locally innovate. Amendments and improvement can come from the grassroots and bottom up, without the bureaucracy that innovators often face.
  • A shift in the market towards a healthy, commercially sustainable, services oriented marketplace.

7) Open Platform Fund mechanism

The main aim of this Open Platform bid is;

Support the development of services towards Personalised Care 2020 –

support the development of an NHS ecosystem around an open digital platform

To be clear, while we do not currently have any secured funding for an open platform fund, our aim is to gauge interest in this approach and make the evidence based case to NHS Digital.

The fund is intended to support innovative projects that stimulate the creation of an open digital ecosystem and as such aims to support a large number of small projects that are unlikely to be supported as part of “business as usual” investment by health and care organisations. The aims are to driving innovation and transformation that is scalable, shared, flexible and adaptable and ultimately improve health IT for clinicians and improve care outcomes for patients. Winners will show that they will concentrate their efforts on usability, interoperability, patient centred care that meet the vision. To do so we suggest;

7.1) Request for Expressions of Interest

We initially invite the submission of expressions of interest into this Open Platform Fund. In so doing, we wish to gauge the wider interest in this Open Platform fund proposal to then quickly bring these related responses to the attention of both NHS Digital and NHS England by the end of February 2017 and seek the related funding .

Please submit a brief expression of interest (1-3 page) via this Google forms link; https://goo.gl/forms/4SaNvAgkAe2AfLZ82 by Friday 10th February 2017.


We will acknowledge expressions of interest, collate and feedback the results of our findings, pass on related submissions and summary findings to the Apperta Foundation CIC which we believe is ideally placed to independently oversee this process and support the case for funding from NHS Digital and NHS England. The Apperta Foundation is a not-for-profit community interest company supported by NHS England and NHS Digital led by clinicians to promote open systems and standards for digital health and social care.

While the focus of this paper relates to the NHS in England, we know that colleagues in the health systems of Scotland, Wales, Northern Ireland and indeed the Republic of Ireland are facing the same challenges at the frontline, while aware of the same opportunity on offer from an open platform from a 1% investment, particularly if done openly and collaboratively. Therefore we invite related submissions towards an open platform fund on an All Islands basis – which we also will pass onto the Apperta Foundation and the UK and Ireland CCIO Networks.

7.2) Outline of Proposed Allocation

A) Infrastructural component projects

45% of £40m = £18m over 3 years (until 2020)
Open source tooling & infrastructure components – underpinning standards and compliant components that provides services useful in an open ecosystem (See Appendix 1 examples)

B) Personalised Care: Innovation Incubation and Exemplar Implementations

50% of £40m = £20m over 3 years (until 2020)

Open APIs & open data models based projects as showcases of an open platform in action. (e.g. may include open APIs (e.g. INTEROPen CareConnect FHIR based APIs) + open data models +/- open source data repository (e.g. openEHR based). Examples may include Person Held Records/Electronic Patient Record/Integrated Digital Care Record etc. related projects.

C) Oversight/Custodian of process by an independent CIC such as the Apperta Foundation

Along with the CCIO Network and INTEROPen Collaborative to oversee clinical merit and technical connectathons.

5% of £40m = £2m over 3 years (until 2020)

7.3) Eligibility

We suggest that this open platform fund is open to:

  • UK Registered for-profit commercial entities (Companies and LLPs) and
  • UK Registered not-for-profit entities (CICs,Trusts,Companies limited by guarantee and other recognised forms) meeting UK definition of an SME (In the UK a company is defined as being an SME if it meets two out of three criteria: it has a turnover of less than £25m, it has fewer than 250 employees, it has gross assets of less than £12.5m)
  • UK Public Sector bodies (NHS Bodies, Government agencies and local authorities etc.) irrespective of size.

7.4) Match funding obligations

We suggest that applicants will be required to match fund any award from the fund as follows

  • Social or commercial micro-enterprises 1
    No match funding obligation
  • Social or commercial SMEs 2
    Match funding equal to 50% of the award
  • Public sector bodiesMatch funding equal to 100% of the award

 

1 A business with less than 10 employees and (a turnover < £2 million euro or a balance sheet total of less than £2 million euro)
2 A business with less than 250 employees and (a turnover < £50 million euro or a balance sheet total of less than £43 million euro)
These are the current official definitions applying in the UK

8) Criteria

We suggest that an Open Platform fund is open to projects that stimulate and support both the creation and adoption of an open digital ecosystem which meet the definition in section 5 of What is an Open Platform.

While the main aim of all projects will be to improve NHS services towards personalised health and care 2020, the criteria by which the funding from this fund will be allocated will depend on the concurrent creation of value add in the form of;

  • Collaborative – all projects must establish open channels of communication and means of engagement with other parties in the bid at the time of their application (e.g. INTEROPen Ryver etc).
  • Transparent – all projects must be willing and evidence how they will partake in regular clinical and technical reviews. We suggest these should be in the form of bi-annual CCIO Network led review along with INTEROPen led Connectathons with a minimum of 3 out of 6 Connectathons undertaken.
  • Share Ideas, Knowledge, Experience – i.e. willing and able to openly collaborate with others in this initiative (e.g via online community building via tools such as the Open Health Hub, Ryver etc) and partake in Open Data connectathon against INTEROPen FHIR APIs

9) Judging process

Initial Bid and Review Point Principles

We suggest the related submissions into this fund will need to evidence the following as part of their bids and progress at agreed review points:

  • Clinical merit – against the Personalised Health and Care 2020 Vision
  • Technical merit – against the open platform principles outlined
  • Clinical gap / need / demand
  • Clinical Leadership – all projects need nominated clinical lead
  • User Centred Design – include/demonstrate a commitment to open publish UX design
  • Alignment with Agile Development methodologies
  • Business readiness (preparatory work, governance etc in place)
  • Collaboration with other parties in the open platform bid
  • Open Source track record

10) Conclusion

If public monies are for one purpose, they should be for the common good. Our proposal aims to ensure the efficient and effective allocation of public monies to projects that can impact the health and care of millions of citizens in England, supporting local NHS & Social Care organisations in their hour of need, while leveraging Britain’s long held reputation for industry and innovation to enable a new global open platform fit for the 21st Century.

Our proposal for an open platform technology fund aims to offer a means towards the integrated care vision of Personalised Care 2020 that is in the best interests of the NHS. In aligning patient, clinical and care needs with the investment potential offered by open platforms in healthcare, we believe there is a clear win-win on offer here.

At times of challenge and change the natural instinct may be to withdraw from risk or novel action, yet all our instinct is telling us that now is very time to embrace this challenge and seek the opportunity – which is why we are taking a public lead in getting this Open Digital Platform for Healthcare into action and welcome your interest and support in this effort.

Dr Tony Shannon, Ewan Davis
14th January 2017

Questions or Comments?
Email us at 1percentfund@ripple.foundation or tweet @rippleosi with #1percentfund

11) Declarations of Interest

Both of the authors are unashamedly proponents of an open platform in healthcare for some time. One might argue that this constituents a conflict of interest with the proposed approach. Rather we would suggest that our track record in leading the effort to disrupt the market towards an open platform, equates to a confluence of interest with the approach now required.

Dr Tony Shannon, Director – Ripple Foundation C.I.C
Director – Frectal Ltd

Ewan Davis, Director – Synapta C.I.C
Director – Handi Health C.I.C
Director – Open Health Hub C.I.C
Director – Operon Ltd
Director – Woodcote Consulting Ltd

12) Related Links

Ripple Foundation Community Interest Company http://rippleosi.org/
HANDI Health Community Interest Company http://handihealth.org/
Synapta Community Interest Company http://synapta.org.uk/
Endeavour Health Charitable Trust http://www.endeavourhealth.org/
Apperta Foundation Community Interest Company http://www.apperta.org/
INTEROPen Collaborative http://www.interopen.org/
openEHR Foundation http://openehr.org/
HL7 FHIR https://www.hl7.org/fhir

Appendix 1 – Open Platform Infrastructural Component Candidates

The aim here is to initially outline examples/suggestions of a “top 10” set of federated service components in a Service Oriented Architectural world that would be useful to in healthcare. In doing so we welcome further suggestions and related expressions of interest that would aim to provide open source solutions to plug gaps / provide enhancements towards the open digital platform movement. The fund may support the open sourcing of existing components or their development.

Identification & Authorisation
Master Patient Index
User Interface framework
Integration technologies
Clinical Data Repository
Terminology services
Workflow services
Rules engine
Scheduling
Business intelligence
Clinical content collaboration/authoring tools (i.e. openEHR/FHIR etc)

Applications for these open source infrastructure projects are encouraged to state their preferred OS license (weighting towards non copyleft (Apache 2/MIT/BSD) or AGPL licensing)

 



 

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 openEHR.org  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 www.nhsopensource.org and the second is HANDI www.handihealth.org and in particular HANDI www.handihealth.org  HOPD www.handi-hopd.org

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 www.nhsopensource.org and the second is HANDI www.handihealth.org and in particular HANDI www.handihealth.org  HOPD www.handi-hopd.org

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 england.opensource@nhs.net 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 england.opensource@nhs.net or ewan@woodcote-consulting.com

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!

 

Food England?

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”.

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 www.comparethesoftware.co.uk 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.