Introduction

The objective of this report is to present the results of the privacy impact assessment (EFVP) for the PACS AI application. We identify all personal information that may be collected, used, stored, or disclosed by PACS AI, and provide an analysis of the various legal criteria that apply to this personal information. We also offer a list of recommendations that would propose solutions to minimize privacy risks that PACS AI could create, and the follow-up done to date to address these recommendations (see tables 3.6 and 3.7).

This report is divided into 4 main sections:

• First, we describe the method we used to carry out this EFVP and the documents on which we relied to develop this method. We also explain the scope of our analysis.
• Next, we present the PACS AI platform by describing its objectives and explaining how it operates. We also identify the stakeholders.
• Third, we present the results of the analysis and the measures we have taken to ensure the best protection of patients' personal information.
• Finally, we establish a strategy and timeline for future EFVPs, based on the main anticipated developments of PACS AI.

1. Working method and scope of the assessment

To carry out this EFVP, we held a series of meetings with the PACS AI research and development team in spring 2024 and winter 2025. The objective was to gain a thorough understanding of the application's operation, to inventory the personal information collected, and to map the main personal information processing flows of the application. We determined which types of information—personal or not—were collected, used, stored, and disclosed by PACS AI, for what purposes, by whom, and at what times. We also determined retention periods and modes of access to personal information. These meetings led to a productive dialogue resulting in a few minor proposed changes to PACS AI's design. We will return to these.

As part of our analysis, we also conducted a workshop during the Conference on Privacy, Computers and Data Protection in June 2024. We presented PACS AI to a group of 12 privacy law experts to better identify the privacy risks the current PACS AI design could pose and to identify possible solutions to properly address those risks.

To prepare these workshops and working meetings, as well as this EFVP, we relied on relevant documents from the Commission d’accès à l’information, specifically its guide “Conducting a Privacy Impact Assessment,” as well as tools developed by the Office of the Privacy Commissioner of Canada. We also consulted the Government of Canada’s Directive on Privacy Impact Assessment. Although the latter does not apply to PACS AI, we drew inspiration from it to build the analysis, develop our questions, and refine the report structure.

With respect to the scope of our analysis, it focuses exclusively on the collection, use, disclosure, and retention of patients' personal information by PACS AI. Two main components are therefore excluded from the analysis. First, we do not analyse the digital environment in which PACS AI is deployed, i.e., the hospital intranet. In our view, doing so would significantly broaden the scope of our analysis and we do not have access to the information required to conduct such an analysis. Second, we do not examine the privacy impact of collecting, using, or disclosing personal information about the healthcare professionals who will use PACS AI. We will, of course, consider these actors with regard to access management to PACS AI, but we exclude any analysis of the potential impact on their workplace privacy from processing their personal information. Again, our primary objective is to focus on PACS AI's impact on the privacy rights of patients and users of the health system.

This finalized assessment primarily has an internal purpose: enabling the research team to fully understand the privacy issues PACS AI may raise. It is a project-level assessment and does not replace the institution-specific EFVP required of teams, managers, or directors who deploy PACS AI. It may serve as a basis for those evaluations, and all adopting institutions remain responsible for conducting their own EFVP.

2. Description of the PACS AI platform

2.1. PACS AI development context

PACS AI is a medical imaging application developed as part of a research project led by the CIFAR health solutions network “AI integrated for medical imaging.” This project is funded by CIFAR and IVADO for the 2023–2026 period and is led by Dr. Robert Avram of the Montreal Heart Institute.

2.2. Objectives and purposes of PACS AI

PACS AI is a digital application whose objective is to allow healthcare professionals to access inferences generated by artificial intelligence tools from images stored in a PACS. A PACS is a secure image archiving and communication system used by healthcare professionals to store and view medical images and reports. PACS systems are used in the majority of hospitals in Quebec, Canada, and around the world. PACS AI can be seen as a lens that enables consultation and analysis of images in the PACS through various AI models that generate inferences. It is therefore a decision-support tool whose ultimate goal is to contribute to improved patient care and health outcomes.

2.3. How PACS AI operates

Table 1 below presents a mapping of the interactions between actors and the main components of the PACS AI platform. We provide a description of each of these components here to explain the platform's mode of operation. The table and descriptions were produced based on documents provided by Dr. Avram and his team.

• Hospital intranet: this is a secure network within the hospital, protected by a Virtual Private Network (VPN) and a firewall to ensure the confidentiality, integrity, and availability of data and personal information. Only hospital employees or those with a VPN token (issued by the government for remote access) can access the network. Information transmitted via this VPN connection is encrypted to ensure increased security of informational exchanges. The PACS AI application, represented here by the turquoise rectangle, is fully hosted within the hospital intranet.
• Healthcare professionals: this refers to the users who interact with the PACS AI web interface via a secure HTTPS connection, indicating that data transmission is encrypted. The hospital's IT system acts as the Certification Authority (CA) and is responsible for issuing, maintaining, and validating the TLS certificates used by PACS AI.
• Application API (HTTPS): this component serves as the access point allowing healthcare professionals to send requests to PACS AI services. The use of HTTPS means communication is secured. The API receives POST requests from healthcare professionals and forwards them to the PACS AI application. This is the application's only entry point, often called the ingress point. After a user authenticates with Firebase Authentication, the client exchanges the resulting Firebase ID token with the backend at POST /v1/iam/login for a PACS AI session token. The API gateway also interacts with other components such as Elasticsearch, the data preprocessing service, and the local PACS.
• Elasticsearch audit service: this component indexes audit logs (access times to PACS resources, information related to inferences such as what each user does in the application, when, and by whom) and allows monitoring and analysis of system use. Elasticsearch interacts with Kibana.
• Kibana audit viewer: this component is the analysis and visualization platform that allows viewing of audit traces and logs recorded by Elasticsearch. Communication between Elasticsearch and Kibana occurs over HTTPS and uses TLS certificates validated, managed, and issued by the hospital IT team acting as the Certification Authority (CA). Separate login credentials and passwords are used (defined as environment variables at build time) to access Kibana.
• Data preparation: this service is responsible for preparing data for subsequent analysis by AI models. Preparation may include cleaning, normalization, and transformation of data. AI operations are recorded/indexed in the Elasticsearch service.
• Local PACS: the local PACS is a local storage area for medical images. It provides DICOM query/retrieve (Q/R) capabilities and interacts directly with the hospital PACS using DICOM Q/R operations (C-FIND, C-MOVE, etc.). When an AI inference is requested by the client, DICOM data are moved from the hospital PACS to the local PACS within the application. The data are stored locally in the application for 24 hours in an S3-compatible storage format. Data are encrypted using an encryption key to ensure data security.
• Hospital PACS: this is the typical hospital PACS and acts as the image archiving and communication system used to store and manage radiological images and associated medical data. PACS AI is compatible with any PACS interface and is vendor-agnostic. This means it can operate with various PACS systems from different vendors without interoperability issues.
• AI inference services: this component refers to a set of services comprising different machine learning model servers such as TensorFlow Serving, Caffe2, and TorchServe. These services receive input data—medical images—perform computations, and return inference results as predictions. They do not retain any data, as they only process it.
• Firebase Authentication service: this is an external Internet-accessible authentication mechanism operated by Google and used to validate user credentials before granting access to the PACS AI application. Users sign in with an email address and password, and accounts are separated using Firebase's tenant feature. Communication with Firebase is performed via HTTPS. Only authentication data is processed by Firebase; no medical images, personal health information, AI outputs, or agent conversations are transmitted to this service.
• Hugging Face / model hosting: this is the mechanism for hosting and managing different versions of AI inference models used by PACS AI. Communication is over HTTPS and is unidirectional. During application build and startup on the cluster, automated scripts are executed to fetch the latest versions of AI models from Hugging Face. The PACS AI application never sends data to Hugging Face; the only data stored on Hugging Face are model architectures and weights, which are free of personal health information.

3. Results of the analysis

3.1 Legal requirements and necessity of the EFVP

This section presents the analysis results of the first EFVP conducted on PACS AI. The decision to carry out an EFVP stems both from our team's desire to ensure maximal protection of patients' privacy rights whose personal information will be processed by PACS AI, and from obligations arising from certain legal provisions that apply to the platform. Indeed, the Act on Health and Social Services Information (hereinafter, the LRSSS), which came into force in July 2024 and applies to health or social services organizations, provides that a public body must:

carry out a privacy impact assessment of any project to acquire, develop or redesign technological products or services or an electronic service delivery system when that project involves the collection, retention, use, disclosure or destruction of information it holds.

Since PACS AI is an information system that involves the processing of personal information, and since PACS AI would be deployed within healthcare institutions, we consider that an EFVP will be necessary for institutions wishing to adopt it. The LRSSS specifies that the EFVP must be conducted by the public body. We consider, however, that this initial analysis will, where appropriate, represent a good starting point. Also, because the EFVP must "be proportionate to the sensitivity of the information involved, to the purpose of its use, to its quantity, distribution and medium," and because we are dealing here with digital health personal information, we consider that our EFVP must be thorough and exacting.

3.2 Summary of results

PACS AI collects and uses particularly sensitive health personal information. The processing of this personal information is fully compliant with the applicable legal requirements in this case and presents only low risks of privacy harm. The main reasons supporting this conclusion are: (1) the presence of explicit consent to the use of PACS AI and the AI features that implies, (2) the significant security measures deployed to ensure the confidentiality of the information collected and the management of access to PACS AI, and (3) the short retention periods for personal information generated from these data. The principal residual privacy consideration is the use of Firebase Authentication, an external Google service that processes limited authentication data in the United States. No medical images, personal health information, AI outputs, or agent conversations are transmitted to Firebase. Access is tenant-separated, token exchanges use HTTPS, and PACS AI records and monitors platform access and activity. The recommendations and their implementation status are set out in sections 3.6 and 3.7.

3.3 Inventory and classification of personal information involved

PACS AI collects, uses, discloses and retains two main types of personal information. In both cases, these are health information within the meaning of the Act on Health and Social Services Information, insofar as they concern, in particular, "the person's physical or mental health status and its determinants, including the person's medical or family history." In both cases, this information is also particularly sensitive.

• Medical images: The first group of health information consists of the medical images collected by PACS AI for analysis. These images may take the form of a CT scan, an ultrasound or a coronary angiography, for example. As described in section 2.3, these images are initially stored in the hospital PACS, from where they are collected by PACS AI. It is important to emphasize that the images are not generated by PACS AI; they are images already produced as the result of medical decisions independent of PACS AI. PACS AI only enables analysis of existing images using AI models to generate predictions — which constitute our second group. It should also be noted that medical images include metadata that follow the DICOM standard. This standard contains a library of several dozen attributes that may also be considered personal information. These can include, for example, the patient's name and unique identifier, sex, image creation date or religious beliefs. It is equally important to note that not all these entries are necessarily filled in, but they may be. We will return to these metadata later when discussing the collection limitation principle and the necessity criterion.
• Predictions generated by PACS AI: The second group of health information consists of the inferences generated by PACS AI by means of AI models applied to the medical images collected in the PACS. The generation of an inference about a person is considered by Quebec case law to be a collection of personal information.

3.4 Mapping of personal information

In this subsection, we present a mapping of the personal information used by PACS AI. The goal is to describe it throughout its lifecycle, notably by explaining its distribution and storage medium. We refer here to Table 1 above to illustrate our points.

As described in subsection 3.3, the first personal information that PACS AI collects are the digital medical imaging files located in the hospital PACS. We recall that these images are not produced or generated by PACS AI; they are in the hospital PACS following tests performed based on medical decisions independent of PACS AI. PACS AI only allows consultation of these images and the application of AI models to them. We will return to this.

Only authorized healthcare professionals have access to PACS AI. This restriction is important because access to PACS AI provides access to the hospital PACS. User authentication is managed with Firebase Authentication using email-and-password sign-in and tenant separation. The Firebase ID token is exchanged with the PACS AI backend for a session token.

When a healthcare professional requests an inference via PACS AI, the targeted image is moved from the hospital PACS to the application's local PACS. Queried medical images are stored locally in the application for 24 hours in an S3-compatible storage format, after which they are deleted. Data are encrypted using a key that ensures their protection. PACS AI may then prepare the image for inference. The inference results are displayed on screen but are not recorded in the PACS or in the patient's medical record at the source of the image. If a clinician wishes to obtain the prediction again, they must repeat the inference process. The prediction is stored in Elasticsearch and accessible to the PACS AI team via Kibana. Healthcare professionals do not have access to this personal information. Inferences are retained indefinitely to monitor PACS AI's effectiveness and to detect possible errors in the AI inference models.

3.5 Identification of privacy-related factors

In this subsection, we identify the various privacy-related factors of PACS AI. We address factors related to compliance with legal obligations and privacy risk simultaneously. We also make a number of recommendations to ensure better legal compliance and to reduce privacy risks.

• Accountability principle: Under the accountability principle, organizations that collect, use, disclose or retain personal information are accountable for their management of that information. To comply with this principle, they must prepare and publish privacy policies and practices specific to the protection of the personal information they manage and make the necessary efforts to maximize that protection. This EFVP provided the necessary basis for preparing those policies and documenting the efforts made to ensure maximal protection of the personal information the application processes.
• Recommendation #1: Prepare and publish PACS AI's privacy policy once the EFVP is completed. (Recommendation followed, see table 3.7)
• Purpose specification principle: Under this principle, organizations must collect personal information only for purposes that are legitimate and related to the fulfillment of their mission. PACS AI is a decision-support tool for healthcare professionals. Ultimately, its purpose is to support clinicians and contribute to improving patient health. In our view, this is a legitimate purpose consistent with the mandate of the health organizations in which PACS AI is deployed.
• Collection limitation principle: The limitation principle requires organizations to collect only the personal information necessary to achieve the purposes that justify the collection. As noted above, PACS AI collects two groups of health personal information: medical images and AI-generated inferences. The medical images themselves are necessary to generate predictions. However, it would be important to question the necessity of the metadata and the possibility of not collecting them. Would it be possible to export only the metadata necessary for inference? This must be verified. Furthermore, the predictions also meet the necessity principle insofar as they are the application's very product. They are necessary to PACS AI because they represent its raison d'être. Moreover, the predictions disclose nothing other than information relating to the person's health, and only in response to clinicians' queries.
• Recommendation #2: Verify the necessity of collecting DICOM metadata to generate inferences. (Recommendation partially followed, see table 3.7)
• Consent principle: The consent principle is fundamental because it allows patients to exercise control over how their personal information circulates and is disclosed. Consent must be explicit, free, informed and given for specific purposes. In the case of PACS AI, consent would be obtained at the medical examination that leads to the creation of the image. Before undergoing such an exam, patients must already consent to image capture and its interpretation. Since PACS AI allows subsequent analysis of the image, it seems desirable and logical to build on this initial consent. Under the Commission d’accès à l’information guidelines on consent, consent must be granular, meaning it must "allow individuals to express their agreement or disagreement separately, and for each purpose." We therefore believe it would be desirable to inform patients that the image may be collected and analyzed by AI techniques by adding a specific purpose to the initial consent form and obtaining explicit consent for the use of personal information for these purposes. This can simply be an additional checkbox. By adding this purpose, PACS AI would also comply with the provision of the LSRRR regarding profiling, which we address next.
• Privacy by design and by default: The LSRRR requires organizations using technologies with identification, localization or profiling functions to inform individuals of the use of these technologies and to offer them the means to enable these functions. The law thus implies that identification, localization and profiling functions should be disabled by default. Explicit consent must therefore be obtained for this purpose. PACS AI is a platform that enables profiling as defined by the law, i.e., "the collection and use of information to evaluate certain characteristics of a natural person, notably for the analysis of that person's economic situation, health, personal preferences, interests or behaviour." Consequently, and linked to point 4, we believe the consent form used when collecting the medical image should explicitly include PACS AI usage and obtain explicit consent for its use.
• Recommendation #3: Add to the consent form provided at the time of medical image creation a clear statement that AI techniques may be used for analysis and decision support, and obtain explicit consent for this use.
• Limitation on use, disclosure and retention: Whether medical images or generated inferences, the information collected by PACS AI is used and disclosed only for the original purposes. No secondary use is envisaged. Regarding disclosure, PACS AI does not disclose personal information. This point, however, requires clarification. The fact that PACS AI uses AI models that come from an external service — Hugging Face — could raise concerns. It is important to clarify two things. First, AI models are downloaded and used within the PACS AI application. Personal information is never sent to the external service for analysis; data do not leave PACS AI. The link with Hugging Face is only to find and download the latest model versions. Second, no model training is performed on the medical images. When a model is trained on data, those data remain to some extent embedded in the model, which can lead to inference attacks where a third party attempts to recover training data. Thus, sharing AI models can cause risks of unauthorized disclosure of personal information. Here, because models are not trained on data collected by PACS AI, these risks are neutralized. On retention, two points should be made. First, images collected by PACS AI remain in the application only for a maximum of 24 hours, after which they are deleted. We have not yet addressed the question of the means used to ensure responsible and effective destruction of these data, which could be discussed later. Second, PACS AI's generated inferences are not stored in the application: they are displayed on the clinician's screen and then in Elasticsearch for an indefinite period. Here too, it may be useful to establish a destruction schedule. Do we need to keep them indefinitely? Can we anonymize them as required by law?
• Recommendation #4: Discuss modalities for destroying images collected by PACS AI and stored for 24 hours in the local PACS. (Recommendation followed, see table 3.7)
• Recommendation #5: Discuss modalities for storing inferences and establish a destruction or anonymization schedule for this personal information. (Recommendation followed with reservations, see table 3.7)
• Accuracy: The images collected by PACS AI are accurate and up to date insofar as they originate from medical exams performed within the hospital. Regarding inferences, they are generated by AI models and are not required to be strictly 'accurate'; they serve as decision support for clinicians. However, due to automation bias that a platform like PACS AI can induce, it may be relevant to clarify how models are chosen or used by clinicians. Are models identified by the PACS AI team or can each hospital choose which models to integrate? This question is not trivial as it relates to the accountability principle.
• Recommendation #6: We believe it may be important to discuss the model selection modalities and the measures taken to anticipate selection biases that PACS AI could introduce.
• Security: Images processed by PACS AI are highly sensitive, which means the deployed security measures to protect them must be particularly strong. Information security is implemented both technically and organizationally. PACS AI is deployed within the hospital's secure intranet, and communications to and from the application use HTTPS. Medical images, personal health information, AI outputs, and agent conversations remain within the institution's infrastructure and are not transmitted to Firebase. User authentication is performed through Firebase Authentication using email-and-password sign-in and tenant separation. Firebase Authentication processes limited authentication data in the United States under the applicable Google/Firebase contractual terms. A Firebase ID token is exchanged over HTTPS with the PACS AI backend for a session token. Images stored in the local PACS are encrypted, and Elasticsearch is hosted locally within the institution's secure environment with encryption at rest and in transit. PACS AI also maintains detailed access and activity logs in Elasticsearch, viewable through Kibana by authorized administrators or compliance officers.
• Recommendation #7: Clarify the security mode and storage format for inferences in Elasticsearch. If necessary, find a more secure storage method. (Recommendation followed, see table 3.7)
• Recommendation #8: Implement access management for PACS AI via a service located within the hospital intranet. (Recommendation followed, see table 3.7)
• Recommendation #9: Ensure more precise monitoring and surveillance of activity on PACS AI: who logged in, when, what actions were taken, etc. (Recommendation followed, see table 3.7)
• Recommendation #10: Adopt a clear access policy for PACS AI. (Recommendation partially followed, see table 3.7)
• Transparency: To comply with the transparency principle, certain steps must follow this EFVP. First, in accordance with Recommendation #3, additional information must be provided to patients to obtain the consent referred to. Second, the EFVP results must be made available to hospital managers, patients and researchers who wish to use PACS AI. Third, the PACS AI privacy policy must be published and include the schedules and policies referred to in Recommendations #5 and #10.
• Data subject rights: This point may also deserve discussion with the team. Should patients have access to the inference? Should the inference be automatically recorded in the patient record to respect their right of access? Or does the temporary, nearly ephemeral nature of the inference provide better protection? These different options should be the subject of serious discussions within the team.
• Recommendation #11: Evaluate the possibility of keeping a more concrete record of inferences to promote patients' right of access. (Recommendation partially followed, see table 3.7)

3.6 Table of recommendations

3.7 Table of updated recommendations

4. Schedule and contact person

An EFVP is an evolving process. Therefore, we must schedule when it will be reviewed. The PACS AI project is currently funded until summer 2026. Two working meetings with the entire team are planned each year. We consider these meetings as opportunities to review privacy issues, taking into account legal and technological developments. In short, there will be 2 updates per year.

For privacy-related questions, contact Pierre-Luc Déziel, Professor, Faculty of Law, Laval University: [email protected]