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-009 Sales
      • Deprecated
      • Templates
      • Specific procedures
        • SP-009-001 How to use the CRM
        • SP-009-002 Contracts
        • SP-009-003 How to share performance metrics
        • SP-009-004 Implementation plan helpers
        • SP-009-005 Implementation plan helpers for Clinical Trials
        • SP-009-006 Integration workflow helpers
        • SP-009-007 Scoring Systems Catalog
        • SP-009-008 Conditions List & Visual Assets
        • SP-009-009 Service Provision Guidelines for Intermediaries
        • Copypasters
    • 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 Non-product software validation
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Predetermined Change Control Plan
    • GP-025 Usability and Human Factors Engineering
    • GP-026 Market-specific product requirements
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery and Commissioning
    • GP-030 Cyber Security Management
    • GP-031 Training Data 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
    • GP-110 Esquema Nacional de Seguridad
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-600 Equality Planning
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Legit.Health Utilities
  • Licenses and accreditations
  • Applicable Standards and Regulations
  • BSI Non-Conformities
  • Pricing
  • Public tenders
  • Procedures
  • GP-009 Sales
  • Specific procedures
  • SP-009-009 Service Provision Guidelines for Intermediaries

SP-009-009 Service Provision Guidelines for Intermediaries

Scope and purpose​

The purpose of this procedure is to define the technical and operational guidelines for providing access to the device when an intermediary (such as an integration partner, a pharmaceutical company, or a health network) is involved.

This document clarifies the different deal structures and how they translate into technical access configurations, ensuring the Sales and Integration teams are aligned on how to provision the service. These guidelines apply equally to Iframe and JSON-Only (API) integrations.

Deal Structures and Access Models​

When working with an intermediary, there are two main business models that affect how technical access is provisioned.

1. Single Deal (Direct to Intermediary)​

In this model, we sign a single contract with the intermediary. The intermediary integrates our technology into their product and distributes it to their end-users.

Characteristics:

  • Contractual: One unified contract with the intermediary.
  • Billing: We bill the intermediary based on aggregated usage, total volume, or whatever format.
  • Technical Access: A single access point is created. All traffic from the intermediary uses the same credentials or configuration, regardless of which specific hospital, clinic, or end-user is interacting with the device.

Examples:

  • JSON-Only: SESPA, Quantificare (The partner uses a single API Key for all their traffic).
  • Iframe: Aragón, Teladoc (The partner uses a single Iframe configuration and authentication source).

2. Parent Deal & Sub-deals (Framework Contract)​

In this model, we sign a Master Service Agreement (Framework Contract) with the intermediary, but we structure individual "sub-deals" for each end-customer (e.g., specific hospitals or regional health services) that the intermediary brings to us.

Characteristics:

  • Contractual: One parent framework contract + multiple specific sub-deals (one per end-user/hospital).
  • Billing: Volumes, pricing, and usage are estimated and tracked separately for each sub-deal.
  • Technical Access: Multiple access points are required. A distinct API key or Iframe configuration is provisioned for each sub-deal. This allows us to track usage, isolate data, and enforce specific limits per end-user.

Examples:

  • JSON-Only: A pharmaceutical partner (Parent) rolling out the API to Hospital A (Sub-deal 1) and Hospital B (Sub-deal 2). Each hospital gets its own API Key.
  • Iframe: Boehringer Ingelheim (BI). Different hospitals or regional implementations under the BI umbrella receive separate Iframe access configurations.

Architecture Visualization​

The following diagrams illustrate the difference between the two access models:

Model 1: Single Deal​

Model 2: Parent Deal & Sub-deals​

Guidelines for Sales and Service Provision​

When configuring a new deal involving an intermediary, the Sales team must clearly communicate the expected model to the technical integration team:

  1. Identify the Model Early: Determine if the contract is a "Single Deal" or a "Parent Deal & Sub-deals" during the negotiation phase.
  2. Specify Access Requirements:
    • For Single Deals, request one production environment setup.
    • For Parent/Sub-deals, request a new setup/credentials for each new sub-deal as they are signed.
  3. Usage Tracking: Remember that in a Single Deal, usage metrics will be aggregated. If granular reporting per hospital/end-user is required by the business model, the "Parent Deal & Sub-deals" model (with separate access credentials) must be used.
Previous
SP-009-008 Conditions List & Visual Assets
Next
Copypasters
  • Scope and purpose
  • Deal Structures and Access Models
    • 1. Single Deal (Direct to Intermediary)
    • 2. Parent Deal & Sub-deals (Framework Contract)
  • Architecture Visualization
    • Model 1: Single Deal
    • Model 2: Parent Deal & Sub-deals
  • Guidelines for Sales and Service Provision
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.)