News

In the compliance practice of medical big data and AI diagnosis and treatment, ‘data minimisation’ is often regarded as one of the core principles. Both Article 5 of the EU's GDPR and Article 6 of China's Personal Information Protection Law emphasise that the personal information that should be collected, used and shared must be ‘limited to the smallest extent necessary to achieve the purpose’, and that data processing should not be unlimitedly expanded due to the pursuit of ‘big and comprehensive’. Expansion of data processing. For healthcare organisations and commercial health data platforms, this is of paramount importance - between protecting patients' rights and ensuring normal business operations, the principle of “minimisation” is not only a legal bottom line, but also an effective way to reduce compliance risks.

01Legal Basis and Compliance Pressure of Data Minimisation

From the perspective of the GDPR, Article 5, subparagraph 1(c) of the GDPR clearly states that ‘personal data shall be adequate, relevant and limited to what is necessary for the fulfilment of the purposes for which they are processed (data minimisation).’ In a medical scenario, if a hospital wants to carry out a remote consultation, it can only access the necessary medical records related to the current medical condition, and cannot share all the patient's historical information with a third party. Failure to do so constitutes an unwarranted infringement of patient privacy and may trigger an investigation by a data regulator, and the GDPR imposes stricter scrutiny on healthcare data as a ‘special category of data’, which may result in high administrative fines in the event that excessive collection is found.

From the perspective of personal protection law, Article 6 of China's Personal Information Protection Law emphasises that ‘the processing of personal information shall have a clear and reasonable purpose and shall be limited to the minimum extent necessary to achieve the purpose of the processing, and personal information shall not be excessively collected and used.’ For sensitive information, such as medical data, the law requires ‘specific purpose and sufficient necessity’ and is supplemented by ‘individual consent’ or other legal basis. Assuming that a health management app provides a simple heart rate monitoring function, but requires users to upload their entire medical records and genetic test reports, this clearly exceeds the scope of necessity and is considered ‘excessive collection’, which may result in an order for rectification or even a fine from the relevant authorities.

02How to assess ‘necessity’ and ‘minimisation’

A common way to determine minimisation is to carry out a Data Protection Impact Assessment (DPIA / PIPI), in which the following points are examined:

a. Objectives: What medical or commercial purpose is the processing intended to fulfil?

b. Scope of data: Are there fewer fields or lighter collection methods to achieve the objective?

c. Alternatives: are there ways to replace the raw data with anonymised or pseudonymised results?

d. Risks and benefits: Will the additional health information collected significantly improve the quality of diagnosis or research, or is it just ‘just in case’?

In many cases, data analysts want to ‘get more of what they want’. However, from a compliance perspective, if it cannot be demonstrated that the additional fields have a direct and significant effect on business objectives, they should be redacted or anonymised.

03Anonymisation/De-identification techniques and applications

Anonymisation and de-identification are often seen as the most effective techniques for implementing ‘minimisation’. Although they are often used interchangeably, they are not identical:

a. Anonymization: Personal information is irreversibly processed so that it can no longer be identified to a specific individual, and is therefore no longer subject to GDPR or personal protection laws. However, it is important to ensure that it is ‘truly irreversible’, otherwise, if the identity can be restored by comparison with external data sets, the de-identification is incomplete.

b. Pseudonymisation: replacing direct identifiers such as name, ID number, etc. with codes or numbers (pseudonyms) to reduce the risk of direct identification of the data subject. However, as long as there is a means of ‘decoding’ or a data cross-reference table, it is still reversible and therefore still subject to the law.

Typical examples of the application of de-identification for healthcare organisations include: replacing a patient's name, hospitalisation number, ID number, etc. with an irrelevant number in medical imaging AI training; or removing the patient's personal identifying information in clinical research, and retaining only the examination indicators and diagnostic conclusions related to the subject matter, to ensure that the researchers are not able to ‘reverse lock’ on a specific individual. This will not only meet the needs of academic research, but also ensure that the researchers can not ‘reverse lock’ the specific individual. This not only meets the needs of academic research, but also significantly reduces the impact on patient privacy.

04Common Challenges in Practice

In data processing, especially in practice scenarios involving sensitive personal information (e.g., genetic data, health records, etc.), a series of complex and critical challenges are often encountered, and the following are some common ones:

a. Difficulty of complete anonymisation

In the case of genetic data or highly granular health records, an individual's identity may be inferred from a few characteristics (e.g., very rare diseases, minority genotypes). How to assess true ‘non-identifiability’ is often a complex technical and administrative issue, requiring specialised algorithms and standards.

b. Business Needs and Minimising Conflicts

Business developers may be concerned that ‘de-identification does not allow for traceability or fine-grained analysis’ and may want to retain more information for potential future needs. In this case, it is necessary to find a balance between legal compliance and potential benefits, and avoid endless ‘collect and repeat’.

c. Inadequate Internal Compliance Processes

If a hospital or platform lacks a DPIA system or a team of experts, and the principle of data minimisation is only ‘written in the system’ but not actually implemented, it is also easy for ‘internal staff to act in their own way and collect a large amount of information in excess of the scope’. In the event of a security incident, they will face severe regulatory penalties.

05Floor-to-Floor Recommendations

In order to ensure data security, the author suggests that the following recommendations can be adopted:

a. Strengthen institutionalised assessment: Before each new project goes live, require the project team to submit a ‘Statement of Necessity and Minimisation’, which will be reviewed by the legal/compliance department.

b. Classified management: For sensitive medical data, set stricter storage and access permissions, and authorise access only to professionals with diagnostic or research needs.

c. Early de-identification: Pseudonymise or anonymise system data before it flows through the system, and try not to copy or misappropriate identifiable information on a wide scale.

d. Regular cleaning and destruction: After the project is finished or the data is used up, it should be deleted or completely anonymised in a timely manner to avoid long-term stockpiling.

In summary, ‘minimisation’ is not intended to restrict legitimate medical research or AI innovation, but rather to emphasise that technological advancement and privacy protection can only be balanced if data is handled in compliance with the law and to the extent that it is genuinely necessary. Nowadays, more and more medical institutions and health platforms are aware of this, and through process compliance and technological improvements, the principle of ‘minimisation’ is truly put into practice, laying a solid foundation for the future of data governance.

Special Announcement:

This article was originally written by JIA LAWYER law firm lawyers, and represents only the author's own views, and should not be regarded as a formal legal opinion or advice issued by JIA LAWYER law firm or its lawyers. If you need to reproduce or quote any content of this article, please indicate the source.