Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
      • Templates
    • GP-012 Design, Redesign and Development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity
    • GP-025 Corporate Governance
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
  • Records
  • TF_Legit.Health_Plus
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • Procedures
  • GP-011 Provision of service

GP-011 Provision of service

Procedure flowchart​

Purpose​

To define the methodology to establish activities of production, preservation, storage and delivery of our medical devices.

Scope​

All medical devices developed and distributed by us.

Responsibilities​

JD-005 Technical Manager & Person Responsible for Regulatory Compliance (PRRC)​

To directly supervise internal and/or outsourced manufacturing activities. To release the manufactured product.

JD-003 Design & Development Manager​

To manage and control the manufacturing and the production process related to our medical devices.

JD-002 Sales Manager​

To develop and manage all the documentation regarding purchase, production and sales orders.

JD-004 Quality Manager & Person Responsible for Regulatory Compliance (PRRC)​

To ensure all the documents and records related to the process are properly created, reviewed and archived according to our procedures.

Inputs​

New contract with clients signed

Outputs​

JSON Only integration​

  • T-011-001 API key order
  • T-011-002 API key release

DeepLink or iFrame integration​

  • T-011-003 DeepLink and App keys order
  • T-011-004 DeepLink and App keys delivery

Common​

  • Final product under traceability control

Development​

Due to the nature of our product as a standalone softare, more precisely an API REST, the production phase of the device does not start when a client request the product, but the product is already developed, tested, validated and released according to the GP-012 Design, redesign and development.

When a new contract is signed according to the procedure GP-009 Sales, we start the service provision to the client.

Service provision​

When a customer hires the API Connect service, once they have signed the service contract and all the legal and financial steps are solved, they need to access the API.

In order to do that, the business development person must send an email to the following people:

  • Person A: The technical lead of the customer's company
  • Person B: The manager of owner of the customer's company
  • Our JD-005

The body of that email is specified at the T-011-001 API key order.

After receiving this email, the JD-005 will create a Client Secret Key using a secure, random algorithm, guaranteeing its uniqueness and complexity. Then, he will send them a PDF that includes the Client Secret Key following the T-011-002 API key release template. The PDF will be secured with a password based on the name of the individual who signed the contract from the customer's side, providing an additional layer of security.

JD-005's email will be directed only to Person A and Person B, and the business development representative from our company will not receive that email.

Why are we doing this? Accessing the device via API is very tricky. The main difference is that the customer will not have an email and password to use an app, like with normal applications. Why? Because they are not accesing the device manually: they are programming their own application to access the device.

Therefore, we need to provide them a key so that their application can connect with the device. The password is called the Client Secret Key. It's a very long password that computers use to communicate with each other as: pk_hds7sjUudj_Dt4ZBItXSZT1EzmOd8yCxonL.

This key is super important, as it's the only way for them to make use of the service. But it's also very confidential, because there is only one Key and if anyone got access to it they could consume a lot of calls on behalf of the customer.

Service provision control​

As it is detailed at the GP-012 Design, redesign and development, all customers must use the latest version version of the app. we keep a record of customers that have not transitioned to the new versions in the corresponding T-012-012 Customers product version control document.

Reworking process​

According to the nature of the product, rework is not required. In case of non-compliance we will follow the GP-006 Non-compliance. Preventive and corrective actions and, if necessary, the GP-004 Vigilance system.

Cleaning and decontamination​

According to the nature of the product, this section is not required.

Preservation conditions and storage process​

According to the nature of the product, this section is not required.

Expedition​

Due to the nature of the product being an API REST, the service provision is done virtually.

Associated documents​

  • T-011-001 API key order
  • T-011-002 API key release
  • T-011-003 DeepLink and App keys order
  • T-011-004 DeepLink and App keys delivery
  • T-012-012 Customers product version control
  • GP-004 Vigilance system
  • GP-006 Non-compliance. Preventive and corrective actions
  • GP-012 Design, redesign and development

Signature meaning

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

  • Author: Team members involved
  • Reviewer: JD-003, JD-004
  • Approver: JD-001
Previous
T-010-001 Suppliers evaluation YYYY_nnn
Next
Templates
  • Procedure flowchart
  • Purpose
  • Scope
  • Responsibilities
    • JD-005 Technical Manager & Person Responsible for Regulatory Compliance (PRRC)
    • JD-003 Design & Development Manager
    • JD-002 Sales Manager
    • JD-004 Quality Manager & Person Responsible for Regulatory Compliance (PRRC)
  • Inputs
  • Outputs
    • JSON Only integration
    • DeepLink or iFrame integration
    • Common
  • Development
    • Service provision
    • Service provision control
    • Reworking process
    • Cleaning and decontamination
    • Preservation conditions and storage process
    • Expedition
  • Associated documents
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)