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
      • Deprecated
        • SP-009-001 API onboarding
        • SP-009-002 Hubspot onboarding
      • Templates
      • Specific procedures
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • 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-026 Product requirements for US market
    • GP-027 Product requirements for UK market
    • GP-028 Product requirements for the Brazilian market
    • 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
    • GP-200 Remote Data Acquisition in Clinical Investigations
  • Records
  • TF_Legit.Health_Plus
  • Licenses and accreditations
  • External documentation
  • Procedures
  • GP-009 Sales
  • Deprecated
  • SP-009-001 API onboarding

SP-009-001 API onboarding

Version control​

Reason for reviewDateVersion id
First version202110201
Yearly review202209232
Written byReviewed byApproved by

E-Signature (Appfire integration):

Signature logo

Taig Mac Carthy

59E5447E121DC7727778436CE0A1687C

Signer name: Taig Mac Carthy

Signing time: Thu, 08 Sep 2022 13:45:12 GMT

Reason: Creation of document

E-Signature (Appfire integration):

Signature logo

Alfonso Medela

FEB877112952CB739121969B1BCCE71B

Signer name: Alfonso Medela

Signing time: Sat, 10 Sep 2022 13:57:34 GMT

Reason: Reviewed

E-Signature (Appfire integration):

Signature logo

Andy Aguilar

F4C82ED90FA4D599FAB293D98A565958

Signer name: Andy Aguilar

Signing time: Sun, 11 Sep 2022 13:56:42 GMT

Reason: Approving document

Quality manager (QM)Technical manager (PRRC)General manager (GM)

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
  • Alfonso Medela: Our CAIO, Alfonso Medela alfonso@legit.health

The body of that email will be:

Dear Person B,

I'd like to welcome you to our developer community on behalf of our our team. Don't hesitate to reach out if there is anything you need from us while accessing the API or if you need help customizing your interface to make the most out of the algorithm's data - we are happy to help.

I'm cc'ing this email your technical lead, Person A, and our Chief A.I. Officer, Alfonso Medela. In the following hours, Mr. Medela will send you and Person B an email with a password protected PDF. The password to view the PDF will be full name of the person that signed the contract [Name Lastname]. Inside the PDF, you will find the Client Secret Key that will enable you to post and get data from the algorithms via API Rest. Please, keep this key secure and well protected.

In the PDF you will also find the swagger API documentation, but I'm also sending it here for your convenience: https://api-ia-spec.legit.health/#/default/analyzeImage

Kind regards,

After receiving this email, Alfonso will send them a PDF that includes the Client Secret Key. He will generate this PDF from a template that is available in the template gallery:

Alfonso's email will be directed only to Person A and Person B, and the business dev person from Legit.Health will not receive that email.

Why are we woing this? Accessing the algorithm via API is very different than accesing via app.legit.health. The main difference is that the customer will not have an email and password to use the app. Why? Because they are not accesing the algorithms manually: they are programming their own application to access the algorithm.

Therefore, we need to provide them a key so that their application can connect with the algorithm. The password is called the Client Secret Key. It's a very long password that computers use to communicate with each other: 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.

Previous
GP-009 Sales
Next
SP-009-002 Hubspot onboarding
  • Version control
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.)