Skip straight to content

Information Authority
Health Informatics Zone

about us    |    press room    |    events    |    inform    |    links    |    employment    |    home

Contact Us

Delivery Areas

Get Involved

Useful Links

Patients & Public Zone
Health Professionals Zone
Health Informatics Zone
Industry Zone

Knowledgement Programme


Colin Smith
Principal Consultant, NHS Information Authority

January 2002               


1 What is Open Source?
1.1 OSS Licensing
1.2 Benefits of OSS
1.3 Business Models for OSS
  OSS and Government
  OSS in Healthcare
  Objects, Components and Standards
  NHS Information Systems
  OSS benefits for the NHS
  Sources of OSS healthcare applications
  OSS, the role of the NHSIA


Open Source Software (OSS) is software whose source code is openly published, is usually available at no charge, and which is often developed by voluntary efforts. It has come to prominence by starting to take a significant market share in some specific parts of the software infrastructure market where OSS products have demonstrated better quality and reliability than commercial equivalents at a lower cost. OSS offers the NHS a proven alternative to commercial software in the Server domain and merits consideration for use on the Desktop [22].

The availability of open source healthcare applications would provide healthy competition to the existing closed source commercial market, encouraging innovation whilst promoting compatibility and interoperation. This ultimately will lead to systems that are lower cost, better quality and more responsive to changing clinical and organisational requirements. A number of significant clinical applications are already available, or are under development by healthcare organisations across the world.

The UK government has recently published a draft policy on OSS. This proposes that all UK Government departments (taken in this context to include the NHS) should consider OSS solutions alongside proprietary ones in IT procurements, and also should obtain full rights to bespoke software code and all customisations of COTS (Commercial Off The Shelf) packages that they procure. Comments on this have been invited and there is an urgent need for a response by the NHSIA.

There are a number of barriers to the more widespread use of OSS, and initiatives discussed in this paper that the NHSIA could undertake to remove these are:

  • Promoting awareness of the potential of OSS among NHS users and healthcare systems suppliers.
  • Developing and publishing a specific NHS policy on OSS, based upon the government proposals.
  • Provision of guidance on the licensing of software developed and procured by NHS Trusts and Health Authorities and information generally about open source in healthcare - applications, projects, licensing issues etc.
  • Encourage the development of an OSS market in Healthcare systems by evaluating applications and identifying companies willing to support OSS products.

Taking part in or supporting open source healthcare developments in order to improve the availability of high quality, cost effective healthcare systems.

The potential benefits to the NHS from OSS are considerable and limited actions by the NHSIA along these lines could have a significant impact on the implementation of the NHS Strategy and the achievement of the objectives of Information for Health.

1       What is Open Source?

A full and readable explanation of open source, and a discussion of all of the issues that surround it, can be found in the report by the EU ISTAG working group on open source software [20] and in a more recent consultancy report commissioned by the UK Government [22]. A brief overview is provided here for completeness.

1.1 OSS Licensing

Open Source is the generic term for software that is distributed in its source code form with a licence that allows the recipient to use and modify this code. The concept of source code distribution is not new, but in the last few years, fuelled by the Internet, a whole “open source” movement has grown up. Major components of the Internet (notably Domain Name Server software) have been developed by software engineers collaborating over the Internet, with source code written, tested and debugged in a completely open manner. The LINUX operating system has been developed in the same way.

There are a variety of types of published open source licences [16] e.g.

  1. no license at all, allowing software to be incorporated into commercially licensed products

  2. licenses like the BSD License that place relatively few constraints on what a developer may do (including creating proprietary versions of open source products)

  3. the GNU General Public License (GPL) and variants which attempt to constrain developers from "hoarding" code, i.e., making changes to open-source products and then not contributing those changes back to the developer community, but rather attempting to keep them proprietary for commercial purposes or other reasons;

  4. the Artistic License, which modifies various of the more controversial aspects of the GPL;

  5. the Mozilla Public License (MozPL) and variants (including the Netscape Public License or NPL) which go further than the BSD and similar licenses in discouraging "software hoarding" but which still allow developers to create proprietary add-ons if they wish.

The intent of these various forms of licenses is to ensure that the code remains open for all to use, validate, modify, and improve. The Open Source Organisation [11] now provides a definition of the characteristics of a licence that can be termed Open Source. The distribution terms of open-source software must comply with the following criteria:

  1.  Free Redistribution: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

  2. Source Code: The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

  3. Derived Works: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

  4. Integrity of The Author's Source Code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

  5. No Discrimination against Persons or Groups: The license must not discriminate against any person or group of persons.

  6. No Discrimination against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

  7. Distribution of License: The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

  8. License Must Not Be Specific to a Product: The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

  9. The License Must Not Restrict Other Software: The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

1.2 Benefits of OSS

Open source proponents vary in their motivations and in the benefits that they believe come from OSS development. Some claim that developing software in an entirely open manner, enables the most brilliant software developers across the world to collaborate and thus out perform even the biggest commercial developers such as Microsoft. Some even go so far as to suggest that open source development is the only way to develop the most complex software systems [10]. Recent benchmark tests have found favourable comparison between LINUX and Windows XP.

Others argue from an ethical viewpoint, claiming that access to information is in some way a fundamental right, and should not be obstructed by commercial interests. The ethical argument is particularly relevant in healthcare, where the use of closed application systems that hold clinical knowledge and practice, contrasts with the general ethos of freedom of sharing of knowledge that exists in all other areas of healthcare. Midgley [12] claims also that the NHS (and in particular the GP sector) is not currently well served by commercial software owned and developed by companies, as these often have a short lifetime, frequently going out of business, leaving their users of their products unsupported. He believes that if NHS systems were comprised of peer reviewed, open source code, this would lead to better, more fit for purpose software, able to develop over years or decades to meet evolving clinical practice, without the sudden discontinuities, brought about by company take-overs and changes in policy.

A discussion of the specific benefits that might accrue to the NHS from use of OSS follows in section 6.

1.3 Business Models for OSS

As software developers cannot use software license fees with open-source software, other ways of generating revenues and profits must be found, based on services to the customer. There are several ways to do this, for example (courtesy of OpenSource.Org and [16]):

  • "Support Sellers," in which revenue comes from media distribution, branding, training, consulting, custom development, and post-sales support instead of traditional software licensing fees.

  • "Loss Leader," where a no-charge open-source product is used as a loss leader for traditional commercial software.

  • "Widget Frosting," for companies that are in business primarily to sell hardware but which use the open-source model for enabling software such as driver and interface code.

  • "Accessorizing," for companies which distribute books, computer hardware and other physical items associated with and supportive of open-source software services in exchange for franchise fees of some sort.

Although frowned upon by OSS purists, it is also possible to combine OSS licences with traditional software licences:

  • use of different licences for the same product, depending upon the user (e.g. for-profit organizations vs. not-for-profit organizations vs. individuals) and/or the use (e.g. intranet vs. extranet use, use on one platform vs. another, and so on);

  • alternately, a company might license source widely to any and all users, and even allow "evaluation" licensing at no charge, but still charge "right-to-modify" license fees and restrict re-distribution of modified versions in some way.

Not withstanding these possible business models, it is not yet clear that open source will provide a viable alternative to commercial software in all areas of software. The most successful open source projects to date have been in the area of software infrastructure where there is a very large (global) user base: Internet utilities, operating systems etc. The Internet has enabled a very large pool of resources to be tapped to contribute to some common objective, normally to provide a better product than commercial alternatives) or one that can be freely modified to meet local or regional requirements. Some established major manufacturers of general-purpose applications: e.g. Netscape, Sun, IBM, Microsoft, are beginning to recognise that there may be commercial advantage in adopting it as the means of distribution of some of their own products. The QINETIQ report [22] predicts that within five years, OSS could take 50% of the volume of the software infrastructure market, and that in the developing world, OSS on the desktop may soon become a significant competitor to Microsoft.

However, the motivation for open sourcing domain specific applications software that has a smaller market is less clear. This is discussed further in section 5 in the context of NHS applications.

2          OSS and Government

It is clear that EU governments in particular are beginning to look favourably on OSS as it is seen as a possible counterbalance to the dominance of (US based) Microsoft products in the EU Information Technology infrastructure. A number of European Governments [2] are currently considering legislation that would make all software developed as part of a public sector procurement, available under an open source licence.

The UK government has recently responded by publishing a draft policy on OSS by the Office of the e-Envoy (OeE) and Office of Government Commerce (OGC). The key proposals are:

  • UK Government will consider OSS solutions alongside proprietary ones in IT procurements. Contracts will be awarded on a value for money basis.

  • UK Government will only use products for interoperability that support open standards and specifications in all future IT developments.

  • UK Government will seek to avoid lock-in to proprietary IT products and services.

  • UK Government will obtain full rights to bespoke software code that it procures and all customisations of COTS (Commercial Off The Shelf) packages that it uses wherever this achieves value for money.

  • UK Government will explore further the possibilities of using OSS as the default exploitation route for Government funded R&D software by academic research institutes.

In this context UK Government is taken to include, central government departments and their agencies, local government, the devolved administrations as voluntary partners, and the wider public sector, e.g. non-departmental public bodies (NDPBs) and the National Health Service.

3       OSS in Healthcare

As note above, the concept of Open source finds particular resonance among the healthcare IT community. There are a number of active OSS developers from across the world [18] who participate in OSS healthcare developments, and there are an increasing number of available applications. The EU sponsored SPIRIT project [8] disseminates best practice in OSS and news about OSS projects.

In the USA the Freedom of Information Act (FOIA) is being used to force the release of the source of software which has been developed with public funding. Notably a very large and comprehensive patient based Hospital Information System – the Department of Veteran’s Affairs VISTA system is now being made freely available [14] under this Act.

4       Objects, Components and Standards

Object Technology encompasses a set of related software engineering techniques which can be applied at all stages of Information System (IS) development, from requirements analysis to coding [9]. While benefits of Object Technology are realised within a single programme or system, its real power is realised when it is combined with network technologies to enable the creation of object based distributed systems. A natural extension of objects that are specific to particular system and to one supplier, are objects that are general enough to be used on different platforms, across networks and by different applications. Such objects are called components. By providing software developers the same level of interoperability as is available to, for example, manufacturers of electronic circuit boards, component technology is radically altering the way software is developed. Major software suppliers such as Microsoft, SAP, IBM, Netscape and COREL, make extensive use of component technology within their own developments, and in many cases publish interfaces for use by third party developers.

The wide availability of software components within the healthcare sector would reduce the effort required to build reliable, large and complex healthcare systems, thus lowering the entry level for new suppliers into the market.

By their nature, components provide openly defined and available standard interfaces. Components embody a set of underlying data structures and knowledge concepts, and could thus also provide a mechanism for the direct implementation of EHR standards. Paper specifications have to be interpreted by system developers, and the complexity and inherent ambiguity in many standards together with the fact that few of them use formal definition languages, frequently leads to problems of incompatibility between systems which claim conformance to the same standard. Use of software components built around EHR standards would ensure interoperability as well as reducing development effort.

5       NHS Information Systems

Within the NHS the concept of source code distribution of healthcare applications is not new. During the 1970’s and 80’s most NHS systems were developed and maintained by in-house staff at a number of Regional Centres. It was common practice for applications to be exchanged between these Regions and modified for local use. This was a time of rapid innovation in the early application of IT in the NHS. The beginnings of a collaboration between several Regions to develop a comprehensive patient based hospital system was halted by the outsourcing of all of these development centres in the late 1980’s. Many of these applications sold at the time to commercial companies, often at very low cost, remain in operation today. The NHS FHS Computer system is the one remaining major national system the source code of which is owned by the NHS. However, there still exist a significant number of applications in NHS hospitals, the source code of which is still owned by the Trust. Some of these have been developed by NHS Trusts staff for local use, others have been acquired under software escrow contracts, when the supplier has gone out of business without making alternative commercial maintenance arrangements. All of these systems could be made available under open source licences, allowing the possibility of low cost systems, providing healthy competition to commercial companies.

In the last 10 –15 years the NHS has moved to the current situation in which systems are almost exclusively purchased from commercial suppliers. This gives rise to a number of problems:
  • In secondary care, the market for systems is increasingly dominated by a small number of US based companies. These systems originate in a high cost, privatised healthcare system and are expensive to buy and maintain. Because the UK represents a relatively small part of their market, global suppliers are unresponsive to request for local variations, and/or provide them at very high cost.

  • In other sectors there are a large number of suppliers, mostly of UK origin. Many of these are quite small, some offering systems of unproven quality. The Requirements for Accreditation (RFA) is slowly improving this situation in respect of GP system, but this applies only to newly procured systems, leaving a legacy of systems that do not comply with the latest standards. Company failures and take-overs can lead to forced changes of system and/or suppliers, with consequent user dissatisfaction [12].

  • Getting the degree of universal standards conformance necessary to implement National policy for information sharing and interoperability, solely through the enforcement of standards in the procurement process (RFA and STEP), has proved to be ineffective. Evidence for this is the length of time it has taken for the NHS to implement the relatively technically simple task of electronic pathology test reporting, first set as an objective in the early 1990's.

One of the main objectives set out in Information for Health, is to develop and implement person-based Electronic Health Records (EHRs), providing the basis of lifelong core clinical information [1]. Currently Electronic Patient Records (EPRs) from which the EHR will be created are stored in differing formats on computer systems from many different suppliers, and information cannot easily be transferred between them. The code running these systems is in most cases proprietary, as is the format of each of a patient’s clinical records. The EHR cannot be implemented until these systems are able to exchange clinical information safely and securely. The issue of standards is thus central to the Strategy, but it is difficult to see how the complex sharing of EPRs between heterogeneous systems, necessary for effective shared care, can be achieved by the current sole reliance on commercial suppliers to implement defined standard interfaces.

Key to the success of the Strategy is the availability of specifications for the format, content and exchange protocols for healthcare information in the NHS. Currently we are in a time of rapid development of healthcare record standards and of considerable debate within the main healthcare Standards Development Organisations (SDOs): HL7, CORBAMed, CEN TC251 and ISO TC215 [3,4,5,7]. Many of the standards under development have adopted and taken forward the products of the Information Authority's Health Care Modelling Programme. However, the time scale for the necessary international consensus on these standards to emerge is not yet clear, and even when published, such standards are necessarily of a generic nature, and specific versions will need to be produced for use in the NHS.

EPR system suppliers will not invest in the necessary software development resources until stable, mature specifications are available. Even then, as noted above the current process whereby national standards are enforced in the procurement of new systems via the mechanisms of STEP and RFA, takes a long time to produce results, and does not effect the bulk of legacy systems. It is difficult not to conclude that a radically different approach to achieving standards conformance is needed in order to meet the time scales for the implementation of the EHR as set out in Information for Health.

6       OSS benefits for the NHS

Among the potential benefits of open source code for the NHS are:

  1. Quality security and reliability. Open source software developments involve large number of people who collaborate closely. Frequent and close peer review of code results in software that is better engineered, more secure and with fewer ""bugs" than commercial products. Adoption of the Linux operating system by IBM is evidence that even highly complex open source software can be made reliable through the open source approach. The Open Source Apache web server remains the most popular web server on the market, and suffers from fewer bugs and security breaches than its main commercial rival. There is as yet no evidence that open source applications are more reliable than commercial products, but the free availability of the source code will offer the possibility of immediate local fixes to problems identified.

  2. Interoperability. As noted above, the failure of commercial suppliers to offer effective means of exchanging information with systems from other suppliers is a fundamental inhibitor of progress towards the objectives of the NHS Information strategy. By its nature, the Open Source approach promotes interoperability, because the availability of open source code, instantiating NHS standards, will facilitate the implementation of these standards in systems. Applications that are themselves open source will quickly be enabled with the necessary interfaces, commercial suppliers will be forced to respond.

  3. More responsive systems System enhancements are frequently required at short notice to meet changing local or national requirements. The failure of their application suppliers to keep pace with new data requirements is frequently cited by Trusts as a cause of poor data quality. The availability of source code frees users from dependence upon one supplier for enhancements. The user is free to buy support, maintenance and development from different companies, or even use in-house resources. Thus users of OSS systems are likely to be able to move quickly and economically to meet evolving data and interoperability standards.

  4. Encouragement of innovation Computer systems that cannot be economically evolved to meet changing healthcare patterns is a frequent complaint. The free interchange of the source code of healthcare information systems will encourage innovation – new concepts from wherever these originate – suppliers, users, Universities etc. will become more rapidly incorporated into operational systems.

  5. Economic. Commercial license costs, although only one element of the Total Cost of software ownership, are nevertheless considerable. There is the potential for Open Source software to offer economic benefits to the NHS. Use of licence-free LINUX rather than NT, as the basis for application and Intranet servers could bring immediate savings for NHS Trusts. LINUX rather than Windows on the desk-top is a more difficult change, but one where determined Trusts might find considerable economic benefit.

In summary, Open source healthcare applications would provide healthy competition to the existing closed source commercial market, encouraging innovation whilst promoting compatibility and interoperation. This ultimately will lead to systems that are lower cost, better quality and more responsive to changing clinical and organisational requirements.

7       Sources of OSS healthcare applications

Open source healthcare applications could be made available to the NHS in a number of ways:

  1. Existing “NHS owned” source could be subject to an open source licence. Examples are:
    • Locally developed systems - these are normally small departmental system, but some large teaching hospitals own and operate comprehensive hospital wide systems.

    • Software acquired by a Trust due to a contractual arrangement – either as part of a development contract, or as a result of an escrow arrangement. At least one comprehensive PAS acquired in this way is owned and maintained by a Trust.

    • The code of the national FHS and other NHSIA software could readily be open sourced.

    Lack of awareness of the benefits of OSS and understanding of OSS licensing issues currently inhibits such initiatives

  2. New development contracts, both centrally and locally funded, could specify that the source code is subject to an open source licence. As noted in the introduction, the proposed UK government policy on OSS would make this a requirement of all NHS procurements. Again however, lack of OSS awareness and information on licences mean that few software contracts are let in this manner.
  3. Open source software from outside of the NHS. The USA VISTA system noted above provides an example of a complete open source hospital system, already used in a number of other countries. A number of other development projects [18] could result in systems of potential use in the NHS. A number of open source implementations of standards based healthcare components [4] are available and more are under development.

Mots NHS organisations do not have enough IT expertise among their own staff to implement information systems. The widespread use of open source software depends therefore on the emergence of companies prepared to build their business on providing installation, training, on-going maintenance and other support.

8       OSS, the role of the NHSIA

As noted in a recent report by the NCC [23], commissioned by the DTI, the open source movement is relatively new and unfamiliar to IT professionals so that there are a number of barriers to its wider use. However while it is difficult to assess precisely its impact on the NHS, the potential benefits are considerable. A limited initiative by the NHSIA at this stage, to overcome some of these barriers in the NHS, could have a significant impact on the implementation of the NHS Strategy and the achievement of the objectives of Information for Health. There are possible actions by the NHSIA in a number of areas:

Policy. As noted above, the Cabinet Office, e-envoy [21] has proposed a UK Government policy on OSS. Responses to this proposal are required by the end of February 2002. In this context UK Government is taken to include the National Health Service. There is an urgent need for an NHS response to this proposal.

A specific NHS policy on OSS, based upon the government proposals, should be developed and conveyed to NHS Trusts together with specific guidance on the procurements and use of open OSS.

Promoting awareness. A campaign should be conducted aimed at increasing awareness among NHS IT users and suppliers of the potential benefits of OSS.

Licensing. An assessment should be made of the applicability of various Open Source licenses to NHS Trusts and Health Authorities. Guidance will be issued on the licensing of software developed and procured by NHS Trusts and Health Authorities.

Information. The NHSIA should provide a source of expert advice on open source in healthcare - applications, projects, licensing issues etc.

Market stimulation. Measures should be taken to encourage the development of an OSS market in Healthcare systems. The NHSIA should identify open source healthcare applications originating both from within and from outside of the NHS and evaluate these for possible NHS use. Where such applications are of an adequate standard, but support is not readily available, the NHSIA should identify companies willing to provide such support.

Open Source development. Fostering the development of standards based healthcare OSS components is likely to be a cost effective way of encouraging compliance with NHS standards and interoperability between heterogeneous IT systems, necessary for the achievement of many of the objectives of the NHS strategy. OSS component development by the NHSIA does offer the possibility of influencing suppliers in a more direct way than through specifying standards in procurement. By developing high quality open source software components that embody NHS EHR standards, and supplying them free to software developers, the NHSIA would facilitate the rapid implementation of these standards in systems developed for the NHS. The NHSIA is not prevented from developing open source code, as this does not compete with commercial software. Software development is not currently considered to be a necessary, or even a legitimate role for the NHSIA, but the need to maintain the legacy FHS computer system has provided us with a body of skilled software developers. OSS, standards based, component development would enable the NHSIA to make best use of these skills By taking part in or supporting other open source healthcare initiatives, the NHSIA would also contribute to the general availability of high quality, cost effective healthcare systems.



Information for Health, section 1.49



French Government OSS legislation:


The Object Management Group:




Health Level 7:


The GEHR Project:


European Health Informatics Standards committee:


SPIRIT Project


Cathedral & Bazaar, seminal paper on OSS:


The Open Source Organisation:


Home page of Dr A Midgley:


Free Software Foundation:


VA Vista System: 


How to establish an OSS development


NHS Healthcare Model:


Open Source Healthcare Alliance:  


The Good Electronic Record:


Report of the EU ISTAG working group, libre software:


OSS draft UK Government Policy statement:


Paper by QINETIQ consultants, commissioned by UK Government:


Open Source - the UK Opportunity