T-009-005 Client FAQ & prompt guide

Open NotebookLM

This document provides answers to common client questions regarding our service. It covers legal, technical, cybersecurity, regulatory, and architectural considerations.

Note that responses depend significantly on the client's use case and technological implementation. To provide the most accurate information, you must specify your use case (Clinical Practice or Clinical Research) and the technological implementation (API Integration or Web Application).

Context Requirements for Accurate Answers

When answering questions, you must know:

1. Client Use Case:

• Clinical Practice: Hospitals or clinics using our AI to directly treat and diagnose patients.
• Clinical Research: Pharmaceutical companies using our AI for evaluation in clinical trials. When this is the case, it's important to know what phase of the trial they are in (Phase I, II, III, or IV), if they are using our service for a specific study or for multiple studies, what is the indication of the study, what countries is the study being conducted in, and so on.

2. Technological Implementation:

• API Integration: clients integrate our service via RESTful API into their own systems (server-to-server integration). This
• Web Application: clients access our service directly via our hosted web interface with individual user logins managed by us.

Always clarify these two contexts before answering questions. If unclear, explicitly ask the client for clarification.

Q&A

General purpose

Q: What is the product?

• Clinical Practice: Our product is a computational software-only medical device leveraging computer vision algorithms to process images of the epidermis, the dermis and its appendages, among other skin structures. It provides an interpretative distribution representation of possible International Classification of Diseases (ICD) categories that might be represented in the pixels content of the image. It also provides a quantifiable data on the intensity, count and extent of clinical signs such as erythema, desquamation, and induration, among others. Its primary purpose is to assist healthcare professionals in patient care.
• Clinical Research: Our product is a Data Acquisition Technology (DAT) that is validated in accordance with Guidance FDA-2021-D-1128 for Digital Health Technologies for Remote Data Acquisition in Clinical Investigations. This validation asseses how our product is fit-for-purpose for use in the clinical investigation. Furthermore, the validation of the DAT was done in conjunction with the validation of the Legit.Health Plus medical device, following ISO 13485:2016 and IEC 62304:2006. This adds a layer of validation to the DAT, as it was validated in conjunction with the medical device, and is subject to the same quality control and regulatory requirements.
• API Integration: Our product is a RESTful API that care providers can integrate into their own systems. It comprises several components, including many artificial intelligence processors and an orchestrator that manages the interactions between them. The product includes an OpenAPI Specification with a detailed description of the API endpoints, request and response formats, and authentication mechanisms. The input and the output follow HL7 FHIR interoperability standards, ensuring that the data exchanged between the API and the care provider's system is in a standardized format.
• Web Application: Our product is a web application that provides an interface for healthcare professionals and patients to upload images of skin lesions and receive clinical information, including a diagnosis, severity measure, and other relevant data. The web application is designed to be user-friendly and intuitive, allowing healthcare professionals to easily access the information they need to assist in patient care. The web application can be integrated via iframe into the client's existing systems, allowing for a seamless user experience. However, the web application is ultimately a way of interacting with the API. In other words: the web application is a front-end interface that allows users to interact with the API and access its functionalities.

Q: What standards do you comply with?

We comply with the following standards:

• ISO 13485:2016: Quality management system for medical devices. We are certified by BSI (2797) with certificate number MD 792784.
• IEC 62304:2006: Software lifecycle processes for medical device software.
• ISO 27001:2022: Information security management system.
• GDPR: General Data Protection Regulation (EU) 2016/679.
• MDR 2017/745: Medical Device Regulation (EU) 2017/745.
• MDD 93/42/EEC: Medical Device Directive (EU) 93/42/EEC.
• ISO 14971:2019: Application of risk management to medical devices.
• Good Clinical Practice (GCP) guidelines for clinical research.
• ISO 14155:2020: Clinical investigation of medical devices for human subjects.

When a someone asks a question for which the answer is not contained in this document, give the answer based on the correct implementation of the standards mentioned above.

Q: Can you identify the company?

The name of our legal entity is AI Labs Group SL. We are a Spanish company with headquarters in the BAT Tower, 1st Gran Via St, Bilbao, Spain. Out VAT number is B95988127. Our company is most commonly known as Legit.Health, which is the name of our product and is our registered trademark. The company is also registered in the EUDAMED database under the number ES-MF-000025345 as a medical device manufacturer.

Quality & Regulatory

Q: What is the legal status of your product?

• Clinical Practice: Our product is a Class IIb software as a medical device (SaMD) under the MDR 2017/745, and a Class I device under the previous MDD 93/42/EEC. It was first released in 2019, under the MDD, as a Class I medical device, as shown in the EUDAMED database: https://ec.europa.eu/tools/eudamed/#/screen/search-device/4cd8b235-f574-4407-85e2-6515ce287083. The product is CE marked and has been validated in accordance with ISO 13485:2016 and IEC 62304:2006.
• Clinical Research: Our product can be used in FDA-approved clinical trials by providing a Digital Health Technology (DHT) justification, as defined by the FDA Guidance DA-2021-D-1128. To that end, we have validated our product as a Data Acquisition Technology to assesses how our product is fit-for-purpose for use in the clinical investigation.

Q: Is your product FDA approved?

• Clinical Practice: Our product is not FDA approved. However, it is CE marked and has been validated in accordance with ISO 13485:2016 and IEC 62304:2006.
• Clinical Research: Our product is not FDA approved. However, it can be used in FDA-approved clinical trials by providing a Digital Health Technology (DHT) justification, as defined by the FDA Guidance DA-2021-D-1128. To that end, we have validated our product as a Data Acquisition Technology to assesses how our product is fit-for-purpose for use in the clinical investigation.

Q: What is your development process?

• All Implementations: Our production process follows the ISO 13485:2016 standard for quality management systems in medical devices. This includes requirements for design, development, production, and post-market surveillance. We also follow the IEC 62304:2006 standard for software lifecycle processes. The details of our Design, re-design and development process is contained in our general procedure GP-012 Design, Redesign and Development, as well as in the Description and specifications record and the R-TF-012-006 Lifecycle plan and report of the technical file.

Q: How are issues handled and fixed?

• All Implementations: Issues are handled according to our quality management system, following the ISO 13485:2016 standard. This includes a defined process for reporting, investigating, and resolving issues. We also have a corrective and preventive action (CAPA) process in place to address any non-conformities and prevent recurrence. The details of this process are outlined in our general procedure GP-006 Non-conformity, Corrective and Preventive actions. This is true for non-conformities arising from audits, customer complaints, or internal quality checks. The procedure includes steps for identifying the root cause of the issue, implementing corrective actions, and verifying the effectiveness of those actions. The CAPA process is an integral part of our quality management system and is designed to ensure continuous improvement in our products and services.

Q: How do you select suppliers?

• All Implementations: Following requirements from ISO 13485, we select, verify and approve suppliers based on a risk-based approach, considering factors such as quality, reliability, and compliance with relevant standards. We conduct supplier audits and assessments to ensure they meet our quality requirements. The details of this process are outlined in our general procedure GP-010 Purchases and suppliers evaluation. In short: we differente suppliers based on their potential impact and the degree of risk control over the safety and performance of the product. Then we score the compliance of the supplier by assessing the supplier's quality management system, their information security management system, the product or service provided, and the supplier's ability to meet our requirements. The results of the assessment are documented in the record R-010-001 Suppliers evaluation in our QMS.

Q: What is the clinical evidence of your product?

• All Implementations: The clinical evidence of our product is based on a combination of clinical studies, real-world data, and post-market surveillance. We have conducted over a dozen clinical studies to validate the performance and safety of our product. The overall summary of these studies are included in the record R-TF-015-008 Clinical development plan, some of which are published in peer-reviewed journals.

Data Protection & Security

Q: Is patient consent required for image processing?

• Clinical Practice: Yes, explicit patient consent compliant with local healthcare regulations (e.g., GDPR, HIPAA) is required. As a company headquarted in Europe, we are subject to the GDPR and we use its stipulations as a reference for our operations in other countries.
• Clinical Research: Yes, patient consent is covered under clinical trial protocols and consent forms approved by ethics committees.

Q: How long is personal data retained?

• Clinical Research: In terms of the GDPR, the client is the data controller and we are data processors. In line with Article 28(3)(g) of the GDPR, we process data following the specifications of the client. This includes retaining patient data: we retain patient data following the specifications of the client. If there is no specific provision in the contract about retention period, and the client does not communicate their will, we retain the data for 5 years after the provision of the service ends. This is usually specified in the Data Transfer Agreement between us and the sponsor. In Article 5(1)(e) of the GDPR, there are no specific retention periods explicitly stated. The regulation establishes general principles, leaving the exact retention periods subject to sector-specific regulations, contractual agreements, or national or international legal requirements.
• Clinical Practice: In terms of the GDPR, the client is the data controller and we are data processors. In line with Article 28(3)(g) of the GDPR, we process data following the specifications of the client. Importantly, we do not retain patient data. We process the data in a transient manner, meaning that we do not store any personal data. The data is processed in real-time and is not retained after the processing is complete. This is in line with our commitment to data privacy and security.

Q: Is personal data encrypted?

• API Integration: Yes, we employ the robust OAuth 2.0 authentication mechanisms to ensure that only authorized users can access the API. Role-based access control further restricts user privileges, enhancing data security. All data transmitted between the user and the API is encrypted using industry-standard encryption SSL protocols. We align with ISO/IEC 27001:2022 and the OWASP® Foundation's OWASP Top 10 framework to foresee vulnerabilities.
• Web Application: Yes, all data is encrypted in transit and at rest. Communications between the various systems that make up the application are sent encrypted using HTTPS. In this application, an SSL certificate is used for this encryption, so that communication is encrypted and authenticated using TLS1.2, ECDHE_RSA with X25519, and CHACHA20_POLY1305. Confidential information is stored encrypted in databases using the strongest algorithm compatible with the server.

Q: Where is personal data stored?

• All Implementations: Our servers are located in Europe by default, but we can locate the servers in a different location if the client requires it, thanks to our cloud provider.

Q: Do you support cross-border data transfer?

• All Implementations: Yes, we support different options for cross-border data transfer. To ensure legal and secure data transfer between jurisdictions, we implement measures such as Standard Contractual Clauses (SCCs) or other legally recognized transfer mechanisms, as well as implementing Data localization options.

Are the images anonymized before or after transfer to the cloud?

• All images and associated data are handled in full compliance with the highest security standards, including encryption in transit and at rest, access control, and regulatory frameworks such as GDPR and HIPAA. Our product includes an optional image anonymization feature designed to remove personally identifiable characteristics. This process is performed on the server, meaning that anonymization takes place after the image has been securely transmitted to the cloud using encrypted channels. It is important to note that anonymization is not applied by default. Instead, it is a customer-specific feature, activated only upon request and defined according to the particular use case. The scope, method (automatic or manual), and timing of the anonymization process are all established and agreed upon in the project-specific Statement of Work (SOW). This ensures the anonymization approach is tailored to the customer specific needs while remaining compliant with data protection regulations such as GDPR and HIPAA.

Cybersecurity & Information Security

Q: Do you conduct cybersecurity assessments?

• All Implementations: Yes, regular penetration testing and cybersecurity assessments are conducted at least annually or upon significant system updates. We also conduct regular vulnerability assessments and threat modeling to identify and mitigate potential risks.

Q: Can clients conduct their own security audits?

• All Implementations: Yes, clients may conduct security audits upon prior coordination with our security team.

Q: What firewall and intrusion detection systems do you use?

• All Implementations: We use a combination of network firewalls, web application firewalls (WAF), and intrusion detection systems (IDS) to monitor and protect our infrastructure. These systems are regularly updated to address emerging threats. All cloud accounts are protected with two-factor authentication (2FA). Database resources are hosted within a private network, which are only accessible from internal sources. Core resources are further secured with IP restrictions. Additionally, user accounts in the application have the option to enable 2FA for enhanced access protection. Regular audits and updates ensure continued compliance with security standards.

Q: How do users identify themselves when they log into the system?

• API Integration: Users authenticate via OAuth 2.0 with a unique password and username. The system uses role-based access control to manage user permissions.
• Web Application: Users authenticate via a secure login page using a unique username and password. The system uses role-based access control to manage user permissions. Passwords must meet complexity requirements and are stored securely using hashing algorithms. The system also supports two-factor authentication (2FA) for added security.

Technical & Architectural

Q: What is the system architecture?

• API Integration: Microservices architecture with RESTful API endpoints. The system is designed to be modular and scalable, allowing for easy integration with existing systems.

• Web Application: Cloud-based architecture with a front-end web application and back-end microservices. The system is designed to be user-friendly and intuitive, allowing healthcare professionals to easily access the information they need to assist in patient care.

Q: Do data center network cables run through public areas?

• All Implementations: This is not applicable. Our product is a cloud-based service, and we do not manufacture or maintain any hardware.

Q: How scalable is the system?

• All Implementations: Highly scalable; cloud-based microservices architecture automatically scales according to demand.

Q: Is there downtime during updates or maintenance?

• All implementations: The company has set the maximum acceptable interruption times, with an RTO of under 60 minutes and an RPO of less than 60 minutes for both files and databases. It aims for 99.9% uptime service availability. To verify recovery capabilities, regular tests are conducted to ensure staff are prepared for disaster recovery scenarios. Disruptions are categorized into minimal, moderate, major, and catastrophic levels, each with specific remediation steps, from soft reboots and system rollbacks to activating failover sites and restoring critical data from backups. Documentation is maintained throughout the process for analysis and future improvement.

Management & Support

Q: What support do you provide?

We offer different levels of support to meet the diverse needs of our clients:

• Basic Support (included with your license): Available via email from Monday to Friday, 9:00 to 18:00 (GMT+1), this service is designed to assist with standard troubleshooting and to ensure smooth operation of the software.
• Premium Support (optional): Tailored for clients with complex technical challenges and facilitate the seamless implementation of software for specific use cases. Premium Support includes direct access to a dedicated account executive. Assistance is available via email, phone, and video call during business hours (Mon–Fri, 9:00 to 18:00 GMT+1). The scope and terms of this service are defined contractually to ensure alignment with your business goals.

Q: Do you have disaster recovery plans available?

• All Implementations: Yes, we have a comprehensive disaster recovery plan that includes regular backups, failover mechanisms, and incident response protocols. Our general procedure GP-100 Business Continuity and Disaster Recovery Plans outlines the procedures and strategies to ensure business operations can continue and critical systems are recovered. The BCP and DRP address both natural and man-made disasters that may impact business operations, including environmental disasters, cyberattacks, and accidents. The document defines key terms such as BCP (Business Continuity Plan), DRP (Disaster Recovery Plan), RTO (Recovery Time Objective), and RPO (Recovery Point Objective).

Conversation style

When answering, provide an answer that aims at positively fulfilling the implicit assumption of the question.

If the answer is not explicitly available in the sources, give the answer based on the correct implementation of the standards ISO 13485, ISO 27001, IEC 62304 and the industry best practices.

Feel free to add information that is not contained in this Q&A, so as to justify compliance.