Category Archives: Open Source

It’s not about Open Source

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

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

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

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

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

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

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

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

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

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.


The Platform deployed in these two places brings together OpenEHR 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 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 The same basic technology as Marand had already successfully implemented in Slovenia where the IHE componets were supplied by . 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 to build your dream kitchen 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  and OpenClinical  – 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. Using an affordable online printing services can provide several ways to promote your products and services. 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 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 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




Open Interfaces, Open Standards and Open Source

Everyone I talk to agrees that we have to create an Open Digital Health and Care Ecosystem in which a range of digital health and care service can be delivered. This needs to support the interoperability and orchestration of ecosystem components and provide the infrastructure to make it easier for innovators to deliver safe and secure services by offloading the technical and governance complexities from applications and by supporting a diversity of business models to enable sustainable digitally enabled health and care services.

In this context, pretty much everyone I talk to agrees that the existence of stable, robust, open interfaces on both legacy and contemporary systems is critical. Also most agree that both Open Standards and both Open Source have a role to play in the creation of Open Interfaces. However, I think there is some conflation of various issues, which I think could be usefully clarified and I attempt to do this in this blog.

Neither Open Source or Open Standards are necessary or sufficient in the creation of Open Interface and Open Standards and can be a Barrier to Innovation

Open Source and Open Standards have a role to play in the creation of robust Open Interfaces and I’ll attempt to describe what I think this is, but both are neither necessary nor sufficient and in some circumstance insisting on either can be a barrier to innovation and progress. What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

Interfaces can exist at file levels of maturity which are illustrated in the diagram below.

Open API Pyramid

What’s important is the availability of freely available, robust open interfaces not necessarily that they are Open Standard or Open Source.

At the lowest level (5) Closed Systems lack stable, documented interfaces. Such a design approach is still encountered in monolithically architected legacy systems which were designed to “stand alone” at a time when, amongst other reasons, hardware constraints made the use of modular software architectures too computationally expensive. The only way to interface with such systems is to “hack” into the systems source code and data structures (always possible with Open Source systems, in the gift of the IPR owner otherwise.) Such interfaces tend to be fragile and are easily broken by changes to the underlying system.

Systems at the next level Private Interfaces (4) are the most commonly found in health and care systems today, with more modular software architectures. Such systems will typically have both internal interfaces (between modules) and external interfaces. Private interfaces are intended for the use of the systems software developer and are typically insufficiently documented, and less robust than is required for their easy and safe use by third party developers, so you might add a Software development outsourcing to up keep. With proprietary systems access to the interfaces is controlled by the IPR owner; with Open Source anyone can use and improve the interfaces.

The concept of a partner interfaces (3) applies only to proprietary systems and such interfaces are commonly found in health and care systems in use today. Partner interfaces are designed and documented to make them easily and safely usable by third party developers, but access to them is controlled by the IPR owner who can choose with whom they wish to partner – Otherwise partner interfaces are identical to open interfaces (2)

Open interfaces (2) are designed and documented for safe and easy use by third party developers and differ from partner interfaces only insofar as the IPR owner has made the interfaces irrevocable freely available to all. This is automatic in the case of Open Source systems and can be achieved by a range of licensing or contractual arrangements in the case of proprietary systems – Public policy encourages public bodies to insist on the availability of open interfaces as a contractual requirement in procurement of systems. Open interfaces may be produced directly by the system developer or by a third party as a layer above a freely available private interface – Typically as an Open Source plug-in.

At all levels described above the technical and content characteristics of the interfaces are defined by the software developer but at this highest level Open Standard Interfaces (1) the interface implements wildly accepted open standards for both technical and content aspects of the interface. Such standards might be formal (ISO, CEN, BSI etc.) Industry/community de-facto (IHE, HL7,etc) or NHS (ISB, PSRB, etc). While a requirement for the use of open standards where such standards exist is highly desirable, insistence on the adoption of formal/NHS standards before they are fully mature, stable and widely accepted can be a serious barrier to innovation and adoption, as can onerous accreditation requirements in relation to standards compliance. Often a better approach can be the partial use of open standards in open interfaces (2) covering those characteristic where there is consensus.

The priority then is to get to level 2 – Open Interfaces. Ideally such interfaces should make use of those technical and content standards that support aspects of what they do, but the priority should be to expose rich interfaces able to allow access to all of the data and functions supported by the system.



The  Code for Health initiative and the idea of teaching doctors to code (disambiguation: I mean write computer software not learning to apply clinical codes to health records and other health data) is in my mind a really good idea but something that is capable of being badly misunderstood and misapplied with the potential to seriously back-fire. In this piece I’ll try and explain why I think it’s a good idea and how we can ensure it delivers that which its’ protagonists hope for and also some other ways which may be more appropriate for HCPs to become involved in designing digital systems and services.

In this blog I use the term HCP (Health and Care Professional) as shorthand for any professional group whose primary domain of expertise is health and/or care rather than IT. This group includes doctors, nurses and other clinicians, clinical scientists, social workers and other social care professionals as well as managers and commissioners, particularly those working at the frontline.

I conclude that it’s a good idea to teach those HCPs who wish to learn to code – not so they can become or replace professional developers and designers, but to create a more meaningful discourse between HCPs and digital professionals and to enable them build simple tools at the user interface level, while digital professionals concentrate on building robust systems that make this safe and easy. I also suggest that for many HCPs, engagement in the design of digital systems and services may be more appropriately achieved by enabling them to contribute their expertise in the development of clinical content and the user experience rather than teaching them to code.

So what’s my rationale for these conclusions?

Amazing things happen when you get people with different skills, ways of thinking and insights in the same problem space working together.

I’ve seen this many times in my career. In the early days of GP Computing in the late 70’s and 80’s more recently in the NHS Hack Days and  on many occasions in between See this previous blog

I’ve tried to make it happen at other times and places and have both failed (as I did working inside the NPfIT) and succeeded (as for example with HANDI ) and I’m increasingly focusing my efforts in areas where I think I can help create hybrid vigour or heterosis

Central to the generation of heterosis is the creation of mutual respect, shared perspectives and common language to enable a meaningful discourse between the parties.

In the development of digital health and care tools and services there are five critical groups of actors who we need to engage in a meaningful discourse in the design and creation of digital health and care tools and services:



To facilitate this discourse we need to create some boundary objects – things of which each of the participants has some common understanding. The first and most important boundary object is the citizen/patient who in my model is both an actor and a boundary object. This is possible because all of the actors are citizens and have direct or indirect experience of being a patient and so from the outset can engage in a meaningful discourse about what a citizen/patient might want from digitally enabled health and care services. I’d also suggest that there are other boundary objects that it is useful to create. These allow each of the groups of actors to gain insights into the domains of the others, facilitating a meaningful discourse, building mutual respect and hopefully creating heterosis. There are many potential boundary objects that can be developed I’d like to concentrate of these:

  • Software
  • Care pathways
  • Clinical content
  • User interfaces and user experience

Code for Health is concerned with the first of these and is useful as it creates a boundary object between HCPs and the other groups of actors facilitating. Its aim should not be to make HCPs software engineers, but to help them develop a common language and understanding so that each understands and respects the contribution the other can make and to enable HCPs to be meaningfully engage throughout the life-cycle in the design, development and implementation of digital tools and services.

Next, creating an understanding of the issues associated with maintaining well-being and treating poor health and in particular the care pathways which we hope digital technology can enable and support will help those other than HCPs better understand the challenges to which they can apply their skills. So, for example teaching engineers to deliver care is equally as valuable as teaching HCPs to code.

Clinical content is perhaps the most promising boundary object with which we can most usefully engage HCPs in the creation of digital tools and services.

Clinical content represents the information and knowledge required to deliver health and care and consist of information models, care pathways and decision making rules The primary experts in this domain are the HCPs, the experts in the construction of the artefacts required to represent these things and the informaticians, while those with the expertise to build the tools to enable HCPs to engage in ways which hide the technical complexity are the engineers and designers.

Historically, the formalisms that enable clinical content to be represented in a computable form have been impenetrable to those without substantial training in information modelling and/or knowledge engineering (just look as things like ProformaArden Syntax RDF or the Hl7 MIM ) making them inaccessible to frontline clinicians, and HCPs while many of those with the technical skills to use these things lack the clinical understanding needed to use them to best effect. The result has been that the control of clinical content has been left with a few High Priests versed in both the dark arts of Knowledge Engineering and Medicine who are often too remote from the front line to know what’s really needed. However, this is now changing with the creation of tools that allow mortals to engage in ways that are accessible to an ordinary IT literate clinicians and HCPs. Great exemplars of this are OpenEHR and OpenClinical which provide intuitive tools to allow, respectively the creation and maintenance of electronic record and clinical decision support components by frontline practitioners while dealing with the technical complexities essential to the production of the technical artefacts needed by the engineers and designers to produce digital systems. This new generation of tools allows people to concentrate on their core competences knowing that the requirements of others will be met and provides boundary objects, enabling an ever more productive discourse between domains supporting effective user centred agile design by multidisciplinary teams.

Finally, creating functional and desirable user interfaces and user experiences is critical as without this good underpinning clinical content and well engineered components will not be enough to properly support the process of care. The key experts in this area are the designers and human factors specialists, but they need to work in close conjunction with HCPs who understand care processes and their supporting business processes. It is also important to work with citizens and patients who should be the beneficiaries, but are so often the victims, of digital tools that get in the way of HCPs trying to deliver safe, convenient and compassionate care. So this again is a key area where we maybe can make good use of HCPs as well as teaching them to code.

So in summary, we need heavyweight informatics, software engineering and design skills to deliver an open health and care ecosystem which allows HCPs to do much more for themselves in the creation of clinical content and at the user interface level without having to understand the technical complexities which have to be satisfied to allow them to do this safely, securely and easily.

This means teaching HCPs to use these tools and looked at this way, Code for Health is not just a good idea but essential.



What makes an Open Source community?

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

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

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

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

Stakeholders include:

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

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

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

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

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

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




“Wicked” Barriers to Innovation and Adoption

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

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

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

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

They are:

  • Clinical safety
  • Evidence

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

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

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

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.

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 providing combined ayahuasca and san pedro retreat to the world.

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 Champion! in the UK clinical community (both at a very senior level and amongst future clinical leaders) which will help achieve the clinical engagement that has so far eluded most outside of primary care.
  • VistA is the most functionally rich and best proven  of any of the currently available open-source EHRs.
  • The VistA community shares a common vision with many in industry and the NHS to create an open digital health ecosystem. Working together will enable us more easily to tap into the massive investment the US recently made and to the intellectual resources of the global VistA community. The successful creation of such an ecosystem would be good news for the NHS,. UK plc and the vendor community. I have many positive discussions in the last few days that make me think there is a real appetite for this both sides of the pond and substantial work towards this is already underway.

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


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 ?


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


  • 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


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)


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.
Note focuses on the specific open clinical technology while provides a valuable resource covering a the international clinical knowledge management domain.)
EWD Files
eHealthOpenSource codeforge