Open Referral UK Project Initiation Document

Introduction

The Ministry of Housing, Communities and Local Government (MHCLG) is supporting councils to adopt the Open Referral UK (ORUK) data standard.

ORUK is the project name for UK use of the international data standard Human Services Data Standard (HSDS). Essentially this is the data fields used to describe the details about a local service to support people e.g. the name, description, venue, start time etc. A service could be a public sector service or a community service e.g. foodbank, benefit assessment.

This initiative aims to improve efficiency with partners, enhance data accuracy and completeness, enable sustainable cost models, and facilitate data sharing across boundaries to better serve residents in various contexts.

This document is designed for programme and project managers leading the implementation of Open Referral UK within a council area. The project scope should include collaboration with external partners, which is briefly addressed on the next page.

We assume the business case has been agreed in principle and a project mandate submitted. While each council may approach this project differently, the headings in this document reflect standard elements of a project initiation document (PID). Rather than providing exhaustive project details, the document focuses on key considerations and ideas, offering a concise yet supportive framework to help councils create their own PID for implementing Open Referral UK.

For additional resources, refer to our ORUK Executive summary, ORUK Business case and ORUK Technical overview documents.

1. Project overview

Title: ORUK data standard adoption project

Purpose: To implement the Open Referral (ORUK) data standard, streamlining local service information and enabling better outcomes for residents and service users.

2. Vision

Create a single, accurate source of truth for local support services, accessible across all tools and pathways, to empower residents, families and frontline workers with the right information when they need it. This will ensure people get the help they need, reducing reliance on the public sector and breaking down outdated silos.

Achieving this vision will require strong leadership and robust digital resources. A phased approach is recommended, starting with areas already gaining momentum, such as Adult Social Care, SEND Local Offer, and Family Information Services/Hubs. Over time, this can expand to address other critical local issues, including homelessness, foodbanks, the cost-of-living crisis, bereavement, autism assessments, or any other priorities identified locally.

3. Objectives

• Demonstrate that data can be collected more easily and efficiently by multiple sources.
• Ensure the collected data is accurate, reliable, and trusted.
• Enable partner organisations to effectively reuse the data.
• Gather insights and lessons to inform scaling across the full council geographical area.

3.1 Digital Declaration

More than 200 councils have signed up to the Local Digital Declaration, reflecting a shared commitment to improving flexibility and interoperability of software systems across the public and third sectors.

Open Referral UK defines the data and interfaces needed for tools that help people find services and analyse service provision, ensuring these tools can seamlessly communicate with each other.

4. Scope

The ultimate intention is to implement the ORUK model across the entire council area, overcoming partner administrative boundaries. However, this project will begin on a smaller scale to refine the approach, gather evidence, and strengthen the business case for broader adoption in the future.

Scope overview

This project will focus on proving the concept, but will include partners outside of the council itself. While more could be included, the scope has been defined to meet realistic timelines and will be refined after a discovery exercise.

In scope:

• Collecting and validating data from at least one external partner organisation
• Data collection and assurance focused on the three required by a council i.e. Adult Social Care, SEND/Local Offer, and Family Hubs or a particular context e.g. cost of living crisis
• Developing a service type taxonomy
• Building a digital infrastructure for data sharing via API
• Ensuring at least three partner organisations consume the data
• Producing a management report with service numbers, types, and geographic grouping

Out of scope:

• Alternative technical methods for data collection and consumption
• Additional partners collecting or using data
• Development of other taxonomies

5. Benefits

We have prepared a separate ORUK Business case document for councils looking to start up an implementation project. The following outlines the key capabilities and benefits that implementing ORUK is expected to deliver. The bigger benefits will be realised when citizens and frontline workers consume the accurate data.

• Aggregating data from various sources will provide efficiency savings for those currently managing their own service directories through reducing duplication of effort and focussing assurance on a single data repository.
• ORUK's rich data set will help people find the right service and decide to attend without needing further information.
• Structured accurate data will improve the results of AI and enable integration of the data directly into frontline pathways, interventions, processes and applications rather than creating yet another service directory.
  • This will give access to support for patients awaiting surgery, assessments, or post-treatment support; or to support an existing intervention or where a threshold has been missed. It also empowers self-care, helping prevent crises and reducing reliance on statutory services.

6. Stakeholders

While the Transformation/Digital team is expected to be involved in implementing this project, this may not always be the case. Therefore, they are listed below, along with other key stakeholders who should be kept informed through highlight reports, deliverables, and invitations to data demos. Some may also have roles in governance.

• Director of Public Health. Focused on reducing health inequalities and improving overall health
• Director of Adult Social Care. Needs accessible service information to provide residents with information and advice relating to care and support for adults and support for carers
• Director of Children’s Care. Aims to make SEND and Family Hubs information widely available across websites, tools, and neighbouring areas
• Health & Wellbeing Board. Seeks comprehensive data on services available to improve health and wellbeing across the area
• Commissioners. Need data on local service demand and availability to identify gaps and prevent reliance on statutory services
• Transformation / Digital Leader. Would be able to help with new process and digital infrastructure
• Chief Executive of local infrastructure organisation. Interested in engaging infrastructure organisations for data collection, ensuring free reuse of service data for the third sector
• Finance Director. Aims to reduce current costs for service data collection and establish a sustainable cost-sharing model. Seeking savings from reduced enquiries as people self-serve preventing the need for formal support
• Third sector organisations. Seek efficient promotion of services through well-organised data sharing

7. Deliverables

8. Budget

These are illustrative figures only. Costs will vary based on your specific circumstances.

9. Risks and issues

10. Governance and structure

The Sponsor is the local council. A representative of the council will be the project executive. This should be a member of the Senior Leadership Team and preferably someone who is on a council area (place-based) board e.g. Health & Wellbeing Board.

Ideally this project would be part of a programme overseen by an existing council area (place-based) board rather than setting anything up in isolation. If this project proves the concept then the council area board could then oversee the scaling.

The council should appoint a project manager who will set up a project board with the data collection organisations taking a senior supplier type role and the three data consumer organisations taking a senior customer role. The project executive and manager can decide whether there is a need for a quality manager but a suggestion might be to appoint a council service commissioner.

The project will follow the stage plan given at the end of this document. (Section 15)

11. Approach and methodology

The following roles are key contributors to the model, with the same organisation potentially taking on multiple roles simultaneously:

• Project Executive. Leads the project board and governance, ensuring effective collaboration with partners. Could be a member of the H&W Board
• Local Support Services Manager. Responsible for driving the vision and coordinating activities across the council area. This role may also be the Project Manager. This could be a new role to consider or be a programme manager from the council team.
• Infrastructure Support. Supports the promotion of the initiative and registration of service providers. This role is likely to be carried out by an organisation such as a CVS or similar community group.
• Service Providers. Organisations that offer services to the community and are central to the project’s success.
• Collector. The designated organisation or individual responsible for gathering information from service providers about their services. This may involve "self-entry" by the service provider or support by a third-party collector. The collector’s role is expected to diminish significantly over the next 2-3 years as service providers take on more responsibility for managing their own data.
• Assurer. The central role responsible for overseeing the quality of data and taxonomies, ensuring accuracy and consistency. This role is accountable to the consumer.
• Consumer. The organisation or entity that reuses the data. Consumers will report errors and make demands for data improvements.

There is no fixed blueprint for implementing this data standard, but the following diagram provides a framework for planning. A brief explanation of the steps is outlined below, with a detailed implementation plan in section 15.

Leadership, governance and oversight

Discovery exercise

To kick off, it’s crucial to understand the current landscape, including who is involved and what tools are being used.

We recommend conducting a discovery exercise to identify who is:

• Collecting/maintaining local service information
• Storing service information in software
• Using service information on websites or in processes

You can capture this in a simple spreadsheet with tabs such as: Data collected, Data stored, and Data used, or create a visual "rich picture" for better clarity.

This exercise will provide insights for the business case, stakeholder management, existing software, data fields, and help identify potential proof of concept participants, as well as any challenges or benefits in making changes.

Finalising the scope

For the proof of concept, we recommend scoping for council departments that already have service directories, alongside external partners:

• Special Educational Needs and Disabilities
• Family Hubs/Information Services
• Adult Care Support Services
• Health and Wellbeing services

Focus on a specific issue that leaders will engage with, ensuring it involves multiple services within a manageable geographic area. Potential issues include:

• Bereavement
• Suicide prevention
• Homelessness
• Health and wellbeing

Consider the stakeholders involved, as their buy-in will be influenced by credible leaders.

Policy, software, and finance model

While the ORUK data standards provide a framework, there are areas open to interpretation—such as data quality checks, field definitions, mandatory fields, taxonomies, and service handling. It’s essential to define a policy for accurate data management.

The discovery exercise will also highlight existing software. You'll need to assess whether these systems can align with the ORUK data set and support the compliant API. A decision will then be made about continuing with current software or introducing new solutions.

There is a need to identify a finance model which will ensure any council area policy and process will be scalable and sustainable. The policy, process and finance models can collectively be known as the business model. Likely costs are given in the ORUK Business case document under the implementation planning framework headings. Note that the council is being asked to take responsibility and therefore will carry the financial risk whilst it will be other public and third sectors that gain more of the benefits.

Recommended model

We suggest that the most effective business model would involve larger public sector beneficiaries contributing to the council's costs.

The following considerations are given:

• the council employ a programme/project manager to drive this project forward, take responsibility and manage the inevitable moving parts
• the third sector is involved in the collection and should be paid for its involvement; however care should be taken to ensure they have the required skills and can provide the required outputs
• the assurers should come from a variety of resources but be combined under the council area policy and process and managed by the programme manager
• the API infrastructure will be provided by a single tier local council where a County council would provide the API and the districts post in the data collected in their area
• the data is freely available to the third sector and that a public sector organisation using the data contributes to the costs according to their usage or size of budget.
• procurement policies should ensure that any application processing local service information should be compliant with ORUK
• performance information should be provided to the service providers, third sector and public sector to encourage better use of this infrastructure

Deliverable: discovery landscape, draft business model

Collect & Manage

Data collection already happens across various teams and organisations including the providers themselves. This process should continue but within a federated model that better coordinates contributions into a single repository.

Federated approach

Public sector organisations and large service providers are generally equipped to upload their own service data. However, smaller providers may lack the digital capacity or resources. In these cases, the third sector, closely connected to smaller providers, may need to be commissioned to collect and maintain the data. Consider offering training in data handling to equip them with the skills to complement their understanding and relationships with service providers. They will also play a key role in promoting the model and encouraging service registration.

Open Referral data fields

Current data collections must be refocused to align with the standard, likely increasing the amount of data collected. While organisational-level data is easier for providers to manage, it can cause friction for frontline workers and citizens if service details are hard to access. Clear, complete service information is crucial, as citizens may disengage if they can’t find sufficient details on websites or forms.

Registration of provider

The most reliable way to collect service information is to establish a formal relationship with the service providers themselves, rather than relying on research or web scraping. While providers may have limited resources, they are likely to verify their services periodically or respond to ad hoc queries. Providers may be more inclined to register their services if they are linked to specific issues or service types, and infrastructure organisations may also want to register services within their area. This establishes a route for integrating their data into the repository.

Single repository (aggregation)

Ultimately, all service information needs to be aggregated into a single repository. The ideal method would be through a POST/UPDATE API, though not all providers may have the technical capability. As a backup, provisions for spreadsheet imports and a user-friendly interface for direct data entry should be considered.

Deliverable: collection process map (for business model)

Assure Data Quality

Assurance focuses on data quality, not service quality, which can often cause confusion. It’s a resource-intensive process that is currently handled by the ‘collector,’ but it’s recommended that this responsibility be elevated to a dedicated data custodian due to the significant benefits of having accurate, well-categorised data. Software used in this process should be sending reminders at appropriate points to encourage data quality checks to keep data up to date and accurate.

De-duplicate

A challenge of having multiple collectors contributing to a single repository is data duplication. To reduce this, it’s helpful to align each service rovider with their preferred collector/assurer, making it easier to spot and separate duplications from other sources. The assurer should prevent any duplicate data from being published, and a regular de-duplication exercise will be required during aggregation. Contacting the source of the duplication can help prevent wasted effort in the future.

Data quality check

Even with direct input from service providers, data errors may still occur. The assurer should audit a sample of data to assess each collector’s confidence level. Collectors should verify their data quarterly, with a report on data quality to support improvements. Verification should be straightforward, with software enabling easy updates and a 'no change' option for existing services. Feedback on errors from frontline workers should influence the confidence level, which can be managed through assurance software, reducing oversight for higher-confidence collectors.

Align categories

Categorising services correctly is crucial for identifying appropriate services and generating meaningful management insights. While national taxonomies are being developed, existing ones (such as those from the Local Government Association) can be used in the interim. Over-categorisation by providers is a common issue, so it’s recommended that the assurer finalise and apply taxonomies to ensure better service discoverability and data management.

Deliverable: repository of trusted data

Publish & Reuse

The main benefit of implementing ORUK across a council is that data, once collected and verified, can be reused multiple times. The easiest way to share this data is through APIs, though simpler options like CSVs or data links should also be available for smaller organisations without technical resources.

Building the API

The ORUK website (ADD LINK) provides detailed guidance, along with the ORUK Technical overview document. Each upper-tier council should aim to implement an ORUK-compliant API. These can be validated on the website.

Re-use of the data

There are many ways local service information can be reused to help citizens, families, and frontline workers. To gain momentum, examples of data reuse should be shown during the proof of concept. Some key use cases include:

• Waiting for a public sector service (e.g. ASD assessment, social care, surgery)
• Extra support alongside interventions (e.g. hospital discharge, benefit assessment, SEND)
• Support after an intervention (e.g. child in need, mental health, physiotherapy)
• Help after missing a threshold (e.g. ASD/SEND, carer assessment, care review)
• Self-care to reduce reliance on public services (e.g. elderly parent supported by a child, smoker trying to quit, teenager seeking youth services)

These use cases can be supported through websites, apps, and AI, delivering the right information at the right time.

Websites

Websites that help people should link to local community services that might be useful.

Applications

Many existing apps could benefit from local service data. If reliable data is available, new solutions could also emerge to support people’s needs. Self-care apps and citizen accounts will gain trust as they reuse this data, potentially easing demand on public services.

AI

Well-structured data makes AI more effective. A chatbot that helps users find local services based on their needs is just one example. With reliable data, new AI tools can be developed quickly.

Deliverables: A compliant API, Demo of data being reused

Performance Monitoring

A coordinated approach across the council will provide valuable data at a strategic level, including reports on service gaps, demand by area, number of providers, and feedback from frontline workers and citizens. This data will give commissioners and policymakers better insights to support community resilience, prevention, and early help.

It’s important to showcase some of these figures from the proof of concept to help organisations see the potential impact.

Feedback

Feedback from frontline workers and citizens is vital but needs careful handling. Both groups can provide input on service and data quality.

Service quality feedback can be tricky, as negative comments may relate to factors unrelated to the service itself (e.g. parking issues, long queues). It’s worth separating feedback from frontline workers and citizens, as workers often value peer feedback when signposting to unfamiliar services.

Data quality feedback is where frontline workers and citizens can play a key role. Make it easy for them to report errors directly to the assurer for verification and correction. A policy to correct any reported errors within 48 hours would help maintain data accuracy. This is one of the key advantages of a single repository over multiple systems, which can create confusion when data isn’t updated consistently.

Deliverable: Management Report

12. Project Close

This project aims to prove the concept and gather insights to recommend how to scale it across the council area. The listed deliverables will support this, but as the proof of concept concludes, focus should be on drawing conclusions and outlining the next steps. Scaling may require several efforts to reach the point where it becomes part of the local culture and operations. The goal is that the proof of concept demonstrates enough value to justify this effort.

Deliverable: Recommendations for scaling

13. Communication plan

Communications will follow council guidelines but will ensure stakeholders stay informed through regular highlight reports, a demonstration of the collection, aggregation, and use of data, and the recommendations for further scaling.

14. Approval and sign-off

This PID should be signed off by the project board and the council area board.

15. Conclusion

The PID is a dynamic document that may be updated as the project progresses. It provides clear guidance and acts as a reference for all involved, ensuring alignment throughout.

16. Implementation Plan with timeline

The table outlines recommended timescales, suggesting the proof of concept should be completed within 12 months to maintain the potential partners/beneficiaries interest. It focuses on deliverables and tasks, which will need full consideration by the council.