Critical privacy issues on medical data

id192780   CRITICAL PRIVACY ISSUES ON MEDICAL DATA ISABEL PIEDRAHÍTA VÉLEZ Thesis supervisor ULISESCORTÉSGARCÍA(DepartmentofComputerScience) Thesis co-supervisor ATIACORTÉSMARTÍNEZ(BarcelonaSupercomputingCenter) Degree Master'sDegreeinArtificialIntelligence Master's thesis School of Engineering Universitat Rovira i Virgili (URV) Faculty of Mathematics Universitat de Barcelona (UB) Barcelona School of Informatics (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 27/01/2025  Acknowledgments I wish to express my gratitude to all the individuals who contributed to the completion of this master’s thesis. I would first like to thank my supervisor, Prof. Ulises Cort´es, for his invaluable patience, advice, and feedback. I would also like to thank my co-supervisor, Atia Cort´es, for her insight and guidance. It was a pleasure to collaborate with and learn from you. I also extend my sincere gratitude to the staff of the Pablo Tob´on Uribe Hospital in Medell´ın, Colombia, whose expertise and knowledge were invaluable to the execution of this project, as well as to all the other researchers and medical professionals who generously lent me their time and skills. This project would not have been what it is without your help. Lastly, I would like to thank my family and loved ones for their unwavering support, latenight calls, and expert advice. Their belief in me has motivated me beyond measure. I am truly grateful to each of you. i Contents Acknowledgments i Abstract ix 1 Introduction 1 2 Methodology 5 2.1 DocumentStructure .................................. 5 2.2 ResearchDesign .................................... 6 2.3 Research Plan per Research Question . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Which technical controls exist for AI-based systems in healthcare? . . . . 7 2.3.2 How should a large-scale AI-based system in healthcare be planned to ensure the privacy of individuals? . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.3 How can we guarantee that the benefits of AI-based systems in healthcare are balanced with rigorous data protection standards? . . . . . . . . . . . 8 2.3.4 Are the mandated standards for data protection in AI-based healthcare systems in Catalunya sufficient to be considered a referent in the field? . . 8 2.3.5 Are the mandated standards for data protection in AI-based healthcare systems in Colombia sufficient? . . . . . . . . . . . . . . . . . . . . . . . . 8 ii Contents iii 2.3.6 How could Colombia implement key findings from the case of Catalunya in order to pursue the development of AI-based medical applications in an ethical and privacy-conscious way? . . . . . . . . . . . . . . . . . . . . . . 9 3 Literature Review 10 3.1 Personal and Medical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Designing AI Systems with Privacy in Mind . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Privacy by Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 DataMinimization............................... 15 3.3 Privacy-Enhancing Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.1 End-to-End Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.2 Related to Dataset Curation . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.3 Related to Development and Model Training . . . . . . . . . . . . . . . . 24 3.3.4 Related to Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4 DataGovernance.................................... 28 3.4.1 Documentation................................. 29 3.4.2 ExternalAuditing ............................... 34 3.4.3 InternalAuditing................................ 37 3.4.4 DataLifecycle ................................. 39 3.4.5 Data Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Regulatory Landscape on Personal Data Protection in Catalunya and Colombia 47 4.1 Regulatory Landscape of Catalunya . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.1.1 Personal Data Regulation in Catalunya . . . . . . . . . . . . . . . . . . . 48 Contents iv 4.1.2 Regulation Regarding Medical Records in Catalunya . . . . . . . . . . . . 49 4.1.3 Regulation of Artificial Intelligence in Catalunya . . . . . . . . . . . . . . 52 4.2 Regulatory Landscape of Colombia . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2.1 Personal Data Regulation in Colombia . . . . . . . . . . . . . . . . . . . . 53 4.2.2 Regulation Regarding Medical Records in Colombia . . . . . . . . . . . . 61 4.2.3 Regulation of Artificial Intelligence in Colombia . . . . . . . . . . . . . . . 65 4.3 Legal Framework Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5 Proposal for a Privacy-Aware Data Lifecycle and Management Plan for Medical Data, MDLC 74 5.1 TheMDLC ....................................... 74 5.1.1 Stage 1: Plan and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.1.2 Stage 2: Select and Collect . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1.3 Stage 3: Analyze, Assure, and Prepare . . . . . . . . . . . . . . . . . . . . 86 5.1.4 Stage 4: Model and Compare . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.1.5 Stage 5: Assess and Share . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.1.6 Stage6:Deploy................................. 97 5.1.7 Stage 7: Delete or Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.1.8 Intermediate Risk Assessment (IRA) . . . . . . . . . . . . . . . . . . . . . 99 6 Proposal for an Auditing Framework for MLDC, UMAPER 103 6.1 UMAPER: An Auditing Framework for MDLC Projects . . . . . . . . . . . . . . 103 6.1.1 Understand: Why is the Audit Necessary? . . . . . . . . . . . . . . . . . . 105 6.1.2 Map: What is the System Being Audited? . . . . . . . . . . . . . . . . . . 107 6.1.3 Assessment: What are the Risks? . . . . . . . . . . . . . . . . . . . . . . . 108 Contents v 6.1.4 Plan: What Tests Will be Conducted? When Will they be Conducted? . 110 6.1.5 Execute: Carrying Out the Plan . . . . . . . . . . . . . . . . . . . . . . . 111 6.1.6 Reflect: Audit Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . 112 7 Conclusions 113 7.1 Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 List of Figures 3.1 GDPR obligations for different types of pseudonymised and anonymised data [19] 21 3.2 Factsheet methodology steps [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Overview of the SMACTR Framework [57] . . . . . . . . . . . . . . . . . . . . . . 38 3.4 Comparison of data lifecycles and methodologies. . . . . . . . . . . . . . . . . . . 42 5.1 Proposal for an Iterative, Non-Lineal Medical Data Lifecycle . . . . . . . . . . . 76 5.2 Plan and Design Stage Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Select and Collect Stage Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.4 Analyze, Assure, and Prepare Stage Summary . . . . . . . . . . . . . . . . . . . . 87 5.5 Model and Compare Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.6 Assess and Share Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.7 DeploySummary.................................... 97 5.8 Delete or Archive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.9 Intermediate Risk Assessment Summary . . . . . . . . . . . . . . . . . . . . . . . 101 6.1 Overview of the UMAPER Framework. Double-lined boxes represent processes, regular boxes represent tasks, blue represents input documents, and orange representsoutputdocuments................................ 105 vi List of Tables 1.1 ResearchQuestions................................... 3 3.1 Relevance of Privacy by Design on the GDPR . . . . . . . . . . . . . . . . . . . . 15 3.2 Relevance of Documentation on the GDPR . . . . . . . . . . . . . . . . . . . . . 33 3.3 Relevance of Documentation on the AI Act . . . . . . . . . . . . . . . . . . . . . 33 4.1 Legislation for Medical Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2 Comparison Between Colombia and Catalunya . . . . . . . . . . . . . . . . . . . 73 5.1 Project Definition and Scope Deliverables . . . . . . . . . . . . . . . . . . . . . . 79 5.2 Organizational Structure and Policies Deliverables . . . . . . . . . . . . . . . . . 80 5.3 Foundations of Responsible Data Use Deliverables . . . . . . . . . . . . . . . . . 81 5.4 External Communication Deliverables . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5 Data Selection Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.6 Data Collection Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.7 Know the Data Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.8 Prepare the Data Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.9 Compare Modeling Techniques Deliverables . . . . . . . . . . . . . . . . . . . . . 91 5.10 Model and Test Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 vii List of figures viii 5.11 Assess Compliance Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.12 Assess Project Results Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.13 Assess Risk Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.14ShareDeliverables ................................... 96 5.15DecideDeliverables................................... 96 5.16 Plan Deployment Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.17 Conduct Final Assessment Deliverables . . . . . . . . . . . . . . . . . . . . . . . 98 5.18 finalize Documentation Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.19ArchiveDeliverables .................................. 100 5.20DeleteDeliverables................................... 101 5.21IRASummary ..................................... 102 2.2. Research Design 6 Understanding these regulations is necessary to propose management frameworks that comply with international and local legal requirements, which will be relevant for RQ2 and RQ3. This chapter covers all the necessary legal information to vinculate the regulatory aspects of data prosessing and protection with responsible system design. Although special attention is given to the legal specifics of the medical field, the insights of this chapter can be extended to other domains. Chapter 5: Based on findings from the literature review, this chapter proposes a privacycentric data lifecycle for medical AI systems, addressing RQ2 and RQ3. Chapter 6: Suggests a methodology for internal auditing that is tailored to the controls incorporated into the data lifecycle proposal. This discussion ties into RQ2 and RQ3. Chapter 7: Presents conclusions, limitations, future work and discussion. Summarizes the main findings of this masters thesis, revisits the research questions (RQ1-RQ6), and proposes directions for future research. Identifies challenges and constraints of the proposals made. 2.2 Research Design To achieve the goals of this project, we will conduct in-depth research on current data protection regulations, as well as on technical, design, and governance protocols for such systems. We will take a qualitative research approach to acquire a deeper understanding of the study area, capture contextual nuance, and provide detailed insights into these complex issues. During the qualitative research conducted, we will focus on textual information, in the form of academic papers, official guides, and legal instruments. We will also prioritize, when possible, giving domain experts a voice through the inclusion of interviews. In these cases, the role of the interviewee and their relevance to the topic at hand will be made clear. However, their affiliations will only be revealed with their explicit consent. 2.3. Research Plan per Research Question 7 2.3 Research Plan per Research Question 2.3.1 Which technical controls exist for AI-based systems in healthcare? We will explore this question during our literature review by researching various technical controls currently available for AI-based systems and other data-intensive systems. We will primarily study a wide array of academic papers and technical guides. Combining these sources will offer a comprehensive view of the current technologies available. This research will inform activities and controls within the methodologies that will be proposed in this thesis. 2.3.2 How should a large-scale AI-based system in healthcare be planned to ensure the privacy of individuals? It is our intention to gather a wide perspective of the necessary processes, techniques, and policies that would enable the development of such a system. With that in mind, we will study the frameworks, methodologies, and best practices that would provide the tools needed to achieve privacy-conscious medical AI systems. We will approach this issue from three main perspectives: Design, technology and governance. Together, these three aspects provide a holistic view of a system. Design focuses on how systems are conceptualized, structured and implemented to meet requirements and gives us insight into how systems may be shaped to respect privacy inherently. Technology focuses on the methods and tools that enable systems to process data securely while still being functional, and it is the backbone of privacy-preserving AI applications. Finally, Governance addresses the regulatory and ethical frameworks that guide development and ensure compliance with laws and internal policies. Through the study of these three dimensions, we strive to find interactions between them that may provide balance regarding innovation, compliance and data protection. Based on the findings of the research we will propose a data lifecycle model that reflects on the existing frameworks, management models, and other best practices. This medical data lifecycle could potentially guide the development of AI-based applications with longer lifespans and better policy compliance in the medical field. 2.3. Research Plan per Research Question 8 2.3.3 How can we guarantee that the benefits of AI-based systems in healthcare are balanced with rigorous data protection standards? To address this question we will leverage the research conducted for other research questions and delve deeper into governance concepts regarding risk management and impact assessment. We will also look into external and internal auditing practices that can serve as tools to identify, monitor and mitigate risk. The research conducted in this section will be reflected on an auditing and risk management framework proposal that can be easily integrated with the proposed methodology resulting from the work conducted for RQ2 (see §2.3.2). 2.3.4 Are the mandated standards for data protection in AI-based healthcare systems in Catalunya sufficient to be considered a referent in the field? In order to explore this research question, we will begin by identifying the specific set of laws that govern personal data, artificial intelligence and medical records in Catalunya. Once the necessary legal instruments have been identified we will rely on expert’s opinions to ascertain the completeness and coverage of these regulations, allowing us to conclude about its fitness as a referent for Colombia. We will then go into detail regarding the core tenants of the regulatory environment of Catalunya for each of these three main areas of interest. This is done so that we may then draw comparison between it and the Colombian regulation. 2.3.5 Are the mandated standards for data protection in AI-based healthcare systems in Colombia sufficient? We will present a summary of the current legal landscape in the region and explore its sufficiency in terms of coverage, completeness and enforceability. The author will support the analysis with legal research findings and provide any differences identified by the author after studying both legal frameworks. In addition, this section will feature interviews with experts in different domains of Colombian 2.3. Research Plan per Research Question 9 medicine. These interviews are conducted in order to identify interesting interactions of the law with the daily running of hospitals and how they affect management activities and medical practice. The interview also informs on general feelings towards artificial intelligence in the medical field. Interviews were conducted with a Compliance Attorney for the General Secretariat and Legal Affairs of the Pablo Tob´on Uribe Hospital in Medell´ın, with the Head of the Medical Division of the Pablo Tob´on Uribe Hospital in Medell´ın, and with a Colombian General Practitioner who holds a master’s degree on Data Science and who is currently a PhD candidate pursuing a degree in a computational biology program shared by the University of Pittsburgh and Carnegie Mellon University. 2.3.6 How could Colombia implement key findings from the case of Catalunya in order to pursue the development of AI-based medical applications in an ethical and privacy-conscious way? From the insights acquired during the research proposed for RQ4 and RQ5 (see §2.3.4 and §2.3.5 respectively), we will specify particular insights from the European regulatory body that may be of immediate use for Colombia. The conclusions we reach on this section will greatly depend on the differences found between borth regulatory frameworks. Chapter 3 Literature Review Oxford Languages defines best practices as commercial or professional procedures accepted or prescribed as being correct or most effective. In the case of software development, best practices are usually the result of the combined experience of skilled software developers. These practices will, on average and over time, promote characteristics (or non-functional requirements) in the developed applications, such as resilience, usability, portability, and many others. Ethical principles for AI-based applications are very similar to non-functional requirements. We can attempt to explore these principles through the same lens software engineering has used to study a system’s characteristics that relate to its overall conduct rather than its individual features. For medical AI-based applications, the desired outcome of good practices goes beyond the pursuit of strong performance, and strives to achieve adherence to ethical AI principles. This Master Thesis will focus mainly on privacy; however, other characteristics of responsible AI, such as transparency or fairness, could potentially be explored through this lens. Simply defining principles cannot guarantee ethical AI. While it would be ideal if merely stating our intention to develop transparent,explainable, or fair AI-based applications, were enough to ensure that the developed system complies with these principles, it is certainly not the case. It is necessary to find and implement development practices that set out to guarantee these characteristics in our applications. This is a lesson we learn from traditional software engineering, as there has been a consistent effort to turn a software project’s ethereal qualities—such as reliability, maintainability, or compatibility—into concrete actions with measurable outcomes. 10 3.1. Personal and Medical Data 11 In this section, we will define personal and medical data, and study how privacy-preserving AI systems can be achieved from the design, technical, and data governance perspectives. We will explore the current state of Privacy-Preserving AI (PPAI) and the techniques it proposes to protect AI systems against model attacks and leakages that extract information about the training data or model parameters [6]. We will describe the design, development, and governance practices currently used to promote more privacy-oriented AI systems. We will emphasize techniques that have been proven helpful in medical AI-based systems and other high-security fields, and mention relevant drawbacks when possible. 3.1 Personal and Medical Data Any discussion about protecting personal and medical data must start with a clear definition of these terms. The European Commission defines personal data as “(...) any information that relates to an identified or identifiable living individual”, or alternatively “Different pieces of information, which together can lead to the identification of a particular person.” [7] As such, data that has been encrypted, de-identified, or pseudonymised but is still re-identifiable remains personal data and falls within our scope of interest. However, any data that has been anonymised in such a way that it can no longer be re-identified or de-anonymised is no longer considered personal data[7]. Some examples of personal data include: •Names and surnames. •Home addresses. •IP addresses. •Emails and phone numbers. •Data held by a hospital or doctor, which could uniquely identify a person. Medical data is a particularly sensitive type of personal data related to the past, present, and future mental or physical health of an individual, as defined by Spain’s organic law 15/1999, 3.2. Designing AI Systems with Privacy in Mind 12 on the protection of personal data [Ley Org´anica 15/1999, de protecci´on de datos de car´acter personal (Real Decreto 1720/2007)] [8]. In Recital 35 of the General Data Protection Regulation (GDPR) greater detail is provided as to which pieces of information generated during the provision of medical care are considered medical data: [9] •Information about a person collected during registration for medical care or during medical care. •Any number or symbol assigned to a person to uniquely identify them for health purposes. •Results from clinical tests or examinations of a body part or bodily substance. •Any information derived from testing or examining genetic data or biological samples. •Any information on a disease, disability, disease risk, medical history, clinical treatments, or physiological or biomedical state of a patient, regardless of source. 3.2 Designing AI Systems with Privacy in Mind In this section, we will focus on how privacy preservation should be incorporated into the planning and design stages, which aim to responsibly create AI-based applications The goal is to design systems that positively impact society without compromising the fundamental right to privacy. Here, we will group design principles and activities that occur before development begins, which are usually more abstract and typically require stakeholder and administrative involvement. 3.2.1 Privacy by Design Principles The following section summarizes the concepts found in the “Guide for Privacy by Design” [10] written by the Spanish Agency for Data Protection (AEPD, by its initials in Spanish), “Privacy by Design: The Definitive Workshop. A Foreword by Ann Cavoukian, Ph.D.” [11], and the General Data Protection Regulation. 3.2. Designing AI Systems with Privacy in Mind 13 The Information and Privacy Commissioner of Ontario proposed the concept of privacy by design over twenty years ago. It was first presented at the 31st International Conference of Data Protection and Privacy Commissioners, internationally accepted at the 32nd International Conference of Data Protection and Privacy Commissioners, and subsequently adopted by the GDPR as a necessary practice. The GDPR goes into detail regarding privacy by design in Recital 78 and Article 25. Article 83 is particularly interesting as it states that not adhering to data protection by design is a sanctionable offence. A list of the instances of the GDPR that provide a legal basis for privacy design principles can be found in Table 3.1. The term privacy by design refers to protecting data through technology design and aims to provide the user with state-of-the-art data protection. The desire for privacy by design emerges from the idea that data protection standards are easier to adhere to when they are integrated with the technology from its creation. However, there is no strict definition of privacy by design, which is reflected in the legislation, as the GDPR leaves the exact protective measures that should be taken completely open. Although particular techniques for privacy preservation are mentioned in the law, it does not go into a level of detail that dictates the exact measures a data-based project should take [10]. Nevertheless, seven privacy-by-design principles can be used to guide the development of privacy-conscious AI-based applications and other data-based applications from a more abstract level [11], a fact we will examine here. The particular privacypreserving techniques mentioned in the GDPR will be explored in §3.3; in this section, we will review each of the seven privacy-by-design principles. Proactive not Reactive; Preventative not Remedial: Possible events that may affect privacy should be anticipated. Risks regarding people’s rights and freedoms should be identified and minimized during the design stage to mitigate possible damages. Additionally, a systematic approach to early detection of potential issues during and after deployment, as well as a clearly defined responsibility distribution, should ensure that every individual working on the project is aware of their obligations regarding user privacy. Privacy as the Default Setting: The default configuration of any application, system, product, or service shall be defined from the design stage to be as respectful of people’s privacy as possible. This ensures that even if an individual takes no action to configure the system, their 3.2. Designing AI Systems with Privacy in Mind 14 privacy will be guaranteed. This implies the need for data minimization through all stages of data handling. For example, by default there should be well-defined and limited criteria for data collection, the use of personal data should be limited to the purposes for which it was collected, these purposes should have a legitimate basis, access should be restricted to a need-to-know basis, and so on. Privacy Embedded into Design: Privacy should not be an add-on to a service or system, it should be an essential component of the core functionality being constructed and delivered. Privacy is not meant to be tacked on at the end of production, it must be a non-functional requirement from the project’s conception. Full Functionality; Positive-Sum, not Zero-Sum: Unnecessary trade-offs should be avoided. Privacy by design seeks to accommodate, not hinder, legitimate interests and objectives while preserving privacy. Instead of adopting a privacy vs. security or privacy vs. utility mental framework, privacy by design aims to demonstrate that all parties involved can achieve their goals, reaching a balance that enables everyone to “win”. This requires developers, organizations, and researchers to acknowledge that multiple legitimate interests may coexist and should be balanced accordingly. End-to-End Security – Full Lifecycle Protection: Privacy is a concern at all data lifecycle stages. It must be planned even before the first piece of information is collected and should extend until the data is ultimately deleted. To adequately preserve privacy during each stage of the data lifecycle, it is necessary to analyse every single operation required for each stage of data processing, and implement the most appropriate protective measures at each step. Visibility and Transparency – Keep it Open: This principle aims to allow independent verification of the fulfilment of a given system’s promised data safety guarantees. Transparency in data treatment is a fundamental pillar in demonstrating the diligence with which data protection measures are undertaken to both the competent authorities and the individuals to whom the data pertains. This principle aligns with Recital 39 of the GDPR, which states that natural persons should be informed about the collection, use, consultation, and handling of their personal data. 3.2. Designing AI Systems with Privacy in Mind 15 GDPR Section Summary of Relevant Aspects Recital 78 States that in order to demonstrate compliance with the regulation that dictates the rights and freedoms of natural persons with regard to their personal data are being met, the data controller should be able to demonstrate that they have adapted internal policies and technological and organizational measures that adhere to the principles of data protection by design. Recital 108 States that when transferring data to a country that does not have the same privacy standards as the European Union, the controller or processor of the data will be obligated to compensate for that lack of protection by implementing the appropriate safeguards, among which is the adherence to the privacy by design and default principles. Article 25 States that data controllers should implement appropriate technical and organizational measures to promote data protection principles. By default, controllers must also implement appropriate technical and organizational measures to ensure privacy. Controllers may use an approved certification mechanism as an element to demonstrate their compliance with the obligations detailed in this article. Article 47 States that the competent supervisory authority will approve legally binding corporate rules, and these have minimum required specifications of the system, among which is the application of general data protection principles, including data protection by design and by default, and data minimization. Table 3.1: Relevance of Privacy by Design on the GDPR Respect for User Privacy – Keep it User-Centric: Privacy by design requires that architects, operators, and developers prioritize the rights and freedoms of the individuals to whom the data pertains. This includes offering measures such as privacy-respecting defaults, appropriate notice of data treatment, and other user-friendly options that empower users regarding their informational self-determination. 3.2.2 Data Minimization Data minimization is a design strategy for privacy that aims to reduce the amount of data collected and processed to the smallest possible amount. In this way, it intends to avoid the processing of unnecessary data or the processing of data for unjustified purposes. Data minimization is one of the concepts from privacy by design that needs to be taken into account at 3.3. Privacy-Enhancing Technologies 22 public. Local differential privacy, on the other hand, addresses scenarios where the collector is not trustworthy, allowing users to perturb their data locally on their own devices [23]. There are many methods to introduce differential noise into a dataset. Some of the most common include the Laplace mechanism and the Gaussian mechanism, which are typically used in centralized differential privacy. Other mechanisms like general randomized response are most commonly applied in local differential privacy. [23] Differential privacy counts among its strengths its strong mathematical definition, and its academic backing, as it has been well-studied over the years. The mathematical definition of DP also provides a quantitative notion for the performance of a given model in regards to its privacy protection [24]. Additionally, compared to other privacy-preserving techniques like homomorphic encryption, it has a relatively small impact on performance and can be implemented relatively quickly. However, differential privacy has drawbacks. For instance, the protection guarantees offered by differential privacy for groups of users diminish exponentially as the group size increases. Nevertheless, a large group of people sharing the same information does not make it any less sensitive [25]. This drawback is particularly pronounced in the case of medical data, as even if a large group of patients share the same diagnosis, the data still needs to be highly secure. Additionally, it is essential to consider how adding noise may lead to a loss of accuracy. This is a common phenomenon for privacy-preserving techniques, usually referred to as the privacy-utility trade-off. 3.3.2.3 Dataset Sanitization Data sanitization is a process through which data is deliberately and permanently removed from a source. It is designed to be an irreversible process, after which no usable residual information regarding the sanitized data remains, making it unrecoverable [26]. The term dataset sanitization is used more or less interchangeably to refer to two different activities: removing information from a physical device that will be disposed of or reused, and removing data from a dataset to make it more suitable for training, both of which are relevant to privacy preservation. 3.3. Privacy-Enhancing Technologies 23 When performing data sanitization on a memory device for reuse or disposal, three main methods exist: physical destruction of the memory device, cryptographic erasure, and data erasure [26]. On the other hand, for dataset sanitization on a data source intended for model training or data sharing, a common approach involves using a parser-based algorithm followed by a classifier model that tags each unit of information based on defined patterns or rules learned from data that has been manually tagged as sensitive or not sensitive [6]. The main advantage of data sanitization is that data is no longer being stored in any capacity and cannot be misused or leaked. If a physical memory device is to be disposed of or repurposed for another use, all information should be entirely removed, particularly if the data is sensitive. This would undoubtedly help avoid situations such as the Maine 2021 data breach, in which HealthReach Community Health Centers discovered that a worker at a third-party data storage facility had improperly disposed of hard drives containing patient data, resulting in the medical data of over 116,898 patients being leaked [27]. The role of data sanitization in privacy-preserving AI is to permanently delete sensitive information from a dataset used for training, so that it may not be misused or leaked. There has been academic interest in defining metrics for the level of sanitization and the utility of a sanitized dataset, which helps quantify the privacy generated by the process of sanitization [28]. This is crucial, as privacy cannot be treated as an unquantifiable quality of a system. Unfortunatelly, using data sanitation for datasets in model training has significant drawbacks. For starters, it involves a substantial privacy-utility trade-off. This disproportionately affects the medical field and other high-security sectors, as the useful information for model training, such as diagnoses or medical histories, is often highly sensitive. Furthermore, a current issue with medical data, at least in Spain, as stated by Dr. Joan Guanyabens, is the lack of structure in the data. This lack of structure makes it harder for standard data sanitization methods to work effectively, as they are better suited for well-formatted data [6]. Furthermore, identifying sensitive information in a data corpus is both challenging and context-dependent. This issue becomes even more relevant with the advent of LLM-powered medical applications [29]. These models are trained on text-based examples where it is nearly impossible to determine which sections of text should be considered sensitive, as this task is context-dependent and sensitive 3.3. Privacy-Enhancing Technologies 24 sections often lack clearly defined boundaries, making data sanitization less effective. It is important to note two additional issues. The first is related to the guarantee of full deletion of all data related to an individual, which is technically challenging. Malte Schwarzkopf et al. address this subject in their paper titled Position: GDPR Compliance by Construction [30]. The second issue arises when an individual requests to delete their data after a model has been trained. The fact that the individual’s information was used during training causes their data to persist in some ways even after it has been deleted from the training dataset, as well as making them vulnerable to MIA attacks. In theory, the model would need to be retrained to eliminate the influence of this data point. However, in some cases, it is not feasible to retrain the entire model due to computational cost and time constraints. This has led to an emerging branch of research called “machine unlearning,” which aims to address this issue by enabling a model to remove the influence a particular data point has had on it [31]. This field is rapidly gaining relevance, particularly due to the GDPR’s policy regarding the right to be forgotten. 3.3.3 Related to Development and Model Training 3.3.3.1 Federated Learning Federated learning is a collaborative, privacy-preserving paradigm [32] that enables multiple devices to jointly train a model without sharing their data with a central server [33]. Federated learning typically involves the distributed training of deep neural networks (DNNs), although other models, such as decision trees [34] [35] and support vector machines [36], have also been successfully implemented using this technique. The main advantage of federated learning is that it eliminates the need for data sharing. This is beneficial not only because it preserves privacy but also because it facilitates research and discovery by bypassing the usual bureaucratic processes associated with data sharing, particularly in scenarios where hospitals share patient data for model training and research. Additionally, keeping the data within the hospital helps patients maintain control over their information, as the data is not exposed to external parties. This also makes it more challenging for external entities to infringe upon patients’ rights concerning their data. 3.3. Privacy-Enhancing Technologies 25 However, it is important to note that techniques like federated learning (FL) may lead to liability deflection. Decentralizing data processing complicates users’ awareness of how their data is being used and could result in users being classified as controllers or processors of their own data under laws like the GDPR [33]. While hospitals generally have the infrastructure and resources to manage these responsibilities effectively, the situation is different when the hospital is not present to act as an intermediary. For instance, this issue arises when wearable devices are used as a data source for federated learning, which is a growing trend [37]. In such cases, patients may find themselves at a disadvantage, as they might inadvertently assume accountability for data processing without the expertise or resources to advocate for themselves successfully. 3.3.3.2 Encryption The GDPR defines encryption as a process that “converts clear text into a hashed code using a key.” This process makes the data accessible only to parties that possess a key. The process can be very simple, such as shifting every character to its immediate predecessor in ASCII code, or very complex, as in the commonly used 3DES or AES encryption standards. Data encryption helps protect privacy and defends against cybersecurity threats. It is a tool for preserving the confidentiality and integrity of digital information [38]. HIPAA regulations explicitly require encryption for medical data, and the GDPR advises its use for personal data, taking into account the “risk of varying likelihood and severity for the rights and freedoms of natural persons” (Art. 32), which, in the case of medical data, are consistently high. Encryption is usually incompatible with model training, as most traditional encryption standards lack operability [39]. This is why data must be decrypted before it can be processed. This leaves the information vulnerable to developers, as they will handle unencrypted data during some stages of the development process. Homomorphic encryption emerges as a potential solution to this issue. Homomorphic encryption was first proposed in 1978 by Rivest, Adleman, and Dertouzos. However, it was not implemented until 2009, when Craig Gentry’s fully homomorphic encryption (FHE) scheme was published. There are different levels of homomorphic encryption 3.3. Privacy-Enhancing Technologies 26 which vary in strictness and versatility. FHE is the most versatile, allowing computation over fully encrypted data and returning fully encrypted outputs so that only the owner of the decryption key may reveal the results of the computation. This technique preserves privacy and security throughout the training process. Additionally, it reduces the potential damage caused by a data breach, as all information remains unintelligible. Partially homomorphic encryption (PHE) allows either addition or multiplication while encrypted. For example, RSA supports multiplication, and Paillier supports addition. Meanwhile, somewhat homomorphic encryption (SHE) supports a limited number of operations without creating errors but does not support all operations as FHE does. For example, BGN is a type of SHE that allows both addition and multiplication [40]. Encryption is a powerful tool for maintaining confidentiality and protecting privacy; however, it has its pitfalls. To begin, it is important to note that different encryption standards vary in how challenging they are to break. For instance, 3DES emerged as a successor to DES, which, with only a 56-bit key length, has become easily breakable in our current technological environment [38], and current advances on quantum computing have caused some unrest regarding the safety of current encryption standards. Additionally, there is the previously mentioned issue of traditional encryption’s lack of compatibility with computation. Although FHE solves the issue of operability and would be an excellent tool to preserve privacy throughout the data life cycle, it has a significant computational overhead, which greatly limits its practical use [24]. While researchers are actively working to make it less computationally taxing [40], the overhead remains substantial enough to prevent it from being widely adopted. Furthermore, encryption as a whole relies heavily on adequate key management to fulfill its purpose of protecting data. If it is relatively easy to acquire the decryption key through illegitimate means, encryption becomes far less effective. In addition to the possibility of malicious intent leading to the theft of a key, there is also the need to consider the consequences of losing a key. Unforeseen situations, such as server damage, could result in the loss of the key, rendering the encrypted data inaccessible. In the context of medical data, this is especially concerning, 3.3. Privacy-Enhancing Technologies 27 as being unable to access clinical records would immediately hinder patient care. Although the loss of medical data for research and discovery would not have such a devastating impact, it would still be far from ideal. [38] 3.3.3.3 Differential Privacy In the context of model training, differential privacy involves adding a small amount of noise during model training [24]. In the case of federated learning, intermediate model updates are performed locally, and noise is added during the aggregation of these updates [33] to conceal the contributions of individual parties to the dataset used for training. Differential privacy is particularly effective against Membership Inference Attacks (MIA). The most common MIA format involves determining whether a data record was included in the model’s training dataset, given a data record and black-box access to a model. This can be achieved by adversarially using a machine learning model trained to recognize differences in the target model’s predictions on inputs that were part of the training dataset and those that were not [41]. More sophisticated and accurate alternatives, such as the Likelihood Ratio Attack, also exist [42]. Although there are no confirmed large-scale instances of MIA, either because they have not yet occurred or have gone unreported, proof-of-concept attacks as those mentioned above have been very successful. Thus, there is reason to account for them when planning privacy strategies. The advantages and disadvantages of DP during model training are the same as those discussed for local and centralized differential privacy during dataset curation. However, there is one more important detail: differential privacy impacts model performance, and its impact is not uniform across all classes and groups. When DP is used during model training accuracy drops significantly more for underrepresented classes and subgroups [43]. This is particularly troublesome in healthcare, where available datasets are disproportionately white and male [44]. This raises immediate concerns regarding fairness, as any unfairness in the original model would only be exacerbated by differential privacy. Ongoing research aiming to mitigate this characteristic of DP has suggested that local differential privacy is less prone to this behavior [45]. 3.4. Data Governance 28 3.3.4 Related to Deployment 3.3.4.1 Secure and Available Interfaces It is important to remember that standard data security practices should not be neglected. The previously mentioned best practices for privacy in artificial intelligence complement any activities already in place to increase availability, integrity, and confidentiality. It is necessary to ensure that the interfaces through which medical professionals, researchers, or even patients interact with any potential models meet data safety standards. Additionally, the high availability of any system deployed as a diagnostic or attention aid is a critical feature, as prolonged downtimes (and, depending on the system’s criticality, even short ones) are inadmissible. Numerous activities can be performed during all project stages to achieve this goal, but these fall outside the scope of this master’s thesis and will not be discussed. However, guidance can be found in the ISO guidelines, particularly ISO 27001 on Information Security Management Systems (ISMS), ISO 25010 on System and Software Quality Requirements and Evaluation (SQuaRE), and ISO 15408 on Common Criteria for IT Security Evaluation. 3.4 Data Governance The ISO 3700 Standard defines governance as “the system by which the whole organization is directed, controlled, and held accountable to achieve its core purpose over the long term.” Data governance refers to the exercise of authority and control over the management of data. Abraham et al. [46] expand on this definition after reviewing 145 scientific articles on the topic, defining it as “a cross-functional framework for managing data as a strategic enterprise asset. In doing so, data governance specifies decision rights and accountabilities for an organization’s decisionmaking about its data. Furthermore, data governance formalizes data policies, standards, and procedures and monitors compliance.” Data governance is a transversal concern that provides a framework for managing a databased application throughout the entire data/model lifecycle. This section will cover the avail- 3.4. Data Governance 29 able accountability mechanisms to uphold policies, procedures, and regulations. 3.4.1 Documentation Documentation of datasets, models, and systems has been at the forefront of discussions regarding accountability and transparency in the field of artificial intelligence. Additionally, it aligns with the Visibility and Transparency Privacy by Design principle. Appropriate record-keeping has also become essential in light of regulations like the GDPR and the AI Act, as shown in Tables 3.2 and 3.3, respectively. These regulations, however, do not propose or enforce any specific template for system documentation. There have been various proposals regarding which aspects of an AI-based system should be documented and how they should be documented. Among these proposals, three major contributions stand out: Datasheets for Datasets, Google’s Model Cards for Model Reporting, and IBM’s FactSheets for AI Systems. The medical field has also made strides toward transparent reporting of statistical models, which can serve as a valuable resource for adapting commercial AI proposals to the medical domain. 3.4.1.1 Datasheets for Datasets Datasheets for Datasets were proposed in an article by the same name in 2018 [47]. They emerged as a standardized process for documenting machine learning datasets, inspired by the electronics industry’s datasheets. A datasheet is meant to document a dataset’s motivation, composition, collection practices, and recommended uses, among other aspects, in an effort to increase transparency and accountability within the machine learning community. [48] The authors propose a list of questions related to each stage in the data lifecycle to bring forth the necessary information to fill out a datasheet. These questions also encourage dataset creators to reflect on the processes of creating, processing, and distributing datasets, while helping dataset consumers make informed decisions about the practical use of a given dataset. [47] Datasheets also provide value to policymakers, individuals whose data is included in a 3.4. Data Governance 30 dataset, researchers, consumer advocates, and more. In the medical field, it is particularly interesting to consider the impact a datasheet can have on individuals whose data has been added to a dataset, as it would allow them to make an informed choice regarding whether they want to be part of it or if they would prefer to revoke their consent. Another notable advantage of datasheets in the context of healthcare, where sharing datasets is challenging, is that they would allow different hospitals to recreate datasets with similar characteristics within their own institutions, enabling them to potentially replicate the results of AI-based solutions that have shown promising outcomes elsewhere. [48] One of the main challenges of the Datasheets for Datasets proposal is the need for dataset creators to adapt the questions and workflow proposed to better fit their field, organizational structure, and workflows. Moreover, the process of creating a datasheet imposes overhead on dataset creators. Although it is clear that datasheets alone will not suffice to completely solve or mitigate all bias or risks, it is widely accepted that the benefits to the machine learning community outweigh the costs of developing datasheets. Among other advantages, the use of datasheets can help dataset creators and dataset users detect potential biases in the training data or inconsistencies between the training data and the expected real-world data, which could hinder model performance. [48] 3.4.1.2 Model Cards for Model Reporting Model cards are Google’s proposal for documentation that communicates the performance characteristics of a trained ML or AI model. Model cards can inform users about what a machine learning system is capable of doing, its limitations, the types of errors it might make, and any additional steps that could create fairer outcomes. They are designed with human-centric models in mind and aim to increase fairness by encouraging population-based reporting of results through intersectional analysis. This analysis contrasts the results for different races, genders, ages, and demographics in order to provide an overview of how the system’s behavior might differ depending on cultural, demographic, or generational groups. Slicing the evaluation across these different groups helps highlight errors that disproportionately affect a specific subset of people. [49] 3.4. Data Governance 31 3.4.1.3 FactSheets FactSheets are IBM’s proposal for AI system documentation [50]. They take a broader approach than Datasheets and Model Cards and attempt to document the entire system, which may be composed of many models trained on many datasets. They aim to increase trust by delivering clear records of the development and deployment of models within systems. This solution centres on business applications of AI; however, it is general enough to be applied to AI systems outside of this setting. The generality of FactSheets is one of its core features. FactSheets from different domains and model types will have common elements but will most likely contain different information and levels of detail. FactSheets are not proposed as a one-size-fits-all solution. They will look different depending on the type of AI system they pertain to, who will consume the FactSheet, and for what purpose. The information presented in them will vary accordingly. In the same article in which FactSheets are proposed, a methodology for creating them is also introduced. It is an iterative approach with seven steps, shown in Figure 3.2. In step one, the FactSheets team interviews the expected consumers of the FactSheet. Step two involves interviewing the FactSheet producers. In step three, using the information acquired in steps one and two, the FactSheets team produces a FactSheet Template for the specific system being documented. In step four, the FactSheets team fills out the FactSheet template to assess it. Although cooperation from those directly involved in the system’s development is beneficial for step five, it is not necessary. This is because, in step six, the producers of the system will fill out the FactSheet. In step seven, the FactSheets team repeats the process to increase coverage and value by devising templates for other audiences and purposes. 3.4.1.4 The TRIPOD Statement and TRIPOD + AI The reporting and documentation strategies we have previously mentioned originate from the software industry. The TRIPOD statement [51], introduced by the medical field in 2015, aimed to promote proper reporting in studies developing or validating multivariable prediction models for individual prognosis or diagnosis. However, with advances in artificial intelligence (AI) 3.4. Data Governance 38 Figure 3.3: Overview of the SMACTR Framework [57] 3.4.3.2 The SMACTR Framework The Google Responsible AI Impact Lab has also proposed an end-to-end framework for internal algorithmic auditing, the SMACTR framework. This framework incorporates lessons from auditing practices in other safety-critical and regulated industries, such as aerospace and medical device design and manufacturing. These industries have a long history of auditable processes and design controls that have helped improve safety. The SMACTR framework comprises five stages plus a post-audit stage, as shown in Figure 3.3, taken from the original paper [57]. It aims to create internal audits that produce a trail of documentation at each stage of development and enable critical reflection on the system’s impact, which can also serve as internal educational material on ethical awareness. The goal of the scoping stage clarifies the audit’s objective. Auditors review the system’s motivations and intended impact to anticipate potential sources of harm and social impact. The mapping stage aims to review the current state of the system. This includes searching for internal stakeholders and relevant collaborators. Another important aspect of this stage is that Failure Modes and Effects Analysis (FMEA) will be started at this stage and updated and expanded through the following stages. In the artifact collection stage, auditors set out to identify and collect all the necessary documentation from the development process to prioritize testing. If necessary, the auditor may enforce retroactive documentation or document some processes themselves, checking the results with the development team. The outcome of this stage includes the datasheets and model cards, 3.4. Data Governance 39 as well as a design checklist that keeps track of the availability of all the expected documentation. During the testing stage the auditing team executes a series of tests to assess the system’s level of compliance with the organization’s ethical values. In this stage, there will be variability in the approach taken by the auditing team to conduct tests, as they will depend on the organizational context. This paper’s authors propose the use of adversarial testing by attempting to simulate a hostile actor; however, they do not provide more detail. The main output of this stage is the ethical risk analysis chart, in which the importance of each risk is defined in proportion to its severity and likelihood. The reflection stage is reserved for analyzing the results of the tests in the context of the ethical expectations defined in the scoping stage. The FMEA is finalized in this stage, and artificts such as a mitigation plan can be proposed, together with a design history file that contains all the documentation related to previous stages, and finally, a summary of the audit. The post-audit stage is concerned with keeping track of the implementation of action plans proposed by the auditing team, as well as making final decisions regarding the proposed AI-based application, even to the extent of deciding to fully scrap the project. This framework is very informative as an outline for internal auditing for AI, but it is overall rather general. This is definitely an inteded feature of the framework, as it is meant to be able to perform in multiple domains. 3.4.4 Data Lifecycle Data lifecycles are a tool for data management, as they provide a structured framework that can guide data management practices. Oracle defines data management as collecting, keeping, and using data securely, efficiently and cost-effectively [58]. In many ways, a data management strategy establishes the foundation upon which a data project, such as a medical AI application, will be built. Proper data management has a wide variety of benefits, but in short, its fundamental role is ensuring that data is findable, accessible, interoperable, and reusable [59]. These four characteristics are usually referred to as the FAIR principles, for their initials [60]. Proper data management can also enhance collaboration by making data clear and accessible 3.4. Data Governance 40 while preventing the data entropy to which digital information is often prone. Moreover, journals and funding bodies increasingly require open data in academic research, making adequate management essential to ensure it can be understood and reused. In essence, effective data management ensures that data remains accessible and meaningful for years to come. In the case of most projects by “years to come”, we refer to a decade or two, but in healthcare, it can span an entire lifetime and more. For each patient, there is an entire life’s worth of data that needs to be accessible, understandable, and secure to properly support them as a patient at any given point in their life. This makes adequate data management a core concern in the development of data-based medical applications. [59] Data lifecycles are abstractions of the various stages data undergoes, from its creation or capture to its archival or deletion. As mentioned, they provide a structured framework for managing data throughout its existence, ensuring desired characteristics such as efficiency, quality, and responsible use. The stages commonly identified in general data lifecycle models include data collection, storage, processing, analysis, and visualizing or interpreting. Each stage presents unique challenges and opportunities, particularly concerning data quality, security, and accessibility. [61] The specific stages and characteristics emphasized in a data lifecycle often depend on the type of data and its intended purpose. For instance, research-oriented data lifecycles differ significantly from those designed for business applications. In the case of medical data, there is a clear need for heightened transparency, ethics, and accountability throughout the data’s lifespan. To the best of the author’s knowledge, as of December 2024, no data lifecycle model explicitly tailored to healthcare purposes exist. To verify this, a review of several academic databases, including PubMed, Elsevier, IEEE, and the ACM Digital Library, was conducted using keywords such as medical,data lifecycle,medical data lifecycle,data management,healthcare, and abstract framework medical data. The same keywords were also used in the Google Scholar academic search engine, yielding similar results. The lack of a domain-specific data lifecycle for medicine might be problematic, as common- 3.4. Data Governance 41 purpose lifecycles do not account for the unique requirements of medical data. For example, many general data lifecycle models omit a deletion or archival stage. However, in the case of electronic medical records, such stages are critical since, by law in countries like Colombia and Spain, medical records must be retained for fifteen years after the last healthcare interaction and then securely deleted through a predefined process. In Colombia, records related to the armed conflict or crimes against humanity must be preserved indefinitely, underscoring the necessity of an archival stage. These legal and ethical considerations highlight the need for a medical-specific data lifecycle that adequately addresses this field’s unique demands. In the following sections, we will study data lifecycles proposed by Harvard Business School [62], the CRISP-DM methodology [63], DataONE [59], and Harvard Longwood Medical School [64]. We do this to generate a general understanding of the most common data lifecycles and those that might closely resemble what a medical data lifecycle should be. The first two are conventional business and industry standards, while the second two are explicitly designed for scientific data management, with the last one being particularly interested in biomedical data. 3.4.4.1 Harvard Business School Data Lifecycle The Harvard Business School data lifecycle is a relatively simple model consisting of eight stages: generation, collection, processing, storage, management, analysis, visualization, and interpretation, which can be seen in section (a) of Figure 3.4. These steps are described as a cycle because the lessons learned and insights gained from one data project typically inform subsequent projects. However, as with all the data lifecycles we will study in this section, it is understood that there can be jumps between different stages throughout a single project. [62] For example, in one iteration, a project might aim to identify clusters of users. The insights from this first iteration could then inform the next, where a subsequent project seeks to classify new users into the previously identified clusters. This iterative process allows to build upon the insights of the previous iterations, compounding knowledge over time. Nevertheless, it is possible that while visualizing the user clusters, it becomes clear that the outcome is not ideal and more information needs to be collected, or the available information might need to be processed differently, so there can be jumps between the different stages. [62] 3.4. Data Governance 42 (a) Harvard Business School Data Lifecycle [62] (b) CRISP-DM Methodology [63] [65] (c) Data ONE Data Lifecycle [59] (d) Harvard Medical School Data Lifecycle [64] Figure 3.4: Comparison of data lifecycles and methodologies. 3.4. Data Governance 43 It is clear that this data lifecycle intends to keep extracting value from all the available data. Hence, it does not include a deletion or archival stage. This lifecycle also neglects to include a planning stage. This might be related to the fact that being a business-focused data model, it does not have to communicate information such as what data is needed for, how it will be stored, for how long it will be accessible, and how it will be used to any governing bodies. As we discovered by speaking with different researchers in Catalonia, this is a necessary step usually led by the ethics committee in any medical research project. Another characteristic of this model is that it emphasizes presenting data in an easily understandable format, such as graphs or charts. This is an interesting feature, as turning data into diagrams or charts presents information while obscuring the identity of the humans from whom this information was gathered. This could be an interesting insight when proposing a data lifecycle model for medical data. This is a standard definition of the data lifecycle, and other sources propose very similar models. The Columbia University’s Data Science Department is one of those sources [66]. 3.4.4.2 CRISP-DM Data Lifecycle The Cross-Industry Standard Process for Data Mining (CRISP-DM) was originally published in 1999 to standardize data mining practices. Although it is not technically a data lifecycle model but a data mining reference model, it also provides a structured approach to data projects with comparable stages and activities to a data lifecycle[65]. Because of this and its wide use and availability, we chose to include it among the data lifecycle models studied. Instead of being a circular or a linear model, it proposes a different feedback structure, as seen in section (b) of Figure 3.4. This aims to allow for faster refinement of the project as new insights are gained, as there is no need to complete an entire cycle to readjust. The arrows in the process diagram illustrate the most important and frequent feedback loops between phases, while the outer circle represents the complete cycle through which the final stage is connected to the next first stage. [63] Although it is more targeted towards industry projects, it makes some proposals that are 3.4. Data Governance 44 also interesting in the medical field. For instance, the data understanding stage includes tasks such as describing the data and verifying data quality, which would be essential for medical data applications. CRISP-DM also emphasizes documentation in all its deliverable objects, facilitating auditing and promoting transparency. Additionally, it has different retrospective stages in which both the process and the results are evaluated, making identifying and correcting errors easier. [63] Unlike the Harvard Business School data lifecycle, the final stage of the CRISP-DM methodology is deployment. This stage is particularly relevant in the context of medical AI-based applications, as the ultimate goal is to make these solutions accessible to clinicians and other medical professionals. However, deployment requires meticulous planning to ensure that data security and patient privacy are upheld. Robust measures must be in place, such as implementing a secure login system that restricts data access to authorized users. Additionally, other deployment-specific considerations must be addressed to align with the sensitive nature of healthcare data and the demand for high availability. 3.4.4.3 DataONE Data Lifecycle The Data Observation Network for Earth proposes the DataONE lifecycle. This communitydriven program aims to facilitate access to Earth and environmental data while educating the community on good practices. It is an eight-stage, iterative lifecycle, as seen in section (c) of Figure 3.4. This model emphasizes practices that enhance data sharing and reuse within the scientific community, as it is meant for scientific data management. As such, it has a structure that differs from the previously described models, with a more considerable emphasis on planning and quality assurance. One of its main goals is to create self-describing datasets that are understandable and usable even after a significant period of time has passed. [59] Like most other data lifecycle models, the Data ONE proposal is iterative and includes core stages such as planning, data collection, and analysis. This model emphasises metadata as a tool for data understanding and reuse. It also proposes some unique stages: assure, describe, and integrate. [59] 3.4. Data Governance 45 The assurance stage is for quality control and quality assurance. It includes tasks such as describing any conditions during collection that might affect data quality, identifying estimated values, and checking hand-entried data. Meanwhile, the next stage, describe, is concerned with the generation of metadata and documentation by describing the digital context of the data, stakeholders and personnel, scientific context, and information regarding units of measurement, formats, precision, uncertainty, and other information about the data’s different values. Finally, the integration stage focuses on the combination of data from different sources. This can be particularly interesting for our case study, as medical data will come from electronic health records, lab results, pharmacies, and other members of the healthcare ecosystem. [59] 3.4.4.4 Harvard Longwood Medical School Data Lifecycle As seen in section (d) of Figure 3.4, this is a six-stage, iterative lifecycle. It focuses particularly on biomedical data for research projects. Because of this, it prioritizes the presentation of research findings in academic publications instead of the deployment stage found in other data lifecycles. This model puts special emphasis on the planning and design stage and advocates for a detailed management plan that covers aspects such as strategies for managing clinical data, policies for data security, compliance with regulation, and the enforcement of directory and naming conventions that ensure data organization and accessibility. [64] This model is especially concerned with data security. Although data security is an underlying concern for other models, it seldom gets any more than a mention in the footnotes. By contrast, this model highlights best practices for securing active data, choosing appropriate storage locations, and creating backups. This model considers the importance of collaboration and data sharing for this field and, as such, proposes the creation of data use agreements and adequate permission management. All of these individual considerations are made available to the researcher through the Research Data Management Lifecycle Checklist document [67]. 3.4.5 Data Lifecycle Management Defining a theoretical framework for the data being handled has many advantages. By defining a framework, we can provide structure and formalization for data management. This is where Data 3.4. Data Governance 46 Lifecycle Management (DLM) emerges as a comprehensive policy-based approach to managing the flow of data [68] through the data lifecycle, which we explored in depth in Section §3.4.4. A common first step toward DLM is creating a data management plan, which details how data will be described, managed, and stored. The plan can also define any standards that will be used regarding data protection and other matters. The definition of a data lifecycle management plan usually involves tasks like identifying the data that is being generated and collected and how it will be organized in terms of what tools will be needed to manage it, which storage type will be used, and whether it should be stored on-site or locally. Documenting a data storage and preservation strategy is another reasonable incorporation into a DLM plan, stating information about the lifespan of data, who has access to it and under what circumstances, as well as documenting measures taken to protect the data throughout its lifecycle [68]. Common additions to a DLM plan also include the definition of data policies, roles, and responsibilities. By data policies, we refer to documenting how data will be managed and shared, emphasising the legal and ethical restrictions on access or use of the data. The roles and responsibilities section aims to define the necessary players to ensure adequate data management and their respective responsibilities. For example, it is necessary to define who will ensure that policies are followed and the extent of their responsibilities [68]. Chapter 4 Regulatory Landscape on Personal Data Protection in Catalunya and Colombia The rapid advancement in AI and the increasing reliance on digital systems to manage sensitive information, such as medical records, underscores the importance of of robust regulatory frameworks for personal data protection. In this context, the Catalan regulatory landscape stands out due to its comprehensive approach to data governance. This section explores the Catalan regulation governing personal data, medical records and AI development. By doing so, we intend to lay the groundwork for a comparative analysis with the Colombian regulatory landscape to identify any potential gaps. This section’s goal is not to go into detail regarding the specifics of the legal framework, as no in-depth legal analysis will be conducted. Our principal goal trough this study of the regulatory landscape is to elicit insights that enable us to accurately formulate strategies within data management that facilitate compliance, guiding the design of the frameworks which will be proposed later on. As a secondary goal we would like to analyse the current state of regulation in Colombia, to understand where it stands in comparison to the European example. Since it is our intention to propose frameworks that could work both within the Catalan and Colombian context it is necessary to verify that there are no major regulatory differences that would make this impossi47 4.2. Regulatory Landscape of Colombia 54 We will begin by citing a translation of Article 15 of the Colombian National Constitution, provided by Oxford University’s Comparative Constitutions Project [79], as it is the fundamental right of Colombian citizens that provides the legal basis for all other developments on this topic. ARTICLE 15 - All individuals have the right to personal and family privacy and to their good reputation, and the State has to respect them and to make others respect them. Similarly, individuals have the right to know, update, and rectify information collected about them in data banks and in the records of public and private entities. Freedom and the other guarantees approved by the Constitution shall be respected in the collection, processing, and circulation of data. Correspondence and other forms of private communication may not be violated. They may only be intercepted or recorded based on a court order in cases and following the formalities established by statute. For tax or legal purposes and cases of inspection, the oversight and intervention of the State may require making available accounting records and other private documents within the limits provided by statute. [79] We will now outline the guidelines of Colombian legislation on the processing of personal data. These guidelines apply to all personal data that exist in any database belonging to any entity within the Colombian jurisdiction, regardless of whether it is of a public or private nature. This regulation also applies to all of Colombia’s National Territories and outside of them when Colombian legislation is applicable due to different international treaties. It only considers the following exceptions: •Data for exclusively personal and domestic use. Should this data be provided to any third parties, it will become subject to the legal dispositions defined by the Colombian legislation for personal data. •Databases and files related to national security and defence, control of money laundering and funding of terrorism. •Databases that contain information related to intelligence and counterintelligence. •Databases and files containing journalistic information and other editorial contents. The definition of personal data given by the Colombian law is consistent with the definition 4.2. Regulatory Landscape of Colombia 55 provided in the GDPR, as shown in section 3.1. Colombian legislation also defines sensitive data as information which may affect the data subject’s privacy, and which can, if misused, generate discrimination. For instance, information pertaining to their race, political orientation, religious convictions, and information relative to their health, and biometric data (among others). 4.2.1.2 Principles for the Treatment of Personal Data The following principles are established in Law 1581 of 2012 as necessary for handling personal data. The principle of legality in matters of personal data treatment decrees personal data handling is a regulated activity which must adhere to the legal framework of Colombia. The principles of purpose establishes the need for a legitimate purpose of processing in accordance with the constitution and the law, and said data processing must be previously informed to the data subject. The principle of freedom states that the treatment of personal data may only occur with prior informed and explicit consent. Additionally, personal data may not be divulged without previous authorization or legal basis that relieves the need for consent. The principle of veracity and quality calls for correct, complete, exact, updated, ascertainable, and comprehensible data for the purposes of data treatment. It explicitly forbids the handling of data that does not fulfil these characteristics or data that may induce errors. The principle of transparency grants the titular of the data the right to obtain at any moment, and without restrictions, information regarding the existence of their personal data from the responsible or processor of their personal data. The principle of access and restricted circulation reiterates that the processing of personal data may only be carried out by those with the data subject’s consent. Additionally, it forbids displaying personal data on the internet or other massive divulgation channels unless they are controllable through technology to provide restricted access only to the data titular 4.2. Regulatory Landscape of Colombia 56 and to third parties for which consent to access data has been granted. The principle of security states that the data subject to processing must be handled with adequate technical, human, and administrative controls to ensure the safety of the data, avoiding adulteration, loss, unauthorized consult, unauthorized use, fraud or misuse. The principle of confidentiality expresses that all parties involved in processing personal data are obligated to safeguard the secrecy of personal data, even after they no longer have any relationship to the tasks involved in processing. 4.2.1.3 Rights and Obligations The principles stated in Section 4.2.1.2 are used as the base to define the rights of data subjects. These principles also pertain to the obligations of data controllers and processors. Rights of Data Subjects The person to which personal data pertains, known as the Data Subject in the GDPR or the Titular de los Datos in Colombian laws, has the following rights in Colombia: •To know, update, and rectify one’s personal data before the Data Controllers or data owners. •To request proof of the authorization granted to the Data Controller, except when it is explicitly exempted as a requirement for Processing. •To be informed by the Data Controller or Data Processor, upon request, of how one’s personal data has been used. •To file complaints with the Superintendence of Industry and Commerce for violations of the provisions of the law. •To revoke the authorization and/or request the deletion of data when the principles, constitutional and legal rights, and guarantees are not respected during the processing. •To access, free of charge, one’s personal data that has been subject to Processing and to consult the data pertaining to themselves on any database. 4.2. Regulatory Landscape of Colombia 57 As stated by Law 1581 of 2012, the processing of personal data is only allowed under the informed and ascertainable authorization on behalf of the data subject. Authorization is considered informed if the Data Controller makes it clear and understandable to the data owner the processing their personal data will be subjected to, the purpose of this processing, the possibility of refusing to answer questions related to sensitive data or regarding the personal data of children and teenagers, as well as the rights of the data subject and the data controller’s physical address, electronical address, and phone number. In order for the authorization to be ascertainable, the data controller must keep proof of authorization. The instances in which authorization on behalf of the data subject is unnecessary are few and well-defined by Law 1581 of 2012. These are limited to instances in which the data is required by a public or administrative entity in the exercise of their legal functions. The data is considered public data in cases of medical or sanitary emergencies, if authorized by law for historical, statistical or scientific ends, or if the data pertains to the civil registry of people (from the Spanish Registro Civil de Personas, a legal and administrative instrument by which the State recognizes the rights and obligations of Colombian citizens). However, even in these cases, those who access the data must still follow the obligations that will be discussed in the following two sections. Obligations of Data Controllers The Data Controller, or Responsable del Tratamiento as they are called in Colombian law, must fulfil certain duties in addition to the additional regulations for their field. There are 16 obligations in total, which we will group into four different categories. •Obligations towards the Data Subject: Guarantee the right of habeas data. Ask them for consent to authorize data processing. Inform them about the purpose of the collection and the rights conferred by the authorization. Process any inquiries or claims submitted by the data subject. And upon request, inform the owner of any information regarding the use of their data. •Obligations towards the Data Processor: Ensure that the data given to the processor adheres to the principle of veracity and quality. Inform the processor in a timely manner 4.2. Regulatory Landscape of Colombia 58 of any updates to the information so that the processor may update it as well. Rectify any incorrect information and communicate it to the processor. Supply the processor only with the data that has been previously authorized for processing in accordance with the law. Demand from the data processor for adherence to safety and privacy regulations. Inform the processor when the data subject is disputing a given piece of information. •Obligations towards the Competent Authority: Inform the competent authority about any safety breaches and about the existence of any risks regarding the administration of the data owners’ information. Follow the instructions and requirements stated by the Competent Authority. •Obligations regarding Governance: Keep a copy of the authorization granted by the owner of the data. Ensure adequate conditions to safeguard the principle of security. Adopt internal policies and procedures to guarantee the fulfilment of the legal requirements and to support the solution of consults and reclamations. On top of these obligations outlines in Law 1581 of 2012, Decree No. 090 of 2018 establishes that Data Controllers that are non-profit entities with over 100.000 UVTs (equivalent to 1044763 euros as of 2024) in assets must register to the national database registry (RNBD, for its initials in Spanish) all of the databases under their control that contain personal information subjected to manual or automated processing. This is done with the purpose of keeping track of the number of data owners, the types of personal data being processed, the Data Controllers that exist within the system, the objective of the processing and the policies for personal data handling being used. Obligations of Data Processors The Data Processor, or Encargado del Tratamiento, also have a list of 12 duties they must fulfil, which we will similarly categorize into four different groups. •Obligations towards the Data Subject: Guarantee the right of habeas data. Process any inquiries or claims submitted by the data subject. 4.2. Regulatory Landscape of Colombia 59 •Obligations towards the Data Controller: Update any information reported by the Data Controller in a time span of 5 work days. •Obligations towards the Competent Authority: Refrain from circulating information that is being disputed by the data subject, and the Competent Authority has ordered for it to be blocked. Register any reclamations in the designated database. Register the data regarding information that is under juridical discussion in the database established for it once the competent authority makes the Processor aware of any such cases. Inform the competent authority about any safety breaches and about the existence of any risks regarding the administration of the data subjects’ information. Follow the instructions and requirements stated by the Competent Authority. •Obligations regarding Governance: Ensure adequate conditions to safeguard the security principle. Carry out any updates, corrections or deletions in a timely manner. Adopt internal policies and procedures to guarantee the fulfilment of the legal requirements and to support the solution of consultations and reclamations. Allow access to the information only to those who have a legal basis to access it. 4.2.1.4 Mechanism for Vigilance and Sanctions The authority for data protection in Colombia is the Superintendence of Industry and Commerce through the Delegation for the Protection of Personal Data. It is responsible for exercising surveillance to ensure respect for the principles, rights, guarantees and procedures described by the law during data processing. Within the Delegation for the Protection of Personal Data, there is a Direction of Investigations Regarding the Protection of Personal Data, inside of which there is a second Direction of habeas data. The Superintendence of Industry and Commerce exercises the following core functions with respect to the protection of personal data: •Ensure compliance with existing regulations for the protection of personal data. •Investigate, on its own initiative or at the request of a third party, and order the necessary 4.2. Regulatory Landscape of Colombia 60 measures to enforce the right of habeas data. •Order the temporary blocking of data when, based on the request and the evidence provided by the data subject, there is a clear risk of violating their fundamental rights. •Carry out promotion, dissemination, and educational activities to inform and train citizens about exercising and guaranteeing the fundamental right to data protection. •Issue instructions on the measures and procedures that existing data controllers and processors must adopt to comply with the provisions of the law. •Collect from data controllers and processors any information required to carry out its functions. •Issue declarations of conformity regarding international data transfers. •Administer the National Public Registry of Databases and issue any orders and acts necessary for its administration and operation. •Sanction data controllers and processors who have failed to comply with the law. Regarding sanctions, the Superintendence of Industry and Commerce may issue successive fines while the regulation violation persists. The amount of these fines will depend on the damage, risk, or economic benefit to the infractor and others caused by non-compliance with the law. The Superintendence may also call for the suspension of activities related to data processing for up to six months, temporary closing of operations related to the processing, and immediate and definitive cease of activities that require the processing of sensitive data if the necessary corrective measures have not been at the time the suspension ends. However, these measures only apply to private institutions, in the case of a public authority being in breach of the regulation the Superintendence of Industry and Commerce will pass the case to the Procuradur´ıa General de la Naci´on (Office of the Inspector General) to carry out the investigation. 4.2.1.5 Transfer of Data to Other Countries The transfer of personal data to other countries is forbidden if the other country does not have adequate levels of data protection regulations, which in all cases must not be inferior to those 4.2. Regulatory Landscape of Colombia 61 mandated by Colombian law. The Superintendence of Industry and Commerce establishes which countries are considered to fulfil this requirement. There are some exceptions to this prohibition, mainly when the data subject gives their consent to transfer the data or when it comes to the exchange of medical data required for the data subject’s treatment for reasons related to their own health or public health concerns. It will not apply either to data transfers that are agreed upon in the framework of an international treaty based on mutual reciprocity or if the transfers are legally required to safeguard public interest or to exercise or defend a legal right in a judicial process. One final exception is data transfers related to stock trading or bank transactions, which are regulated by their own set of laws that are not considered relevant to the topic of this project. Suppose an international transfer of personal data is needed in a different context than those described before. In that case, the Superintendence of Industry and Commerce issues a declaration of conformity on said transfer (except, of course, if the transfer falls within the list of exceptions presented above). To do this, the requester will be allowed to request information and carry out the necessary steps to establish compliance with the requirements that would enable the requester to transfer the data. 4.2.2 Regulation Regarding Medical Records in Colombia Medical records are medical data sources that receive particular care during legislation. Although medical data is considered sensitive data according to Colombian law, this law extends additional guarantees and requirements to medical records. We will explore these special characteristics in this section. In general, medical records are regulated in a different way than medical data. In any of the laws concerning medical records, it is not explicitly mentioned that other medical data should be treated with the same level of care. This results in other types of medical data being covered as personal and sensitive data by the regulations related to Law 1581 of 2012 for personal data protection. A s an example of this, we can see how Suramericana (one of the largest companies in the health sector in Colombia) built the privacy policy for its general 4.2. Regulatory Landscape of Colombia 62 Type Full Name Relevant Sections Topics Resolution Resoluci´on 1995 de 1999 – Dictates the norms for the management of the medical record. Law Ley 23 de 1981 Chapter III Law by which rules on medical ethics are established. Chapter III on Medical Prescription, Medical Records, Medical Confidentiality, and Some Procedures. Law Ley 2015 de 2020 – By means of which the interoperable digital medical record is created and other dispositions. Table 4.1: Legislation for Medical Records insurance, EPS (Entidad Promotora de Salud: institution responsible for ensuring access to medical attention), IPS (Institucion prestadora del Servicio de Salud: Healthcare provier), and diagnosis and medical assistance branches created their privacy policy around Law 1581 of 2012 [80]. Article 34 of Law 23 of 1981 defines the medical record as the obligatory register of a patient’s health conditions. The law considers this record a private document that may only be accessed by third parties with prior consent from the patient or in cases covered by the law. The medical record details a person’s physical, psychological, and social profile. It chronologically records any information regarding a patient’s condition, treatment, and other procedures. Personal and familiar information is detailed in this file. As such, it is a highly sensitive repository of data that requires special protection. The body of law that regulates medical records in Colombia is vast and can be found in Annex II. However, Table 4.1 lists some of the most relevant regulatory documents. We will focus on the main characteristics of the Colombian medical record and how it differs from regular personal data. 4.2. Regulatory Landscape of Colombia 63 4.2.2.1 Data Subject and Data Controller Law 2015 of 2020 states in its sixth article that each person owns their medical records; in its fifth article, it states that healthcare providers are the custodians of these medical records. This puts hospitals and other system providers in a position where they must adopt the necessary techniques and procedures to protect this information. 4.2.2.2 Storage Resolution No. 1995 of 1999 states in Article 18 that healthcare providers may store medical records using physical or technological means. Whichever method is selected must comply with Decree No. 1080 of 2015 (Title II, chapter 5 on Document Management, Articles 2.8.2.5.1 to 2.8.2.8.3), Law 527 of 1999 by means of which the access and use of data messages, electronic commerce, and digital signatures are defended and regulated and any posterior regulations that modify or add onto them. Any electronic system used to administer medical records needs to fulfil a set of requirements, which are detailed in Circular No. 2 of 1997 of the General Archive of the Nation (Archivo General de la Naci´on). Among these requirements, it is stated that there must be prior technical studies to before implementing any new storage systems, and the choice to move to a new storage system must be justified. The documents stored in the system must have the same validity and efficacy as the originals. The system must maintain the same level of safety, durability, and reproduction of the information as the prior system and guarantee the adequate functioning of the services that depend on it. 4.2.2.3 Archival and Deletion In accordance with Article 3 of Resolution No. 839 of 2017, medical records in Colombia must be stored for a minimum of fifteen years, which are counted starting on the date of the last medical service provided. During the first five years, the medical record must be stored in a data management system or archivo de gesti´on, and for the following 10 years, it can be stored in a central archive or archivo central. This time span will be doubled for victims of human rights 4.3. Legal Framework Comparison 70 4.3 Legal Framework Comparison Overall, Colombian law implements similar tenants to the GDPR in regard to personal data protection, with similar rights for data subjects and obligations for data controllers and processors. Both regional legislations also include a special classification for sensitive data with similar definitions, however, the Catalan legal instruments provide more special guarantees for this type of data. As for medical records, both proposes a similar structure in which the medical institution is the custodian of the data, and the patient is its owner. It differs in one aspect, the lack of centralized governmental medical record system. Due to the Law 2015 of 2020 this might change in the future, as the development of an interoperable scheme for medical records has been mandated. This directly conflicts with the minimization of centralization data minimization strategy, however, so far only pilot tests have been conducted and due to the lack of information on the final design and implementation details of the proposed system it is not possible to provide any further conclusions regarding it. On this area, one of the key insights from the Catalan example that Colombia might want to look into is the creation of a PADRIS-equivalent. As far as we ascertained from interviews conducted with Colombian medical and computational researcher the access to medical information is strictly governed by the hospital and its ethical board. Additionally, we did not find any legal instrument that mandated the creation of such an entity. The introduction of a similar organization might facilitate innovation by empowering researcher in different institutions to access medical data. Additionally, the introduction of a third party which explicitly advocates for patient’s data rights could be very interesting in the Colombian context. As for artificial intelligence regulation, although Colombia has not passed any laws on the topic yet, the proposals that are currently being made are partly based on the AI Act and propose similar ideas. However, one recommendation that can be made from the example of the AI Act is the introduction of a Scientific Panel of Independent Experts (AI Act Art. 68), which does not make part of any of the law proposals currently under consideration. In conclusion, the Colombian legislation does not differ from the Catalan legislation in any 4.3. Legal Framework Comparison 71 way that would make it impossible to create development and auditing frameworks that can potentially be useful in both contexts. It is important to note that although the Colombian laws are less detailed than the European legislation, which is particularly noticeable when studying the GDPR, the law in Colombia is complemented by a considerable amount of resolutions, decrees and circulars which are all enforceable by law. This makes the comparison challenging, due to the sheer amount of documents that should be studied in order to gain full understanding of the Colombian regulatory context. Table 4.2 summarizes some of the important aspects of the current state of regulation for both regions regarding personal data, medical records, and artificial intelligence applications. Colombia Catalunya Competent Authority for Personal Data Delegation for the Protection of Personal Data of the Superintendence of Industry and Commerce (Delegatura para la Protecci´on de Datos Personales de la Superintendecia de Industria y Comercio) Spanish Data Protection Agency (Agencia Espa˜nola de Protecci´on de Datos) at a national level. Position of the Competent Authority for Personal Data Within the Government The Delegation for the Protection of Personal Data exists within the executive branch, hierarchically below the president, the vice president, the Ministry of Industry and Commerce, and the Superintendence of Industry and Commerce. Fully independent administrative authority. 4.3. Legal Framework Comparison 72 Special Categories of Data Data revealing racial or ethnic origin, political orientation, religious or philosophical beliefs, membership in unions, social organizations, human rights organizations, or entities promoting the interests of any political party or guaranteeing the rights and guarantees of opposition political parties. It also encompasses data related to health, sexual life, and biometric data. (Ley 1581 de 2012) Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation (GDPR Art. 9). Right of Data Subjects Know, update, and rectify personal data. Request proof of consent for processing. Be informed upon request of how one’s personal data is used by the controller or processor. File complaints if data protection laws are violated. Revoke authorization, request deletion of data, and access the personal data stored by a controller or processor. (Ley 1581 de 2012) Transparent information, communication, and modalities for the exercise of the rights of the data subject. Be informed of where their data is being collected directly from them, be informed of where their data is being collected from another source, right to access their data, right to rectify, to erase, to restrict processing, to object, and to refuse automated individual decision-making (GDPR Ch. 3). 4.3. Legal Framework Comparison 73 Breach Reporting Obligated to inform the competent authority. (Ley 1581 de 2012) Obligated to inform the competent authority and data subjects (GDPR Art. 33). System for the Storage of Medical Records Defined by each medical centre according to the disposition of the competent authority. Centralized system developed by parliamentary mandate. [87] Persistence of Medical Records 15-year minimum legally required, and in practice perpetually. 15-year maximum for patient identification data, informed consent forms, discharge reports, surgical reports and delivery records, anesthesia-related data, reports from complementary examinations, autopsy reports, and pathology reports; 5-year maximum for everything else. Legislative Adoption of AI Regulation No laws accepted yet. AI Act accepted and in force. Table 4.2: Comparison Between Colombia and Catalunya Chapter 5 Proposal for a Privacy-Aware Data Lifecycle and Management Plan for Medical Data, MDLC 5.1 The MDLC Based on the research conducted, it has become clear that a data lifecycle framework can be a fundamental tool for preserving privacy. This is because it can be used to embed privacypreserving measures at every stage of data processing. Particularly in the medical field, which is known to be highly regulated, it can also aid in incorporating internal controls into project development and reduce the need for retroactive documentation during a potential audit. In light of some of the interviews conducted with medical professionals and compliance specialists, it is my view that, for AI-based systems to exist within hospitals and the wider assistive framework of healthcare, the level of internal control will need to rise to the standard of other processes in the field. Regulation is also an important concern when it comes to medical data, which a domainspecific data lifecycle framework can help address. Most data lifecycles aim to be general and cover a wide range of different projects; however, this compromises the level of detail they can provide regarding the necessary tasks for regulatory compliance. In the case of systems that process medical data, there are a variety of legal requirements, such as conducting a privacy 74 5.1. The MDLC 75 impact assessment. Other data lifecycles do not mention the need for a privacy impact assessment or the definition of a data access plan; nevertheless, these are necessary when dealing with medical data (according to the GDPR). A domain-specific data lifecycle can bring such tasks to attention and help specify the appropriate point in time at which they should be performed to achieve better results. Privacy-by-design principles place full life cycle protection, or end-to-end security, as one of the core pillars of data security. However, the benefits of a structured approach to integrating privacy concerns in development go even further, as it can also help maintain transparency and visibility, promote proactiveness, and give designers and developers ample opportunity to consider privacy through each stage of development. However, even if this is true, most data lifecycles studied do not emphasize privacy concerns in any significant or detailed way. As a final remark, a recent survey [88] conducted in the software development industry has brought to light a consistent pattern of small development teams finding themselves in a position where they must make privacy decisions by themselves at various stages of the software development lifecycle. This survey identified inconsistent notions of privacy held by individuals at different stages of the development process and the need for a standardized approach that covers the different aspects of privacy at various stages of a project. Clearly defining the activities and policies that exist within each stage of data handling for the purpose of protecting privacy is a necessary first step toward achieving a standard framework for privacy-aware development, which could potentially aid responsible development. The introduction of a medical data lifecycle is pertinent because medical data is uniquely sensitive. As such, the common activities proposed in broader data lifecycles are not likely sufficient to fulfill legal, transparency, and privacy requirements. Additionally, the proposal of a domain-specific lifecycle can aid in making explicit activities that are not relevant or common in other fields, such as acquiring an ethical board’s consent. Auditability, regulatory compliance, the characteristics and security requirements of medical data, and the need for standard practices motivate the proposal of a domain-specific medical data lifecycle to fill the gap in the literature for an auditable, privacyand regulation-aware 5.1. The MDLC 76 abstract framework to support the development of AI-based systems that perform processing tasks on medical data. The proposed medical data lifecycle, called MDLC for the initials of the Medical Data Life cycle, consists of seven stages, plus an additional intermediate stage, the Intermediate Risk Assessment (IRA). Figure §5.1 illustrates the complete data lifecycle proposed. The proposed solution is iterative, and although the tasks are presented in a particular order consistent with most common data lifecycles, it is not meant to be lineal, as we acknowledge that there can be unexpected feedback loops that do not perfectly adhere to the proposed order. Figure 5.1: Proposal for an Iterative, Non-Lineal Medical Data Lifecycle This data lifecycle is specifically aimed at AI-based projects conducted within the context of a healthcare facility, developed by internal or external teams, and reliant on patients’ personal data. It is particularly focused on projects expected to have a medium to long lifespan, such as research projects tested over prolonged periods or attempts to adapt the findings of an academic publication to the facility’s environment. It may also serve as a relevant guide for public or private entities that are not healthcare providers but are involved in the broader 5.1. The MDLC 77 medical attention environment. However, it is not well-suited as a reference for projects in the field of medicine that do not utilize patient data, such as the development of models related to drug discovery, drug interactions, equipment, or staff, among others, as it places special emphasis on data subjects’ privacy and rights. This data lifecycle is designed with privacy-by-design in mind. It promotes proactivity through tasks aimed at predicting and detecting risks early and places special emphasis on the development of adequate documentation to ensure transparency and visibility. Additionally, conducting tasks throughout the data lifecycle that prompt the development team to consider how privacy can be impacted or protected during the project’s lifespan supports embedding privacy into the system’s design from its inception through to its conclusion. In this chapter, we will go through the seven stages of the proposed medical data lifecycle and the proposed IRA. We will explore the purpose, activities, and outputs of each stage. Although effort was made to create activities that are as concrete as possible, some level of abstraction is necessary due to the lack of specific knowledge about the particular project being conducted. This need for abstraction will be particularly noticeable in processing, modelling, evaluation, and deployment sections. 5.1.1 Stage 1: Plan and Design The Plan and Design stage sets the foundation for the responsible development of the project. This stage of the data lifecycle focuses on defining project objectives, scope, and guiding principles while addressing the unique challenges of medical data and its applications, such as the medical context, the motivation for development, and the relevant population. This stage ensures that key considerations, such as privacy-by-design, regulatory compliance, and alignment with principles, are integrated from the outset. It also promotes the mapping of use cases and the identification of the target population, which will be helpful later for selecting the data to be used. Additionally, it involves operational aspects, such as defining roles and establishing a timeframe to access to the data. By the end of the plan and design stage, the project should have a clear roadmap that aligns 5.1. The MDLC 78 with ethical, legal, and practical requirements, setting the stage for responsible and effective development. The main tasks and outputs of the Plan and Design stage are shown in Figure 5.2, and a detailed explanation of each task and its deliverables can be found in Tables 5.1, 5.2, 5.3, and 5.4, respectively. As a general remark, it is important to keep in mind that the specific details will change from project to project. In order to reflect this we do not provide documents such as the principles and violations checklist, but invite the development team to construct it themselves so that it will match their context, project proposal, and scope of execution. For this same reason we don’t specify a responsible for each task, we are aware that development groups will vary in size and configuration, and they will be better equipped to define which team member has the required expertise to carry out each task. Figure 5.2: Plan and Design Stage Summary 5.1. The MDLC 79 Task Outline Project Definition and Scope The team’s first objective in this task is to understand the objectives and intended reach of the project from both a clinical and a technical standpoint. Often, there will be many competing objectives and constraints that must be balanced, and through this task, the team may begin to clarify these trade-offs and uncover potential factors that might affect the project’s outcome. Neglecting this step may lead to putting effort into making a correct analysis for the wrong proposal. Outputs Project Background Document Record the information that is known about the project’s situation at the beginning of the project. Key Activities: Researching analogous developments made in other fields or other medical institutions, exploring the clinical context of the proposal, and defining relevant regulatory frameworks. Requirement Specification Document Lists all the requirements of the project, both functional and non-functional. Lists any assumptions made about the project or the data that may have to be rechecked once access has been granted, and list project constraints. Project Proposal Document Describes the intended plan for achieving the goals described in the Project Definition and Scope document. Lists the tasks that will be carried out during project development, their required inputs, outputs, dependencies, and estimated completion time. It is also pertinent beginning a preliminary assessment of tools and techniques, which might be forced to change during the following stages of development. Table 5.1: Project Definition and Scope Deliverables 5.1. The MDLC 86 5.1.3 Stage 3: Analyze, Assure, and Prepare The main objectives of this stage are to shed light on possible quality issues of the data, highlight interesting relationships between features, and create the final data sources for model training and evaluation. This section is relatively consistent with other data lifecycles. Nevertheless, this does not mean that data protection is neglected during this stage. It is important to ensure that development is guided by the proposals made during the Plan and Design stage and that the promise of secure storage and controlled access made in the plans is adhered to. It would be interesting to consider the use of zero-trust systems or trusted execution environments starting at this stage in order to provide a higher level of security for the data. This stage places slightly more emphasis on data quality assurance than other proposed data lifecycles, similarly to CRISP-DM and the DataONE lifecycle. This is partly due to recommendations made by medical professionals during the interviews, but it is also a common concern when developing AI models; as the saying goes, “garbage in, garbage out.” This stage is also concerned with producing sufficient metadata. This can be used to guide attempts to replicate a successful project or effectively reuse the data on a future project, reducing the amount of new processing required. Figure 5.4 provides an overview of the tasks and deliverables for this stage, which are expanded upon on Tables 5.7 and 5.8. 5.1. The MDLC 87 Figure 5.4: Analyze, Assure, and Prepare Stage Summary 5.1. The MDLC 88 Task Know the Data Examine the data to gain an understanding of its superficial properties and those fundamental, underlying, or inherent attributes of data that are not immediately observable. This task can give the development team insights as to what type of questions can be answered with the data, which graphs or plots might be illustrative, and reporting needs. Outputs Data Description Describes the surface properties of the data, including its format, the quantity of data, the names and descriptions of fields, and other gross features of the data discovered. Key Activities: Elicit field descriptions if the names are not clear, conduct basic count functions on the data, and document the names, sizes and topics of the available datasets. Data Exploration Report Detail the activities carried out during data exploration and their outcomes. Key Activities: Calculate the distribution of relevant attributes, study relationships between attributes, conduct basic statistical operations, identify relevant sub-populations or risk groups, harness domain knowledge to guide data exploration. Data Quality Report Detail the data-quality verification activities conducted and list their results. If issues in data quality are found, list possible solutions or implications for subsequent stages of project development. Key Activities: Verify the compliance of the data provided with the participant acceptance criteria, confirm that the amount of data is consistent with the number of participants selected, review that the available fields are consistent with the fields requested on Stage 2: Select and Collect, check for errors paying special attention to fields that are filled by hand, identify missing values, use statistical operations to find impossible values in minimums, maximums or averages, and identify outliers. Consider using quality flags to indicate the perceived data quality [89]. Table 5.7: Know the Data Deliverables 5.1. The MDLC 89 Task Prepare the Data In this task, the development team takes action on the insights gained during the Know the Data task by processing the data to clean it, handle missing values, generate new features and integrate it with other data sources. Outputs Data Cleaning Report Describes the actions taken to improve the quality issues discovered during the previous task (such as missing data), as well as explaining the reasoning behind the course of action selected. It details how the data was transformed for cleaning and any possible impacts these activities may have on subsequent stages of project development. Constructed Data Report If any new features were produced by combining existing attributes or by incorporating external data, they should be listed and explained in this document. Additionally, if any synthetic registers are generated for the purpose of modeling, they should be disclosed in this document and the reasoning behind them should be made explicit, as well as the possible impacts this decision may have on subsequent stages. Data Integration Report If any of the data sources were merged, it should be disclosed and justified in this section, as data segmentation is preferred for privacy preservation. Additionally, if any external datasets or resources are incorporated into the final dataset, they should be listed and justified as well. Final Datasheet At this point, the team should be able to answer all the questions in the Datasheets for Datasets questionnaire and fill out a complete datasheet for the datasets that will be used for training and evaluation. Final Datasets This data will be used during the Model and Compare stage to train and test the proposed models. Table 5.8: Prepare the Data Deliverables 5.1. The MDLC 90 5.1.4 Stage 4: Model and Compare This stage focuses on the evaluation of various model versions, implementations, and hyperparameters. During this phase, the development team transitions from the preliminary assessment of tools and techniques conducted in Stage 1: Plan and Design to the concrete implementation of a specific model or set of models from which results will be derived. This process follows a standard approach but incorporates a higher level of documentation. Among the proposed documentation for this stage is the Design History File (DHF), a concept not covered by any of the data lifecycles explored in the literature review. Originating from the medical device industry, the DHF is not universally mandated; however, it is a required artefact for medical device development in the United States under the Code of Federal Regulations (CFR) Title 21, Section 820.30(j). The CFR defines the DHF as “a compilation of records which describes the design history of a finished device.” The adaptation of the DHF as a tool for auditing AI systems was proposed in [57]. Its application appears particularly appropriate for AI-based healthcare solutions, where rigorous documentation and traceability are critical for compliance, safety, and ethical considerations. The proposed tasks and deliverables for stage 4 are shown in Figure 5.5 and explained in more detail on Tables 5.9 and 5.10 5.1. The MDLC 91 Figure 5.5: Model and Compare Summary Task Compare Modeling Techniques The goal of this task is to select the best implementations and configurations of the possible models. Outputs Evaluation Metrics List of the evaluation metrics selected to compare the different models and configurations. Consider incorporating performance metrics as well as metrics that target fairness and bias, explainability and other non-functional requirements. Model Selection Report This document will describe all the activities carried out to select any specific implementation and configuration of the algorithm or model. It will at a minimum list the tests carried out, an explanation of why these tests were considered relevant and sufficient, and describe the train/test split used. It will also display the results of the tests and the final decision regarding model selection. It will outline the trade-offs of each option being considered. Key Activities: Define candidate models, define hyper-parameters to consider, define tests, run tests, produce graphs and metrics to show the results of the tests, and define the models that will be used from this point onward. Table 5.9: Compare Modeling Techniques Deliverables 5.1. The MDLC 92 Task Model and Test In this task, the development team will focus on the selected model or models to gain a better understanding of how they behave and the results it provides. Outputs Model Test and Insight Report This document should detail the results of model training and testing, which might differ from those in Compare Modeling Techniques if those tests were conducted with subsets of data. It should describe any other tests conducted to extract insights from the model’s behaviour, such as tests regarding risk groups or minority populations within the dataset. Key Activities: Do the full training necessary to achieve the project’s goals, conduct additional in-depth tests as necessary (for instance tests related to risk groups), specify concrete use cases, define assumptions the model makes about the data to avoid a potential mismatch with production data. Model Cards for Model Reporting Fill out a Model Card [49] for each of the trained models. Complete DHF Master document refers to all the design and implementation documentation files of the algorithm’s development and any notes made by the development team or other stakeholders during IRAs. Table 5.10: Model and Test Deliverables 5.1. The MDLC 93 5.1.5 Stage 5: Assess and Share This stage seeks to go even further than the evaluation conducted in Stage 4: Model and Compare and to assess to what extent the proposed model or models fulfill the project’s objectives without compromising on the agreed foundations for responsible data use. This section emphasizes the adherence to the plans made on stage 1, enforces accountability, and provides space for reflection on the process so far. This stage also provides mechanisms to communicate with and gather feedback from stakeholders. This will be fundamental to inform the decisions about the project’s next steps, which will be made based on what the assessment and feedback reveal about the project so far. Although some of the studied data lifecycles provide similar structures to this stage, they are not as expansive in their project assessment and do not emphasize risk assessment or adherence to original plans. A summary of the tasks and deliverables for this stage is shown in Figure 5.6, with more details available for each task on Tables 5.11, 5.11, 5.11, 5.11, and 5.11. 5.1. The MDLC 94 Figure 5.6: Assess and Share Summary 5.1. The MDLC 95 Task Assess Compliance In this task, the goal is to assess the development team’s compliance with the plans and policies made during Stage 1: Plan and Design. Outputs List of Deviations from Data Access Plan List of changes, deviations, or additions to the data access plan, together with their justification and a short assessment of its possible impacts. List of Deviations from Project Proposal List of changes, deviations, or additions to the project proposal, together with their justification and a short assessment of its possible impacts. Table 5.11: Assess Compliance Deliverables Task Assess Project Results Assess the level of fulfilment of the objectives of the project, as well as determine if all the important tasks have been carried out and all the relevant facts have been considered during the development process. This task will serve as a retrospective on the project so far. Outputs Review of Process Summarizes the process of reviewing if all the tasks have been completed to an acceptable degree and list any tasks that might need to be redone or that were, for some reason, forgotten. Lists any facts that were not taken into account during planning or development but that, in retrospect, might cause issues later down the road. Review of Project Goal Fulfillment Lists all the goals stated during the project proposal and goes into detail regarding the level of completion for each of them. Table 5.12: Assess Project Results Deliverables Task Assess Risk This task is aimed towards creating a general overview of the possible risks of the implemented system. Outputs Updated Preliminary Privacy Impact Assessment Privacy Impact Assessment updated to reflect the developed system. Self Assessment Checklist Review of the Future AI Assessment Checklist for trustworthy medical AI tools [90]. Table 5.13: Assess Risk Deliverables 5.1. The MDLC 102 Task Assess In order to promote the early detection of potential or materialized risks, this task prompts the development team to update their transversal documentation to reflect the current state of the system and to review their adherence to the initial commitments made to the guiding principles. Outputs Updated PPIA Built upon the document started in Stage 1: Plan and Design, and on top of any updates made on prior IRAs, the updated PPIA will review the previously identified risks and consider any new potential ones. It may include, remove, or modify any risks in light of the system’s current state. Updated History File This document is a reviewed system history, updated to reflect any new developments. Past entries may not be edited, but in case of error, they may be corrected by adding a note including the correction and the source of the error. It is important to note that unlike the PPIA, which is first created in Stage 1: Plan and Design, the very first history file will be created during an IRA. Document Requirement Checklist Assessment A structured checkpoint to ensure that all necessary documentation for the stage being exited is in place. The development team reviews the required documents to verify their completion, accuracy, and relevance to the project’s current state. If any required documents are missing or incomplete, the team must create a plan to address these gaps retroactively. Principles and Violations Checklist Assessment Review of adherence to guiding principles established during the project’s planning. The team carefully examines the checklist to ensure no violations of these principles have occurred up to the current stage. This assessment helps identify deviations from agreed-upon standards and ethical commitments, promoting accountability and allowing for early corrective actions if violations are detected. Table 5.21: IRA Summary Chapter 6 Proposal for an Auditing Framework for MLDC, UMAPER 6.1 UMAPER: An Auditing Framework for MDLC Projects An audit is the activity of verifying processes and quality systems to ensure that “textitthe organization’s control processes are adequate to mitigate its risks, governance processes are effective and efficient, and organizational goals and objectives are met” [91]. Auditing gathers evidence to confirm the proper functioning of established internal controls. It is a valuable tool for identifying errors, ensuring regulatory compliance, and highlighting areas with outdated controls. Internal controls are policies, processes, tasks, and behaviours that facilitate effective operations, they ensure quality reporting, and maintain compliance with applicable laws and regulations [56]. Throughout the stages of the MDLC, various internal control mechanisms were introduced to raise awareness of risks and challenging situations, promote and support informed decision-making, and minimize errors. Healthcare systems are already subject to high levels of scrutiny and frequent audits due to the critical nature of their operations and the need to maintain public trust. Auditing in this domain enhances transparency and accountability, reduces errors, and strengthens compliance with regulations. However, the introduction of AI-based systems introduces unique risks, par103 6.1. UMAPER: An Auditing Framework for MDLC Projects 104 ticularly in regard to privacy. As addressed in the justification for the MDLC, it is likely that if AI-based systems ever become widespread in the medical field, they will need to be audited. This is why we propose an auditing methodology based on the traditional auditing cycle and the SMACTR methodology [57] to conduct end-to-end audits for projects modeled after the MDLC. A tailored auditing framework for the MDLC offers several key advantages. First, it provides a structured approach to verifying compliance with internal controls while assessing the performance and safety of AI-based medical systems. By focusing on both the process and product levels, this framework ensures that workflows adhere to the MDLC-defined standards and that the resulting systems meet quality benchmarks. Furthermore, adapting the existing auditing cycle to fit the MDLC model reduces the initial costs and resource demands of conducting audits, making it a more feasible option for organizations. The benefits of such a framework extend beyond operational efficiency. A well-designed audit methodology promotes continuous improvement by creating a feedback loop between audit findings and system development. This iterative process not only improves the quality of the audited project, as it might kickstart a new iteration of the MDLC, but it can also improve the quality of future projects through the insights it produces. Stakeholder trust is a crucial consideration in the adoption of AI-based medical systems. Auditing outcomes are often met with scepticism due to their reliance on human judgment, which can lead to the insights provided by the audit being disregarded. We can generate a sense of legitimacy and credibility around the auditing process by proposing a specific framework with predefined stages and activities. In particular, the development of an auditing framework seeks to establishing procedural justice in the auditing process, as establishing a framework can help auditors demonstrate the adherence to accepted standards and demonstrate the integrity of the audit. The proposed auditing framework has six stages: Understand, Map, Assess, Plan, Execute, and Reflect. Each of these stages is based on the key auditing activities, defined by referencing the SMACTR framework, the standard auditing cycle, and the ISO/IEC 27001:2022 requirements for information security, cybersecurity and privacy protection. An overview of the audit 6.1. UMAPER: An Auditing Framework for MDLC Projects 105 Figure 6.1: Overview of the UMAPER Framework. Double-lined boxes represent processes, regular boxes represent tasks, blue represents input documents, and orange represents output documents. framework is shown in Figure 6.1 6.1.1 Understand: Why is the Audit Necessary? This stage aims to evaluate the audit’s relevance and specify its objectives by anticipating sources of risk and areas to investigate. In order to do this, the auditing provider (the entity that provides the auditing service, whether it is internal or external) will collaborate with the audit requirer (individual, group, or organization that requests the audit to be conducted) to gather information such as: •Why was the audit requested? •Is the audit requested as part of routine controls, or is it a special request? 6.1. UMAPER: An Auditing Framework for MDLC Projects 106 •What are the main concerns perceived by the requirer? •What is the relevance of this system in the context of the requirer’s operations? •What are the main characteristics and functionalities of the system? •Has the system already been audited in the past? If so, what were the recommendations made? Where they followed through on? •Have there been any significant changes made to the system? •What is the expected timeframe for the audit? •What would be the expected deliverables of the audit process in regard to the requirer’s internal policies? •What is the expected scope of the audit? •Who is the system owner? •Who are the key collaborators the auditing team can rely on to gather information about the system? The auditor can complement this information with the documentation produced by the MDLC at different stages: •From the Plan and Design stage: The project background document, the requirement specification document, and the principles and violations checklist. •From the Deploy stage: The final privacy impact assessment, and the audit triggers. In short, this stage’s main tasks are gathering information on the audit’s motivation and the system’s organizational, ethical, and regulatory context. The reason for carrying out this preliminary investigation is twofold. First, it will help the auditing team gather initial data to assess the feasibility of the audit. In second place, it will help the auditing team identify the areas on which the audit will focus or the audit scope. The audit scope could potentially be 6.1. UMAPER: An Auditing Framework for MDLC Projects 107 privacy risk assessment, but this framework is flexible enough to provide a base for other types of audits. These findings of this stage should be reflected in a report that is to be presented to the requirer once it is finished and to the system owner (the individual responsible for the system) prior to the initial meeting. The Audit Scope Report: This report should include notes on the requirer interview, the reasons for the conduction of the audit, the areas of interest for the audit, the normative references for the audit, the proposed auditing team, and the immediate activities, which will include the notification of the audit to the system owner and the setting of a date for an initial meeting with the system owner so that they may prepare. 6.1.2 Map: What is the System Being Audited? The goal of this stage is for the auditing team to learn as much as possible from the system’s available documentation. This stage takes place before the first meeting with the system owner, as its goal is to minimize the imposition on their time by becoming as familiar with the system as possible independently. The knowledge acquired during this stage will later need to be verified with the system owner team, as although the documentation strives to capture the system’s reality, it is prone to errors and inaccuracies, especially if the system has had any major changes recently. In this stage, the auditing team will review the systems documentation to familiarize itself with the development process and identify internal stakeholders and collaborators. The documentation review aims to identify opportunities for testing by reviewing the development process and assessing the completeness of the documentation by interacting with it. Meanwhile, the internal stakeholder and collaborator identifications is done to help establish relevant contacts which might be necessary during following stages, and to identify individual participation towards the final outcome, allowing auditors to assess personal accountability towards each stage of the development process. In order to carry out the tasks of this stage, the auditing team may rely on documents from the MDLC, such as: 6.1. UMAPER: An Auditing Framework for MDLC Projects 108 •From the Plan and Design stage: The outline of roles and responsibilities. •From the Analyse, Assure, and Process stage: The final datasheet. •From the Model and Compare stage: The model cards and the design history file. •From the Deploy stage: The system fact sheet and project retrospective. Once these tasks have been completed, the auditing team may move on to the initial meeting with the system owner. During this meeting, the auditing team will share and confirm the information they have acquired about the system, and the system owner will provide any additional resources. After this meeting, the auditing team will create a final system map with the most up-to-date information on the system. It may then move on to the following stages, in which they will begin preparing questionnaires and tests to conduct the audit. It is important to note that it is common practice to have an opening meeting with the system owner before going into detailed planning, as it sets up the stage for a better informed and prepared audit. The System Map: This document provides a checklist of the expected documentation, marking it as available or unavailable and pointing out if any errors or inaccuracies came to light during the initial meeting. the system map also provides a summary o the system’s structure, a description of each relevant system unit and and the relevant stakeholders and contacts. 6.1.3 Assessment: What are the Risks? A necessary precursor to the planning stage is the risk assessment stage. The potential risks incurred by the system are necessary to inform test selection, as they are the key to defining relevant tests. This is essential in order to guarantee that the audit is efficient and effective, focusing on areas of greatest risk. Although the MDLC innately considers privacy impact assessment, the expertise of auditors goes a long way towards reviewing and complementing this document. Additionally, as an audit’s scope is not restricted to privacy, it might be relevant to conduct a human rights impact assessment, system bias risk assessment, or failure modes and effects, among others. 6.1. UMAPER: An Auditing Framework for MDLC Projects 109 This stage is informed by the system map, however, this information can and should be complementing by consulting others. Relevant contacts found during the previous stage, domain experts (medical professionals or hospital administrative personnel in this context), external experts, or legal advisors should be consulted in order to have wider coverage of the potential risks that are inherent to the system being audited and systems similar to it. Additionally, documentation produced during the MDLC that is not considered during the system mapping can also provide insight into potential risks and mitigatory measures already in place. These documents will be particularly relevant to a privacy audit, but they can also be relevant towards informing audits with different objectives as they cover a wide variety of relevant aspects regarding the project’s development. Relevant documents include: •From the Plan and Design stage: the data access plan and the principles and violations checklist. •From the Select and Collect stage: The data selection report, the data origin report and the data deidentification report. •From the Analyze, Assure, and Propose stage: The data quality report. •From the Model and Compare stage: The model test and insight report. •From the Assess and Share stage: The list of data access plan deviations and the self assessment checklist. •From the Deploy stage: The proposal for monitoring and maintenance, the final privacy impact assessment, the project retrospective and the audit triggers. The auditing team’s work should be registered in a report. This document will be shared with the system owner and the audit requirer, so that they may review it and make necessary recommendations before moving on to the following stage. The Risk Assessment Report: Lists the risks found, their likelihood and their severity, as well as possible mitigatory measures for them. This document will also disclose any communica- 6.1. UMAPER: An Auditing Framework for MDLC Projects 110 tion with relevant contacts that led to the discovery of this potential risks or their justification based on the system map. 6.1.4 Plan: What Tests Will be Conducted? When Will they be Conducted? During this stage, auditors will use all the information they have gathered so far regarding the system, its context, and the risks it entails to produce a concrete set of tests to be executed. Tests are one of the main tools auditors use to assess a system’s compliance with internal company policies, legal regulations, and even–as proposed in the SMACTR Framework–ethical values. These tests should ideally help assess the system’s most concerning or most likely risks, which is why the planning is conducted once the auditors have a thorough understanding of the system. If this is a routine control and no major changes to the system have occurred between this audit and the last, a list of relevant tests might already exists. If this is the case, then auditors should take it as a base, update the timeframe, review the tests to ensure they are all still relevant, and either remove those that no longer are or update them as necessary. The resulting plan will be delivered to the audit requirer and the system owner, so that they may be informed of the proposed tests. If there are any questions or clarifications that the audit requires or the system owner wishes to make, they can be taken into account by the auditing team. With this information, the system owner can also begin to prepare for the upcoming tests by designing which human, technical and other resources will be assigned to aid during test execution. Test selection and the satisfaction criteria for each test are highly dependent on the system’s specific purpose, implementation details and context. This is why planning will have to be conducted for each individual system, and results may vary widely. However, auditors may reference testing plans made for similar systems during this process. For instance, for a medical image classifier system, auditors may want to take inspiration from clinical audit guides to assess the medical aspect of the system, audit guides for classification systems to assess the algorithmic aspects of the system, GDPR compliance guides to assess the regulatory aspects of the system, and so on. 6.1. UMAPER: An Auditing Framework for MDLC Projects 111 The Testing Plan: This document will include the tests to be carried out during the execution stage, their justification, the risk they target, the required collaborators to carry them out, their expected start and end date, the member of the auditing team responsible for them, and any additional considerations that are deemed relevant by the auditing team. If this is an update to a previously existing plan, it should highlight the added, removed or edited tests. Each test will also be accompanied by a justified grading rubric, which will detail the requirements for a test result to be satisfactory. In addition to the individual test design, the testing plan will also include how system satisfaction will be calculated based on the individual test results. 6.1.5 Execute: Carrying Out the Plan During this stage the audit team, together with the system team, will carry out the established tests in accordance with the test plan. This is where most of the audit time is likely to be consumed and where the audit team will need to work most closely with the system team. Trough this stage auditors will engage with the system to carry out each test defined in the plan, grade it according to the rubric proposed in the test plan, and point out any specially relevant results. The test results will be provided to the system owner and the audit requirer, who may request a re-do test if the results seem inconsistent or unexpected. These re-tests need to be highlighted in the test result report, as they can highlight aspects of the system that are of special interest for future audits. The Test Result Report: This document will list the tests conducted, if it was not possible for any reason to execute all the tests proposed in the test plan it will have to be justified in this document to. For each test conducted, the auditors responsible will provide the timeframe for execution, a result according to the rubric, and any notes made by themselves or the system team members they collaborated with. Bibliography ii [14] Naeem Firdous Syed, Syed W. Shah, Arash Shaghaghi, Adnan Anwar, Zubair Baig, and Robin Doss. Zero trust architecture (zta): A comprehensive survey. IEEE Access, 10:57143– 57179, 2022. [15] Christoph Buck, Christian Olenberger, Andr´e Schweizer, Fabiane V¨olter, and Torsten Eymann. Never trust, always verify: A multivocal literature review on current knowledge and research gaps of zero-trust. Computers Security, 110:102436, 2021. [16] Cybersecurity and Infrastructure Security Agency Cybersecurity Division. Zero Trust Maturity Model, Pre-decisional Draft. Technical report, June 2021. Accessed on Jan. 17, 2024. [17] David Loshin. 8 - dimensions of data quality. In David Loshin, editor, The Practitioner’s Guide to Data Quality Improvement, MK Series on Business Intelligence, pages 129–146. Morgan Kaufmann, Boston, 2011. [18] Suntherasvaran Murthy, Asmidar Abu Bakar, Fiza Abdul Rahim, and Ramona Ramli. A comparative study of data anonymization techniques. In 2019 IEEE 5th Intl Conference on Big Data Security on Cloud (BigDataSecurity), IEEE Intl Conference on High Performance and Smart Computing, (HPSC) and IEEE Intl Conference on Intelligent Data and Security (IDS), pages 306–309, 2019. [19] Mike Hintze and Khaled El Emam. Comparing the benefits of pseudonymisation and anonymisation under the gdpr. Journal of Data Protection & Privacy, 2(2):145–158, 2018. [20] APDCAT. Guia de protecci´ On de datos para pacientes y personas usuarias de los servicios de salud. https://apdcat.gencat.cat/web/.content/03-documentacio/documents/ Guia-proteccio-de-dades-pacients-v14-CAST.pdf. Accessed: 2024-12-26. [21] Thomas Neubauer and Johannes Heurix. A methodology for the pseudonymization of medical data. International Journal of Medical Informatics, 80(3):190–204, 2011. [22] Helge Aamot, Christopher D Kohl, Daniel Richter, et al. Pseudonymization of patient identifiers for translational research. BMC Medical Informatics and Decision Making, 13(1):75, 2013. [23] Mengmeng Yang, Taolin Guo, Tianqing Zhu, Ivan Tjuawinata, Jun Zhao, and Kwok-Yan Lam. Local differential privacy and its applications: A comprehensive survey. Computer Standards Interfaces, 89:103827, 2024. [24] Microsoft Research. Privacy-preserving machine learning: Maintaining confidentiality and preserving trust, 2022. Accessed: December 29, 2024. [25] Hannah Brown, Katherine Lee, Fatemehsadat Mireshghallah, Reza Shokri, and Florian Tram`er. What does it mean for a language model to preserve privacy?, 2022. [26] Data Sanitization Organization. Data sanitization terminology. [27] Steve Alder. Healthreach community health centers reports improper disposal incident affecting almost 117,000 patients. https://www.hipaajournal.com/ healthreach-community-health-centers-reports-improper-disposal-incident-affecting-almost-117000-patients/. Accessed: 2024-12-28. Bibliography iii [28] Mina Askari, Reihaneh Safavi-Naini, and Ken Barker. An information theoretic privacy and utility measure for data sanitization mechanisms. In Proceedings of the Second ACM Conference on Data and Application Security and Privacy, CODASPY ’12, page 283–294, New York, NY, USA, 2012. Association for Computing Machinery. [29] James C. L. Chow, Valerie Wong, and Kay Li. Generative pre-trained transformerempowered healthcare conversations: Current trends, challenges, and future directions in large language model-enabled medical chatbots. BioMedInformatics, 4(1):837–852, 2024. [30] Malte Schwarzkopf, Eddie Kohler, M. Frans Kaashoek, and Robert Morris. Position: Gdpr compliance by construction. In Heterogeneous Data Management, Polystores, and Analytics for Healthcare, page 39–53, Berlin, Heidelberg, 2022. Springer-Verlag. [31] Jie Xu, Zihan Wu, Cong Wang, and Xiaohua Jia. Machine unlearning: Solutions and challenges. IEEE Transactions on Emerging Topics in Computational Intelligence, 8(3):2150–2168, June 2024. [32] Bingyan Liu, Nuoyan Lv, Yuanchun Guo, and Yawen Li. Recent advances on federated learning: A systematic survey. Neurocomputing, 597:128019, 2024. [33] Rui-Jie Yew, Lucy Qin, and Suresh Venkatasubramanian. You still see me: How data protection supports the architecture of ai surveillance, 2024. [34] William Lindskog and Christian Prehofer. A federated learning benchmark on tabular data: Comparing tree-based models and neural networks. In 2023 Eighth International Conference on Fog and Mobile Edge Computing (FMEC), page 239–246. IEEE, September 2023. [35] Zijun Wang and Keke Gai. Decision tree-based federated learning: A survey. Blockchains, 2(1):40–60, 2024. [36] Yu-Chi Chen, Song-Yi Hsu, Xin Xie, Saru Kumari, Sachin Kumar, Joel Rodrigues, and Bander A. Alzahrani. Privacy preserving support vector machine based on federated learning for distributed iot-enabled data analysis. Computational Intelligence, 40(2):e12636, 2024. [37] Arshad Farhad, Sandra Woolley, and Peter Andras. Federated learning for ai to improve patient care using wearable and iomt sensors. In 2021 IEEE 9th International Conference on Healthcare Informatics (ICHI), pages 434–434, 2021. [38] Google Cloud. What is encryption?, 2025. Accessed: 2025-01-11. [39] Kha Dinh Duy, Taehyun Noh, Siwon Huh, and Hojoon Lee. Confidential machine learning computation in untrusted environments: A systems security perspective. IEEE Access, 9:168656–168677, 2021. [40] Abbas Acar, Hidayet Aksu, A. Selcuk Uluagac, and Mauro Conti. A survey on homomorphic encryption schemes: Theory and implementation. ACM Comput. Surv., 51(4), July 2018. [41] Reza Shokri, Marco Stronati, Cong Song, and Vitaly Shmatikov. Membership inference attacks against machine learning models. 2017 IEEE Symposium on Security and Privacy (SP), pages 3–18, 2017. Bibliography iv [42] Milad Nasr, Reza Shokri, Amir Houmansadr, James Nieh, and Dan Song. Membership inference attacks from first principles. In Proceedings of the 31st USENIX Security Symposium, pages 937–954, 2018. [43] Eugene Bagdasaryan, Omid Poursaeed, and Vitaly Shmatikov. Differential privacy has disparate impact on model accuracy. In Advances in Neural Information Processing Systems, volume 32, pages 15453–15462, 2019. [44] Victoria Ruiz-Serra, Nataly Busl´on, Olivier R. Philippe, Diego Saby, Mar´ıa Morales, Camila Pontes, Alejandro Mu˜noz Andirk´o, Gemma L. Holliday, Aina Jen´e, Mauricio Moldes, Jordi Rambla, Alfonso Valencia, Mar´ıa Jos´e Rementeria, Atia Cort´es, and Davide Cirillo. Analyzing sex imbalance in ega and dbgap biological databases: Recommendations for better practices. iScience, 27(10):110831, 2024. [45] H´eber Hwang Arcolezi, Karima Makhlouf, and Catuscia Palamidessi. Local differential privacy has no disparate impact on fairness. In Vijay Atluri and Anna Lisa Ferrara, editors, DBSec 2023 - 37th IFIP Annual Conference on Data and Applications Security and Privacy, pages 3–21, SOPHIA ANTIPOLIS, France, Jul 2023. [46] Rene Abraham, Johannes Schneider, and Jan vom Brocke. Data governance: A conceptual framework, structured review, and research agenda. International Journal of Information Management, 49:424–438, 2019. [47] Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daum´e III, and Kate Crawford. Datasheets for datasets, 2021. [48] Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daum´e III, and Kate Crawford. Datasheets for datasets. Commun. ACM, 64(12):86–92, November 2021. [49] Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru. Model cards for model reporting. In Proceedings of the Conference on Fairness, Accountability, and Transparency, FAT* ’19, page 220–229, New York, NY, USA, 2019. Association for Computing Machinery. [50] John T. Richards, David Piorkowski, Michael Hind, Stephanie Houde, Aleksandra Mojsilovic, and Kush R. Varshney. A human-centered methodology for creating ai factsheets. IEEE Data Eng. Bull., 44:47–58, 2021. [51] Gary S. Collins, Johannes B. Reitsma, Douglas G. Altman, and Karel G. M. Moons. Transparent reporting of a multivariable prediction model for individual prognosis or diagnosis (tripod): the tripod statement. BMC Medicine, 13:1, 2015. [52] Gary S Collins, Karel G M Moons, Paula Dhiman, Richard D Riley, Andrew L Beam, Ben Van Calster, Marzyeh Ghassemi, Xiaoxuan Liu, Johannes B Reitsma, Maarten van Smeden, Anne-Laure Boulesteix, Jennifer Catherine Camaradou, Leo Anthony Celi, Spiros Denaxas, Alastair K Denniston, Ben Glocker, Robert M Golub, Hugh Harvey, Georg Heinze, Michael M Hoffman, Andr´e Pascal Kengne, Emily Lam, Naomi Lee, Elizabeth W Loder, Lena Maier-Hein, Bilal A Mateen, Melissa D McCradden, Lauren Oakden-Rayner, Johan Ordish, Richard Parnell, Sherri Rose, Karandeep Singh, Laure Wynants, and Patricia Logullo. Tripod+ai statement: updated guidance for reporting clinical prediction models that use regression or machine learning methods. BMJ, 385, 2024. Bibliography v [53] European Data Protection Board. Ai auditing, 2024. [54] Banco Interamericano de Desarrollo. Quantilai: Algorithmic audit, 2023. [55] ACCA. A brief guide to internal auditing. Accessed: December 31, 2024. [56] Turnbull Review Group. Internal control: Guidance for directors on the combined code, 1999. Also known as the Turnbull Report. [57] Closing the ai accountability gap: defining an end-to-end framework for internal algorithmic auditin. 2020. [58] Oracle. What is data management? [59] Carly Strasser, Robert Cook, William Michener, and Amber Budden. Dataone best practices primer: primer on data management: what you always wanted to know, 2012. 11pp. DOI: http://dx.doi.org/10.25607/OBP-84. [60] FAIR Data and Services Working Group. Fair principles. [61] J. M. Wing. The data life cycle. Harvard Data Science Review, 1(1), 2019. [62] Tim Stobierski. The data life cycle: Processing. [63] P. et al. Chapman. Crisp-dm1.0 step-by-step data mining guide, 2009. Tech. Rep. [64] Harvard Medical School. The biomedical data lifecycle. [65] X. Wang and P. S. Yu. Data lifecycle management: An overview. IEEE Transactions on Knowledge and Data Engineering, 32(12):2339–2357, 2019. [66] Jeannette M. Wing. The data life cycle. [67] Julie Goldman. Research data management lifecycle checklist (pdf), 2024. Last updated on October 2, 2024. Part of Research Management Resources on OSF [https://osf.io/pw7ed]. [68] Evren Eryurek, Uri Gilad, Valliappa Lakshmanan, Anita Kibunguchy-Grant, and Jessi Ashdown. Chapter 4: [data governance over a data life cycle]. In Data Governance: The Definitive Guide. O’Reilly, 2021. [69] European Parliament and Council of the European Union. Regulation (EU) 2016/679 of the European Parliament and of the Council. [70] European Parliament and Council of the European Union. Regulation (EU) 2023/1234 of the European Parliament and of the Council. [71] General data protection regulation (gdpr). Online, n.d. Accessed: 2025-01-17. [72] Bloomberg Law. Gdpr program checklist, ND. Accessed: 2025-01-11. [73] David Erdos. European Data Protection Regulation, Journalism, and Traditional Publishers: Balancing on a Tightrope? Oxford University Press, 12 2019. [74] Padris - programa d’anal´ıtica de dades per a la recerca i la innovaci´o en salut. Online. Accessed: 2025-01-17. Bibliography vi [75] Ai act enters into force. Online, 2024. Accessed: 2025-01-17. [76] Artificial intelligence act: Council gives final green light to the first worldwide rules on ai. Online Press Release, 2024. Accessed: 2025-01-17. [77] Artificial intelligence - european council policies. Online, n.d. Accessed: 2025-01-17. [78] High-level summary of the artificial intelligence act. Online, n.d. Accessed: 2025-01-17. [79] Zachary Elkins, Tom Ginsburg, and James Melton. Constitute: The world’s constitutions to read, search, and compare. Online at https://www.constituteproject.org. Accessed January 5, 2025. [80] EPS SURA. Article on eps sura, n.d. Accessed: 2025-01-19. [81] Proyecto de ley 154 de 2024 de la rep´ublica de colombia. [82] Proyecto de ley 005 de 2024 de la rep´ublica de colombia. [83] Proyecto de ley 130 de 2023 de la rep´ublica de colombia. [84] Proyecto de ley 91 de 2023 de la rep´ublica de colombia. [85] Proyecto de ley 59 de 2023 de la rep´ublica de colombia. [86] Proyecto de ley 447 de 2024 de la rep´ublica de colombia. [87] Santiago Marimon-Su˜nol, Mar´ıa Rovira-Barber`a, Mateo Acedo-Anta, Montserrat A. NozalBaldajos, and Joan Guanyabens-Calvet. Historia cl´ınica compartida en catalu˜na. Medicina Cl´ınica, 134:45–48, 2010. [88] Maxwell Prybylo, Sara Haghighi, Sai Teja Peddinti, and Sepideh Ghanavati. Evaluating privacy perceptions, experience, and behavior of software development teams, 2024. [89] NASA. What are quality flags (qa), what do they mean, and where can i find them?, n.d. Accessed: 2025-01-19. [90] Future AI. The Future AI Ethical Checklist, n.d. Accessed: 2025-01-19. [91] The Institute of Internal Auditors (IIA). About internal audit, 2025. Accessed: 2025-01-15. Annex I: Catalan Regulation on Medical Records Taken from [20] the following is a list of relevant laws regarding medical records in Catalunya. •Reglamento (UE) 2016/679 del Parlamento y del Consejo, de 27 de abril de 2016, relativo a la protecci´on de las personas f´ısicas en lo que respecta al tratamiento de datos personales y a la libre circulaci´on de dichos datos, y por el que se deroga la Directiva 95/46/CE (Reglamento General de Protecci´on de Datos). •Ley Org´anica 3/2018, de 5 de diciembre, de Protecci´on de Datos de Car´acter Personal y garant´ıa de los derechos digitales. •Ley Org´anica 1/1982, de 5 de mayo, de protecci´on civil del derecho al honor, a la intimidad personal y familiar y a la propia imagen. •Ley Org´anica 10/1995, de 23 de noviembre, del C´odigo Penal. •Ley Org´anica 3/1986, de 14 de abril, de Medidas Especiales en el ´ Ambito de la Salud P´ublica. •Ley 21/2000, de 29 de diciembre, sobre los derechos de informaci´on concerniente a la salud y la autonom´ıa del paciente, y a la documentaci´on cl´ınica. •Ley 41/2002, de 14 de noviembre, b´asica reguladora de la autonom´ıa del paciente y de derechos y obligaciones en materia de informaci´on y documentaci´on cl´ınica. •Ley 25/2010, de 29 de julio, del segundo libro del C´odigo civil de Catalu˜na, relativo a la persona y la familia. •Ley 14/2010, de 27 de mayo, de los derechos y las oportunidades en la infancia y la adolescencia. •Ley 14/2007, de 3 de julio, de Investigaci´on Biom´edica. •Ley 31/1995, de 8 de noviembre, de prevenci´on de Riesgos Laborales. •Ley 19/2015, de 13 de julio, de medidas de reforma administrativa en el ´ambito de la Administraci´on de Justicia y del Registro Civil. •Ley 14/2006, de 26 de mayo, sobre t´ecnicas de reproducci´on humana asistida. •Ley 2/1974, de 13 de febrero, sobre Colegios Profesionales. vii Bibliography viii •Ley 7/2006, de 31 de mayo, del ejercicio de profesiones tituladas y de los colegios profesionales. •Ley 14/1986, de 25 de abril, General de Sanidad. •Ley 33/2011, de 4 de octubre, General de Salud P´ublica. •Ley 18/2009, del 22 de octubre, de salud p´ublica. •Ley 15/1990, de 9 de julio, de ordenaci´on sanitaria en Catalu˜na. •Real Decreto Legislativo 2/2015, de 23 de octubre, por el que se aprueba el texto refundido de la Ley del Estatuto de los Trabajadores. •Real Decreto Legislativo 5/2015, de 30 de octubre, por el que se aprueba el texto refundido de la Ley del Estatuto B´asico del Empleado P´ublico. •Real Decreto 190/1996, de 9 de febrero, por el que se aprueba el Reglamento Penitenciario. •Decreto 203/2015, de 15 de septiembre, por el que se crea la Red de Vigilancia Epidemiol´ogica y se regulan los sistemas de notificaci´on de enfermedades de declaraci´on obligatoria y brotes epid´emicos. •Decreto 169/2015, de 21 de julio, por el que se establece el procedimiento para facilitar el conocimiento de los or´ıgenes biol´ogicos. •Orden SSI/81/2017, de 19 de enero, por la que se publica el Acuerdo de la Comisi´on de Recursos Humanos del Sistema Nacional de Salud, por la que se aprueba el protocolo mediante el que se determinan pautas b´asicas destinadas a asegurar y proteger el derecho a la intimidad del paciente por los alumnos y residentes en Ciencias de la Salud. Annex II: Colombian Regulation on Medical Records List of relevant laws regarding medical records in Colombia by their titles in Spanish. Legal Instrument Number Year Article Title Constituci´on Pol´ıtica de Colombia N.A 1991 15 T´ıtulo 2. De los derechos, garant´ıas y deberes. Cap´ıtulo 1: De los derechos fundamentales, art´ıculo 15: Derecho a la intimidad Ley 23 1981 ´ Etica m´edica. Cap´ıtulo III: De la prescripci´on m´edica, la historia cl´ınica, el secreto profesional y algunas conductas Ley 527 1999 Sobre comercio electr´onico Resoluci´on 1995 1999 Norma para el manejo de historia cl´ınica, los anexos a ella y el consentimiento informado Ley 594 2000 Incorpora todos los acuerdos promulgados por el Archivo General de la Naci´on Resoluci´on 3374 2000 Minsalud establece los datos b´asicos relevantes que deben generar los prestadores de salud Ley 594 2000 Se establecen las reglas y principios generales que regulan la funci´on archiv´ıstica del Estado Decreto 2200 2005 En su cap´ıtulo IV: Prescripci´on de medicamentos Resoluci´on 2346 2007 Minsalud regula la pr´actica de evaluaciones m´edicas ocupacionales y el contenido de sus historias cl´ınicas ix Bibliography x Legal Instrument Number Year Article Title Resoluci´on 1918 2009 Minsalud modifica los art´ıculos 11 y 17 de la resoluci´on 2346 de 2007 en cuanto a la contrataci´on de servicios de evaluaci´on m´edica ocupacional y la custodia y entrega de las evaluaciones m´edicas e historias cl´ınicas ocupacionales Ley 1581 2012 Normas generales para protecci´on de datos personales Decreto 2364 2012 Reglamenta el art´ıculo 7 de la ley 527 de 1999 referido a la firma electr´onica Ley 1712 2014 Ley de transparencia y del derecho de acceso a la informaci´on p´ublica nacional Ley 1955 2019 246 Plan Nacional de Desarrollo 2019-2022. Interoperatividad historia cl´ınica Resoluci´on 2003 2014 Minsalud establece los procedimientos y condiciones de inscripci´on y habilitaci´on de los prestadores de servicios de salud Decreto 1074 2015 ´ Unica reglamentaria del sector comercio, industria y turismo, cap´ıtulo 25 del t´ıtulo 2 y la parte 2 Decreto 1080 2015 2.8.2.5.1 al 2.8.2.8.3 T´ıtulo 2, cap´ıtulo V, gesti´on de documentos. Obliga a las entidades privadas que presten servicios de car´acter p´ublico y a las entidades p´ublicas Resoluci´on 839 2017 Establece el manejo, custodia, tiempo de retenci´on, conservaci´on y disposici´on final de las historias cl´ınicas, as´ı como los manejos que se deben dar en el Sistema General de Seguridad Social en Salud, en caso de liquidaci´on de alguna de sus entidades Bibliography xi Legal Instrument Number Year Article Title Ley 2015 2020 Por la cual se crea la historia cl´ınica electr´onica interoperable y se obliga a los prestadores de servicios de salud a diligenciar y disponer los datos, documentos y expedientes de la historia cl´ınica en la plataforma de interoperatividad que disponga el Gobierno Nacional Resoluci´on 866 2021 Minsalud reglamenta el conjunto de elementos de datos cl´ınicos relevantes para la interoperatividad de las historias cl´ınicas electr´onicas Plan de trabajo N.A 2023 Minsalud establece el proceso de despliegue del plan de interoperatividad de las historias cl´ınicas de manera escalar, modular y por fases Lineamiento diagn´ostico TIC N.A 2023 Diagn´ostico de las capacidades TIC en recursos tecnol´ogicos, humanos y de procesos en los prestadores de servicios de salud Plan de trabajo N.A 2023 Plan de adopci´on territorial de la interoperatividad de la historia cl´ınica electr´onica (IHCE) Plan de trabajo territorial N.A 2023 Lineamientos para la formulaci´on del plan territorial de interoperatividad de historias cl´ınicas electr´onicas (IHCE) Plan de trabajo N.A 2023 Lineamientos t´ecnicos para la operaci´on Consulta p´ublica N.A 2023 Recibo de propuestas y observaciones de la comunidad