Data sharing agreement template

Introduction

This template Data Sharing Agreement (DSA) (ODT, 33KB) can be used by all health and care organisations to provide a high-level summary of data sharing between the parties signed up to the DSA. It is not mandatory to use this DSA and it can be adapted locally if you wish. This guide is to complement the template by providing guidance on how to complete the DSA including what needs to be completed in each section. 

A DSA can be used between parties to help show compliance with the UK General Data Protection Regulation (UK GDPR), the common law duty of confidentiality and other data protection law beyond the outline strategic view given in the Data Protection Impact Assessment (DPIA). A DSA can be used to help operationalise and underpin the DPIA. It should help you justify your data sharing and demonstrate you have considered and documented relevant compliance issues.

Prior to completing a DSA, you may want to consult with your local Data Protection Officer and/or Caldicott Guardian.

You can download the template Data Sharing Agreement (DSA) (ODT, 33KB) as an editable OpenDocument file to complete. 

Background

DSAs can take a variety of forms depending upon the complexity and scale of the data sharing. They document a common set of rules but are not the same as other documentation, such as a Service Level Agreement or a Data Processing Agreement. 

DSAs used across the health and care sector vary; nearly all contain more information and binding requirements than are necessary. These requirements often give the appearance of contractual requirements or legally enforceable rights and actions. These are not, however, binding in a DSA. If enforceable rights are required by any or all parties, then these need to be framed in a Data Processing Agreement, rather than a DSA. 

An example of this could be, two hospitals deciding to pool patient data relating to asthmatics to understand local need and service provision in the area. A DSA would be appropriate for this type of sharing. 

Another example is, if the two hospitals were using a processor to collect and analyse information on their behalf, a written contract would be required. The hospitals would be able to hold the processor to account through the contract for example, due to non-delivery of service. 

DSAs must be written in a clear and concise way, using plain English. They should be understood by all parties and anyone who accesses them. Our aim is to produce a template DSA, in line with the Information Commissioner's Office (ICO) advice, that can be used across health and care. We hope it will provide clarity and consistency of approach removing the variation in quality that exists with the number of in-house developed DSAs that are being used. It takes into account only what is necessary to be contained in a DSA and also guidance from the ICO. Information contained within a DSA may be one of the sources of evidence the ICO uses to inform any investigation or decision.

Completing the Data Sharing Agreement 

1. Between [parties]

This section details which organisations the agreement is between. All parties need to be listed here. It does not include organisations which are processing data on behalf of the parties named in this section. If there are numerous controllers that this DSA will cover, you could complete an Appendix.

2. Purpose or objective of the information sharing

Clearly and concisely state the purpose of the information sharing and what it is intended to achieve here. You can have as many purposes as required, but if these purposes cover a variety of intentions, then you may be best served by grouping the purposes into similar themes (e.g. provision of service planning or research) and having a separate DSA for each theme. For individual care it is not usually necessary to have a data sharing agreement.  

If you have also completed a DPIA for the project, you can reference it here, so that both the DPIA and DSA could be read together.

3. Controller(s)

List all organisations which are controllers as part of this DSA here. You can have as many controllers as necessary.

A controller is an organisation which decides the purpose of, and the manner in which, personal data is to be processed. If you are deciding why you are doing something, then you are the controller. If you have a statutory duty to process personal data (because the law sets out the purpose for which you are processing personal data or you are required by law to process data for a specific purpose), then you will be a controller. If you are deciding the purpose for the processing and another organisation decides how this will be done, then both organisations will be joint controllers. 

Organisations may be sole or joint controllers, and each has slight differences in relation to being accountable for compliance with data protection legislation. A sole controller is responsible for its own compliance with all aspects of data protection, whereas in joint controller situations, responsibilities for compliance may be allocated between each party that is a joint controller. Where responsibilities are shared, it needs to be clearly documented which organisation/s is responsible for which parts of data protection legislation. 

4. Processor(s)

List all organisations which are processors and sub processors as part of this DSA here.

A processor is any organisation which is processing personal data on behalf of a controller. These can be public and private sector organisations but can only act under written instructions given to it by the controller. 

There must be a written data processing contract between a controller and processor, covering the requirements listed in Article 28 of the UK GDPR, and a processor may not use a sub-processor without first obtaining written permission from the controller. Sub-processors do not need to sign the DSA.

5. Data items to be processed

List here the data items that are to be processed as part of this DSA. Each item needs an explanation of why it is necessary to share it to achieve the purpose/s listed in the DSA, unless these items are detailed in the DPIA for the project/programme (in which case you would just need to make reference to the DPIA in this section).

Data items can be grouped in reasonably understood headings to save listing every individual item. Examples might include demographic data (to save listing name, address, etc) or test results (to cover all types of tests).

The minimum amount of personal data and information should be shared to achieve the purpose/s. You should start from a position of sharing anonymous data, and then add data items until you have the minimum necessary to achieve the purpose required. Wherever possible, you should try and achieve your purpose using anonymous data.

6. Article 6 Condition – personal data

State here which of the six Article 6 processing conditions you are relying on to process personal data. Note that you cannot rely on the legitimate interests condition if you are a public authority processing data to perform your official tasks.

7. Article 9 Condition - special category data

State here which of the ten Article 9 processing conditions you are relying on to process special category personal data. Information relating to a person’s health is classed a special category, and so to share it as part of the DSA, you need to identify an Article 9 condition. Usually this will be 9 2 (h) for healthcare, but the controllers listed in this DSA need to identify this condition for themselves, depending upon the purpose of the sharing.

Organisations may also wish to state which Schedules (if any) apply to the processing of special category data (this can be found in Schedule 1, Part 1 of DPA18).

8. Individual rights and preferences 

State here how you will manage data subject’s rights. For example (and not exhaustive):

1. How will Subject Access Requests (SARs) be handled?
2. Who (and how) will complaints be managed?
3. How will objections to the data sharing be managed?
4. Does the National data opt-out apply to this data sharing? 

9. Compliance with duty of confidentiality or right to privacy

You will need to demonstrate how you will be satisfying the duty of confidence. For the type of sharing which is appropriate for a Data Sharing Agreement this can be satisfied in one of two ways:

1. Consent – the patient or service user has consented, under common law, to the sharing. See guidance on the IG portal on consent. 
2. Statutory gateway – the law allows or requires you to share this information for this purpose, such as support under section 251 of the NHS Act 2006.  

Data Sharing Agreements are unlikely to cover disclosures where the common law duty of confidence is set aside due to overriding public interest; such decisions should be made on a case by case basis rather than being covered by a DSA.
Where you are relying on a statutory gateway, it is important to state which piece of legislation (including the section) you are relying on and to ascertain whether or not the gateway provision for the duty of confidentiality is to be set aside.

Data sharing between the parties must also comply with Article 8, Human Rights Act 1998 (the individual's right to family and private life). 

10. Transparency 

UK GDPR places a duty of transparency on organisations – being able to show data subjects how their information is processed and who can access it, along with the basis for this. You need to show in this section how you will be meeting this duty, for example, by setting out that you have included information in your privacy notice and on your website

11. How will the data sharing be carried out?

This section should detail how personal data will be shared between organisations (for example, by secure email) and what security measures are in place to protect data from inappropriate disclosure or a breach of security. It should also detail which organisation is responsible for which elements of sharing and security.

If any outputs or analysis are to be shared by organisations, this needs to be explained here, along with an explanation of why sharing this output will be acceptable, necessary and proportionate (for example, the outputs are anonymous).

Frequency of data sharing also needs to be stated here - Is it a one-off share or regular sharing of data between organisations? If so, then the frequency also needs to be stipulated here. 

If information is being transferred outside the EU, you must stipulate this here and what safeguards are in place to protect the data.

It may be helpful to add a data flow diagram to illustrate the proposed data sharing. 

12. Accuracy of the data being shared

It is important that all data shared by the parties in the DSA is as accurate and as up to date as possible. Organisations must make all reasonable efforts to ensure the accuracy of their data prior to sharing it with other parties.

Efforts to check for accuracy could include checking with the patient or service user when they are in contact with services (and when appropriate to do so), or double checking against other sources (where reasonable and proportionate).

Organisations should start from the position that information being shared with them from or by other parties is accurate and shared in good faith.

13. Rectification of data that has been shared

There may be occasions when inaccurate information (held in good faith) is shared with other parties. Should any factually inaccurate information have been shared with other organisations, then the responsibility lies with the organisation identifying the inaccuracy to notify the source organisation. 

It may also be necessary to inform the data subject of the sharing of inaccurate information, and what actions have been taken to rectify the situation. It will also be important to know who the information has been shared with as data subjects have the right to know which organisations have accessed their data.

14. Retention and disposal requirements for the information to be shared

State here how long the shared information will be retained for, what will happen to it once it has reached the end of that retention period and criteria to be used to determine retention. Disposal doesn’t always mean destruction and the parties signed up to the DSA need to agree what will happen to the data. Options could include destruction of the data (with permission of the source organisation), return to the source organisations for onward management or destruction, or longer retention (with justification). The NHS Records Management Code of Practice may support you with this.

15. Breach management

If a breach occurs, then you need to document how this will be managed by the relevant parties. It is impossible to document here the process for each type of breach, but the main types should be covered here – an example being inappropriate or accidental disclosure, or loss of data. See further information about reporting breaches to the ICO.

16. Specify any particular obligation on any party to this agreement

There may be occasions in relation to the data sharing, that one party may have a specific obligation or task that the others do not have. If so, these need to be listed here, stating what the obligation is, and which party is responsible for it.

17. Contacts – Information Governance (IG)

Each party needs to provide the contact details of:

1. Their Single Point of Contact (if relevant)
2. Their Information Governance Lead, or the person responsible for IG in their organisation.
3. Their Caldicott Guardian

Contact details for processors do not need to be included. If a processor needs contacting regarding IG then this should be done via the controller who they are accountable to.

If the contacts details change, then the relevant party must inform the others as soon as practicably possible.

18. Commencement of agreement

The date of when the DSA commences is put here. This might not be the date the DSA is signed. It might be at a time in the future, to allow processes to be established prior to information being shared.

19. Review of agreement

The DSA must be reviewed on a regular basis to ensure that it remains current and fit for purpose. Outline here how this will be completed and what circumstances may trigger a review (such as change in legislation or a party deciding to leave the agreement).

20. Review period

The DSA will need to be reviewed on a regular basis, and the parties can decide how long that review period will be. The purpose for the DSA will contribute towards determining the review period. For example, a long-term sharing programme may review the DSA every two years, but a DSA for high-profile sharing or a sensitive issue may be reviewed every six months. A one-off DSA will not need a review as once the data is shared, the purpose is finished, and so the DSA ends.

21. Variation

If a party wishes to change any part of the DSA, then the process for doing so should be outlined here.

22. Ending the agreement

A party (or parties) to the DSA may wish to end their involvement at any time. This section details how a party serves notice on its involvement in the DSA, what notice period applies and more importantly how the data of the leaving party will be managed.

23. End date

Each DSA requires an end date on which it ends – whatever reason this may be. When the DSA is reviewed, this date can be changed in light of the revisions.

The end date relates to when the sharing will stop. After this date, some elements of processing may continue to fully close down the activity, such as returning data to the original provider or archiving data into a secure location.

24. Signatories

The DSA is not valid unless it is signed by appropriate individuals authorised to do so by each organisation. Their details and designation should be listed here. The level of signatory should correspond to the profile of the data sharing (for example, the more sensitive or complicated the purpose, the more senior the required signatory).