Live More new Guides on the way! Get notified by signing up to CAST's newsletter..

Contributed by

BTSE brings the third sector together for the benefit of local communities. They work in partnership with service commissioners and the not-for-profit sector for the benefit of local residents.

Use this Guide if you’re involved in joint reporting with other organisations. It covers what to think about when choosing a system. It also covers some strengths and limitations of Charity Log.

Steps to sharing data between organisations

Data sharing between organisations can be very powerful. It can also be hard work. If you’re going to embark on a data sharing project, examine what you want to achieve, and what it will mean for:

  • The people you support

  • The frontline teams who input the data

  • The reporting teams who need to use the data

Some of the common benefits can be:

  • Simplification of joint reporting

  • Better experiences for people when they need to receive services from different organisations

  • Improvements to safeguarding

  • Efficiencies and cost sharing

Bromley Third Sector Enterprise (BTSE) supports a group of charities who collaborate on improving the health and wellbeing of residents in the London Borough of Bromley and surrounding areas. It holds several contracts with the local authority and the NHS. It reports to the commissioning bodies that award those contracts.

BTSE and their partners wanted a central database/CRM (Customer Relationship Management system) for collective reporting. Once the project started, the partners also recognised several other benefits. They found Charity Log made it easier for frontline staff to support people. This is because they can see key information about other services people are accessing.

A great way to do this is for all partners to map what data they currently collect. Then they should label:

  1. Data that is essential for everyone to be able to access

  2. Data that might not need to be accessible to all, or that might be sensitive

  3. Data that they don’t need and could stop collecting

Don’t skip the third point. Most of us find we’re collecting some data we don’t need when we do this kind of mapping or review!

Next you can use workshops to bring all partners together. Alternatively, data experts in one organisation can take the lead.

You need to consider what set of data fields you need, and how you will describe them. This will help partners use them consistently.

You will also need to think about what will happen if partners need to leave a data field empty.

Then you’ll want to think about how you want to report that data. This includes the fields you'll want to sort data by, and other queries you might want to run.

During these discussions, think about data protection and data access. We cover that in the next step.

BTSE's 4 partner organisations were running several different services. They needed to share core data from every service, but each service also captured other information to help measure KPIs. This meant that BTSE knew they were going to need a large number of data fields.

They decided to keep the system focused on services that the partnership was delivering. They did not extend it to other services delivered by partners. This kept the system simpler. Each partner also has other systems they were already using.

BTSE accepted that it was likely that whatever system they chose would only be able to handle some elements of the reports they needed. They thought that they would need downloads, spreadsheets and data visualisation software for some reporting

They also decided that the project should include future flexibility. They needed to be able to add data fields or improve data descriptions to the solution.

First ask whether you are storing any special category data.

Special category data is types of personal data that is considered sensitive. Many services in health and wellbeing will have special category data. Other services may have special category data for impact measurement. For example, if you are tracking ethnicity, disability or other protected characteristics.

Next, think about your consent processes. You’ll need to make clear to the people you support which information they give you will be shared across the partnership.

Thinking about data protection also means thinking about how you handle deleting records from the system. Do you need automated features to make sure you delete data after a certain amount of time? Or do you just need an easy way to run a manual process?

Finally, consider access needs of the different people who will use the data. Do some people only need permission to add data to the system, not view it? The reporting team need to see all the fields that are relevant to KPI’s. But maybe they don't need to see information that is designed to help frontline workers support clients.

Do you have to respond to Data Subject Access Requests? These are a type of freedom of information people often use to see case notes written about them. If you do, then you need to make sure that case notes don’t include personal data (even names) about third parties - such as other people in the person's life. You might want to think about how your system can help you avoid that problem in advance, or whether you'll solve it when a request is made.

The decisions you make will define the user permissions you need to set for accessing data.

Bromley Third Sector Enterprise knew that they would be handling special category data. They intended to use the system in at least two ways: for reporting and for improving frontline support. And they wanted the ability to set a range of different user permissions.

They needed a system that would be storing the data in the UK (or in another place, but in a way that met GDPR regulations).

Over time, they have added further data protection needs. For example, they are looking at ways to use the system to remind people to make sure case notes are anonymised. This helps them handle data subject access requests more efficiently.

You need to choose a system that meets all the needs you have identified in Steps 1-3.

You could use:

  • A CRM designed for impact management in Charities

  • A general CRM that can be configured to do what you need

  • A case management system (like a CRM but tailored to holding case notes)

  • A self-built database using Airtable or similar software

If your data sharing needs are limited, you could collect information in individual spreadsheets. You could then feed their data into an impact management tool like Power BI to monitor and generate reports. 

BTSE examined different systems the partners were already using. This included Casebook.net, Charity Log and others.

They decided that they needed a separate centralised system. They chose Charity Log because it met their needs best. They were particularly happy with the:

  • support offered by the Charity Log team 

  • user permission options

  • process of adding and editing fields and field descriptions

  • ability to handle different fields for each of their service pathways

  • forms it offered to make uploading data easy.

It also helped that some of partners were already familiar with Charity Log.

As their services have evolved, they’ve discovered that Charity Log doesn’t offer all the reporting features they need. They’ve been able to solve this by integrating Charity Log with Power BI for data visualisation reports. See 'Further information' below for how to do this.

You could consider some or all of the following steps:

  • Arrange training for key users

  • Create strong protocols and processes for when data should be uploaded, so no one ends up having to deal with backlogs

  • Create guides showing how to use different elements of the system

  • Make sure you have a process where people can feedback on difficulties they’re having and see the action taken on the feedback

  • Talk to your staff about how this new shared data has helped deliver services or win funding - this helps people understand the wider reasons for inputting data timely and accurately

  • Use technical data validation of fields on forms (such as postcodes) to make accurate data entry easier.

BTSE received initial support from Charity Log. They have also successfully enabled partners to input data in a timely fashion. This is impressive, because each partner is maintaining two data systems. They have the BTSE Charity Log system for contractual reporting on the partnership's services, and their own systems for other services.

BTSE put their success down to:

  • Taking the time to think through and test the initial build

  • Making sure that the build could support future developments with a degree of ease

  • Creating guides to help people use the system

  • Managing the system in a flexible way, supporting new requirements from new projects

  • Discussing improvements as a regular agenda item at their operations management meeting

Here is an example of a simple PDF guide for system users.

Improving an impact reporting database or CRM is a balancing act. You need to keep it flexible so that it meets the needs of all your services and your stakeholders. You also need to make sure it doesn’t become bloated with so many fields that no one can use it.

To make this easier, try to have:

  • A process where people can request amends and improvements

  • A process that asks exactly what those suggestions will achieve, and checks there aren’t already existing ways to meet the same need

  • A process for prioritising changes and improvements into an action list

  • The ability to make at least some improvements in-house

  • A way to call on expert support when you do need it

  • A test and learn, iterative approach to everything you decide to change.

Here’s some of the improvements BTSE have made to their system:

  • Adding fields when projects need them

  • Connecting with Power BI for better reporting

  • Adjusting field descriptions to help teams enter the correct data

  • Improving processes for adding third party data to free text fields, to keep data anonymous

  • Adding fields that are not relevant to KPI’s but improve front-line staff experience. This includes a warning flag, where home visits may involve a higher risk to the worker.

They have a data-focused team member looking after the system. They expect to continue making improvements throughout its lifespan.

Further information

If you’d like to know more about this work contact a member of BTSE's team at [email protected].

See related guides:

If you’re thinking about choosing a system. Use Datawise London’s guide to choosing a database.