Guide - How to embed open data into the procurement of public services

This guide outlines why open data is useful for public services and explains how open data can best be embedded into the process of procuring them.

For public service providers, it explains what kinds of data they can collect and share about themselves or their services, and how to make it open.

For public service procurers, it explains how to maximise open data by including it in contracts, calls for tenders and evaluation of bids and services.

Contents

When is open data useful in public procurement?

How is open data in public services produced and used?

How to embed open data into agile project design

Procuring through framework contracts and G-Cloud

What to include in invitations to tender

Requirements and evaluation questions

How to incorporate open data when evaluating proposals

When is open data useful in public procurement?

There are many benefits of open data for the public sector. It can help deliver value for money, aid quality of service, and by improving transparency help competition and underpin accountability.

Everything involves data. When buying any type of good or service, you should think about what open data are you going to require your supplier to produce, and what open data they should use. You should bear in mind that the open data requirements should be proportional to the nature of the contract. Open data considerations are particularly important when transparency can enhance operational efficiency and value for money of the contract.

It is much easier to make decisions about open data requirements before procuring something than it is to try and change existing contracts to be more aligned with open data policies. Therefore it is important to consider open data as an integral part of public procurement:

• from the earliest stage, to ensure you have fully taken your open data responsibilities into account, and also considered opportunities to produce and use more open data

• when requirements are being framed, to ensure the service will produce and use the open data assets you have identified

• when the draft contract is being drawn up, to ensure that intellectual property ownership is addressed

• when advertising an opportunity and inviting tenders, guiding bidders how to respond to the open data requirements

• at selection stage by ensuring the evaluation addresses your open data requirements

• after contract award, to make sure open data commitments are adhered to, as part of your performance management approach

The Public Services (Social Value) Act 2012 says that the public sector has to consider the economic, environmental and social benefits of a procurement before starting any procurement process. Producing, using and contributing to open data are all very important types of social value. Considering open data as part of the social value of your procurement can change the whole shape of the services you are buying as well as your procurement approach. You should address the open data issues identified in this guide before starting your procurement, to benefit from the opportunities of open data and to fulfil your legal duty to consider the social value of your procurement.

Procurement rules impose some constraints, for example around whether you can specify the use of a particular open data resource. However, there is considerable scope to include open data considerations particularly where they are related to the primary purpose of the contract. And there are many benefits to be gained from framing open data requirements as part of public procurement.

Open data can enable organisations to work together in different ways, supporting alternative approaches to delivering public services. Public sector organisations, companies and others can all collaborate around creating and maintaining open data, without necessarily needing to enter into a contractual relationship involving a procurement.

Open data also helps to reduce the lock-in to a particular provider and should therefore be part of your organisation’s overall procurement strategy.

How is open data in public services produced and used?

Open data can be produced as a result of performing a public service, and can be used to inform the performance of that service.

Producing open data

There are four types of data that are produced and maintained by services procured by government:

• performance data about how well the supplier is fulfilling the contract in terms of performance against contracted targets,

• administrative (exhaust) data created as a by-product of fulfilling the contract,

• reference data that is used in fulfilling the contract, and

• infrastructure data whose creation and maintenance is the main focus of the contract.

There are separate requirements around each of these sources of data which you should include within your procurement. In framing requirements, you should be aware of the likely capability of the suppliers to perform analysis and to publish data themselves, and your own capabilities to perform those functions, perhaps delivered to you under a different contract. Your requirements need to be proportional to the nature of the contract. For example, you may expect suppliers of large contracts to be able to analyse and publish data on your behalf, but only expect suppliers of small contracts to provide you with the underlying data you need to do this analysis for yourself.

Including requirements about the publication of open data will give assurance that you are complying with the openness principle when your project is reviewed by the Government Digital Service as part of the spending controls process for IT projects.

Performance data

Every government contract should include requirements about publishing performance data as open data.

Re-procuring is a good opportunity to publish past performance data as open data. If your current contract does not enable you to do this, you can ask your supplier whether they would be willing to let you publish this information as open data. This may even save you from having to run a restricted data room for bidders during re-contracting.

Using past performance data, potential suppliers can understand which parts of the contract are easy or difficult, or judge how well incumbent suppliers have performed. Having this data available helps to enable competition during the tendering process.

During the life of the contract, open data about performance introduces transparency and accountability into the performance of the service. It can also incentivise suppliers to perform above standard.

For suppliers, publishing performance data can enable them to substantiate claims about their performance. Performance data can also help citizens make more informed choices about the services they use.

We recommend that open performance data is published to a ‘Standard’ level against the Open Data Certificates. We also recommend using open standards when publishing performance data as this enables it to be more easily published, compared and visualised. Contracts should include a list of performance data that should be published as an output of the service, as part of the performance management regime.

Administrative (exhaust) data

Providing almost any type of service involves the creation and maintenance of administrative data, which is sometimes termed exhaust data. This is data that is created and managed as part of delivering the service, often because it is needed to operate efficiently. This data may be information about the users of the service or the resources used to deliver the service. For example, real-time data about where trains are within the train network, or the records of everyone who has been through border controls, are administrative data.

Administrative data is very important, often with untapped potential. This data forms the basis of important management information that you can use to understand better the demands on the service and the effects of changing policy. This data may also be of interest to businesses and third-sector organisations who wish to better understand the context in which they operate, and to researchers in economic and social policy. You should frame requirements in your procurement to enable administrative data to be made available as open data, whenever possible.

Administrative data may include personal data collected about people accessing or using the service. Personal data cannot be published as open data without permission, but it can be aggregated and anonymised to create statistical data which can then be published.

We recommend that open administrative data is published to an ‘Standard’ level against the Open Data Certificates. Contracts should include a schedule that lists the data that should be provided to enable publication of administrative data as an output of the service.

Reference data

Reference data is essential information that is frequently referenced in data from multiple sources. For example, information about railway stations — what they are called and where they are — might be referenced in data about railway timetables, about rail service operators, about transport links and so on.

Reference data is often created and maintained as a necessary by-product of performing a service: if you need to know where railway stations are in order to paint them, then you will have to create and maintain a list of them. Having many of these lists maintained across the public sector through the performance of separate contracts is inefficient: a better approach would be if these lists were published and maintained as open data so that everyone, including those outside the public sector, could make use of, and reference, the same data.

You should analyse what reference data is likely to be maintained as part of performing the service. It may be that there are other, open, sources of that reference data which should be reused to save maintenance costs.

We recommend that open reference data is published to an ‘Expert’ level against the Open Data Certificates. Contracts should include a schedule that lists the reference data that should be provided for publication as an output of the service.

Infrastructure data

Any information assets that are created as the principal output of a government contract are by definition important to government and society. Your organisation may have a statutory duty to make the information available, or these data assets may have been listed within the National Information Infrastructure. Unless there is a very good reason for this information to be withheld, such as national security or privacy, then it should be available as open data.

Contracts whose principal output is infrastructure data will need to contain a range of specific requirements about four aspects of its publication:

• legal aspects such as rights, licensing and data protection

• practical aspects such as availability, timeliness and quality

• technical aspects such as data formats and API access

• social aspects such as documentation, support and services around the data

These four aspects are addressed in the Open Data Certificate.

You should have a mandatory general requirement that the data is published at an ‘Expert’ level against the certificate. If you are framing an evaluation, there should be a pass/fail question against this requirement.

You should also use the Open Data Certificate as a tool during the process of framing specific requirements for the service. This will help you make sure you are covering all aspects of open data publication. You should have requirements against each of the requirements in the Expert level Open Data Certificate, to help ensure that the data can be published at Expert level.

The Open Data Institute offers a range of services that can help you during this process, including training and consultancy, and can act as a convening point for discussions with potential reusers of your data to ensure that the data publication is fit for purpose.

Using open data

Requirements around using open data in performing a service need to be framed carefully to avoid unfairly discriminating against suppliers who use different (possibly closed) sources of data to provide the same service.

You can specify that suppliers must use particular open data if it relates to fulfilling a recognised standard. For example, if the supplier needed to validate information about companies to provide the service, you could specify that they must use the open data from Companies House. When an industry standard is a closed data set, but you have discretion to allow an open alternative, then you should do so. You should avoid requiring the use of closed data as a technical specification.

If you’re procuring services where the primary purpose is producing or making available open data then it is reasonable to frame specific requirements that suppliers use open data in the delivery of those services.

If you are not procuring a service whose primary purpose is to produce or publish open data, and the open data that you would like the supplier to use does not relate to fulfilling a recognised standard, there may be a risk of challenge, from suppliers whose solution is based on closed data, if you mandate the use of open data. To avoid this risk, you should encourage the use of open data by making sure the whole-life cost of using closed data is fully factored in to your price-based evaluation. For example, it needs to take into account the cost of exit and the cost of licensing ongoing use of the closed data in future under a new contract.

Embedding open data into procurement processes

This section explains how open data can be incorporated into different parts of the procurement process, in agile projects, framework contracts, invitations to tender, evaluations and contract negotiation.

How to embed open data into agile project design

If you are running an agile project, open data should feature in your vision statement. You should identify data users and aim to address their needs.

An alpha version or Miniminum Viable Product should include publishing open data to the ‘Raw’ level of the Open Data Certificate. This will ensure that open data publication is embedded by design into your system rather than retrofitted later.

A beta version should include publishing open data to the ‘Pilot’ level of the Open Data Certificate. This will help you to gather feedback from open data users which can inform the design of the live system.

The live system should publish open data to the ‘Standard’ or ‘Expert’ level of the Open Data Certificate, depending on the importance of the data assets as discussed above.

The Open Data Certificate reflects data users needs. Throughout an agile project, it can be helpful to frame user stories around particular questions within the Open Data Certificate to ensure those needs are met.

Procuring through framework contracts and G-Cloud

If you have a choice between running your own procurement or using a framework contract, you should consider your open data needs and how well those will be met by the different approaches. Open data requirements may or may not have been built into the standard terms and conditions within framework contracts.

Procuring through G-Cloud

The aim of G-Cloud is to make it easier for the public sector to access and use utility-based ICT services and easier for suppliers to work with public sector organisations.

There are a wide variety of different services available through the G-Cloud that can help you to deliver open data. This framework is very good for commodity ICT service provision, such as hosting or storage services. There are also a number of specialist data services available through the G-Cloud, for example for data modelling, analysis, publication or visualisation, which are typically provided on a consultancy basis. Finally, there are specialist open data services on offer including consultancy and open data publication.

For open data projects you can use the G-Cloud for provisioning the underlying infrastructure for your open data initiative (storage or hosting), to access consultancy, or to procure a managed data publishing service.

We have conducted a survey of the capabilities of suppliers on the G-Cloud framework to deliver open data services, which is available separately.

Procuring through the Digital Services Framework

The Digital Services Framework helps the public sector to develop digital services that are delivered in an agile way, by procuring the time of skilled people.

Open data is relevant to any project developed using this framework. It works alongside the Government Digital Service Design Manual, and frames Discovery, Alpha, Beta and Live project phases. The manual includes the need to provide open data as part of any digital service. We discussed how to embed open data in an agile project earlier in this document.

The Digital Services Framework is a good way to access people with the technical skills needed to deliver a project focused on the publication of open data. It can be used on its own or in combination with another service that you have procured, for example through G-Cloud.

When using the Digital Services Framework you should include specific open data deliverables in your statement of work. If you conduct a technical evaluation of proposals from suppliers, you should also make sure you evaluate their open data approach.

ODI has conducted an assessment of the capabilities of suppliers on the Digital Services Framework to deliver open digital services, which is available separately and shows that there are many suppliers who are able to deliver open digital services.

What to include in invitations to tender

When procuring a good or service you need to specify your requirements. This is usually done in an Invitation to Tender document, which tells bidders what you need and how you are going to select a supplier. This should include the full evaluation criteria and weightings.

Public contracts are usually awarded based on an assessment of the “most economically advantageous tender”. The aim is to achieve value for money. This is not necessarily the lowest price, but the best combination of the whole-life cost of the contract, the quality of the goods or services and how well the supplier’s proposals meet requirements.

To assess the most economically advantageous tender you will need to evaluate suppliers proposals using price-based and non-price-based criteria. Your assessment of bidders’ open data proposals will be part of your non-price based criteria (although using open data can help suppliers deliver services at lower cost as well, so it is worthwhile encouraging this).

Your requirements, including your open data requirements, have to be set out for bidders, in detail and in advance, usually in your Invitation to Tender document.

Your invitation to tender document should include:

• information about your organisation’s overall open data policies, why you make your data open and why you are encouraging the use of open data;

• your specific open data requirements in the context of the procurement; and

• information about how you will evaluate bidders proposals, with, we recommend, at least one question that probes how bidders will fulfil the open data requirements, as part of your evaluation criteria.

Statement of intent

The Invitation to Tender will include background information, the policy, business and culture of the organisation, the service standards that are expected, the relative priority of the different requirements and the constraints. The contextual information is a good place to describe your organisation’s open data policies.

It is good practice to have a general statement of intent that states your organisation’s general policy around the production and use of open data. The UK government has made a commitment in the G8 Open Data Charter, that says that data should be open by default.

In keeping with this general policy, an example statement of intent would be:

Your Organisation aims to make its data open and supports the use of open data. We do this by making data available under an open licence, and in a machine readable form, so that others may use it freely. Where we can, we use open data sources as part of ensuring good value for money.

This sets a context that enables bidders to understand the general aims of the tender.

Requirements and evaluation questions

The Invitation to Tender document will include a statement of the requirements: a specification of the products or services to be provided. The requirements must describe what needs to be done rather than how it should be done: the outputs rather than the methods.

When framing a specification, it is straightforward to require the production of open data as an output of a service (you are not specifying how to perform the service). Where legal constraints mean that you cannot require the use of particular open data, you can still ask non-scoring evaluation questions about the use of that data, to signal to bidders your commitment to open data.

The number of requirements that you can make around open data in your ITT, and how exacting those requirements are, will vary depending on how closely associated open data is to the primary purpose of the contract. A contract to publish a local authority’s spending data as open data is likely to have several different open-data-related requirements and related evaluation questions. A contract to provide plumbing services to a local police force, maybe just one.

We have discussed above the various kinds of requirements that you might include in a procurement. The general form of wording that we suggest you use for requirements for specific data might be:

The contractor must publish the data listed in Appendix X according to the indicated level of the ODI Open Data Certificates.

In the associated Appendix, you should list:

• exactly which data should be published,

• what format it should be published in,

• how frequently it should be published, and

• what level of the ODI Open Data Certificates it should adhere to.

Most data should be published to the Standard level of the ODI Open Data Certificates but, as discussed below, you may want to require the data to be published to the Expert level.

Price criteria

As part of their response to an ITT, bidders have to supply information about their price for providing the service.

To be able to assess the whole-life cost of the contract, and to encourage suppliers to propose using and publishing open data, you need to capture the costs of licensing data as part of the contract costs. You also need to capture the costs of moving to alternative data suppliers at the end of the contract. These costs should be broken out separately within the template that you ask bidders to complete.

Proposed contract

You must make available a proposed contract to bidders along with your invitation to tender. The contract will includes clauses about the ownership of the intellectual property created in the course of delivering the products or services.

Early on, you need to figure out what data is going to be produced through delivering the service, directly and indirectly.

Data that is created in the process of delivering the service is valuable. We strongly recommend that you ask your legal advisors to frame your contract so that you own the data that is created. If you own the data, you can then choose to licence it as open data. Within the contract, you should ensure that the rights to the data are held by you.

Bidders may be prepared to offer a lower contract price in exchange for retaining ownership of some of the data produced through fulfilling the contract. Bidders may alternatively be prepared to provide a deal whereby you retain ownership of the data, but they have an exclusive right to use it. Entering into such an exclusive arrangement is contrary to Regulation 14 of The Re-use of Public Sector Information Regulations 2005. Both these types of “deal” have caused problems in the past: government departments have found that they cannot open up data that they would like to for contractual reasons.

To properly consider the trade-offs between a lower price and ownership of data, you should evaluate the whole-life cost of the contract, including the exit costs. You need to understand the full cost of not owning the data and the risk of losing it at the end of the contract. Strong open data policies can guard against these risks. Reprocurement offers an opportunity to make changes for the longer term and potentially regain control of vital data assets.

How to incorporate open data when evaluating proposals

Proposals should include evidence of the supplier’s capability to deliver the service. You can encourage suppliers to provide you with open data sources as evidence of their capability and performance. This will help you and other buyers in the public sector who are looking to assess those suppliers.

Proposals are assessed based on price-based and non-price based criteria.

Non-price-based criteria

There are three types of question whose answers can form the basis of a non-price-based evaluation:

• weighted questions that you grade, about how the supplier fulfils a requirement,

• yes/no questions which are make-or-break, and

• non-scoring questions which are just used to ask for information.

Questions can be grouped, with each group having a scoring threshold. When inviting proposals, the evaluation method needs to be explained, and you should also provide model answers.

Producing open data

Regardless of what you’re procuring, ODI recommends that you have at least one requirement and one scoring question about producing open data. The requirement may be as simple as requiring the supplier to provide you with information about the performance of the contract in machine-readable form such as a spreadsheet, which you can then publish as open data.

We recommend having a yes/no question such as:

“Can you meet the requirements for publishing open data?”

which confirms that the supplier can meet those requirements, and therefore that they can then be written into the contract.

If open data is an important aspect of the service that you’re procuring, then you should be differentiating between suppliers based on their open data capability. To do this, you can ask them any number of follow-up questions.

When the essence of the contract is about delivering a service that is unrelated to open data publishing, you could just follow up with a single question:

“If yes, how will you meet those requirements?”

When there are significant requirements for open data publication, you will need to ask more detailed questions about the supplier’s approach. We suggest asking questions around each of the areas highlighted in the Open Data Certificates, namely:

• “How will you meet the legal requirements for open data around rights, licensing, and privacy?”
• “How will you meet the practical requirements for open data around findability, accuracy, quality and guarantees?”
• “How will you meet the technical requirements for open data around locations, formats and trust?”
• “How will you meet the social requirements for open data around documentation, support and services?”

Model answers

We recommend framing model answers around the criteria set out in the Open Data Certificate. The relevant criteria will depend on the type of open data being published, either at a ‘Standard’ or ‘Expert’ level on the Certificate. Good answers will:

Rights, licensing and privacy

• list the sources for the data

• provide guarantees and assurances over the supplier’s ability to secure the rights to publish any third-party data as open data

• state who will have the rights to any data that is produced as part of delivering the service; the data should belong to the contracting public-sector organisation

• state the open licence under which the data will be published, which should be the Open Government Licence or another standard open data licence and not a custom licence

• describe the steps that will be taken to manage personal data, including an intention to carry out a privacy impact assessment

• state an intention to have independent audit of any anonymisation methods used

Findability, accuracy, quality and guarantees

• state where the data will be registered (such as data.gov.uk)

• describe how frequently the data will be updated, including dumps of data available through an API

• describe how any reports of errors will be responded to or handled

• describe the quality control processes associated with the data

• provide guarantees of service availability for any APIs

Locations, formats and trust

• state that data will be published on the internet

• describe the method of release (API or through static files)

• indicate that the data will be made available in ways that will enable developers to download all the available data (potentially through scripting)

• state whether a feed of changes will be available

• state which format is used to publish the data; this should be a standard open format that is appropriate for the type of data that is being published, such as CSV for tabular data or HTML for documents

• describe the URLs that are going to be used for accessing information and where links to third party sites are used in the data

• describe the method through which the provenance and reliability of the data can be accessed and assessed by third parties

Documentation, support and services

• state that there will be documentation to help people understand the data

• describe the level of support provided for users of the data

• describe any activities they will engage in to encourage the use of data

• indicate that the supplier will maintain a list of tools and services that make use of that data

Social value

The production and maintenance of open data assets, particularly high-quality reference data, is a form of social value. Public procurement can be a way of releasing this type of social value. Depending on the context of the procurement, you may be able to include an assessment of social value of open data as part of your evaluation criteria.

Using open data

You should always ask suppliers about what data they will use to deliver the service. Some of the data will be open data, and some may come from closed sources. You can ask a non-scoring question if you don’t have a specific requirements about using open data rather than closed data. This will give you an insight into the supplier’s overall approach for delivering services, and perhaps the risk of being locked in to that supplier.

We recommend including a question like:

“Please describe what data you will use in delivering this service, including whether it’s open or closed.”

A good answer to this question will demonstrate a commitment to using open data where possible and give examples of the open data sources that the supplier uses. An excellent answer might include a commitment to contribute back data into those sources, such as contributing to Open Street Map.

Price criteria

When you evaluate the pricing information supplied by the bidders, you need to make sure you understand the whole-life cost of the contract. Providers relying on closed data to provide you with services may be introducing hidden costs of exit: costs you will have to bear when the contract comes to an end. These costs should be exposed through the costing template that you use.

How to include open data in contract negotiation

The process of negotiating a contract differs depending on the type of procurement that you are engaged in.

Framework contracts

When you procure a service through a framework, the terms and conditions are fixed as part of the framework contract.

If you procure through the Digital Services Framework you will need to complete an Order Form and the Call Off Terms for your project. You should include your open data outcomes in the Statement of Work and also in the description of the services to be provided in the Order Form. You should also explicitly reference the Open Data Certificates under the “Standards” heading of Section C, “Customer other contractual requirements”.

Whilst the Digital Services Framework requires suppliers to use the best applicable standards and follow Good Industry Practice, we strongly recommend that you identify the Open Data Certificates as being the relevant standard for open data. Depending on your project’s requirements, you should specify achieving either the Standard or the Expert level of the Open Data Certificates as an outcome of your project, and list the Standard or Expert certificate as the relevant standard. Working through the Open Data Certificates will prompt you to consider other standards, such as technical standards for data formats, that you may want to specify as standards in the Call Off Terms for your project.

If you procure through G-Cloud, you need to check the terms and conditions that have been provided by the supplier, particularly around Intellectual Property rights, and you should not award the contract to a supplier who retains ownership of or an exclusive right to use data.

Other framework contracts might not address the Intellectual Property of data generated as part of services that are procured through them; you should check this before embarking on procurement through a framework contract.

Other contracts

You should make sure that all your open data requirements are manifested in the contract you sign. You should also make sure that the open data commitments that your chosen supplier has made in their proposal are written into the contract.

As discussed above, the proposed contract that you include with the ITT should include clauses that ensure that any data produced through the performance of the service is owned by you. You should ensure these clauses are not altered during contract negotiation, nor clauses added to grant the supplier any exclusive licence to use the data.

The open data requirements that the supplier has agreed to, and the detailed commitments that they have made, should be mapped into contractual requirements within the schedules of the contract.

It is a good practice to have a schedule that lists the datasets that are produced as part of the contract, how frequently they should be produced, and the level of the Open Data Certificate that should be attained in their publication.

You should also have a schedule that lists third-party Intellectual Property rights that are used to deliver the service. As part of this, you should have a table that lists the open data that is used.