Category Archives: EHR

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)

 



 

Hiding the Onions – Interop and Open Platforms


With McKinsey telling us that open platforms can save more that 11% of total health care costs, we really have to sweep away the barriers and make it happen. This means moving to an open platform architecure meeting the principles I described in my last blog, which require open standards, open data and open APIs. While most in the vendor community understand this and some actively promote it for others asking them to open up their systems and data and adopt open standards is like asking the turkey’s to help make the stuffing – They might help you find the sage, but they are  going to hide the onions.

Many existing vendors recognise the need to move open standards, open data and open interfaces (APIs) but while some are moving in the right direction, they are not there yet Others drag their feet knowing their current success relies on existing proprietary solutions, customer lock and their pseudo-ownership of customer data. Getting to the tipping point at which open platforms can really take off is going to require new players challenging the status qou and a willingness from the health and care community to help them successfully engage.

The objective is to move towards what is now being described as a Post Modern EHR  this is an architecture that separates data (describing both record content and work-flows) from the applications that create and process it storing it in an open computable format available to all authorised applications.

There are almost certainly no vendors who think interoperability is a bad thing and this is exemplified by the techUK Interoperabity Charter, to which many vendors have signed up . While some have described this as “Motherhood and Apple Pie” in nonetheless contains some specific commitments and there is certainly no justification for any health or care organisation to do business with companies that are not signatories (it is not necessary to be a member of techUK to sign up to the charter). Having  signed the Charter should be a mandatory condition in the PQQ of any IT procurement in Health and Care.

However, vendors commitment to interoperability is not always what it seems and varies between companies and within companies depending on what particular aspect of interoperability at issue.

Most vendors are keen to facilitate interoperability that enhances the range and quality of data in their systems or which adds functionality that they don’t and and have no desire or ability to provide. Vendors are less keen to support interoperability that allows competitors products more easily to replace some or all of their system or which loosens their peusdo-ownership of their customers data – True interoperability does both of these things.

For a system to be fully interoperable the following needs to be true:

  • It should be possible to access all of the data in a system in an open, shareable and computable format, either for an individual patient or any cohort of patients (include all patients). Interfaces should be provided to efficiently access data and where the customer wishes to maintain a near real-time replica of the data in a parallel system.
  • It should be possible to upload to a system any data that could otherwise be manually entered into a system, subject to relevant  user defined work-flows and quality assurance.
  • All business functions that can be executed using a system should be exposed via an appropriate API to allow them to be executed by an authorised external application.

Looking at the API’s than vendors are now providing, few come close to meeting the criteria above. For some systems and to some extent there are real technical barriers to opening up systems and making the data they hold available in an open format, but there can also be pressing commercial reason for not opening up systems and it can be very difficult for customers to determine the extent to which vendors have genuine technical challenges to overcome or are simple looking for excuses to hang on the commercial benefits of limiting what can be done through their APIs.

Customers need to push vendors towards open platform architectures, open standards, open data and open APIs, but need to recognise that this transition cannot be achieved overnight and will require investment by vendors that will ultimately need to be paid for by customers. The trick is to link new business to an evolution to open standards without making unrealistic demands, that in the end you will have to allow vendors to ignore.

Vendors need to appreciate the value of open platforms and the commercial opportunities they bring. The increasing complexity of digital health means that I can foresee only two future options:

  • The first based on open platforms creates opportunities for vendors, particularly innovative SMEs, to enter the market and compete with the larger players on a level playing field and forces vendors to compete on quality, performance, support and value rather than relying on customer lock-in and pseudo-ownership of customer data.
  • The second is increasing market consolidation with a few very large  vendors owning competing proprietary platforms, that allow access to other vendors on their terms with customers locked into their platform

The first option drives innovation and value, creating a competitive market  for both the provision of  federatable open platforms and the applications that run it. The second will result poor value and reduces both the opportunity and motivation for innovation and gives the platform provider too much influence in the way health and care services are provided.

There is a great future for vendors of all sizes in an open platform environment, which by delivering value to the health and care system, will result in market growth delivering greater revenue opportunities for those that can adapt their business models to take advantage – For those that can’t there always the cranberry sauce.

Stuffed Turkey
By No machine-readable author provided. Chensiyuan assumed (based on copyright claims). – No machine-readable source provided. Own work assumed (based on copyright claims)., CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1491125

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

openEHR a Game Changer Comes of Age


I’ve been watching openEHR over more than fifteen years, and although I have always been impressed by its potential to enable us to do things differently, I must admit it has been a slow burn, and take up has been limited, particularly in the UK where it was invented. However, due to some recent developments, I think this is about to change, and that openEHR is going to take off in a big way. This is going to revolutionise how we think about and do digital health, and it should increase the speed at which we can do it by at least two orders of magnitude. Why do I say this, and what evidence is there to support my assertion?

openEHR has come of age with a large number of successful small implementations, and a few much larger ones (1) which have proven the approach works at scale. We have also seen the use of openEHR by governments and major health providers across the globe, including the NHS (2), as the mechanism for the creation and curation of clinical content standards in their territories. In addition, changes to the openEHR Foundation have made it unarguably an open source organisation with a global user community; a growing vendor community has developed offering both open source and proprietary tools and components supporting the standard; and there is serious interest from major system integrators. These changes make openEHR look like a much better alternative to the hegemony of the big US megasuite providers, who still want to shape health and care systems in their image and who own the platforms on which these providers will increasingly depend.

UPDATE (12 April 16)

Possibly the best explanation of openEHR I’ve seen “openEHR technical basics for HL7 and FHIR users” Well worth reading.

UPDATE (15 March 16)

Some great videos here which provide an easy way to understand various aspects of openEHR.

In particular:

Clinician-led e-health records – An introduction to openEHR for clinicians

National governance of openEHR archetypes in Norway – A national approach to building information models with openEHR. Many lessons here for HSCIC who have just started doing something similar here.

UPDATE (13 July 15)

In their PQQ which kicks of the procurement for the Datawell to support Devo Manch,  Manchester have mandated openEHR along with other established standards including IHE-XDS. This could potentially lead to the largest implementation of openEHR in the UK with Manchester building on pioneering work in Moscow and Leeds

UPDATE  (24 Apr 15) Further information and news about the growing interest in openEHR will be found here

Firstly, everything I read and all of the people I talk to across the globe about digital health agree on a couple of things.

  • Firstly, we need to move towards a platform architecture into which we can plug the thousands of apps and hundreds of traditional systems that we currently use in health and care; an architecture which will enable all of these to interoperate and work together.

  • Secondly, we need to separate content (the data, information and knowledge that applications consume and update) from the applications that process it; and that content needs to be expressed in a modular, computable and reusable format.

Beyond this, agreement breaks down – people do argue about business models (who should own and control the platform), and also the details of the particular standards and technology to be used – but on the core principles, everyone with any credibility agrees.

When it comes to business models, some would like to own the platform, because doing so would create a massive commercial opportunity. And while some still pursue this goal, most significantly Apple, others have decided, as I have, that ownership of the platform is neither achievable (competitive and customer pressures mean even the mighty Apple can’t win this battle) nor is it desirable from the perspective of citizens, health and care providers and payers – none of whom wish to be locked in or to pay the ‘fruit tax’ or its equivalent.

Others, including me, and more significantly some big players, have come to the view that while it might be great to own the platform, that isn’t going to happen and so we need to move to an open platform which nobody owns (in the sense that nobody owns the Internet). As for commercial opportunities, they will still exist higher up the value chain, and the existence of the platform will create such opportunities by the spadeful. Surely it’s more fruitful to concentrate on these, rather than waste time and resource on a battle no one can win.

On the details of implementation, disagreement is less significant. The two major contenders, openEHR and the Healthcare Consortium, both have similar approaches, and they are already converging through the Clinical Information Modeling Initiative (CIMI) to reduce their differences to the point where they really don’t matter and can be dealt with at a purely technical level, with their components being easily interchangeable.

So, if we want to create an open platform, what do we need? We need openEHR or something like it – and frankly there is nothing else as mature or as well supported as openEHR.

OpenEHR is not software, nor is it a particular technology. It’s an open specification or standard for the representation of a key bit of content – the health and care record. The specification is open source (insofar as you can apply this term to something that is not software), and it’s curated by the openEHR Foundation, which is a not-for-profit company democratically controlled by those who choose to be part of the global openEHR community (and anybody can). The community is truly global and growing, and consists of both users and developers; and is supported by a number of vendors who can offer tools, components and services supporting the standard.

openEHR provides a simple, robust and stable over-arching reference model (3) which defines a formalism for the representation of the modular components of a health and care record. openEHR calls these ‘archetypes’ and they define the elements of a record, their properties, and how they are represented (including bindings to terminologies and classifications). Archetypes are intended to represent a superset of all those properties that might be associated with the concept they represent (at a high level these will be either an observation, an evaluation, an instruction or an action). Archetypes can then be constrained and/or combined in a ‘template’ to provide practical interoperable components for use in a particular context or system.

The tools available for the creation of archetypes and templates are open source (as are the vast majority of the archetypes and templates created with them), and this makes openEHR easily accessible to clinicians and other domain experts while also providing system developers with robust components to handle many of the technical complexities. openEHR enables clinicians to concentrate of the clinical stuff, and developers to concentrate on the technical stuff, without needed to understand more about the other domain than they want to.

By building systems using openEHR, system development work shifts from the technical level to the domain level. A repository that has been built to store an openEHR health and care record does not need to take account of the particular content of a given archetype. Whatever that archetype might represent, the repository will be able to store it, and you will be able to query that repository about its content. This feature of openEHR is the key enabler of much faster application development, because the addition of new features will not require changes to database schemas (with all the associated testing and data migration that entails). Instead, all that is needed is the addition of some archetypes and/or templates – and these may already be available as the result of work by others in the community, or else they can be created rapidly by a relevant domain expert – plus the creation of some new user interface components, and these can often be generated automatically from the underlying templates. In this way changes can be made by end users, or by people close to them. This will reduce the time to add new features from months to hours, and the time to build new systems from years to weeks.

openEHR is also technology independent. Applications don’t need to concern themselves with the technology of a particular implementation of an openEHR repository – that’s purely a matter for the implementer, who can chose whatever technology works best for them at a particular time and in a particular context. The applications that use it will not be affected, so long as they remain compliant with the standard. We can see this happening in the dozen or so existing implementations of openEHR repositories: they use different operating systems, different databases (SQL and NOSQL) and various development tools to create both open source and proprietary implementations of the standard. Compliant implementations of the standard from different vendors are interchangeable, and a single query can be executed across multiple implementations. openEHR is vendor independent, and it eliminates vendor lock-in.

Suppliers of openEHR repositories will have to compete on performance, security, robustness, value and service – they cannot rely on customer lock-in, as the vendors of many traditional EHR systems have in the past. From the perspective of health and care providers, openEHR puts them back in charge of their own destiny. This contrasts with most of the current successful approaches to the delivery of enterprise-wide EHR, where customer institutions have adopted one of the four big US megasuites, and then have had to adapt internal processes and organisation to fit with the chosen system – in effect, you become an EPIC, Cerner, Allscripts or Meditech institution, rather than a customer who calls the shots.

The ‘megasuite model’ has worked spectacularly well (if expensively) in a number of big US hospitals, particularly for EPIC, but that model starts to break down when you seek to extend the scope of a system from an institution to an integrated health and care community. It also fits badly with UK and other European models of health and care, which are not so close to the US model as the megasuite vendors might hope them to be.

Of course European health and care providers don’t want to remodel their processes along American lines – why would relatively successful European providers want to adopt systems designed primarily for the inequitable and unsustainable US system? According to the well respected US Commonwealth Foundation the United States ranks last among eleven leading developed countries on measures of access, equity, quality, efficiency, and healthy lives (and, by the way, the UK’s NHS takes the number one spot).

Much of my conviction about openEHR comes from work I’ve been involved in with HANDI, in building HANDI-HOPD – the HANDI Open Platform Demonstrator, which has now been adopted by NHS England as the NHS England Code4Health Platform. This platform provides a simulation environment for any system or service that wants to expose an API (interface) within an open ecosystem, and it includes an openEHR repository loaded with test data from the Leeds Lab Project.

We have exposed SMART and FHIR APIs, as well as the native openEHR service API, on top of the repository; we have used this to build a number of apps, and also demonstrated how you can simply plug in apps that were developed elsewhere using the SMART API. We have also used this platform to prototype a UK localisation of an open source ePrescribing product (www.openep.org), and the speed at which we have been able to carry out the localisation and meet some special mental health requirements has been impressive – indeed so impressive that we will shortly be announcing the first NHS Trusts who will be taking the system live.

Work is currently being completed to re-brand the HANDI platform as the NHS Code4Health Platform, and this will shortly be available for those who want to learn more and experiment with this and other open technologies.

openEHR has come of age – If you don’t believe, me give it a try.

Notes:

This is a slightly updated version of the original with a few minor changes to make it more readable to the general reader and correct some typos my thanks for this to my friend and colleague Conrad Taylor.

1) Large scale implementations of openEHR include:

Moscow – Integrated health and social care 12 million population 

Slovenia – Country wide 2 million population

Brazil – Unimed Medical cooperative

2) Health systems using openEHR to create curate and publish clinical content.

NHS HSCIC

NHS Scotland

Australia

Norway

Slovenia

Brazil

openEHR Foundation 

Applications built on openEHR platform

OPENeP EPMA product www.openep.org

Marand Think!Med Clinical, Ljubljana Children’s Hospital http://www.marand-thinkmed.com

Ocean Multiprac Infection control, Queensland Health, Australia http://www.multiprac.com/?portfolio_4=infection-control-2

Ocean LinkedEHR, Western Sydney, Australia  http://openehr.org/news_events/industry_news.php?id=121

DIPS Arena, Norway http://openehr.org/news_events/industry_news.php?id=97

mConsole, Mental Health patient portal, Code24, Netherlands

Clinical Decision Support, Cambio, Sweden http://www.cambio.lk/News-and-facts/Produktnytt/COSMIC-Clinical-Decision-Support1/

See also http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities

3 Some key documents on OpenEHR

OpenEHR Architecture Overview

OpenEHR Reference Model

Moscow eHealth a Model for the UK


The approach that Moscow City Council has adopted to create an open platform to support health and social care services in Moscow which uses some of the same technology as the Code4Health platform would seem to have relevance to the UK and in particular is a good fit for the needs of emerging new approaches to the integration of health and social care like that recently announced for Manchester.

Many of you will know about HANDI-HOPD the HANDI Open Platform Demonstrator  that we have been working on for the last few months, this has now morphed into the NHS Code4Health Platform launched by NHS England during eHealth Week in London this week (5th March 2015).  However, what you probably won’t know is that one of the key pieces of technology available on the platform is the same as that which is currently powering the whole of the eHealth system in Slovenia and even more impressively Moscow.

Moscow

The Platform deployed in these two places brings together OpenEHR www.openehr.org and IHE XDS  in a very impressive way. And I believe provides a model for what we might do in the UK and even more interestingly aligns with the thinking in a number of UK city regions who are already looking at IHE XDS and/or OpenEHR and who in a number of cases have already implemented one or the other. However, the UK initiatives appear to know little of what’s been done in Slovenia and Moscow and in particular how XDS has been successfully integrated with OpenEHR, which I believe takes the capabilities of the platform to a new level – This blog aims to put this right.

One of our key partners in the Code4Health Programme who have provided the core of platform and open source components for the OPENeP Project www.openep.org are Marand,  and they are also the company who provided the platform for both Slovenia and Moscow and it is from their charismatic CEO Tomaž Gornik that I draw much of my inspiration and information.

Before turning to some of the technical details I’d like to describe a little of what I understand of the somewhat different approaches in Slovenia and Moscow and the motivations behind them, as while both use what is fundamentally the same technical platform they came to the solution from different directions in ways which graphically illustrate the flexibility of the underlying technology.

Moscow City Council is responsible for pretty much all of the health and social services serving Moscow’s 11 million citizens covering broadly what we call primary, community and social care and outpatient clinics. Moscow is a complex environment and has large number of siloed legacy systems, which made interoperability difficult and created significant vendor lock-in of data and systems. Moscow wanted to separate data from applications and store its data in a vendor and technology neutral format and chose OpenEHR to do this. They piloted this approach using the Marand Think!EHR OpenEHR implementation (which is one of the components on the Code4Health Platform) and IHE XDS components from  www.forcare.com. The same basic technology as Marand had already successfully implemented in Slovenia where the IHE componets were supplied by www.tiani-spirit.com . The pilot was successfully and the platform is now rolling out across the City.

While both Slovenia and Moscow have ended up with broadly similar solutions they reached this point from opposite directions. Slovenia started simply wanting to implement IHE XDS to allow sharing at a document level, but came to realise that this did not support their need for fine-grained structured data to support big data analytics. They solved this problem with the integration of  OpenEHR. Moscow on the other hand started with a view they just needed OpenEHR, but were persuaded of the quick wins IHE XDS could bring with document level sharing and in particular its ability to mobilise documents already produced by legacy systems that would take some time to be replaced or upgraded to take full advantage of the power of OpenEHR.

In both Moscow and Slovenia the same proprietary components have been used to implement both XDS and OpenEHR.  However, both have the comfort that because the data is stored in an open format, these components can easily be replaced if alternatives emerge which appear to offer better performance or value. Indeed this portability of data is something that HANDI have already proven in the creation of the Code4Health platform which required the data to be moved between two competing OpenEHR implementations.

Requirements and technology will evolve, but for me for now and the foreseeable future the approach taken in Moscow seems like the best bet for the integration of systems and information in the complex environment of health and social care across a city region. It brings the long-term benefits of OpenEHR, which has the capacity to put data into an open, fine grained, structured format that is technology and vendor neutral, with the tools to easily engage frontline clinicians and other Health and Care Professionals in its curation while delivering the quick wins with XDS that can ensure the right document is available in the right place at the right time to support safe, efficient care.

 

IMS and Open Maxims – A big step forward for NHS Open Source

IMS’s recent decision to open source its Maxims EHR as Open Maxims  is to be very much applauded and their decision to do so under the AGPL licence is an encouraging indication of their commitment to a mainstream open source approach.

However, making the code available is just the first step. Exploiting the opportunities that we hope will arise requires the creation of a community of users (using and contributing to the product in many different ways) and vendors able to offer services in relation to the product to the user community in competition to IMS, who at the moment are the only organisation with the capacity and capability of doing so. The situation here is very different from building an open source product from the ground up or where an effective open source community already exist around a product.

I know that IMS are sold on the need to build such a community and have a sophisticated understanding how this can work commercially for them, knowing, as I do, those who lead IMS I am sure of their commitment to the creation of such a community and making a genuine open source project from IMS Maxims. If anyone doubts IMS’s determination and commitment they need only look to their MDs Shane Tickell’s recent 216 mile “walk to work” to see both his determination and willingness to take considerable pain for the greater good, but there are some obvious conflicts of interest and challenges for them in the process

I have an interest in seeing successful open projects created in the NHS both personally, through my work with HANDI (who what to support both open source and proprietary contributions to building a open digital ecosystem) and my work as a consultant to the NHS England Open Source Team. For NHS England for whom one key role is to support the creation of vibrant opens source communities and the supporting technical and governance infrastructure to enable their successful operation and ownership by the community.

NHS England will be working with IMS and others to create a custodian for an NHS “Gold Version” (a distribution of Maxims owned and controlled by the user community and quality assured for use in the NHS) Creating this custodian and procuring the services needed to run it will takes some weeks/months and once it’s up and running getting to the point where there is a fully effective community with multiple organisations contributing to the code and able to offer services around it will take some time, probably running into years, allow this depends on the speed at which the product is taken up and the enthusiasm of those in the initial community.

Turning away from the specifics of IMS. NHS England are currently looking at 4 potential sources of open source health systems.

Established open source projects which have an existing diverse community of users and vendors – there are a number of such projects globally of which VistA is the most obvious example, but none of significance currently deployed in the NHS.

  • Home grown NHS open source projects – There are many of these (including some that have emerged from NHS Hack Days) most are niche and/or relatively immature and few if any have active engagement beyond those involved in their original creation, although, a number are close to taking the next step and have great promise like OpenEyes, eOBS and OPAL.
  • Projects where NHS organisations or local authorities have developed  products in-house sometimes with thoughts of possible commercial exploitation or with no particular plans for its use beyond their organisations who are now interested in the benefits of releasing them open source.
  • Commercial vendors, thinking of taking a similar path to IMS.

Building vibrant open source communities in the NHS from these different starting points creates similar challenges but requires different approaches, but in all case NHS England are keen to work with all those with compatible objectives.

You can read more about what I think makes an open source community here

There are also some other projects which while strictly not open source software but which are nonetheless based on open IPR  and which represent key components of an open digital ecosystem. Specifically OpenEHR www.openehr.org  and OpenClinical www.openclinical.net  – These both have the benefit of established global communities supported by open a number of vendors with both proprietary and open source tooling and implementations at scale.

HANDI are also keen to work with the open source community, particularly with HANDI-HOPD our Open Platform Demonstrator which made its first appearance at the recent NHS Hack Day in London and which will be launched properly in September. We hope HANDI-HOPD will provide a great experimental and learning platform bringing together open source and proprietary implementations of open standards with realistic data and open source clinical content in a ‘sandpit’ environment. While HANDI-HOPD is built on industrial strength components and work done on it should be transferable to a production environment HANDI itself has no ambition to offer production facilities which we hope will allow the platform to operate as honest broker promoting a vendor neutral environment true to HANDI’s agnostic position with regard to open source and proprietary approaches to the creation of an open digital ecosystem.

See www.handi-hopd.org for more about HANDI-HOPD and for more on open interfaces, open standards and open source and approaches to openness here

I’d also recommend Wolands Cat http://wolandscat.net/ for some insightful stuff on open platforms and why traditional health IT projects often fail.

Finally, I hope HANDI-HOPD can provide a platform for Code4Health activity

 

 

 

PHRs – An important but limited role

There is a lot of interest around PHRs at the moment at senior levels within the NHS, but there seems to be a lack of clarity the role PHRs might play in the UK

If we are to make progress we have to develop a shared understanding of what we are hoping to achieve, what we mean by a PHRs and what role they might play in meeting our objectives?

For many, including me,  the key feature that separates a PHR from other forms of health records is that it is controlled by the person to whom it relates – i.e. they decide if it exists, what form it takes, where it is held, what it contains, who has access to it and if and when it might be destroyed.

It seems to me that in the UK context PHRs have a limited, but important, role to play as a driver of innovation and change, but that many of the benefits they might bring would be better archived through patient access to existing records, particular GP records, and by a step-by-step evolution from siloed institutional records to a single logical record under share curation and governance.

In this long blog:

  • I provide some background about the purposes of EHRs and the Rights and Responsibilities of both record subjects and record users, an understanding of which I think is essential to understanding the limitations of PHRs and where they fit in the bigger picture.

  • Some thoughts about what I think are seen of the benefits of PHRs. I believe it is important to start with a shared view of what we are trying to achieve rather than jumping to the conclusion that the answer is PHRs

  • Finally, I lay out what steps I think we should take to move towards a shared record and what this is (which is definitely NOT a single physical record) and how patient record access to existing systems fit into this journey.

I conclude:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to support patients engagement in their own care and the relevant sharing of their  data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.

Background

Before coming back to what we do with PHRs I want to develop three points.

  • The purpose of health and care records

  • Rights and responsibilities in relation to such records

  • What we hope to get out of PHRs?

Purpose of Health Records

Health records have a wide range of purposes and these include:

  • Directly supporting the delivery of care to individuals

This category includes both clinical and administrative activities that are necessary for the maintenance of health and wellbeing of and the delivery of care to identifiable individuals including:

    • The provision of an aide-memoire for those involved in care.

    • To facilitate the engagement of patients and their family and informal carers.

    • As a means of communication within teams responsibly for an aspect of care.

    • As a means of communication between teams responsible for the different aspects of care.

    • The provision of the data need by decision support tools design to provide automated guidance to patients, formal and informal carers

    • The provision of data to support workflows, care processes and transactions related to care.

  • Supporting the Health of Populations

The category includes all those uses that are concerned with the health of populations, the planning of care and the development of health knowledge. These uses don’t offer a direct and immediate benefit to individuals, often don’t require identifiable personal information and are often referred to as secondary uses. These uses include:

    • Healthcare planning and commissioning

    • Public health and epidemiology

    • Risk stratification and risk scoring

    • Predictive modelling

    • Drug safety surveillance and pharmacovigilance

    • Clinical audit and outcome measurement

    • Population based healthcare research

    • Identification of subjects for clinical trials

  • Providing a Medico-Legal Record

Those providing care need to be able to demonstrate that they did so with due professional care, recording relevant information appropriately and acting reasonably on the basis of the information available to them. The medical legal record needs to meet the requirements laid down by statue and common law for the admissibility of evidence in both civil and criminal proceedings (principally the “Civil Evidence Act 1995” and “Police and Criminal Evidence Act 1984”. A medico-legal record needs to:

  • Be able to reliably represent the record as it would have been at any particular point in time

  • Securely represent the provenance of information recorded

  • Ensure that information once recorded cannot be repudiated

  • Provide an audit trail of additions, changes and access to the record

The record has to support the needs of all those involved in care which includes health and care professionals, administrative personnel, family and informal carers and patients themselves.

Rights and Responsibilities

In order to understand the issue surround the use and access to health records I think it is helpful to think in terms of a set of rights and responsibilities.

Rights might include: The right to;

  • Determine where and how the record is stored

  • Determine the information stored in the record

  • Decide who has access to the record and the purposes for which they use it

  • Collect information

  • Know the provenance of information stored in the record

  • Use the information in the record for defined purposes

  • Retain/destroy the record

  • Change, clarify or comment on and challenge the veracity of information in the record

  • Disclose information to others for defined purposes

Responsibilities and obligations might include: The requirement to;

  • To ensure the accuracy of information recorded

  • To maintain the currency of information in the record

  • To protect record from inappropriate use or disclosure

  • T disclose information as required by law, regulation or overriding public interest

  • To protect information from loss or damage

  • To maintain details on the provenance of information

  • To maintain audit records of access to, disclosures of and changes to information

  • To securely destroy particular copies of information (typically in compliance with retention policies)

  • Not to disclose certain information even to the patient

Many individuals and organisations may have some of these rights and responsibilities including the patient; those who have contributed to the record or delivered care on the basis of the record; those responsible for maintaining systems on which the record is stored; those who have paid for care on the basis of information for which the record is the authorative source, third parties referenced in the record and those executing certain regulatory or statutory functions.

A PHR as defined above is a record in which the patient has all of the rights and few if any of the responsibilities and in which others have few if any rights and only those responsibilities that may flow from providing and/or hosting the record on behalf of the patient.

Those who wish to maintain records can take one of two basic approaches (and many variations at points between) to ensure the record is fit for their purposes At one extreme each stakeholder maintains their own record for their own purposes (this is broadly the current situation) and at the other extreme we try and create a single logical record under shared governance that satisfies all.

Why PHRs

What then do we hope to achieve by creating PHR? Proponents of PHRs cite many potential benefits, which include the following:

  1. Greater engagement of patients and their informal carers in their health and care.

  2. Facilitation of innovation and experimentation with new approaches to health and care records.

  3. The creation of a truly integrated life-long record which covers all aspects of wellbeing, health and care.

  4. Greater transparency so that patients and their advocates are better able to assess the cost and quality of care that they receive and if needbe challenge it.

  5. Improvements to the completeness and accuracy of health and care records by allowing patients, their digital devices and their informal careers to contribute to and validate the information recorded in the record..

  6. Provide a mechanism which allows patients to see what is recorded about them and manage informed decisions about the sharing of data for both primary and secondary purposes.

  7. To enable patients to record information about the health and care beliefs, values and preferences.

  8. To allow patients to record data about their health and care for their private use which they don’t wish to be available to others.

However, with the exception of the 5th and 8th points above all of these things could be achieved using facilities that are available now in GP systems and which have been offered to patients by pioneering practices for over 10 years. Extending systems to support the 5th and 8th points while non-trivial, is entirely doable.

So what should we do?

My answer to this question is not a simple one as I think we need to pursue multiple paths.

  • First, we need to push forward with GP record access to meet the Goverment’s commitment that all patients who wish to do so should be able to access their GP record online.

  • Secondly, we need to start to lay plans to provide a single shared record under shared governance and curation with the patient as “First Amongst Equals”

  • Thirdly, we should encourage the development of PHRs as a transitional approach for those patient groups who needs would not well met by access to GP records (these are typically those groups undergoing an extended episode of care outside of general practice e.g. renal patients) and as a vehicle to experiment and drive innovation which will inform the creation of shared record.

  • Finally, we should enforce the Open APIs policy being developed by NHS England which requires all new procurement of systems to make open APIs available and require  all systems to enable patients to obtain a machine readable download along the lines of the US “Blue Button” model

Making GP record access a reality

Given that the technical facilities to allow patient access to GP records have been available to the majority of practices for many years and that they have be used successfully by pioneering practices, Government wrongly assumed that getting wider take up would be easy. What they failed to understand is that pioneering practices had chosen to ignore the risk of the unlawful disclosure of third party information to patients, something neither the Government nor their professional bodies could advise others to do. Solving this problem retrospectively is not practical and as a result a more limited approach is now being proposed as laid out in ‘Patient Online: The Road Map’.   We should get on with this and also work to ensure systems are amended so that future recording of third party data is tagged to enable it to be easiy redacted.

Building a shared record

Building a shared record will be a slow process, but one that can be approached incrementally. It’s also important to understand that I’m not proposing a single national record, but rather that for an individual there should be a single authoritve record. Every application that needs information about the patient would get it from this record and any application that needs to persist data about that patient would write it to this record. There could (and should be) multiple providers of repositories for records and the patient should be able to choose which one they use and be able move their record to another provider should they wish. It might even be appropriate for different sections of a record for a single patient to be stored in different services? It would be the responsibility of the service provider to ensure the security and integrity of the record and to put mechanisms in place to enable all those with an interest in the record to secure their rights and responsibilities in relation to the record.

The record architecture required would need to be flexible and extensible and able to handle record dissonance and maintain multiple versions of the truth where the contributors to the record can’t agree a single version.(I will shortly publish a further blog detailing my proposed model for shared governance and the role of multiple truths) It would need to be based on a set of open standards shared (at least) across the UK to ensure interoperability. For me the only currently available viable contender for this architecture is that provided by OpenEHR, which I believe can meet these complex requirements of my proposed model. In this model record storage becomes a commodity service in the cloud and various organisations could offer such storage under a range of business models, but it the UK I would suggest that the default choice of most citizens would be to use the repository funded by their local public sector care provider.

For this approach to work other things need to be in place:

  1. A discovery service for applications to find where the record for a particular patient is – This could be most simply be provided on a centralised basis by the NHS Personal Demographic Service, but could also be achieved using a distributed directory service .

  2. A service to maintain a registry of those who have contributed to the record or have a legitimate interest in it along with the consents granted by the patient for access and particular uses. Again this might be provided centrally as a service on the NHS Spine or as a distributed service. The work of www.miconsent.org has potential to address aspects of this requirement.

  3. Governance structures (probably with a statutory underpinning) to regulate the record service providers to ensure they are irrevocable obliged to: Satisfy the rights and responsibilities of all those with a legitimate interest in the record,  transfer the record  to an alternative provider if they cease to be able to  do so or on request of the patient and ensure that records are protected from loss in the event of a technical or business failure of a provider.

This architecture is one that I have described before  and is built round an enterprise service bus (ESB) that connects back-end services (which would include record repositories) to front end applications that consume these services. An appropriately designed ESB would:

  • Provide a single interface (API) to the various record repositories and supporting services avoiding the need for applications to deal with multiple APIs with the ESB handling mappings and transformations between different APIs, technical and clinical content standards facilitating incremental progress toward common standards.

  • Protecting services from badly behaved applications and denial of service attacks.

  • Off-load many functions from application and service providers to make their lives easier, requiring these functions to be implemented just once in the ESB rather than in each principal system e.g. authentication, identity management, access control, consent management IG, load balancing (to name a few.)

  • Provide an accounting platform that could support innovative business models for apps (such as pay for use models) and a mechanism for charging the responsible party for compute resource and services consumed by applications.

  • Provide a comprehensive patient portal integrating access to existing NHS national web services; NHS Choices, NHS Direct online and NHS 111 online content with record access, and transactional services.

Migration to a Shared Record

My expectation is that, over time, existing systems would migrate to using the shared record to persist the patient information rather than their own local storage. For this migration to occur existing system vendors and users will need to be confident that the shared record can deliver a level of performance and availability to match that provided by local storage and some may wish to start by maintaining of local cache of the record to improve performance and provide resilience. Also, initially that many will continue to use their own storage simply using the ESB for messaging, interoperability and to provide access to transactional services.

Where does the PHR fit

In this model I see that existing PHRs will also migrate to using the shared record just as other ExRs will do.

Many existing PHR systems are already using the latest web technologies and the agile and innovative nature of most PHR vendors and their flexible business models mean that they should be amongst the first to migrate to the shared record.

Similarly the agile and innovative nature of the PHR sector and the much similar Information Governance issue that exist with PHRs (as the patient is in control) will combine with the emerging shared record to enable of slew of PHR developments in which the developers can concentrate on the user experience and user interface design and experimentation with novel business models free from much of the burden of managing record persistence.

For those wanting to experiment there are already facilities provided by the Leeds Health Innovation Lab Platform  which offers what a test platform that could be used to start to build exactly the sort of shared record I’m suggesting.

EhrScape also based on OpenEHR has also recently annocunced an Open Health Data Platform that could also provide a basis for experimentaion

There are also a number of Open Source PHRs that could provide a rapid route for those wanting to experiment or provide live services quickly. Including Indivo and Renal Patient View

We should encourage and facilitate such activities which will help and refine and develop the shared record and the supporting open digital health ecosystem at a pace not possible with the more complex issued raised in the migration of existing large scale EHR systems.

So, in conclusion:

PHR are not the solution to the problem of sharing Electronic Health Records, but an intermediate step on a journey to a single shared logical record for every patient under shared governace with the paitient as “first amongst equals”. We should encourage the further development of PHRs and in particular explore the use of a common model for data persistence across multiple PHRs based on OpenEHR. Recognising that this is a long and difficult journey we should also continue to open up patient access to existing EHR systems (particularly GP systems) which for many will provide a better solution than a PHR to supporting patients engagement in their own care and the sharing of data. We don’t know the answers to some of the challenges we will face achieving  our objectives, but answers will emerge from an exploration of PHRs, Patient Record Access and Shared Governance Models.

NHS and Vista Integration

Here is my presentation I gave at the CAMTA Annual Meeting in London on 14 November 2013

CAMTA, otherwise known as the M Technology Association – UK & Ireland, is a non-profit educational organisation. Its aims are to further the utilisation, improvement and understanding of the M Technology language , and also InterSystems CACHÉ that has backwards support for it, by disseminating related information on a world-wide basis. http://www.camta.net/

VistA is of particular interest to CAMTA members  as it uses M Technology (MUMPS) with version of VistA running on both G.TM and CACHÉ with number of CAMTA members actively involved in the development of VistA and associated tools.

My presentation provides an overview and update of NHS open source and where VistA might fit in the landscape

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 ewan@woodcote-consulting.com and either I or a another volunteer from the community will be in touch to try and help.

 

NHS VistA and NHS Open-Source

Many of the issues discussed here will feature at the HANDI Health Apps Conference – Collocated at EHI Live 5 6 Nov NEC Birmingham

A slighty amend version of this blog piece with a brief commentary for those outside the UK is available on Open Health News a shorter version is available on eHealthInsider

There is much widely publicised interest from NHS England in encouraging the development and implementation of open-source software in the NHS with the debate raging in a number of forums, notably on EHI where this article and the comments it has generated are vital reading for anyone interested in this issue.

This debate has been fuelled by the availability of NHS England’s £260 million Technology Fund which is actively soliciting open source projects include bids to implement an NHS VistA based on the open-source EHR/HIS originally developed by the US Veterans Health Administration and now used by a number of others in the US and elsewhere.

I have written before on this blog about VistA and concluded that this is not the right solution for the NHS. However, I’m now no longer sure and feel that it might have a role. I’ll return to VistA below but before I do I’d like to set some context.

FIrst, and most importantly we should understand that the success of many open-source projects lies in the open, agile and collaborative approach that open source naturally engenders, rather than narrowly on the  licensing model. VistA has been successful in the VA because it achieved high levels of clinical engagement by allowing clinicians to get directly involved in quickly solving problems that mattered to them. Traditional models of user engagement where users are only involve in requirements gathering (when they don’t really know what the technology could do for them) and final testing (when it too late and too expensive  to make substantial changes)are completely ineffectual in a complex area like health (see Dr Tony Shannon’s blog   to understand what I mean by complex.) Design is critical both in terms of the user interface and user experience, but also in term of the underlying information models and this requires the intimate involvement of clinicians and their patients throughout the software development lifecycle. (see my blog  Time for Zero-Tolerance   for more on design and Tony Shannon’s 1 developer 1 clinician  For a practical example of agile user centred design).

NHS England’s interest is open-source the result of pressure from both above and below. From above from Government CTO Liam Maxwell with the publication of the “Government Service Design Manual”  which states:

“There must be a level playing field for open-source and proprietary software solution [sic], that allows organisations the flexibility to change technologies and innovate based on data”

With the current focus on open standards, open data, and open interfaces (APIs) – and while there is recognition that proprietary software can (and indeed will be required to) deliver these this things – there is a view that they go most comfortably hand-in-hand with open-source.

From below we have pressure from the growing number of open-source projects in the NHS that are demonstrating success and gaining traction on a greater scale. These projects have demonstrated how open-source approaches foster agile cooperation between disparate NHS organisations and how forward thinking companies can stimulate and support such activity building sustainable business models and creating wealth as they go. I’m thinking here of projects in London’s Moorfields, Leeds Teaching Hospitals NHS Trust, Kings College Hospital, Luton & Dunstable and work with the open-source nursing observation database app Wardware  While at a national level open-source projects spawned by the NHS ITK Information Sharing Challenge Fund (available on the eHealthOpenSource codeforge) and the replacement of NHS Spine using open source technologies

Interestingly, although these projects started independently both they and their commercial partners (companies like Tactix4, Ocean Informatics, BJSS and Black Pear Software) and increasingly cooperating, sharing code and driving convergence to common open-standards (in particular OpenEHR). Such cooperation is a direct result of the decision to embrace open-source and is of great benefit to the NHS and those companies who understand how to exploit these new ways of working.

I’m convinced open-source has a central role in the development of digital health and care, but I also know it’s not a “magic bullet” and that its role is as part of mixed economy of both open-source and proprietary components (all supporting open standards, open data and open interfaces (APIs))

Open source brings a number of benefits:

  • Users are guaranteed value in relation to services they buy to help create and implement open source solutions as no organisation has a monopoly position in the provision of these services created through the ownership of intellectual property rights, ensuring a vibrant and competitive market for such services.

  • Open source projects can make use of proven pre-existing open source components, the licensing terms of which typically require products incorporating them to be made available as open source.

  • Open source fosters cooperation and sharing. This is particularly important when addressing difficult problems where fragmentation of effort can mean nobody finds a solution and for infrasructrucal components where equal access is essential.

  • All users get the benefits of any enhancements anyone else chooses to make to the product, not just those upgrades they are willing to buy or fund themselves.

However, open source is not necessarily going to be sustainably cheaper typically only around 20% of the total cost of ownership of an IT system is in software licence cost and development still has to be paid for. Many argue that other cost are likely to be broadly the same using open-source or proprietary solutions (I’m not so sure that the loss of the built-in advantage the IPR owner has in delivering many of these other services, won’t increase competition and drive prices down, but we don’t have much evidence either way.)

The critical factor for any software product is that there is a sustainable business model enabling investment to create innovative products and to support it to ensure it continues to meet users needs and in some cases this is more easily achieved with proprietary software – The interesting debate is about which classes of components in the ecosystem are best delivered using open-source and which proprietary solutions. Let’s look at what I think a digital health and care ecosystem should look like. This is illustrated in the diagram below:

 

This represents a platform based or service oriented architecture (SOA) which creates a digital ecosystem in which multiple components compete and cooperate to provide the digital capabilities needed by individual user.

There are three classes of components in this architecture:

  • Application components – These provide the user interface and manage workflows and perform transaction to support the delivery of care. They do not contain any knowledge or information about how to do these things nor do they persist the data they create in the performance of these things, rather they draw on ecosystem services for the data, information and knowledge they need and to store any data, information or knowledge they create. Some of these components provide tools for the creation and maintenance of the data, information and knowledge in the ecosystem and to perform “back office” functions.

  • Ecosystem Services – These store the “data resources” created and consumed by the application components – These resources include: Information about patients (the EHR); knowledge about care and treatments (care pathways, decision support rules and heuristics and the data and metadata to populate and drive them); and information about resources and services available to deliver care (people, equipment, physical facilities and services).

  • The Enterprise Service Bus (ESB) – This provides facilities to allow application components to interact with ecosystem services and each other. It is able to provide transformations between supported standards and services to facilitate and/or enforce ecosystem operation and polices – I describe in more detail what an ESB might do in my earlier blog  and while this relates to GP systems similar principals apply more widely.

The key feature of this architecture is “separation”, both vertically and horizontally. Data resources are separated from each other and the application components that consume and maintain them. Similarly, application components are separate from each other performing a limited range of functions communicating with each other only through the ESB. To some extent, the way in which the scope and granularity of services and application are defined in arbitrary and this needs to be tuned to give the best balance of flexibility, performance, usability and sustainability. Also to operate effectively the ecosystems needs to operate within a governance framework agreed by participants. Such a framework might define things such as design and user-interface principals, the standards to be used and principals concerning information governance issue such as security and consent.

A secondary feature of this architecture is that it does not require a single authoritative instance of any one component. You can have multiple competing applications and services performing similar functions and even multiple ESBs (maybe federated, hierarchical or both) , although in practice it might be decided to restrict the diversity, particularly at the service and ESB level to simplify operation (e.g. a care community might decide to have just one EHR).

These two key features make it much easier for the ecosystem to evolve as it is possible to easily substitute alternative applications and services to deliver small incremental changes and to change and extend the data resources in the system without needing to immediately change the applications that consume them. This allows diversity and Darwinian selection and avoids the need for the periodic and incredibly disruptive upgrades and system changes associated current enterprise systems (such as the “megasuites” described below). Overtime it becomes possible to change all of the components and underlying technologies in the ecosystem as better alternatives emerge while maintaining care and business continuity. This approach also makes localisation easier as the data resources that define the local configuration are clearly separate from the applications which if well designed are locality independent.

So to VistA – VistA looks nothing like a digital health and care ecosystem – It looks more like what Gartner describe as a ‘megasuite’ as set of tightly integrated components designed by a single vendor to work together to provide all or most of the functionality needed by a health care enterprise. Garner cites the products of companies such as Cerner, Epic, McKesson, Allscripts and others as megasuites and some of these products have the significant advantage over VistA that they are already either localised or being localised for UK use. Typically these suites lack the clear separation between components which define an ecosystem and once you chosen one you’re stuck with it unless you are willing to accept considerable cost and disruption to make a change.

Indeed, because of its’ age VistA is more monolithic than some of the commercial megasuites. There are good historical reasons why this is the case as eloquently described by VistA expert Rob Tweed who says:

“VistA: Why it’s like it is

• Hardware limitations at the time:
–Very expensive
–Very low-powered hardware–Very little memory– Developer time relatively less costly

• Code written to:

– minimise resource usage
– Maximise performance
–At the expense of maintainability”

This is taken from Rob Tweed’s Excellent EWD Files  where he has a lot more to say about VistA, The MUMPS language and database it uses and also about how we can solve these problems and modernise VistA without throwing out the bay with the bath water. I’ll come back to this later.

So why my partial change of heart about VistA described in my introduction? Well this flows from some things I participated in over the last couple of weeks where I have been able to meet more people from the VA and VistA, talk further to VistA users, experts and proponents and explore some of the issues emerging with experienced NHS clinicians, industry and other colleagues.

The central driver of my changing opinion is the discovery (to some extent a confirmation of things I already knew) that the VistA community accepts many of the weakness of VistA, shares my vision for the creation of a open digital health ecosystem and have been actively engaged in doing something to  move VistA in the right direction. You’ll find all you need to know about this by looking at the EWD Files  referred to above and the World VistA  and OSEHRA  web sites.

These discoveries leave me with one burning question. Does it make sense for the NHS and the UK open-source health and care community to join the VistA community on their journey?

The VistA community have no alternative but to start from where they are. The idea of replacing VistA in the VA where it is liked and understood by clinicians and where it has played a key role in the transformation of VA Healthcare from “Basket Case” to “Best Care Anywhere” is a lunatic one as would be any attempt at a big bang re-implementation of VistA using modern technology with previous attempts and millions of lost dollars providing all the evidence needed to confirm this view.

However, in the NHS we don’t have the baggage of the VistA legacy. Our legacy is much more diverse, great in parts, dreadful in others, but we haven’t got a single system on which the NHS relies in the same ways as which the VA rely on VistA. We also have a number of open-source projects built using more modern tools and approaches, many based on work that already has international support. So we have a choice of starting points some of which may be more attractive than VistA.

So the issues and the pros and cons ?

Pros

  • We share a common vision with VistA to create an open digital health ecosystem – A vision shared by many others global by amongst both the open source community and the existing vendor community, by working with VistA we get the benefit of the investment and intellectual resources of the VA others in the USA and the World VistA community, which might make it easier to achieve our vision.

  • The VistA community can help us learn and develop the tremendously successful approach they have used based on strong clinical involvement and agile user centred development – This approach and culture is the single most important reason for VistA’s success.

  • VistA provides rich function breadth and depth making it the only thing to come close to the functional richness of the commercial “megasuites” – Building such functional richness from scratch is a major barrier in the delivery of enterprise wide open-source solutions. However, like many of the megasuites extracting individual elements of functionality for use in a SOA is not trivial.

  • MUMPS is a very mature example of the now trendy NOSQL database   the MUMPS database provides a robust, scalable and performant database well suited to handling health data (many other successful EHR systems use MUMPS; EPIC, EMIS LV, Partners HealthCare, Meditech, GE Healthcare) It’s important to understand that usinbg the MUMPS database need not tie you into the integrated MUMPS language (again see the EWD files for more.)  I favour polyglot persistence in the ecosystem, which would allow multiple technologies in the persistence layer so we can explore what works best and above all avoid getting locked into a particular technology.

  • There is some very influential support at the “top of the office” for VistA which includes Ministers, senior officials and some very senior clinicians. In my view to some extent these people conflate the amazing broader transformation of the VA with the effects of VistA, but the VistA concept provides a powerful synecdoche. This combines with more practical enthusiasm from some of our most gifted young clinicians (and some not so young) in the open-source community, who have had the opportunity to see VistA in action to create the support needed for the broader open-source agenda to be driven forward.

  • There is enthusiasm in the VistA community (and indeed a little existing work) to look at how some of the open-source approaches in use in the UK can be integrated into the VistA modernisation programme.

  • VistA broadly as is plus essential localisations has the potential to act as a market disruptor supporting alternative business models based on open-source and driving competition and value for the NHS.

Cons

  • VistA technology and architecture is old. The work underway to incrementally transform it into a SOA based platform is impressive, but the task in non-trivial and far from finished. Do we want to become mired in it?

  • Going down the VistA road means a least a partial commitment to the idea of a single (or primary) open-source system in a health community or institution – Something I have previously described as “a better way to do the wrong thing”. If VistA’s transformation to a platform is successful this issue will eventually go away, but at its’ current state VistA is unlikely to be attractive or appropriate to those communities and institutions already well advanced in their journey to digitisation.

  • The VistA software does not offer any significant functionality that is not available in the commercial megasuites (indeed if you accept the Gartner report (1) of 2011 it lags somewhat behind overall.) There are also  there many more narrowly focussed systems which could be integrated into a “best of breed” approach whose functionality exceeds the equivalent functionality in both the megasuites and VistA and which in many cases have been built for the UK market.

  • The localisation challenge is significant and in my direct personal experience usually vastly underestimated. The tangled architecture of VistA with no clear separation between clinical content, configuration and functionality along with tight integration between functional modules will make localisation more difficult. I have heard from American colleagues who have localisation experience in Jordan that this won’t be such a problem, but I don’t believe it the NHS is not Jordan and my concerns about localisation are shared by all I know with direct experience of  localising US products for the NHS.

  • Resource with an understanding of VistA and MUMPS is scarce and in particular finding and retaining developers able and willing to work in the arcane MUMPS language has been a challenge for VistA. While the modern VistA tools described elsewhere remove this constraint from much VistA development localisation is likely to require work in the core with the MUMPS language. It been suggested to me that if work is available for developer in MUMPS they will learn the language a beat a path to our door. I don’t believe this, in my experience gifted young developers value using the latest tools over financial reward and in any case demand for them is such that they can easily get both although health care has the advantage that its’ potentially  high social value will attract the top developers if we can create stimulating projects.

I have had the opportunity to discuss the localisation challenge with others with relevant experience and we conclude that the two main areas of challenge are the PAS and clinical content.

Patient Administration Systems (PAS) are the foundation of which hospital systems are built. PAS systems are not complex but can be complicated and deal with many things that are uniquely peculiar to the English NHS (mandatory reporting, SPINE and C&B interfaces, PbR) and deals with those things that if not done mean the Trusts does not get paid and the CEO (and probably the whole Board) get fired. Industry experts warned the NPfIT that PAS replacement was a bad idea and that they should build clinical functionality on existing PAS infrastructure, but this advice was ignored. This led to a massive lack of progress as the LSPs discovered that PAS replacement was not as simple as they thought and those Trusts persuaded to take this route experienced much pain, found a negative impact on patient care (it must of cost some lives) and lost income, with the promised enhanced clinical functionality coming much later (indeed with Lorenzo in the North it has still not arrived for most).

Clinical content is at the heart of system configuration and encompasses many things. At the simple end code lists, catalogues, service and resource directories but becomes more complex as you start to deal with terminologies (SNOMED is particularly treacherous territory) clinical models, workflows, pathways, decision support rules and statutory and regulatory requirements. Configuration management (including clinical content) is complex because in needs to support subsiduarity allowing multiple levels of localisation in a sustainable and maintainable way that allows national changes to flow down and local innovation to flow up without breaking individual localisations. My view is that we may be able to  kludge these issues in the short-term but that an adequate solution is urgently required will require the clean separation of content and function with standardised and computable representations of the various classes of content in which I feel things including OpenEHR, OpenClincal, SNOMED, and CIMI have an important role to play.

In the context of VistA we believe that the PAS issues can be addressed by implementing VistA on top of existing PAS and not repeating the error of the NPfIT. The practicality of this needs further investigation but an initial discussion between VistA and PAS experts are encouraging.

Clinical content is more challenging and this needs further work to identify the scope of the issue. NHS England have ePrescribing at the top of their agenda and this means that one of the more complex aspects of clinical content will need to be addressed early on.

So after all this I find myself climbing back on the fence with an inclination to at least put a foot down on the side of NHS VistA. For me the unanswered questions are about localisation and the ways in which any NHS VistA activity can support and integrate with the existing UK based open-source activity.

I remain fervently opposed to the idea of VistA as a single system for the English NHS, but see value in implementing it with the minimum necessary localisations in a few suitable NHS trusts as a step on the journey to the creation of an open digital health ecosystem.

In parallel I would like to see an exploration the transformation of VistA into a digital health platform that can support a mixed economy of open-source and proprietary solutions and in particular how we integrate with other work based on open source and proprietary implementations open-standards. For me this is the key attraction of VistA, that it might help us speed the development of an open digital health platform. This to me is the great attraction of VistA. If it can do this, and I think it can,  it has my support. Otherwise it is  probably a distraction and has little relevance in the UK.

But, finally I return to my opening point “the success of many open-source projects lies in the open, agile and collaborative approach that open source naturally engenders, rather than narrowly on the  licensing model” There is a danger that the NHS could treat open-source projects (and particularly NHS VistA) as like a open-source version of the NHS NPfIT. The centre has a role in catalysing and enabling open-source in the NHS, not in  managing it. Leadership, needs to come from the frontline and the focus has to be on agile user centred design with clinicians and other frontline health and care professional working with their patients and service user, supported by the very best digital engineers and other informatics professionals  to rapidly and incrementally deliver digital tools that support the delivery of high quality care.

I welcome comments please add these below

Acknowledgements 

I’d like to acknowledge the help of the following in reviewing and contributing to this document although the views expressed are mine and not necessarily endorsed by them.

Bill Aylward – OpenEyes and Moorfields Hospital
Silas Davis – Developer – SwiftKey
Rob Dyke – Tactix4 and Wardware
Prof. John Fox – OpenClinical, University of Oxford and Royal Free Hospital London
Dr Phil Koczan – GP and UCL Partners
Dr Ian McNicoll – OpenEHR and Ocean Informatics
Dr Tony Shannon – Emergency Physician – Leeds Teaching Hospital
Colin Smith – NHS VistA
Rob Tweed – M/Gateway Developments Ltd
Dr Wai Keong Wong –  Hematology Registrar, North Central London Rotation (Royal Free Hospital/ UCLH/ Whittington Health)

References

In most cases wen links to items referenced are embedded in the text above the only exception is the Gartner Report which does not seem to be available free to web:

(1) Gartner  “VistA Comparison to the Commercial Electronic Health Record Marketplace” Final Report February 4, 2011

Some significant web site with a broad range of material relevant to matters discussed in this blog.

www.handihealth.org
www.openclinical.net
www.openclinical.org
www.openehr.org
Note openclinical.net focuses on the specific open clinical technology while openclinical.org provides a valuable resource covering a the international clinical knowledge management domain.)
www.worldvista.org
www.osehra.org
www.hardhats.org
EWD Files http://robtweed.wordpress.com
eHealthOpenSource codeforge http://forge.tactix4.net
http://frectal.com/
http://nhsvista.org/