Skip to main content

The following requirements help support improved access to data, streamline data sharing pathways and ensure legal accountability obligations are met. They are essential for ShCR in IG compliance and good practice and need to be considered for both journeys.


3.1 The importance of good IG practice for ShCRs

The UK GDPR stipulates the requirements for controllers and processors. It also sets out where there is a requirement to have a Data Protection Officer (DPO) in place.

In addition, all NHS organisations and local authorities which provide social services must have a Caldicott Guardian. A Caldicott Guardian is a senior person responsible for protecting the confidentiality of health and care information. They should normally be a senior health or care professional or be closely supported by such a person.  

It is important that health and care professionals are represented in discussions about ShCRs. This is particularly important in relation to processes, for example to ensure that IG decisions do not create an unintended burden. It also ensures that a clinical view is factored into processes such as dealing with subject access requests (SARs) or considering whether to uphold an individual’s objection to sharing information.

Each ShCR will need a consistent approach to IG policies, processes and systems to ensure good practice across the ShCR. To achieve this, one individual will need to take the lead for a ShCR’s IG approach and work with their IG colleagues within the ShCR’s constituent organisations. The ShCR Accountable Officers should decide which IG representative takes the role of IG lead. They will need to be a subject matter expert and they are likely to be a DPO, although this will not necessarily be the case in every ShCR. The ShCR IG lead should be a senior post with the power to make sure that IG policies are put in place and followed.

The ShCR IG lead should implement a communications channel with IG representatives in each of the ShCR organisations. They should represent their colleagues, provide a conduit for communications, and become a member of the ShCR IG leads network who meet on a regular basis. As part of the ShCR IG leads network, good practice from local systems should be shared and capitalised upon. Representation from this network will be required at the national strategic IG network (SIGN) meetings. The IG lead will also be required to work with Caldicott Guardians, as well as local IG staff. Organisations must ensure IG resource is planned and budgeted for to meet the requirements set out above for an IG function.

Assurance checkpoint
  • appointment of a ShCR IG lead (subject matter expert)
  • ShCR IG Lead is a member of the ShCR IG Leads network
  • structure chart for ShCR IG function (including a communication strategy)
  • evidence of IG policies  
Further guidance, tools and templates for the importance of good IG practice for ShCRs

NHS England: Key roles and the DPO guide

Skills for Care: The role of the Data Protection Officer

Local job descriptions: Appendix 7

Local IG meeting structure: Appendix 7


3.2 Determining data flows and controllership

ShCRs must demonstrate compliance with the law by mapping data flows and determining roles and responsibilities. One of the most important challenges in the planning stages is to identify the flows of the data and at each point in the process determine who the controllers and/or processors are. This demonstrates a clear pathway to enable better risk identification and mitigation and clarity of who will have responsibility and accountability at each stage. This is particularly important when multiple joint controllers are required such as in a ShCR. A data flow mapping exercise will also inform your Data Protection Impact Assessment (DPIA), assisting you in accessing data from other organisations.

An individual’s health and care record will assist health and care professionals by bringing together content from across different venues of care that can be standardised and then displayed consistently. An example is by providing a consolidated medication list. This should provide the health and care professionals involved in an individual’s care, with confidence that they are accessing timely, complete, accurate and relevant information for the care episode. However, the IG Framework approach recognises the variance that we currently have in how data is captured and represented in local systems.  

Nationally, we have worked closely with ShCR and (LHCR) exemplar localities to learn lessons from existing architectural approaches. Whilst ShCRs are operating to a common architectural model, this is being implemented in different ways. There are differences in how data is captured at the point of care, digital maturity and local coding. There is therefore a need to be able to bring data together locally from organisations to process, standardise coding and handle duplicate entries. At this stage, we believe that the creation of a data layer, where data is held within the ShCR, is the most appropriate mechanism to ensure data is available in a standardised format. An alternative option to creating a data layer is retrieval of data on demand from source systems. This option will be explored by the ShCRs and may provide a future model where data remains resident within its host systems and is retrieved on demand.

3.2.1 Joint controllership

The UK GDPR and DPA 18 removes the concept of controllers in common. There is now a clear distinction between controllers working together as joint controllers or alone as individual controllers. Organisations working as part of a ShCR will work as joint controllers with other members of the ShCR areas. This is because between them they will decide on the purpose and manner for which personal data is collected. It will not be decided by one single organisation within the ShCR. As a ShCR is not a legal entity, joint controllers will need to enter into binding contracts or processing agreements with processors as a “grouping” of controllers rather than appoint a single lead controller to act on behalf of the grouping.

Data protection legislation requires joint controllers to be transparent about their respective responsibilities. They must ensure that individuals know whom to contact when wanting to exercise their information rights under the legislation. Information about the joint arrangements must be made available to individuals. Irrespective of the joint arrangement, an individual may exercise their rights in respect of and against each controller. Good processes therefore need to be in place to manage such situations.

Presently the way in which this can be met is by setting out an agreement containing the details of those involved in the joint ShCR controllership and how it will work, a "joint controller agreement". A joint controller agreement must be an operating model that documents the legal basis and the roles and responsibilities of each controller in the grouping. It should detail common rules for things such as retention and disposal. The agreement should specifically explain who will deal with requests from individuals to exercise their rights under the UK GDPR. For example, as part of the joint controllership arrangements, the constituent legal entities need to agree how they will handle SARs. This should include how decisions will be made on whether or not to redact third party data.

It is important to note that a "joint controller agreement" is not the same as a written contract or other legal act which is required when using a processor (UK GDPR Article 28), nor is it a legal “service level agreement”.

It is sensible for ShCR areas to bring together their suite of agreements into one place, regardless of what type of agreement it is. It would also be good practice to make joint controller agreements available to the public through the participating organisations' publication schemes. This would help meet the duties of accountability and transparency.

With regards to liability, UK GDPR Article 26 (joint controllers), details how joint controller arrangements must be set out and how liabilities and responsibilities for compliance are allocated, managed and if necessary indemnified. Joint controllers can be held “jointly liable” if collectively they are responsible for any breach of data protection law. However, the Information Commissioner’s Officer (ICO), as the regulator, will investigate to establish which organisation is at fault before using any enforcement powers. Therefore, not all controllers as part of a joint controllership agreement are likely to be liable if there is a failure.

3.2.2 Processors

A processor should only be selected and engaged if the controllers have been provided with sufficient guarantees that appropriate technical and organisational measures have been implemented. The joint controllers should be satisfied that the obligations of data protection law (Articles 28, 29, 30 and 32 of UK GDPR) and the rights of the data subjects are met. Any use of a processor must also be aligned with contractual obligations. Suppliers of software and services to care organisations are required to complete the Data Security and Protection Toolkit (DSPT), refer to section 3.6.1.

Processors may only act under written instruction from a controller. Therefore, if using a processor, a written contract must be in place between the group of organisations acting as joint controllers and the processors. This is a legal requirement and is essential so that everyone understands their roles and responsibilities and assurance can be given that the processor operates in a legally compliant way. The written instruction should set out what elements will be required for example telephone support, which may require access to health and care data.

When working as a group of joint controllers it is important to decide if the processor will be instructed by a lead organisation or by all of them. Processors are also required to have a DPO. The ShCR IG Lead should take responsibility for liaising with the DPO in the processing organisation to ensure clarity and compliance.

Processors must gain authorisation from the controllers if they wish to subcontract to a third party. Processors must also ensure the security of their processing, keep records of their processing and notify the controllers of any breaches which occur, without undue delay. Technical specifications such as role-based access, overrides etc. must be carefully considered and all the controllers comfortable with the arrangements.

All GP practices will use a clinical system of their choice. This is usually procured by the Integrated Care Boards (ICBs) on behalf of its member practices. The GP practices will sign an agreement allowing the ICB to procure a system on their behalf. The ICB signs a contract with the supplier of choice to enable them to call off products on behalf of the member practices. As part of this procurement, the system supplier provides a "Deed of Undertaking" which indemnifies GPs. This undertaking sets out what controls will be in place if the system supplier processes data itself and/or uses a data sub-processor. It provides assurances to GPs that compliance will be adhered to in relation to data protection law.  

3.2.3 Data sharing arrangements

ShCRs will share health and care information with other health and care organisations that are not part of the ShCR. At times this sharing will be done on an ad-hoc basis but in some situations the sharing will be more regular. For example, when an adjacent ShCR area contains specialist treatment centres.

There may also be occasions where a ShCR organisation receives a request for information about a patient or service user from outside the health and care family of organisations. These requests should be considered on a case-by-case, rather than automatically sharing. The DPA18 (see section 3.3.2) and the Common Law Duty of Confidentiality (CLDC) (see section 3.3.3) requirements must be taken into account. There may also be condition-specific legislation that places particular requirements on the controller (for example, Gender Recognition Act 2004). Where approval is given to share information, you will need to have a Data Sharing and Processing Agreement (DSPA) in place between the organisations involved.

The ICO’s Data Sharing Code of Practice covers how to approach ad-hoc and more regular data sharing and how to record activities using DSAs. In accordance with the Code, a DSA, sometimes called an information sharing agreement, is useful in setting out the purpose of the sharing, which organisations are involved and who is responsible for which elements of data protection compliance. It will also help you to demonstrate compliance with the accountability principle in UK GDPR (see section 3.7). NHS England has produced a template DSPA that can be used by all NHS and social care organisations. The template provides a high-level summary of the minimum data sharing obligations required between parties to ensure lawful data sharing. The template can be built upon to satisfy local needs. When processors are engaged, a written contract or other legal act is always required which may be supplemented by a separate data processing agreement.

Individuals can seek compensation from joint controllers in exactly the same way as from a sole controller. The law sets out that each joint controller will be liable for the entire damage caused by the processing, unless it can prove it is not in any way responsible for the event giving rise to the damage. When formal regulatory action is being considered by the ICO then the arrangement made between controllers is irrelevant for these purposes.

Assurance checkpoints for determining data flows and controllership
  • joint controller agreement agreed by all members of the grouping
  • DSA or protocols, where applicable
  • service level agreements, where applicable 
  • a processor contract between the grouping and the processor(s)
  • a clear data processing map showing purpose and controller and processor at each stage of data flow 
  • a completed and approved DPIA for each data sharing purpose to be published in participating organisations publication scheme (except for security and storage arrangements)
Further guidance, tools and templates for determining data flows and controllership

ICO: How do we document our processing activities?

NHS Standard Contract: data processing agreement

NHS England Joint Controllers Issues to Consider: Appendix 6

Local Joint Controller Agreement: Appendix 7

Local Contract for the Provision of IT Services: Appendix 7

Local Data Protection Contract: Appendix 7

Local Lead Controller Group: Terms of Reference


3.3.1 Statutory duties and functions

This is often referred to as "intra vires". If you are a public body, does the processing you wish to undertake match your statutory functions? In answering this question, identify and document the statutory function and the legislation it is derived from. For example:

  1. ICBs and NHS England have a duty to commission health services, but this does not confer an automatic power to process personal or CPI for their commissioning purposes.
  2. Where a Local Authority commissions an NHS agency (the Provider) to deliver its Child and Adolescent Mental Health Services (CAMHS) using the NHS Standard Contract, the local authority still retains its duty to respond to statutory complaints.

The Standard Contract (GC21.12) states that "where a commissioner requires information for quality management of care processes, this includes handling complaints about the Provider, the NHS Agency must consider whether the request can be met by anonymised or aggregated data and where personal data is required, ensure there is a legal basis". This legal basis can be found in UK GDPR, Public Task - Article 6. However, the conditions of Article 9(3) must also be met where relevant.

3.3.2 Data Protection Act (DPA) 2018 and UK GDPR

The data protection principles are found in the UK GDPR Article 5 and organisations are reminded to ensure they comply with these principles.

The UK GDPR also offers individuals' rights in certain circumstances. Those rights are:

  • Right to be informed
  • Right of access by the data subject
  • Right to rectification
  • Right to erasure (right to be forgotten)
  • Right to restriction of processing
  • Right to object to processing
  • Right to data portability
  • Rights in relation to automated decision making and profiling

All organisations must have policies and procedures in place to ensure the appropriate management of individual rights. For more detail on individual rights and restrictions under UK GDPR refer to section 3.4 and Appendix 4.

To ensure legal compliance, the requirements of the UK GDPR and the DPA 18 must be met. Chapter 2 of the DPA 18 is relevant to most processing of personal data therefore it is important that the UK GDPR and DPA 18 are read side by side. Each ShCR must be transparent about the legal basis they are relying on for each purpose for which they process data. In addition, when processing any special category personal data (such as health information) controllers will also need to identify a separate condition for processing as described in UK GDPR Article 9.

In practice, for much of the data processed in health and care there will be a two-stage process. The first stage gives the lawful basis as applied to all personal data (Article 6 of the UK GDPR). The second stage applies because you are processing a special category of personal data, data concerning health (Article 9).

First stage

It is for controllers to determine their lawful basis. The lawful basis for processing must be recorded.

The most appropriate basis for lawful processing that is available to funded and/or statutory health and social care organisations in the delivery of their functions is Article 6(1)(c) or Article 6(1)(e).

Generally, many health and care settings have a lawful basis for processing personal data. This is because it is necessary "for the performance of a task carried out in the public interest or in the exercise of official authority" (Article 6(1)(e)). Where processing data and citing Article 6(1)(e) as the basis for processing, you must be able to specify the Act of Parliament, Regulation or Statutory Instrument that provides the lawful basis for the activity. This, in turn, will engage Article 6(1)(e), and provide a lawful basis for processing data.

In some circumstances, the controllers could also decide that the processing is necessary for "compliance with a legal obligation" where they have such an obligation to provide care (Article 6 (1)(c)).

Primary care providers operating under contract with NHS England do not have direct legal authority. The authority rests with NHS England. However, where services are provided under such contracts, the providing bodies are subject to statutory regulation and can therefore rely on Article 6(1)(c). Any service provided beyond the contract will be covered by Article (6(1)(e).

In the case of locally commissioned services Article 6 (1)(b) "for the performance of a contract" may be considered. Where independent care providers are processing personal data in connection with the provision of self-funded care, they can rely on Article 6(1)(f) (legitimate interests).

Article 6(1)(d) to protect the vital interests of the data subject may also be appropriate, for example, in the case of an emergency.

Do not use consent as a condition for processing to meet UK GDPR and DPA 18 requirements, unless in exceptional circumstances. Should specific processing arise in which explicit consent is required by law, for example, Human Fertilisation and Embryology Act 2008 and Gender Recognition Act 2004, then please refer to UK GDPR recitals: 3242 and 43.

Second stage

Special categories of personal data, including data concerning health, may be processed only for reasons specified in Article 9 of the UK GDPR. In the case of most health and care settings, the reasons are generally for:

  • ‘the provision of health care or treatment’
  • ‘the management of health care systems or services or social care systems or services’
  • ‘necessary for reasons of public health in the area of public health’

When processed for these reasons, a healthcare professional, social work professional or a person with a CLDC under a legal provision (as listed in DPA 2018 s204), must be responsible for the processing.


3.3.3 Common Law Duty of Confidentiality (CLDC)

The CLDC will need to be considered when sharing information for ShCR. Common law (case law) is law that has developed through the courts making decisions on legal points in specific cases and creating binding precedents. It differs from statutory law, which is determined by acts of parliament.

Essentially, the CLDC means that when someone (such as a patient or service user) shares personal information in confidence (to a healthcare professional, for example) it must not be disclosed without some form of legal authority or justification. In practice, this usually means that the information cannot be disclosed without that person’s consent. That is unless there is another valid legal basis, such as a court order, statutory gateway which allows confidentiality to be set aside, or overriding public interest. Where a patient or service user has agreed to a programme of treatment and care, it is assumed they have agreed to the use of their relevant information to support that programme of treatment being shared with others who are involved in their care. This is known as implied consent.

In certain situations, other than for individual care reasons, approval may be sought from the Confidentiality Advisory Group (CAG), which is part of the Health Research Authority (HRA). CAG have the power to advise on setting aside the CLDC, usually for research purposes, under Section 251 of the NHS Act 2006.

The Health and Social Care (Quality and Safety) Act 2015 inserts Section 251B into the Health and Social Care Act 2012. The section places an obligation on a "relevant person", for example, a health or adult social care commissioner or provider, hence it is a corporate duty, not an employee’s to share information to facilitate the provision of health and social care services or because they feel it is in the individual’s best interest. This accords with the 7th Caldicott principle. However, the obligation need not be complied with should the relevant person reasonably consider that the individual would object or be likely to object to the disclosure of the information. An objection to processing can be raised, refer to section 3.5 on objections.

In delivering individual care, it is reasonable and lawful to rely upon implied consent as the basis for sharing relevant information about their treatment and care needs with others involved in the delivery of their care. Unlike the high threshold for consent (where applicable) under UK GDPR, the same standard of consent is not necessary to satisfy CLDC. Consent under the CLDC may therefore be implied for the sharing of all information relevant to the care of the individual. This is unless an individual specifically objects to CPI being shared for these purposes. Although implied, individuals with capacity also have the right to withdraw consent for the use of their information, even if this impacts the care that is being provided or is to be provided so long as this has been explained to them. Where health and care information is accessed, only relevant information should be seen as governed by access controls and professional codes of conduct, see section 3.4.

To use implied consent, organisations must inform patients or service users of how their information may be used when providing services. Transparency is a mandatory requirement under UK GDPR. Organisations need to ensure that patients or service users are as informed as possible. This could be through discussions with health and care professionals, information leaflets, and comprehensive transparency materials. Refer to section 3.3.5 for more details on transparency.

3.3.4 Meeting the Human Rights Act 1998 obligations

The Human Rights Act, article 8, gives individuals a right to respect for their private and family life. However, this does not make it unlawful for organisations to process personal data where there is otherwise a lawful basis to do so. A public authority abiding by the UK GDPR and the CLDC is likely to meet the Human Rights Act obligations. This is because the UK GDPR’s overarching aim is the protection of the rights and freedoms of individuals where it concerns the handling of their personal data. However, it will be important to ensure that any information sharing is necessary for the specified purpose AND is proportionate. A DPIA must be completed at an early stage to identify any risks to the processing of personal data. For further information regarding DPIAs, refer to Section 3.7.2.

Assurance checkpoints for understanding legal requirements
  • a statement for each organisation involved in the collective sharing setting out the purpose, lawful basis for processing and CLDC satisfied
  • transparency information stating what data is collected, stored, shared and retained and for how long. The transparency information must also include information on patient or service user preferences, where applicable
  • an agreed approach across the ShCR for the management of patient or service user objections to share their data for individual care
  • evidence of effective Role Based Access Control (RBAC)
  • evidence of completed and approved DPIA for each data sharing purpose to be published in participating organisations publication scheme (except for security and storage arrangements)
Further guidance, tools and templates for understanding legal requirements

3.3.5 The duty of transparency

ShCRs must demonstrate compliance with the law by ensuring transparency about purpose and process. A new requirement of the UK GDPR is the principle of accountability which requires that organisations must not just comply with the law but be able to demonstrate that compliance.

The duty of transparency is also one of the ways we can build trust and gain the respect of the public in the use of their data. The aim of transparency is to ensure there are "no surprises" for the patient. This is now enshrined as the eighth Caldicott Principle - Inform patients and service users about how their confidential information is used.

Part of the transparency requirement involves the provision of information to the public via transparency materials – previously referred to as privacy notices. A specific requirement of the UK GDPR is that organisations must include their lawful basis for processing information in their transparency materials. Individuals must also be informed of their right to object to processing and how to exercise that right, refer to section 3.5. Whilst we do not need to ask permission to use data for individual care, we are under a duty to inform people about what we are doing, as well as why and how we are doing it (UK GDPR Articles 13 and 14).

The law gives discretion to controllers to consider where this information is displayed and which different layers of communication to adopt. It is however clear that information regarding the processing of personal data must be:

  • easily accessible, paper or electronic, if requested or directed to the website
  • concise, transparent and intelligible
  • written in clear, plain language
  • free of charge

There are differences in what you must provide depending upon whether you are collecting information directly from individuals or whether it is being obtained from a third party.

Care must be taken if conveying information to children, as more specific obligations will apply. The ICO has guidance on Children and the UK GDPR including how the right to be informed applies.

Online information can form part of the duty of transparency and can assist in helping to keep the data relevant and accurate. The publication of records of processing activities (RoPA) (see section 3.3.6), data sharing flows etc, can all contribute to this aim (consider publishing under the Freedom of Information Act 2000).

It is helpful, if possible, to involve communications professionals in the transparency process. It is important to ensure that the production of materials, language and channels used are appropriate. To ensure consistency throughout the ShCR, it is important that the same messages and language are used. When new organisations join the ShCR, transparency information will need to be updated. Equally, to ensure consistency across the system, template text for national initiatives such as the Summary Care Record or local requirements such as DPIA and transparency materials should be adopted.

Assurance checkpoints for the duty of transparency
  • production of a clear plan, list of communication materials and channels  
  • transparency materials stating what data is collected, stored, shared and retained for how long). The material should also include information on patient or service user preferences, where applicable
  • publication of information and transparency materials by all participating organisations in the ShCR to the public, patients or service users
  • details of a process for managing and updating communications
  • evidence of public engagement to gain their view of the approach and test materials 
  • demonstration of how patients or service users can exercise individual rights in transparency documentation 
Further guidance, tools and templates for the duty of transparency

3.3.6 Records of Processing Activity (ROPA)

UK GDPR Article 30 requires records of processing activities to be kept. These records must be kept up to date by controllers and processors as they can be requested by the supervisory authority at any time. Records of processing activity can be linked to transparency information for ease of transparency.

From the records of processing activity, organisations will be able to build upon and manage a comprehensive register of information assets and their owners. This should show when, why and how that data is processed for what purposes, with whom it is shared. It should also set out the retention periods.

The registers must be monitored, reviewed and maintained on a regular basis. Where possible, the registers should be released through the organisations’ publication schemes. Publication will assist in demonstrating accountability.

Assurance checkpoints for Records of Processing Activity (ROPA)
  • policies and procedures for information asset management
  • ROPA/Production of an Information Asset register/ROPA list
Further guidance, tools and templates for Records of Processing Activity (ROPA)

Organisations that process health and care information must also have an Appropriate Policy Document (APD) set out in Article 30. This must outline:

  • the legal basis upon which the processing is taking place
  • compliance with UK GDPR Principles (Article 5)
  • how long you retain, and/or the erasure of, personal data. If these retention periods are not followed, or personal data isn’t to be erased at the end of processing, you must explain why

The APD does not need to be a specific document titled as such. An APD may be a local Records Management Policy that sets out within it the points mentioned above.

You do not need a separate APD for each processing activity or condition relied upon. You could have a single document that references the processing undertaking in its various forms and cite which policy or guidance document can provide the necessary detail.

The APD is not designed to be a standalone document detailing every processing activity you undertake. It is aimed at complementing your general ROPA commitments, giving further protections and accountability to the personal data you are processing.

APDs must be seen as an iterative document. They must be retained for at least six months from the end of the processing activity to which they relate. When a service changes operationally, the relevant guides and documents for that service must also be updated to reflect the new changes and still cover the bullet points listed above.

The ICO may ask to see your APDs. If so, you must give it to them free of charge and as soon as reasonably possible following the request. Further guidance can be found on the ICO’s website.


3.4 Data access controls, subject access requests, review and retention

ShCRs must ensure compliance with the law by promoting the application of appropriate technical and organisation measures. When accessing data for individual care purposes, consideration must be given to the policies and processes used to support that disclosure.

Who has access and what they have access to needs to be worked out and made clear within the information sharing agreements and information provided to the public. ShCRs need to ensure that only health and care professionals and non-clinical staff who have a legitimate relationship with the patient or service user, providing or supporting their care, will have access to their record.

An appropriate access control model delivers this commitment. A national policy is being developed for this purpose through engagement with national stakeholders and clinical groups. This will set out basic requirements for an access control model as a minimum standard for intra-ShCR data sharing, journey 1, and cross ShCR data sharing, journey 2. This will ensure health and care professionals access only relevant and proportionate information from the health and care records of individuals with whom they have a legitimate relationship. The ShCR approach will also provide a feedback loop back to source systems to support the improvement of data quality at source.  

Care should be taken to ensure that the ShCR is clear on which individual rights apply and have processes in place to ensure an individual can enact those rights, see section 3.3.2. The application of individual rights is dependent upon the conditions for processing used for the sharing of the data.

Patients and service users have the right to know certain information about the processing of their personal data by health and care organisations. These include:

  • the purpose for processing
  • what information is being processed
  • who is processing their information
  • if they have the right to rectification or erasure of their data
  • the right to complain to the ICO
  • where information about them is collected from (if not themselves)

This list is not exhaustive, and this information will usually be included in the organisation’s transparency materials created for patients or service users.

ShCRs must include high-level audit functionality which enables controllers to meet their access control responsibilities. It should also provide information to individuals about which organisations have accessed their records, when and why. Some audit trail functionality may enable individuals to also see what activity was done in the record. Patient or service users have the right to challenge that access.

There needs to be a process in place to ensure that SARs to the ShCR are responded to. This must be detailed in the joint controller arrangement. The individual has a right to obtain confirmation as to whether personal data is held about them and to have access to that data and the associated information, namely:

  • the purposes of the processing
  • the categories of the data
  • recipients of the data and who has accessed it
  • how long the data will be stored, and the criteria used to determine that
  • the existence of the right to request rectification or erasure, restriction and objection to processing should those rights be applicable

An example of a process which has worked well in some areas is an information sharing group, which is established to lead on the request handling. In the event of a SAR, each organisation contributing to the ShCR would be asked to send their redacted data to the information sharing group who would respond to the individual. It must be made clear to individuals that this is the process in case some individuals do not want information sent outside the organisation that holds it. In such cases the "holding" organisation should deal with the request on an exclusive basis. One option to do this could be that organisations may respond by facilitating online access by the individual to their own record. However, where this is not possible, the organisation can provide a "sealed" redacted record (either on paper, CD or other media) to the "holding" organisation to pass to the individual.

Organisations must avoid a situation where a management fee can be charged by the co-ordinating body. Fees can no longer be charged for subject access except in instances where the request is manifestly excessive or unfounded, particularly if it is repetitive. In these instances, organisations may charge a reasonable fee, but this must only be based on admin costs involved in retrieving information.

It is also important to note that the CLDC applies to deceased patients and any third parties identified in the record. If there are requests to access the deceased's patient information, then these need to be considered under the Access to Health Records Act 1990.

Where data is held within the ShCR, then each ShCRs must ensure that they retain records in an accessible format until the relevant retention period is reached. This is in line with the Records Management Code of 

Practice 2021. A decision must then be made as to whether the record should be:

  • retained for a longer period (there must be a valid reason for this)
  • sent to a Place of Deposit
  • destroyed or deleted
Assurance checkpoint for data access controls, subject access requests, review and retention
  • Compliance with the Records Management Code of Practice for Health and Social Care 2021
  • Audit of IG policies
  • Effective Role Based Access Control (RBAC)
  • Process in place for complying with individual rights where required, such as rectification, objection and SARs
Further guidance, tools and templates for data access controls, subject access requests, review and retention

3.5 Patient and service user objections to processing

3.5.1 Common law duty of confidentiality

There are two legal considerations here; the duty of confidentiality and data protection law. In most circumstances the former will be relevant when proposing to share information for the purposes of providing individual care while the latter is broader and could include individuals objecting to the retention of certain data.

Although consent for delivering individual care is implied, individuals with capacity also have the right to withdraw consent for the use of their information. This is the case even if it impacts the care that is being provided (or is to be provided) so long as this has been explained to them and in particular the consequences of the withdrawal. For example, if an individual states that they do not wish to share a specific piece of information as part of the ShCR, then you should respect their wishes. The individual does not need to justify their reasons unlike the right to object under UK GDPR as set out.

3.5.2 UK GDPR

UK GDPR gives individuals the right to object to the processing of their personal data and have their objection considered Article 21. The right to object is particularly relevant to certain health and care organisations where lawful processing is based on a "task in the public interest" provision. If someone objects to you processing their data, you will need to demonstrate "compelling, legitimate grounds for [either] the processing which overrides the interests, rights and freedoms of the data subject, or for the establishment, exercise or defence of legal claims".

All ShCRs must ensure procedures are in place in relation to individuals' objections under UK GDPR as a minimum. Organisations need to ensure that where objections have been received, procedures and processes are in place to consider and respond. While it is unlikely that an objection would be upheld where it concerns a health and care record, objections must be considered on a case-by-case basis. This allows IG professionals to work with their clinical colleagues and Caldicott Guardian to make the decision to uphold or reject the request. An individual should give specific reasons why they are objecting to the processing (which covers any use of the data including the recording of it and sharing it) of their data based on their particular situation. Individuals must have the risks of their decision clearly explained to them and documented. When considering whether to uphold an objection, the compelling grounds need to be balanced by the individual's original grounds for the objection. This will differ from case to case. Controllers will then need to consider whether their own requirements override that of the individual.

Although UK GDPR does not give a specific definition of compelling legitimate grounds, there is guidance from the ICO on legitimate interests. The guidance can help aid decision making on whether an organisation could continue to process the data subject’s data on compelling and legitimate grounds. It includes information about Legitimate Interest Assessments (LIA) which involve a three part test. Controllers are encouraged to ask the right questions about processing and objectively consider the reasonable expectations of the individual, together with any impact of the processing on them. The Balancing Test (part 3 of the LIA) covers the need to consider the interests and fundamental rights and freedoms of the individual.

3.5.3 Local policies in relation to choices

Some ShCR areas have provided mechanisms for patients and service users to state a preference over whether they have a shared record, for example, by providing an opt-out form. Again, this is a local policy decision. It is important however, that this local mechanism for stating a preference is not confused with the right to object under UK GDPR where each objection needs to be considered and responded to on a case-by-case basis. Communications with patients or service users should be clear and distinguish between the right to object under UK GDPR and an individual's preference around data sharing.

Some ShCRs may go beyond this following local discussions with health and care professionals, patients and service users and implement a local policy where a patient or service user is asked before their record is viewed. This should not be referred to as "patient consent" but rather “permission to view”. Permission to view can help ensure there are no surprises for the patient or service user particularly when a particular role is accessing relevant but more detailed information, see section 3.4.

Assurance checkpoint for patient and service user objections to processing
  • an agreed approach across the ShCR for the management of patient or service user objections to share their data for individual care

3.6 Assuring security

All organisations, including those within a ShCR, are expected to comply with relevant cyber security legislation, policies and guidance. This includes the National Data Guardian’s ten data security standards. This will help ensure that people, processes and technology are maintained to ensure cyber security and protect the confidentiality, integrity and availability of records.

It is also important that policies for areas such as staff training, internal audits and HR, and retention and disposal schedules are adhered to. They should be available under FOI requirements, but withholding anything that may compromise the security and integrity of the record.

3.6.1 The Data Security and Protection Toolkit (DSPT)

The Data Security and Protection Toolkit (DSPT) is a compliance Framework that covers all aspects of security and confidentiality. Its focus is on building trust in health and care IT systems. All organisations processing patient and service user data must meet the DSPT requirements.

The DSPT is based on the National Data Guardian’s ten data security standards. It is linked with, and supported by, the National Cyber Security Centre, the agency tasked with protecting critical infrastructure. To meet the relevant standards, including IG standards, all Toolkit questions must be appropriately answered. Organisations must not, however, rely solely on DSPT returns for assurance.

The DSPT also includes a tool for reporting data breach incidents which must be used by NHS-funded care organisations. See Appendix 5 for more information on Data Breach Management.

Assurance checkpoint for assuring security
  • a ShCR Cyber Assurance Framework is in place
  • a communications route between the ShCR Cyber Security Lead and the ShCR IG Lead and other Cyber Leads within the ShCR participating organisations
Further guidance, tools and templates for assuring security

3.7 Demonstrating accountability

Accountability is one of the key principles in data protection law and all controllers must be able to demonstrate their compliance (Article 5(2)). The ICO has set out how organisations can demonstrate their compliance. It is therefore imperative that all decision making is documented including who was involved and the rationale or justification behind the decision.

3.7.1 Adopting principles by design and default

All ShCRs must ensure the use of data protection by "design and default". Adopting the principles of data protection by design and data protection by default is an important concept for any project or new model of care. It is important that when considering new ways of working, the impact to privacy and confidentiality are factored in at the design stage. That way IG is integrated into the policies, processes and systems from the beginning. It will assist in enabling data sharing for the benefit of individuals and the system, whilst minimising the risk to privacy. IG should be identified as part of any Project Initiation Documents and should be treated in the same way as finance with the essential criteria, key issues and resources assessed.

ShCRs must comply with the law by minimising the use of identifiable data. To meet the data protection principles when using personal data, the amount of data should be adequate, relevant, and not excessive for the purpose. A data minimisation approach should be adopted. Only where there is no alternative to its use should personal data be used for any purpose. Personal data will always be required for individual care. However, caution should be taken to ensure that a balance is sought between the requirement for adequate amounts of data for the provision of care versus the processing of excessive information (taking into account any clinical risk). Clinical Safety Officers (CSOs) as well as Caldicott Guardians and DPOs should be involved with such decision making.

Further information about the responsibilities of a Clinical Safety Officer is set out in the clinical safety standards. These standards are mandatory under the Health and Social Care Act 2012. Ultimately, this helps health and care staff to provide better and safer care.

3.7.2 Data Protection Impact Assessments (DPIA)

If personal data is to be used, UK GDPR (recital 84) states that a DPIA is required “where processing operations are likely to result in a high risk to the rights and freedoms of natural persons”. Article 35 further sets out that one of the situations where a DPIA is required is where the processing will involve large amounts of "special category data". In practice this means a ShCR area must carry out a DPIA. The DPIA needs to be approved by the ShCR DPO or joint ShCR DPOs before any processing of personal/CPI commences. Any decision not to carry out a DPIA must be justified and documented.

You must have a mechanism for ensuring DPIAs are appropriately undertaken and acted on. This includes training for staff, so they understand the need to complete a DPIA, along with the policies and processes they need to follow. When completing the DPIA, if you identify a high risk which you cannot mitigate, then you MUST consult the ICO before starting the processing.

Assurance checkpoint for demonstrating accountability
  • completed and approved DPIA for each data sharing purpose to be published in participating organisations publication scheme (except for security and storage arrangements)
  • IG considerations in Project Initiation Documentation
  • DPIA risks incorporated into (organisational/ShCR) risk register including mitigation and management
  • unmitigated high risks are escalated to the DPO and the ICO is consulted
  • consultation with the public on data sharing for integrated care
Further guidance, tools and templates for demonstrating accountability

Last edited: 6 May 2026 10:47 am