R-052-001 DPIA 2023_001

• Governed by procedure GP-052 Data Privacy Impact Assessment (DPIA)
• Comes from template T-052-001 DPIA for PA-005 PR API and PA-006 PR Web app

Summary

Description of the processing activity

The activity consists of processing medical data, which can be collected via API integration or via web app, by the organisations that use our service. This activity corresponds to the codes PA-005 PR API and PA-006 PR Web app of our Record of Processing activities (ROPA).

info

Although we have differentiated PA-005 PR API and PA-006 PR Web app as two different processing activities, they are very similar except in their implementation method. While PA-005 PR API refers to the API implementation, the PA-006 PR Web app refers to a use through a web application. The purposes for processing and the data processed are the same.

Summary of the project

Legit.Health (hereinafter, us and we) is a technology provider empowering care providers and capacitating general practitioners, specialists, nurses and other healthcare practitioners (hereinafter, HCP) teams to provide more reliable and quicker patient care. Our services are used by hundreds of HCPs, to care for thousands of patients.

Technically speaking, the project consists of providing the Client with access to our artificial intelligence. This means that the Client will access our technology to send images of skin lesions and get back an array of data.

The following section provides an analysis of the clinical benefits and outcome parameters associated with the device, which have been extracted from the evidence available in the record R-TF-015-002.

Claim 1: Comprehensive Dermatological Data for Informed Clinical Decisions. Comprehensive Analysis for Informed Decision Making. Improvement in Dermatological Assessment Accuracy. Precise Detection of Dermatological Features. Empowerment of Health Care Practitioners.

• Performance: The device provides an analysis of the epidermis, dermis, and their appendages, delivering a wide array of clinical data to support healthcare practitioners in their evaluations. Utilizing advanced computer vision algorithms, the device detects and analyses various dermatological features, providing detailed insights into the condition of the skin, that practitioners use to improve their clinical assessment.
• Evidence: Validation studies and real-world applications have demonstrated the device's proficiency in helping practitioners increase their diagnostic success rate, thereby facilitating a more comprehensive and informed clinical decision-making process.

Claim 2: Faster Measurement of Clinical Signs. Accurate and Objective Measurement of Clinical Signs. Precise Quantification, Count and Extent measure of Skin Issues. Facilitation of Longitudinal Skin Condition Monitoring. Consistent Tracking of Patient Condition Over Time. More agile follow-up consultations.

• Performance: The tool provides objective quantification of various clinical signs such as erythema, desquamation, and induration, offering precise measurements that enhance the evaluation and monitoring of skin conditions. More concretely, the device offers precise quantification of the intensity, count, and extent of various clinical signs. By doing so, the device is specifically designed to facilitate the longitudinal monitoring of skin conditions, allowing healthcare practitioners to track changes and progression over time with high precision. And not only that, but it achieves the results in a matter of seconds.
• Evidence: The vast literature shows the high inter-observer variability of HCPs in estimating the intensity, extent and count of clinical signs. The issue of subjectivity is so pronounced that there is even a high intra-observer variability. On the contrary, our validation has consistently shown the device's ability to provide accurate and reliable quantifications, reducing inter-observer variability, and ensuring that healthcare practitioners have access to objective data for improved patient care. Furthermore, the device outputs the score in a range from 1 to 100, which improves the Minimum Observable Change by providing a higher Level of Differentiation (LoD). And most importantly, the evidence shows that the device is a method that is much faster and less time-consuming for HCPs.

Claim 3: Improved Operational Efficiency for Healthcare Organizations. Streamlining Healthcare Operations. Data-Driven Insights for Workflow Optimization.

• Performance: The device not only aids in clinical evaluations but also provides actionable insights that contribute to the optimization of clinical workflows within healthcare organizations. By delivering quick and precise clinical data, the device plays a crucial role in enhancing the operational efficiency of healthcare workflows, leading to better patient outcomes and resource management.
• Evidence: Feedback from various healthcare organizations and practitioners confirms the device's positive impact on streamlining workflows and improving the overall efficiency of patient care delivery in tasks such as increasing the adequacy of referrals or improving triaging patients. Performance metrics have illustrated the device's role in enhancing workflow efficiency, leading to improved patient care and operational effectiveness.

Claim 4: Support in Preliminary ICD Classification through Image Analysis. Aiding in ICD Classification. Diagnostic Support.

• Performance: The device offers an interpretative distribution representation of potential ICD classes based on image analysis, providing valuable preliminary information that can aid in the patient management process, aiding in the preliminary categorization of conditions.
• Evidence: Through extensive testing and real-world application, the device has proven its capability to accurately suggest potential ICD classes, supporting healthcare practitioners in the early stages of diagnosis and treatment planning. Validation studies have showcased the device's capability to accurately represent ICD classes, assisting practitioners in the early stages of diagnosis and patient management.

Claim 5: Targeted Analysis for Facial Palsy Evaluation. Support in Assessing Facial Palsy. Accurate Assessment for Facial Palsy.

• Performance: When it comes to assessing facial palsy, the device offers targeted and specialized data, aiding healthcare practitioners in making accurate and timely evaluations of the intensity of facial nerve injury. Thus, the device aids in the assessment process by providing detailed data specific to facial structures. And not only that, but it achieves the results in a matter of seconds.
• Evidence: Studies focused on facial palsy assessment have highlighted the device's effectiveness in providing critical data necessary for a comprehensive evaluation, showcasing its utility in this specific clinical scenario. The vast literature shows the high inter-observer variability of HCPs in estimating the degree of the affectation of facial nerve injury, which is subject to high subjectivity. On the contrary, our validation has consistently shown the device's ability to provide accurate and reliable quantifications, reducing inter-observer variability, and ensuring that healthcare practitioners have access to objective data for improved patient care. And most importantly, the evidence shows that the device is a method that is much faster and less time-consuming for HCPs.

1. Determining whether the Privacy Impact Assessment (PIA) is necessary

The first step is to determine if the activity needs a full Processing Impact Assessment (PIA).

Checklist

These questions are intended to help decide whether a full DPIA is necessary. Answering “yes” to any of the screening questions below (except those questions which have caveats) represents a potential IG risk factor that will have to be further analysed to ensure those risks are identified, assessed and fully mitigated.

#	Category	Screening Question	Applicable
1	Individual	Will the process or system include the processing of personal or sensitive data?
2	Individual	Will the process or system involve the collection of new information about individuals? For example, additional information collected which was not initially captured in the process or system.
3	Individual	Will the process or system compel individuals to provide information about themselves?
4	Stakeholder	Will information about individuals be released/shared with organisations or people (i.e. internally with ICB/HB departments or externally with individuals/departments) who have not previously had routine access to the information? Caveat: this will only qualify as a “yes” if “yes” has been answered for Q1, Q2 or Q3
5	Information	Will the information be used for a different purpose than originally agreed? For example, an additional purpose, which was not initially captured in the process or system. Caveat: this will only qualify as a “yes” if “yes” has been answered for Q1, Q2 or Q3 and/or a previous PIA or agreement has been completed.
6	Information	Does the process or system involve the use of new technology that might be perceived as being privacy-invasive? For example: biometrics, cookies, finger print identification, IP Addresses etc.
7	Information	Will the project result in you making decisions or taking action against individuals in ways, which could have a significant impact on them?
8	Information	Is the information about individuals likely to raise privacy concerns or expectations? For example: health records, criminal records, staff records, or other information that individuals are likely to consider as private.
9	Information	Will the process or system require you to contact individuals in ways, which they may find intrusive?
10	Approval	Has this process or system already started as a pilot without a DPIA being undertaken?

Outcome

2 of the 10 screening items are deemed applicable, thus:

• a full Privacy Impact Assessment (PIA) is required.
• a full PIA is not required.

2. Privacy Impact Assessment

Since the previous step concluded that the full PIA is necessary, in this section we will lay out an assessment of the risks and the mitigations related to data processing.

To this effect, this document follows two guidelines:

• The Data Privacy Impact Assessment Code of Practice developed by the Information Commissioners Office (ICO) to help organisations complete privacy impact assessments.
• The guidelines of the European Commission, and especially relating to Article 35 of the General Data Protection Regulation (GDPR)

Intended use

The device is a computational software-only medical device intended to support health care providers in the assessment of skin structures, enhancing efficiency and accuracy of care delivery, by providing:

• quantification of intensity, count, extent of visible clinical signs
• interpretative distribution representation of possible International Classification of Diseases (ICD) classes.

Quantification of intensity, count and extent of visible clinical signs

The device provides quantifiable data on the intensity, count and extent of clinical signs such as erythema, desquamation, and induration, among others; including, but not limited to:

• erythema,
• desquamation,
• induration,
• crusting,
• dryness,
• oedema,
• oozing,
• excoriation,
• swelling,
• lichenification,
• exudation,
• depth,
• edges,
• undermining,
• pustulation,
• hair loss,
• type of necrotic tissue,
• amount of necrotic tissue,
• type of exudate,
• peripheral tissue edema,
• peripheral tissue induration,
• granulation tissue,
• epithelialization,
• nodule count,
• papule count,
• pustule count,
• cyst count,
• comedone count,
• abscess count,
• draining tunnel count,
• lesion count

Image-based recognition of visible ICD classes

The device is intended to provide an interpretative distribution representation of possible International Classification of Diseases (ICD) classes that might be represented in the pixels content of the image.

Device description

The device is computational software-only medical device leveraging computer vision algorithms to process images of the epidermis, the dermis and its appendages, among other skin structures. Its principal function is to provide a wide range of clinical data from the analyzed images to assist healthcare practitioners in their clinical evaluations and allow healthcare provider organisations to gather data and improve their workflows.

The generated data is intended to aid healthcare practitioners and organizations in their clinical decision-making process, thus enhancing the efficiency and accuracy of care delivery.

The device should never be used to confirm a clinical diagnosis. On the contrary, its result is one element of the overall clinical assessment. Indeed, the device is designed to be used when a healthcare practitioner chooses to obtain additional information to consider a decision.

Intended medical indication

The device is indicated for use on images of visible skin structure abnormalities to support the assessment of all diseases of the skin incorporating conditions affecting the epidermis, its appendages (hair, hair follicle, sebaceous glands, apocrine sweat gland apparatus, eccrine sweat gland apparatus and nails) and associated mucous membranes (conjunctival, oral and genital), the dermis, the cutaneous vasculature and the subcutaneous tissue (subcutis).

Intended patient population

The device is intended for use on images of skin from patients presenting visible skin structure abnormalities, across all age groups, skin types, and demographics.

Intended user

The medical device is intended for use by healthcare providers to aid in the assessment of skin structures.

User qualification and competencies

In this section we specificy the specific qualifications and competencies needed for users of the device, to properly use the device, provided that they already belong to their professional category. In other words, when describing the qualifications of HCPs, it is assumed that healthcare professionals (HCPs) already have the qualifications and competencies native to their profession.

Healthcare professionals

No official qualifications are needes, but it is advisable if HCPs have some competencies:

• Knowledge on how to take images with smartphones.

IT professionals

IT professionals are responsible for the integration of the medical device into the healthcare organisation's system.

No specific official qualifications are needed, but it is advisable that IT professionals using the device have the following competencies:

• Basic knowledge of FHIR
• Understanding of the output of the device.

Use environment

The device is intended to be used in the setting of healthcare organisations and their IT departments, which commonly are situated inside hospitals or other clinical facilities.

The device is intended to be integrated into the healthcare organisation's system by IT professionals.

Operating principle

The device is computational medical tool leveraging computer vision algorithms to process images of the epidermis, the dermis and its appendages, among other skin structures.

Body structures

The device is intended to use on the epidermis, its appendages (hair, hair follicle, sebaceous glands, apocrine sweat gland apparatus, eccrine sweat gland apparatus and nails) and associated mucous membranes (conjunctival, oral and genital), the dermis, the cutaneous vasculature and the subcutaneous tissue (subcutis).

In fact, the device is intended to use on visible skin structures. As such, it can only quantify clinical signs that are visible, and distribute the probabilities across ICD classes that are visible.

Summary of the processing roles

Party	Role
The Client	Data Controller
Us	Data Processor

Privacy by design measures

When possible, the tool is configured in such a way that the Data Processor does not store the photograph nor the report, and there is no way to associate the photo processed with the user who uploaded it, which provides a high degree of privacy by design that prevents identification.

In cases where it is necessary for the Client to retrieve the image or the report in the future, the users will access through a 'closed system', as defined in 21 CFR 11, which also provides a high degree of privacy by design.

Project Lead:

• Name: Taig Mac Carthy
• Job Title: COO
• Email: taig@legit.health
• Phone: 619085580

Identification of parties

Supplier

Property	Value
Company name	AI Labs Group, S.L.
Trademark	Legit.Health ®
ID Number	(ES)B95988127
Activity	Provision of clinical intelligence and communication software for HCP.
Address	Gran Via, BAT Tower, 48001, Bilbao, Spain
Telephone	+34 653 08 83 37
Email	hello@legit.health
Website	https://legit.health
Legal representative	Ms. Aguilar Robles

Supplier's Data Protection Officer

	Identifying information
Company name	Audens Legal, S.L.P.
Address	Calle del Marqués de Cubas 12, 5ºC, 28014 Madrid
ID Number	(ES)B85808954
Address	Gran Via, BAT Tower, 48001, Bilbao, Spain
Telephone	+34 910 099 875
Email	rgpd@audens.es
Website	https://audens.es

Sub-contractors

No, there are no sub-contractors providing bespoke solutions.

Vendors or sub-processors

Yes, the service is cloud based and uses Secure Virtual Private clouds provided by Amazon Web Services (AWS).

The AWS cloud is used to host all client data for operational purposes including Personal Identifiable Data (PID) which is held in more than one data centre as a natural backup.

Contract and accreditations

Contract in place

Contract	Signed date
License for use	N/A

Checklist of relevant clauses

The contract between us and the Client includes (or will include) clauses related to:

• Data sharing with the between the supplier and the Client
• Data security and protection
• Data confidentiality
• Breach reporting
• Data subject access and erasure requests
• Compliance with all relevant legislation and regulation, particularly UK GDPR

Other clients

We have contracts with dozens of healthcare providers and managing organisations, including European goverment-run health services and hospital groups.

Compliance with standards

We actively follow and comply with the standards checked in the following list.

• ISO 13485 (Medical Devices)
• ISO 9001 (Quality Management System)
• ISO 27001 (Information Security)
• ISO 27018 (Information Technology)
• DSPT (Data Security Protection Toolkit)

Certification with standards

We have been certified by third party auditors regarding the standards checked in the following list.

• ISO 13485 (Medical Devices) certification
• ISO 9001 (Quality Management System) certification
• ISO 27001 (Information Security) certification
• ISO 27018 (Information Technology) certification
• Cyber Essentials Plus
• Data Security Protection Toolkit (DSPT)

Penetration testing

We conduct independent external network penetration testing monthly, which include Open Web Application Security Project (OWASP) Top 10 vulnerabilities.

Information asset register

Information Asset Register

Yes, this system/data has been added to the relevant Information Asset Register

What is an Information Asset?

All organisations own and use information assets that support their local business needs. A subset of these assets will be personal data in some form and/or the equipment within which personal data is held. The majority of these information assets will underpin service user / patient care processes, human resource processes, activity management or clinical audit, research, or service evaluation but there may be a wide range of other business activities supported by such assets. Whilst all information assets should be protected, the importance of ensuring that this particular subset is held securely is paramount.

What is an Information Asset Register (IAR)?

Is a simple way to help you understand and manage your organisation's information assets and the risks to them. It is important to know and fully understand what information you hold in order to protect it and be able to exploit its potential.

What is the Information Asset Register risk rating level (this is the score of the highest risk on the Risk Register)?

Please provide a copy of the Risk Register

Data processing

What is processing?

In relation to information or data, processing means obtaining, recording or holding the information or data, carrying out any operation or a set of operations on the information or data, including - (a) organisation, adaptation or alteration of the information or data, (b) retrieval, consultation or use of the information or data, (c) disclosure of the information or data by transmission, dissemination or otherwise making available, or (d) alignment, combination, blocking, erasure or destruction of the information or data.

Data subjects

The information processed regards the following types of entities:

• Employees
• Patients
• Student
• Partner businesses or organisations
• Other

Data Categories

The information processed as part of the implementation or change pertains to the following classes or categories:

• Personal Data (Personal details such as name, address, postcode, date of birth, NHS number, IP address)
• Special Category Data (sensitive)
• Physical or mental health conditions
• Sexual health
• Family, lifestyle and social circumstances (marital status, housing, travel, leisure activities, membership of charities - please delete as appropriate)
• Education and training details (qualifications or certifications, training records - please delete as appropriate)
• Employment details (career history, recruitment and termination details, attendance details, appraisals, other - please delete as appropriate)
• Financial details (income, salary, assets, investments, payments, other - please delete as appropriate)
• Criminal proceedings, outcomes and sentences
• Goods or services (contracts, licenses, agreements etc.)
• Racial or ethnic origins
• Religious or other beliefs of a similar nature
• Political opinions
• Offences including alleged offences
• Trade Union membership
• Other

Data-flow Mapping

The data flow will depend on the implementation carried out by the Client, and may be subject to change on the Client's side without signifying any meaningful change in regard to how we process data.

Most commonly, when implementing the system via API, the data flow will be:

However, it is also possible that the Client develops an interface for users to upload data. This interface can implement privacy by design measures, as explained above, to avoid providing identifying information. In such cases, here's the data flow:

As you can see, regardless of the interface, the essence is always the same: the image is sent by the Cliente to our server. In the server, the API processes the image and returns data to the Client.

New data

This system will not include data which has not previously been collected as part of the system or process or policy.

If yes, have we or the Client amended the existing privacy notice?

Checks for adequacy, relevance and necessity of data

Only the minimum data is held.

In some cases, photo images are retained for medico-legal purposes and technically comprise part of the patient's primary care record. As such, the data needs to be patient-identifiable via reference to an ID number such as the patient ID.

Transfers outside the EEA

There is no transferring of any personal, sensitive or business data to a country outside the European Economic Area (EEA).

European Economic Area (EEA)

Find out more at https://www.gov.uk/eu-eea

Systems and technology

Systems that are involved in delivering the service

We use AWS secure virtual private clouds as repositories for all PID.

Systems Architecture Diagram

Here is a Logical Connection Architecture (Systems Architecture Diagram)

Intrusive technology

The system does not include new technology that might be perceived as intrusive (i.e. the use of biometrics or facial recognition etc.)

Storage of data

Deployment of servers

In what type of servers is the data stored?

• Only cloud servers
• Only local servers
• Both cloud and local servers

Cloud Technology

Means storing and accessing data and programs over the Internet instead of your computer's hard drive.

If local servers are used:

• Name and location of the servers:
• Physical access controls for data:

If cloud servers are used:

• Name of the cloud provider(s): Amazon Web Services (AWS)
• Data centre location: Paris, France
• Standards met by suppliers: AWS is on the Gov.UK Digital Marketplace.

Formats of data

• Electronic
• Paper
• Verbal
• Other

Data security

Security measures

The AWS Secure Virtual Private Cloud has high levels of physical security and is ISO 27001, 27018 and 9001 certified.

Digital security is such that access to PID is only via secure web-portal and is controlled via a long random password/username combination with Advanced Encryption Standard (AES) encryption:

• Data-in-transit is controlled via username and password combinations (with ~238 bits of entropy) with all data transfer between servers employing strong cryptography (TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
• Data-at-rest is encrypted with AES-256, with each file using a unique key and keys stored encrypted (also using AES-256) via a master key. The master keys are regularly rotated.

Business continuity plans

We have a Business Continuity and Disaster Recovery Policy. Should there be any data loss then this would be recoverable via the cloud based real-time backups.

Data quality

Who provides the information for the asset?

The HCP provides all of this information directly into the system.

Who inputs the data into the system or process?

The HCP inputs this information into the system. In the case of the report generated by the system, it is automatically generated by the system.

How will the information be kept up-to-date and checked for accuracy and completeness?

Data comprises the fully encrypted images and as such contain information about the subjects, typically containing skin lesions. As such, there is no requirement to check data quality or keep it up to date other than regular checking that recordings are being made and stored successfully.

Can an individual (or a court) request a copy, amendments or deletion of data from the system?

Yes.

Data transfer

Data protection measures from AWS

• Data Residency and Control: AWS allows customers to choose the geographic region where their data is stored. By selecting an AWS region within the appropiate territory, we ensure that our data remains within these boundaries. This control over data residency allows complying with GDPR requirements.
• CISPE Code of Conduct: AWS is certified under the CISPE Data Protection Code of Conduct, which is the first pan-European data protection code for cloud infrastructure service providers. This code requires providers to offer services that store and process customer data exclusively within the European Economic Area (EEA). AWS's compliance with this code provides additional assurance that data will not be transferred outside the EEA without our explicit consent.
• Contractual Commitments: AWS has strengthened its contractual commitments to protect customer data, going beyond what is required by the Schrems II ruling. These commitments include not accessing or using customer data for AWS's own purposes, such as data mining or marketing, and apply to all customer data subject to GDPR.
• Security and Compliance Framework: AWS maintains a robust security and compliance framework, with over 300 security, compliance, and governance services and features. AWS's adherence to international standards and certifications, such as ISO 27018 for cloud privacy, ensures that data protection measures are in place to prevent unauthorized data transfers.

How will the data be received by the system?

Data in the form of images will be generated by user (HCPs) communicated via web app. The data is saved directly to the AWS Secure Virtual Private Cloud.

Is data transferred onwards to 3^rd parties?

3^rd parties

3^rd parties are entities outside of the scope of the primary service provision. For instance, the data controller or the disclosed sub-processors are not considered 3^rd parties. Likewise, authorities who need to access data for regulatory reasons are not considered 3^rd parties.

• No, data is not transferred to 3^rd parties
• Yes, data is transferred onwards to other entities

If yes, identify to whom data is transferred

Is the data encrypted at rest and in transit?

Yes, using the following Advanced Encryption Standard (AES):

• Data-in-transit is controlled via username and password combinations (with ~238 bits of entropy) with all data transfer between servers employing strong cryptography (TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
• Data-at-rest is encrypted with AES-256, with each file using a unique key and keys stored encrypted (also using AES-256) via a master key. The master keys are regularly rotated.

Is any personal, sensitive or business data being transferred to a country outside the European Economic Area (EEA)?

European Economic Area (EEA)

Find out more at https://www.gov.uk/eu-eea

• No, data is not transferred to a country outside the European Economic Area (EEA)
• Yes, data is transferred onwards to other entities

If yes, provide the name of the country(ies)

Data sharing

Will the data be shared with any other organisation(s)?

• No, PID will not be available to other organisations.
• Yes, data is shared with any other organisation(s)

If yes, please list the names of the organisation.

Yes - PID will be available to (and therefore shared by) the relevant GP practice and hospital specialist team and is therefore shared by them.

How will the data be shared?

The relevant GP practice and hospital specialist team can access relevant PID only via the secure web portal which is subject to individual login and password combination.

What Information Sharing Agreements or Protocols are in place to support the sharing of data? Please provide a copy

HCPs already share PID with care provider managing organisations (e.g. telephone discussions with consultants; written referrals, and so on) so there is already an acceptance to sharing relating to advice and guidance questions between GP practices and managing organisations. As such, pre-existing data sharing agreements are considered sufficient.

No PID is accessible to or shared with our staff.

Access to the data

Which organisations will access data within the system?

Depending on how the Client may implement the solution, there are two possibilities:

1. No organisations will access the data within the system. The data will only be available to the person who uploads an image.
2. Only duly authorised users can access information via the web-portal, by using an individual login and password combination.

In all cases, data is contained in a 'closed system', as defined in 21 CFR 11.

Which people within organisations will use the system?

Only authorised users within relevant organisations will be able to access data.

Do users have unique login and password combinations?

This topic, like many other aspects of this assessment, depends on how the Client may implement the solution. Most commonly, there are two possibilities:

1. Due to privacy by design, no login information is required, so as to decrease the identification risk. In this case, please note that data cannot be retrieved once is processed and displayed once, so there is no need for identification.
2. Only duly authorised users can access information via the web-portal, by using an individual login and password combination, making it a 'closed system', as defined in 21 CFR 11. For this to work, identification will be needed, as it is the only way to enable signing in.

Are there role-based access controls in place

This topic, like many other aspects of this assessment, depends on how the Client may implement the solution. Most commonly, there are two possibilities:

1. No, because there is no need. This is the case when there is no login and no information being kept or be retrieved.
2. Yes, There are role-based access controls.

The basic user roles are:

• User: a user has access only to communications that they themselves have initiated
• Admin: a user has statistical access only for their organisation
• PID: a user has access to all communications for their organisation

Allocation of roles, other than the basic user roles above, is subject to appropriate written authorisation (e.g. Project Lead or Caldicott Guardian) from the relevant organisation.

What information governance training have users had?

Users with access to PID are already well-used to dealing with PID and receive regular IG training from their organisations both on a personal and group level.

Can users amend data?

Users cannot amend data.

Is there an audit trail in place for the information asset?

Yes, a detailed and anonymized audit trail exists that tracks which users have accessed records and what changes they have made if any.

How often will the system or policy be audited?

Ad hoc audits will be undertaken should there be any reason for concern regarding data security and confidentiality.

Data breaches

How will any system breaches be identified?

Systems are maintained and monitored to avoid system breaches. However, should one arise there are clear procedures requiring immediate notification to the Data Protection Officer.

How and when will any system breaches be reported to Clients?

We, as providers of the system, are required to notify of any such events via the contract and in accordance with the Data Protection Act 2018 and UK General Data Protection Regulations (UK GDPR) and Regulation (EU) 2016/679 (General Data Protection Regulation). In practice this means within 2 working days.

Legal basis for data collection, retention and processing

By the contoller

Public Task - Necessary for performance of a task carried out in public interest or in exercise of official authority

By the processor

Processing is governed by a binding contract or other legal act (Article 28.3 GDPR)

What is the UK GDPR basis for holding and processing the data? - Article 9 (Processing of Special Categories of Personal Data)

By the contoller

Necessary for provision of health and/or social care, including preventative or occupational medicine. Processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law or by way of contract with a health professional.

By the processor

Necessary for the provision of the service to implement the Project.

Data subject rights

Can the data subject opt-out of their data being processed?

Yes; the Data Subject (e.g. a patient) can request that the User (e.g. a GP) should not seek advice via the service.

If an opt-out option is available, how will this be managed?

If the Data Subject opts-out, then the User (e.g. a GP) will discuss alternatives, including other sources of clinical decision support, with the patient.

How will you tell the data subjects about the use of their data?

As they already do, a GP will explain that their data is stored only for medico-legal reasons and is not shared with any organisation other than the organisations who were party to the clinical advice discussion (e.g. GP practice and hospital team).

Have you assessed the likelihood of the use of the data causing unwarranted distress, harm or damage to data subjects concerned?

Yes; the data is held safely and securely and is only accessible to approved individuals within the organisations who were party to the clinical advice discussion. The data is not shared with any other organisations.

Have you assessed the likelihood of the loss or damage of the data causing unwarranted distress, harm or damage to data subjects concerned?

Yes; relevant risk assessments have been undertaken with appropriate mitigating actions taken.

Could the project result in making decisions and / or taking action against the data subjects in ways that can have a significant impact on them?

No.

Do data subjects have a right to access their data?

Yes; patients will typically forward requests via the Data Controller (e.g. a GP practice) and we will ensure that the Data Controller can access the relevant data in accordance with GDPR.

Do data subjects have a right to erase their data?

Yes; in the cases where that is viable, patients have access to a delete function within the service; they can also forward requests to customer service teams who will arrange for them to be processed according to GDPR.

On-going use of data

Will the system or process interfere with the privacy rights of the data subject under article 8 of the Human Rights Act 1998?

No.

Will the data be used to send direct marketing messages?

No.

If direct marketing messages will be sent, are consent and opt-out procedures in place?

Does not apply because no marketing messages will be sent.

Does the system or process / policy involve changing the standard disclosure of publicly available information in such a way that the data becomes more readily available than before?

No.

What is the data retention period for this data?

Please consult the detailed retention schedule (appendix 3)

The default retention period is 10 years subject to approval from the Data Controller.

Furthermore, data is retained in accordance with NHSx Records Management Code of Practice and Information Commissioners Office guidelines.

How will the data be securely destroyed when it is no longer required?

PID will be permanently destroyed or deidentified upon receipt of written authorisation. Once any data transfer arrangements have been concluded, removal of the mapping from the public name to the object starts immediately, and this would generally be processed across the distributed system within several seconds. Once the mapping is removed, there is no external access to the data object. The PID is then permanently deleted/deidentified from/within the system.

Details of the individual completing this form?

The name, role and email of the individual completing this form:

	Details
Name	Taig Mac Carthy
Role	COO
Email	taig@legit.health

IT security review

	Details
Name	Gerardo Fernandez
Role	CTO
Email	gerardo@legit.health

DPIA outcome

• Approved
• Rejected

Applicable Governance Regimes

Always applicable legislation / guidance

• Regulation (EU) 2016/679 (General Data Protection Regulation)
• Data Protection Act 2018
• General Data Protection Regulations (UK GDPR)
• Freedom of Information Act 2000
• Environmental Information Regulations 2004
• Records Management Code of Practice for Health and Social Care 2016
• Computer Misuse Act 1990

Possible applicable legislation / guidance

• Human Rights Act 1998
• Code of practice on confidential information
• Regulation of Investigatory Powers Act 2000
• ISO 27001 Information Security Management
• Privacy and Electronic Communications Regulations 2016
• Children's Act 2006

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001