Note:* This business case template is designed according to HM Treasury’s Five Case Model, HM Treasury’s and Welsh Government’s standard for business cases. For further information, please see the detailed Green Book supplementary guidance by clicking **her*e.

This template business case is comprehensive for all areas of The *Technology Code of Practic*e which is a set of criteria to help government design, build and buy better technology. It’s used as a cross-government agreed standard in the *spend control proces*s and is part of the **Transformation Strategy 2017-202*0.*

*You must follow this code from the start of your technology programme or project. The Technology Code of Practice: Related Guidanc*e collates all the relevant guidance from across government. You can use this to find more information on each Technology Code of Practice topic.

[Organisation name]

Apperta Template Business Case

[Project name]

Contents

[[TOC]]

**Document Control **

Document Title	Apperta Template Business Case
Version	0.8
Authors	Eckhard Schwarzat, Julian Wilkinson
Contributors	Marcus Baw, Adrian Burke, Rob Dyke, David Jobling
Creative Commons Licence
Date	28.03.2018
Further copies from

Executive Summary

This section should summarise the Business Case in such a way that the reader, knowing nothing about the project and related services or the priorities of the decision-maker, would come away with a high-level grasp of this. It is best to write this section last once you have developed the rest of the business case..

The Executive Summary should contain a brief introduction stating what the decision-maker is being asked to decide (e.g. formal approval to invest £x in x service), and key points from each of the five cases. This section should be no more than 1 page.

Business Case details

Project Name
Project Sponsor
Project Manager
Service description
Partner organisation(s)
Project Reference

Strategic Case

Radical change is needed to ensure that delivery of high quality eye services in England remains sustainable. With an increasingly elderly population, the prevalence of eye disease is increasing, as a result of this and increasing complexity of care patients risk avoidable sight loss. The pressures of these demands are exacerbated through a national shortfall in the national ophthalmic workforce, it is imperative that we engage and empower our skilled community optometric colleagues to provide care for stable and lower risk patients.

The Strategic Case demonstrates that the spending proposal provides business synergy and strategic fit and is predicated upon a robust and evidence based case for change. This includes the rationale of why change is required, as well as a clear definition of outcomes and the potential scope for what is to be achieved. You may wish to refer to supporting strategies, programmes and plans.

1. The proposal

2. The case for change

    1. ** Ethics**

When developing healthcare software it is important to recognise the wider global and ethical aspects. Medicine affects all human life in such profound ways that it necessitates a completely different consideration of the moral dimensions of its technological developments, to that of other industries, where there is usually more choice available to the consumer (including the choice not to use that technology). People cannot choose not to need healthcare.

Medicine has historically been an Open Source profession for some time, even before the popular term Open Source came into being. An ancient and inherently conservative profession, doctors have had ample opportunity over the millennia to experience the dangers of quackery, alchemy, and witchcraft which are the unavoidable sequelae of a lack of open sharing and open peer-review of developments in medicine.

Although it is generally regarded as more ‘scientific’ to write in the abstract, sometimes a concrete historical example can be more illustrative than any amount of argument: There is a particularly striking demonstration of the appalling human consequences of secret medical treatments - the Chamberlen family of obstetricians, who for around 150 years kept secret their development of obstetric forceps. During the time that the innovation was kept from the rest of the world, it is likely that hundreds of thousands of mothers and babies died as a result of the lack of this treatment.

It is because of such precedents that modern healthcare interventions are required to be openly published in peer-reviewed journals before they are taken seriously, indeed it would be unthinkable in the medical profession to offer a ‘secret’, unpublished intervention which was not openly published and its principles understood. To do so in the modern medical world would risk professional ridicule and the wrath of medical regulatory bodies, and would possibly even be a basis for criminal charges in some circumstances.

The earliest medical pledge, the Hippocratic Oath, contains in its second paragraph a clear knowledge-sharing commitment - to teach the next generation of doctors ‘without fee or indenture’ - although it stops short of recommending openly sharing the secrets of the medical arts. The Declaration of Geneva, which is the internationally ratified successor to the Hippocratic Oath, makes this knowledge-sharing responsibility even clearer: ‘I WILL SHARE my medical knowledge for the benefit of the patient and the advancement of healthcare’.

As software and technology have become more and more part of medicine itself, neither distinguishable from, or easily separable, from the practice of medicine, we must consider that these software artefacts now become part of the corpus of medical knowledge, and thus there is an ethical duty to share these technological artefacts openly, as Open Source software and Open Hardware, in order for the maximum benefit to humankind.

Increasingly, software is being developed which has the inherent capability to reduce suffering and save lives, and in such circumstances it is unethical and immoral not to be able to openly share such innovation with the world. The model of Open Source software provides a clear and sustainable business and cultural model for such sharing of medical knowledge as an international asset of the commons.

    2. **Apperta Delivery Model Benefits**

Apperta products are supported by the (NOTE: Code4Health is an initiative supported by NHS Digital and NHS England to enable the best use of open standard digital tools and technology, to deliver safe, high quality, efficient and compassionate care. https://code4health.org )Code4Health clinically led community and benefits from the support and contributions of its members; custodianship of the product is managed via the (NOTE: The Apperta Foundation CIC is a not-for-profit community interest company, supported by NHS England and NHS Digital, led by clinicians to promote open systems and standards for digital health and care. https://apperta.org )Apperta Foundation CIC; this means that the clinicians, as custodians of the software can manage and control the product development roadmap, commission the development of any improvements and can approve any changes or product innovations contributed by the wider community.

The Apperta Foundation CIC (NOTE: As defined and supported by the Apperta Foundation CIC https://apperta.org/_attachment/custodian/Apperta_Custodian_Model.pdf )custodian model provides several benefits outlined below;

The custodianship of the software and the "gold standard" version of the code is managed by a clinically led group of users, as such, design choices for the solution are demand driven and the control of the product roadmap, and its priorities lie with the community where requirements and feedback are discussed openly using community tools built into the solution.
The responsibility for the software, any investment made and the outcomes it achieves is shared across each of the members.
The model enables the custodians to commission any changes they wish to see developed for the solution directly with a supplier of their choice. This supports an agile and flexible approach to development that may not be supported by alternative models.
The custodians can ensure the software meets national standards or support best practice where no standards exist. In addition, the community can invite input or support from any experts to support the design and development of the solution.
Software solutions following this model are developed to meet (NOTE: Clinical Risk Management: its Application in the Manufacture of Health IT Systems http://content.digital.nhs.uk/isce/publication/scci0129 )SCCI0129 and published openly in the repository where the code resides. Any implementations of the software are supported by meet (NOTE: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems http://content.digital.nhs.uk/isce/publication/SCCI0160 )SCCI0160; in addition, the custodians can apply any further standards to the software improvements or design decisions are made, for example "CE Marking" software or devices deemed to be a ‘medical device’.
Development and implementation services can be procured by pre-existing frameworks available to NHS organisations, such as G-Cloud. This can significantly reduce the time it takes to complete a procurement and provides additional flexibility for selecting suppliers. It is possible to procure cloud based solutions where offered (NOTE: https://en.wikipedia.org/wiki/Software_as_a_service )SaaS, further simplifying the procurement process.
The custodian model reduces the risk of vendor (NOTE: As covered by open source benefits http://opensource.wikia.com/wiki/Vendor_lock-in )lock for users by ensuring solutions are developed to meet the Apperta Foundation CIC standards as outlined in its implementation standards based upon and through reducing the reliance on a single vendor, as per the benefits of an open source solution. In addition, the Apperta Foundation CIC supports the use of (NOTE: Details for the Apperta Foundation CIC "Defining an Open Platform" report can be found here https://community.apperta.org/assets/191794753/Apperta_Defining_an_Open_Platform_SP.pdf )open standards and open platforms within the Health & Care IT ecosystem.
Apperta products are (NOTE: Further details that describe open source can be found at https://opensource.org/osd based upon the Debian Free Software Guidelines https://www.debian.org/social_contract#guidelines )open source and are in majority available under the AGPL 3.0 licence, users have the freedom to use, study, change and distribute the source code. Several of the benefits outlined above derive from the solution being open source and support the approach outlined by the Apperta Foundation CIC custodian model.

Details for the Apperta Foundation CIC "Defining an Open Platform" report can be found here https://community.apperta.org/assets/191794753/Apperta_Defining_an_Open_Platform_SP.pdf

7 More details can be found here: http://www.linfo.org/vendor_lockin.html

Further details that describe open source can be found at https://opensource.org/osd based upon the Debian Free Software Guidelines https://www.debian.org/social_contract#guidelines

    3. **Alignment with commissioner objectives/priorities**

    4. **F****it with national policy **

Lord Carter’s Report

In June 2014, Lord Carter was asked by the Secretary of State for Health to look at what could be done to improve efficiency in hospitals in England. In Lord Carter’s interim report from June 2015 he described the widely varying resource utilisation across the NHS, and estimated that there could be a £5bn reduction in cost linked to the unwarranted variation across acute Trusts from the £55.6bn spent annually by acute hospitals. The final report published in February 2016, details how these efficiencies can be achieved between now and 2020, and it makes 15 recommendations designed to tackle this variation and help acute trusts improve their performance to match the best. The recommendations of relevance here are:

All trusts should have the key digital information systems in place, fully integrated and utilised by October 2018
NHS England and NHS Improvement should work with trust boards to identify where there are quality and efficiency opportunities for better collaboration and coordination of their clinical services across their local health economies, so that they can better meet the clinical needs of the local community
NHS Improvement should develop the Model Hospital and the underlying metrics, to identify what good looks like, so that there is one source of data, benchmarks and good practice
NHS Improvement should, in partnership with CQC and NHS England, by July 2016, develop an integrated performance framework to ensure there is one set of metrics and approach to reporting, so that the focus of the NHS is on improvement and the reporting burden is reduced to allow trusts to focus on quality and efficiency

Getting It Right First Time - GIRFT

The Getting it right first time (GIRFT) programme is a partnership between the NHS Royal National Orthopaedic Hospital Trust and NHS Improvement to support NHS trusts to improve care quality and increase operational productivity by reducing unwarranted variation in care. The programme encompasses 35 clinical and medical specialties delivered in acute hospitals, with work underway to expand into mental health services.

The GIRFT programme is a data driven collaboration between trusts and the national level. Refining datasets to capture the most important and meaningful metrics is important, particularly in clinical specialties where current datasets are insufficiently granular to support nuanced debate about unwarranted variation. Specialties with less developed datasets, especially mental health, will require significant co-production with trusts before analysis can offer meaningful insight.

Data is the starting point in a complex process to eliminate unwarranted clinical variation by establishing what is and isn’t warranted, agreeing how to tackle this and then delivering the changes to clinical practice required and unlock the savings originally identified.

The GIRFT programme aims to save around £1.4bn per year by 2020/21, which equals just over a quarter of the financial gap facing the NHS by 2020/21.

The Model Hospital

The Model Hospital is a digital information service designed to help NHS providers improve their productivity and efficiency. The second interim recommendation in Lord Carter’s review of hospital efficiency was to "develop a ‘model NHS hospital’ to help providers aspire to best practice across all areas of productivity". It is creating transparency in terms of pricing for treatments.

GIRFT output is the input for the Model Hospital. The Model Hospital delivers benchmarking across all specialities, cost types and Trusts. It will guide commissioners in terms of pricing but it falls to the Trusts to get their costs in line with the benchmarks set by the Model Hospital.

If you are able to capture all of the activities clinicians are performing in relation to a patient when this is matched with financial data you are able to deliver patient level costing. Open source solutions provide this by definition with open APIs and interface architecture components to send information on a very granular level (patient, episode, activity, actor, treatment, etc) to financial management systems. The ability to collect all variable costs related to a patient and their treatment is the precondition for full patient level cost transparency.

Paperless 2020

The ‘Personalised Health and Care 2020’ framework, released in November 2014, which set priorities around replacing paper at the point of care and giving patients more control of their health through technology and data.

Care Quality Commision

The CQC now include data safety in their assessment framework and inspection approach to assure that appropriate validation against the new data security standards have been carried out. The inspection regime will validate the principles stated within ‘The CQC Safe Data, Safe Care Report’, July 2016, report are up held within the organisation.

Data security is defined in this review as:

Availability – how patient information is available to all those who need it to provide care where and when it is needed.

Integrity – how patient information is protected from unauthorised alteration, damage and loss.

Confidentiality – how patient information is kept confidential: safe from access by those without authorisation to read, see or hear it.

CQUIN Targets

CQUIN stands for commissioning for quality and innovation. The system was introduced in 2009 to make a proportion of healthcare providers’ income conditional on demonstrating improvements in quality and innovation in specified areas of patient care. This means that a proportion of our income depends on achieving quality improvement and innovation goals, agreed between the Trust and its commissioners. The key aim of the CQUIN framework is to secure improvements in the quality of services and better outcomes for patients, a principle fully supported at all levels of the hospital.

Meeting CQUIN targets avoids reduction of money the Trust is going to receive from the Commissioners.

Check targets for coverage by this project.

National CQUIN Targets: https://www.england.nhs.uk/nhs-standard-contract/cquin/cquin-17-19/

Technology Code of Practice

The Technology Code of Practice is a set of criteria to help government design, build and buy better technology. It’s used as a cross-government agreed standard in the spend control process and is part of the Transformation Strategy 2017-2020.

You must follow this code from the start of your technology programme or project. The Technology Code of Practice: Related Guidance collates all the relevant guidance from across government. You can use this to find more information on each Technology Code of Practice topic.

The Technology Code of Practice:

Define user needs - Understand your users and their needs. Develop knowledge of your users and what that means for your technology project or programme.
Make things accessible - Make sure your technology, infrastructure and systems are accessible for users.
Be open and use open source - Publish your code and use open source to improve transparency, flexibility and accountability.
Make use of open standards - Build technology that uses open standards to ensure your technology works and communicates with other technology, and can easily be upgraded and expanded.
Use cloud first - Use public cloud first as stated in the government’s cloud first policy.
Make things secure - Keep systems and data safe with the appropriate level of security.
Make privacy integral - Make sure citizens’ rights are protected by integrating privacy as an essential part of your system.
Share and reuse technology - Promote good practice and avoid duplicated efforts by sharing and reusing services, data and software components.
Integrate and adapt technology - Your technology should work with existing technologies, processes and infrastructure in your organisation, and adapt to future demands.
Make better use of data - Consider how to minimise data collection and reuse data to avoid duplication of datasets.
Define your purchasing strategy - Your purchasing strategy must show you’ve considered commercial and technology aspects, and contractual limitations.
Meet the Digital Service Standard for digital services - If you are building a service as part of your technology project or programme you will also need to meet the Digital Service Standard.

International Asset

The model of Open Source software provides a clear and sustainable business and cultural model for such sharing of medical knowledge as an international asset of the commons.

<INSERT – INSERT CONTEXT OUTLINE ANY NATIONAL POLICIES THAT THE PROJECT ALIGNS WITH>** **

For instance Safe Wards, Safe Staffing Levels.

    5. **Customer user needs – current and future**

Define Customers:

Primary - Clinical
Secondary - Back Office, Managerial
Tertiary - CQC, Research, National Audit, Commissioners, Patients
```
  6. **Improvement of current service delivery arrangements**
```

Describe future to be state (for example):

Paper to electronic records with benefits of electronic data
Open APIs
Open standards
Agile, open source community model, adapting guided by community of engaged clinicians who are using the system (validity/lifespan of benefits changing business/clinical practice)

Balanced Scorecard KPI model

  7. **Potential scope for further development/scalability **

Open source model - part of the decision making guiding the development of the solution, contribution of clinical capital into National/International owned asset, not shut off from continuing development and information sharing in open source community

Economies of scale - no economies of scale benefits to proprietary software - the model inhibits that however with the OS costs fall as community grows and benefits increase. Audience for this? Barrier free entry of other developers to contribute, might already be thriving community of devs at your disposal.

Benefit realisation with open source model with the input of the knowledge and expertise of the clinical users which has been acquired with a huge cost to the healthcare sector at large using taxpayers money stays with and is made available to all with the product compared to the proprietary software where the benefits stay with the private company. Good ideas contributed and realised from subject area experts using system

Established infrastructure in place to contribute and collaboration in the development of new features and functionality. User Voice, forums, user groups, subspecialties.

Cost to end, the longer you use a system the more entrenched it becomes. If the proprietary vendor moves away from the product there is a danger it will become unstable and unusable and will need replacing in any case.

    8. **Benefits and risks **

    9. **Constraints and dependencies**

Clinical safety case
1. Medical Device Class Statement

General Principles

Medical devices are defined as articles which are intended to be used for a medical purpose.
It is the intended purpose that determines the class of device and not the particular technical characteristics of the device.
The intended purpose of the device should be substantiated (if required) and be representative of the technical characteristics of the device.
It is the intended and not the accidental use of the device that determines its class.
It is the intended purpose assigned by the manufacturer to the device that determines the class of device and not the class assigned to other similar products.
Accessories are classified separately from their parent device.
The mode of action of a medical device should be clear and evidenced with appropriate data to confirm this mode of action.
If the device can be classified according to several rules then the highest possible class applies.
Multipurpose equipment which may be used in combination with medical devices are not themselves classed as medical devices unless the manufacturer places them on the market with the specific intended purpose as a medical device.
If the device is not intended to be used solely or principally in a specific part of the body, it must be considered and classified on the basis of the most critical specified use.
Standalone software is regarded as driving or influencing the use of a device and so falls automatically into the same class. Software is classified on a case-by-case basis. If the output of the software is general patient information, the software is generally not a device. If the output of the software is based on analysing/manipulating clinical data to facilitate diagnosis or determine treatment schedules, the software is more likely to be a medical device.
1. Clinical Safety Gold Standard Apperta ISB 0129 (SCCI0129)

3. Patient Safety Risk Management Interfaces ISB 0160 (SCCI0160)

Economic Case

This section of the Business Case assesses the economic costs and benefits of the proposal to society as a whole, and spans the entire period covered by the proposal. These are not the same as the financial costs to the decision-maker. You should present the key findings of your financial analysis and the overall conclusions.

1. Appraisals of costs and benefits 

    10. **Total Cost of Ownership **

Rank provides the weight (as regards the cost to the procurement process of that Phase, not necessarily as regards its importance): low=1, medium=3 and high=5. The factors are based on the verbose statements. Zero cost=0, low cost=1, medium cost=3 high cost=5. The total score for each criteria per option is weight * factor and the total score per option is shown at the bottom of the table below.

Phase	Rank	Consideration	Description	Proprietary	Open Source	Apperta Foundation value add for the NHS
Evaluation	Low (1)	Cost of evaluation the solution (PDF and DocX based)	In arriving at the right solution option It is necessary to evaluate the various options. This is not typically considered part of the ICO but has been included for completeness. While the cost of the research for Open Source versus Proprietary will differ to an extent an important point to note Is that Open Source options could be overlooked If traditional sources of information (e.g. analyst reports) are used exclusively. This Is more likely to be the case if someone who does not have an IT background carries out the Initial research.	Literature (analyst material, technical documentation, marketing material etc.) is generally more developed for the established proprietary and Open Source products. However, analyst material carries a cost where Open Source material Is generally free and available online. (1)	PDF and DocX based documentation is freely available. (1)
	Low (1)	Cost of evaluation the solution (proof of concept)	Prior to making a decision on the solution it may be necessary or desirable to carry out a proof of concept. Alternatively if the solution decision Is being driven by the IT department the first step of an evaluation may be to download the most promising looking Open Source software solution and "play around with It" to see If it is suitable. This can be considered as "adoption led selection" as opposed to "procurement led selection" and while this can lead to the best solution being selected it can equally led to a solution with a high TCO being adopted without due consideration every being given to lifetime cost.	High as licences typically need to be purchased to support the proof of concept. Pre-sales effort can reduce this. (5)	Free to download versions are available to support proof of concept work. However, it should be noted that where Proprietary vendors typically have extensive pre-sales support this Is not generally available for Open Source solutions. This can have an adverse Impact on the cost of evaluation. (3)	Free to download versions are available to support proof of concept work Online demonstration versions are often available for Apperta systems. The Apperta Foundation and it’s trusted supplier network are able to provide pre-sales support. (1)
Procurement	High (5)	Cost of procurement process	Crown Commercial Service G-Cloud Framework Approved Suppliers have been preselected by the Crown Commercial Service (CCS), which means International OJEU procurement regulations and processes have already been followed and suppliers have already had statutory compliance and due diligence checks performed. For NHS organisation’s buying direct from frameworks is easy, as the CCS has already navigated the complexity of procurement legislation for you. Buying from frameworks avoids the need to go through long protracted OJEU procurements, saving time, effort, and money on procurement processes. In addition, some proprietary software choices might force you to procure through a third party.	Proprietary software suppliers might or might not be on G-Cloud. (3)	Open Source software service suppliers might or might not be on G-Cloud. (3)	All Apperta Foundation product service suppliers are on G-Cloud. (1)
Upfront	High (5)	Capital cost of software	One of the most important considerations with respect to upfront cost.	High. (5)	Zero although there may be some capital cost for proprietary extensions. (1)
	High (5)	Cost of functional customisation	One of the most important considerations with respect to upfront cost. It is dependent on: - The functional fit of the software to the business requirements -The ease of customising the software to meet the requirements - The cost and availability of skills to make the customisations	Dependent on functional fit not on licence model per se. Factors to consider are ease of implementation and availability / cost of resource to carry out customisation. (3)	Dependent on functional fit not on licence model. Cost of resources to carry out customisation are lower because there is no ‘vendor lock-in’. (1)	Dependent on functional fit not on licence model. In the Apperta model, costs for customisation if they are sector and not Trust specific are shared between all members of the Apperta SIG and therefore lower than the costs in the proprietary model. (1)
	Medium (3)	Cost of Integration	Similar to, or though usually less significant, functional customisation. It is dependent on: - The ease of integration. Partly based on integration options and partly on the quality of design (i.e. is there a well documented and designed API) - The cost and availability of skills to carry out the integration	Dependent on integration complexity, but additional factors to consider are: if you have access to source code and data models,, whether standard integration patterns and formats are supported, and cost of resource. Cost of resource tend to be higher with proprietary solutions, because of ‘vendor lock in’ and the inability to acquire services from a different provider. (3)	Open Source solutions are easier to integrate with because all the code, data models etc. are publicly available. In addition, Open Source software will use open standards whenever they are available. (1)	Open Source solutions are easier to integrate with because all the code, data models etc. are publicly available. In addition, the Apperta model strongly encourages the use of standard integration patterns, but also the use (and provision of) Open APIs, which is usually missing from proprietary software. (1)
	Medium (3)	Migration cost	Cost of migrating data and users from the legacy solution to the new solution. The cost of migration may be reduced if the source and target solutions conform to documents and data standards (something that is more common in Open Source solutions).	Dependent on available documentation. (3)
	Medium (3)	Cost of infrastructure	Determined by a number of factors that are not greatly influenced by the licence model: - The expected load that the solution will place on the infrastructure - The Operating System and RDBMS that the solution requires (Open Source solutions are less likely to be restrictive).	Mainly dependent on quality of design and non-functional requirements. Proprietary solutions usually depend on components from third parties (eg. databases). (3)	Mainly dependent on quality of design and non-functional requirements. Many Open Source are able to work with third party solutions but are completely agnostic to them. Thus allowing you to re-use existing licences, but also giving you the freedom to run completely without them as well. (1)
	High (5)	Training cost	This is usually a small component of the upfront cost but for some desktop applications or business applications it may be significant.Training costs are usually significantly underestimated, are hidden from procurement, and wholly absorbed by existing in-house training team.	Dependent on quality and familiarity of User Interface. Web first apps that use contemporary design patterns (eg. Facebook scroll to refresh, swipe to action) will be naturally adopted by staff regardless of their age. (3)
Support	Low (1)	In-house support cost (usually considered first and second line support)	This is most likely to be a cost that is shared across multiple applications / solutions that require support. It will be influenced by how intuitive the solution is to use (the quality of the Ul) and by the administrative tools available to support staff (e.g. admin console to reset user passwords or change access rights).	Assuming that first line support is largely non-technical then this is not dependent on licence model. It will be based on the established cost of the IT service desk. However, some vendors enforce minimum training and accreditation levels for in-house staff. (1)
	High (5)	Vendor support cost	The magnitude of this cost will be directly proportional to the level of customisation carried out and the capabilities of the supporting organisation. Solutions that are largely ‘out the box’ and that align with an organisation’s IT strategy are likely to have a lower cost of ownership.	No choice but to accept the SLAs offered by the vendor. (5)	Choice of suppliers which meet your organisational needs. (3)	Apperta foundation assures vendor alignment with community values. (3)
Maintenance	High (5)	Software maintenance (of the vanilla product)	Enterprise level software typically requires defect and security releases to address identified defects and security flaws. These releases can be provided as patches or complete releases.	Vendors typically provide defect releases and security patches as part of annual maintenance or subscription fee. In addition to this fee the cost of applying defect fixes and security patches should be factored into the TCO as should the cost of periodically moving to a major new release. Proprietary vendors' timescales for such improvements may not necessarily accord with either the industry standard for fixes/patches OR the organisation's needs An example for that is the EMIS Web/Win 10 story. (5)	There is a greater responsibility on your in-house team to monitor for maintenance releases of dependant components.. Published vulnerabilities and release of defect fixes / security patches need to be monitored. The cost of this and the cost of applying fixes needs to be considered. (3)	Apperta Foundation community members benefit from dependency scanning, update alerts, and automatic subscription to notifications from project maintainers and recognised service providers. (1)
	High (5)	Software maintenance of any bespoke or customised parts of the solution	Where the solution includes bespoke code or customisation of the base software product then there is a need to provide ongoing maintenance for these elements.	The software vendor may exclude bespoke modifications from standard support agreements / costs. (5)	In Open Source software, encourages bespoke customisation. (3)	Apperta Foundation value add for bespoke / customisation is that maintenance costs are shared between members. (1)
	High (5)	Software upgrades	For solutions that will be in place for a number of years there is a need to consider the cost of moving to new releases of the software if this is required. The key determinant is whether it is required at all.	Ongoing support agreements may force software upgrades even if it is not required for business reasons. This may drive both increased licence cost and upgrade costs. If a vendor goes out of business, this may also force a trust into a costly and unnecessary upgrade. Software upgrades can also force hardware upgrades, for instance iOs mobile apps which with a newer version don’t work on older iOS versions and therefore force mobile device replacements. (5)	Customer is free to choose when to upgrade. (1)
	High (5)	Enhancement	The cost of making functional enhancements to meet the changing needs of the business.	Vendor lock-in means the cost of enhancements to proprietary software is up to the vendor. (5)	Enhancements to Open Source systems are encouraged. (1)	Apperta Foundation members have share the costs of functional enhancements. (1)
Exit	Medium (3)	End of Life	The costs associated with the risks the vendor or maintainer ending the life of the product	You have no choice but to reprocure. (5)	In the event of a maintainer abandoning a project (the open source equivalent of EOL), you are able to choose from alternative providers of technical services. (3)
	Medium(3)	End of term	Cost of renewing support agreements beyond initial term	Support can only be provided by the original vendor. (5)	Alternative providers of support services are available. (3)
	Medium (3)	Migration	The cost of moving data and content from the proposed solution to a future solution that is replacing it.	Proprietary vendors do not share code or data models, therefore making migration efforts more costly for third parties. (3)	The publicly available source code, access to an open knowledge sharing community, are key factors which keep these costs at a minimum. (1)
Option				Proprietary	Open Source	Open Source within the Apperta Foundation framework
Total Cost of Ownership Score (lower means better)				268	136	104

    11. **Benefits**

Where this business case document is used as guidance for an application to a national technology found (eg. SHSW, NTF) please refer to the published benefits case materials.

    1. **Quantifiable Benefits**

To be done by the individual projects.

    2. **Non-quantifiable Benefits**

To be done by the individual projects.

2. Options appraisal

Any clinical information system should provide overall good coverage of clinical need at your organisation. No product will have 100% coverage of all needs of each specialty, ward, provider modality, etc. Consequently functional coverage analysis beyond the point of national open standards must be linked to the flexibility of adopting new national standards, adapting to regional service configurations (e.g. open information sharing) and local policy changes.

    12. **Option 1: Do Nothing**

No change, no investment. Describe current situation (paper based, functional shortcomings, no process coverage, etc).

    13. **Option 2: Proprietary Software solution**

Describe solution briefly. Explore shortcomings of proprietary solution in terms of fit to the strategic case, as well as other limiting factors.

    14. **Option 3: Open source / Apperta solution

**

Describe solution briefly. State link-up of open source solution / Apperta approach with strategic case.

3. **Options Appraisal Outcome**

Ethics: The software and technology intrinsic to the practice of modern medicine should be treated the same way as medicine and therefore openly published, peer reviewed, verifiable and audited. Furthermore the philosophy of sharing at the heart of medicine and indeed the NHS means that clinicians volunteer freely of their deep expertise and experience to these projects because they understand open source health applications are public assets for the common good. This collaborative approach is very much akin to how improvements in medicine are also shared in their wider professional lives. If you improve something, it can be shared with the community and in return you freely benefit from developments made with the resources and expertise of the entire community.

National strategy: It is the Government Transformation strategy as stated in The Technology Code of Practice that any technology project must publish code and use open source to improving transparency, flexibility and accountability. The use of open standards ensures technology works together with other technology and can be easily upgraded and expanded.

Total cost of ownership: Option 2 and option 3 have similar benefits but a different Total Cost of Ownership (TCO) score. Option 2, proprietary software has a TCO score of 262 whereas option 3, the Open Source / Apperta solution has only a score of 98. A lower score means a lower TCO, in this case a significant lower TCO for the Open Source / Apperta solution.

Apperta: In the Apperta open source model users have the freedom to use, study, change and distribute the source code of products. The custodianship of the software and the "gold standard" version of the code is managed by a clinically led group of users, as such, design choices for the solution are demand driven and the responsibility for the software, any investment made and the outcomes it achieves is shared across each of the members. The model benefits from the use of open standards and open platforms, fast and simplified procurement on government frameworks, with development and implementation possible by any supplier of choice without the vendor lock in of a proprietary product.

Under the Apperta model of custodianship and governance benefits are achieved which are not available from any of the alternatives. Full alignment with the Government Transformation Strategy, a strong ethical case and from the a and a significantly lower total cost of ownership. The ethical prudent use of national resources.

4. Critical success factors to achieving the Economic Case

Being a member of the Apperta Foundation SIG.

5. Risk assessment

Commercial Case

The Commercial Case demonstrates that the project will result in a viable and well-structured procurement solution. This section should include details relating to the planning and management of the procurement. It requires the buyer to see how the service will be procured competitively and in accordance with procurement requirements.

1. Procurement strategy

Crown Commercial Service G-Cloud Framework Approved Suppliers

Framework suppliers have been preselected by the Crown Commercial Service (CCS), which means International OJEU procurement regulations and processes have already been followed and suppliers have already had statutory compliance and due diligence checks performed. For NHS organisation’s buying direct from frameworks is easy, as the CCS has already navigated the complexity of procurement legislation for you.

A CCS supplier is required to make you aware of using these frameworks. Buying from frameworks avoids the need to go through long protracted OJEU procurements, saving time, effort, and money on procurement processes. Buying direct from frameworks also means public sector spending limits are no longer an issue, as international OJEU procurement contract value rules have already been satisfied as part of inviting suppliers to join the framework.

2. Contractual arrangements

<INPUT – OUTLINE THE NATURE OF THE CONTRACTUAL RELATIONSHIP THAT WILL EXIST BETWEEN THE CUSTOMER AND YOURSELF>

3. Charging mechanism

Financial Case

The Financial Case demonstrates that the project will result in a fundable and affordable arrangement for the decision-maker. You need to summarise the overall capital and revenue affordability of the project, including any additional funding requirements. There are different ways to present this information that will be appropriate for different projects; some template tables are included below as examples. For further information, please see HM Treasury’s guidance by clicking here.

1. Capital and revenue requirements

Description	Value	Start date	End date

2. Resource requirements

Total funding required
What is it for? (equipment, facilities, external expertise etc)	When is the cost incurred?
	Year 1 2015/16	Year 2 2016/17	Year 3 2017/18	Year 4 2018/19



Total

Funding currently secured (if any)

Where is it from? (Grant, revenue budget, capital budget – include cost centres if known)

When will the money be available?

Year 1 2015/16

Year 2 2016/17

Year 3 2017/18

Year 4 2018/19

Total

Staff Resources

Service Area/Function

FTE’s

When are new staff needed?

Year 1

Year 2

Year 3

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Q1

Q2

Q3

Q4

Total

Balance of funding requested
Total	Year 1 2015/16	Year 2 2016/17	Year 3 2017/18	Year 4 2018/19

3. Impact on income and expenditure account

4. Financial benefits

    1. **Financial benefits table**

Description Please include: How the saving is calculated Whether the saving is revenue or capital	Benefit Year 1 2018/19	Benefit Year 2 2019/20	Benefit Year 3 2020/21	Benefit Year 4 2021/22	Cost Centre / Budget affected?	Who is the current budget holder?	Has the budget holder agreed to the saving? (Y/N)

    2. **Requirements in order to realise savings**

<INSERT - WHAT ARE THE CRITICAL THINGS THAT MUST HAPPEN IN ORDER TO CAPTURE THE SAVINGS?>

5. Non-financial benefits

Management case

The management case demonstrates that the project is capable of being delivered successfully, in accordance with recognised best practice.

This section requires the project to demonstrate that there are robust arrangements in place for project management, change management and contract management, the delivery of benefits and the management and mitigation of risk (you could include a risk and benefits register as appendices.

It also requires the project team to specify the arrangements for monitoring during implementation and for post implementation evaluation, and the contingency plans for risk management.

1. Programme and project management plans

The solutions and the supplier are agnostic to delivery method. Acceptance testing procedures and processes will be agreed between Trust and supplier as part of the project.

All integration, development or implementation services to be provided using agile methodology. This will enable the delivery of systems more efficiently with reduced waste, in a shorter time frame and for less cost than more traditional methods. Also allowing fast reactions to changing business requirements throughout the project.

Deployment options - Software as a service option available/local hosting benefits. Deployment, supplier accreditation.

2. Change management arrangements/requirements

3. Approach to management and delivery of benefits

4. Approach to risk management

5. Monitoring during implementation

6. Post implementation evaluation arrangements

7. Contingency arrangements/exit strategy

<INSERT – DETAILS OF CONTINGENCY ARRANGEMENTS SHOULD TOLERANCES BE EXCEEDED DURING THE IMPLEMENTATION STAGE>

Conclusions and salient issues for further consideration
1. Conclusions

2. Salient issues for consideration

Appendices

You could include your implementation plan, risk register, benefits register in an appendix. You could also include comments from project team leads and partners to support your case.

References

Original citation: Shaikh, Maha and Cornford, Tony (2011) Total cost of ownership of open source software: a report for the UK Cabinet Office supported by OpenForum Europe. UK Cabinet Office, London, UK. (Submitted) This version available at: http://eprints.lse.ac.uk/39826/

Lord Carter of Coles (2016) Operational productivity and performance in English NHS acute hospitals: Unwarranted variations An independent report for the Department of Health

This version available at: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/499229/Operational_productivity_A.pdf

Baw, Marcus (2018) Open Source and Medicine - Medicine Was There First (CC-BY-SA)

original presentation: https://pacharanero.github.io/opensourceistheonlyway/#/

blog post version available on Medium shortly

The Technology Code of Practice. This version available at: https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Apperta Template Business Case.md

Apperta Template Business Case.md

<INPUT – OUTLINE THE NATURE OF THE CONTRACTUAL RELATIONSHIP THAT WILL EXIST BETWEEN THE CUSTOMER AND YOURSELF>

<INSERT - WHAT ARE THE CRITICAL THINGS THAT MUST HAPPEN IN ORDER TO CAPTURE THE SAVINGS?>

<INSERT – DETAILS OF CONTINGENCY ARRANGEMENTS SHOULD TOLERANCES BE EXCEEDED DURING THE IMPLEMENTATION STAGE>

Files

Apperta Template Business Case.md

Latest commit

History

Apperta Template Business Case.md

File metadata and controls

<INPUT – OUTLINE THE NATURE OF THE CONTRACTUAL RELATIONSHIP THAT WILL EXIST BETWEEN THE CUSTOMER AND YOURSELF>

<INSERT - WHAT ARE THE CRITICAL THINGS THAT MUST HAPPEN IN ORDER TO CAPTURE THE SAVINGS?>

<INSERT – DETAILS OF CONTINGENCY ARRANGEMENTS SHOULD TOLERANCES BE EXCEEDED DURING THE IMPLEMENTATION STAGE>