Quelles interfaces Probatix propose-t-il ?

REST API pour les commandes, les requêtes de statut et la récupération des résultats ; webhooks pour les notifications push lors des changements de statut (actuellement en version bêta) ; endpoint FHIR R4 pour des résultats interopérables. En option : portail partenaire comme alternative graphique sans développement propre.

Les résultats sont-ils livrés au format FHIR ?

Oui. Les résultats sont livrés sous forme de bundle FHIR R4, avec des ressources Observation par paramètre, une ressource DiagnosticReport pour le résultat global et les références Patient/Practitioner correspondantes. Les valeurs sont codées en LOINC.

Que sont les codes LOINC et pourquoi sont-ils importants ?

LOINC (Logical Observation Identifiers Names and Codes) est la norme internationale pour l'identification univoque des paramètres de mesure cliniques. « Glucose dans le sérum » a sous LOINC 2345-7 la même identité dans tous les systèmes – cela rend les résultats interopérables et économise le travail de mapping côté destinataire.

Combien de temps dure l'intégration ?

Pour une connexion standard à la REST API, généralement quelques jours de développement. S'y ajoutent la phase de test en sandbox et la configuration de la conformité. Time-to-Live réaliste : 2 à 6 semaines à partir de la signature du contrat, selon la profondeur du programme.

Est-ce possible sans développement propre ?

Oui. Le portail partenaire couvre tous les workflows opérationnels – créer des commandes, suivre les statuts, récupérer les résultats, analyser les statistiques. Idéal pour les programmes qui ne souhaitent pas mobiliser leur propre équipe de développement.

Intégrer le diagnostic de laboratoire par API : REST, résultat FHIR, LOINC et un workflow flexible

Le flux API

L’intégration comporte essentiellement quatre étapes :

1.  POST /v1/orders              → Créer une commande (panel, destinataire, profil de branding)
2.  Activation                   → L'utilisateur final active le kit (lien/QR de votre système)
3.  Webhook: status_changed      → Notification push à chaque changement de statut
4.  GET /v1/orders/{id}/report   → Récupérer le résultat (JSON ou FHIR R4)

Créer une commande

POST /v1/orders
Authorization: Bearer <token>
Content-Type: application/json

{
  "panel": "longevity-basic",
  "recipient": { ... },
  "branding_profile": "partner-xyz",
  "callback_url": "https://yourapp.example/webhook"
}

Réponse : ID de commande, ETA estimé jusqu’à la réception de l’échantillon.

Suivre le statut

Les transitions de statut suivent typiquement ce schéma : created → shipped → delivered → sample_received → analyzed → report_ready. Via les webhooks, vous êtes informé de chaque transition en temps réel – pas de polling.

Récupérer le résultat

Dès que report_ready est déclenché, vous récupérez le résultat :

GET /v1/orders/{id}/report?format=fhir

→ Bundle FHIR R4 avec DiagnosticReport + Observations par paramètre. Alternativement format=json pour un format Probatix interne simplifié.

Données de résultats standardisées

La standardisation est ici tout le levier. Si vous travaillez dans des Health Apps, des plateformes de télémédecine ou de soins, vous devez distinguer deux niveaux dans le format des données de résultats :

Structure – comment les champs d’un résultat sont organisés.
Codification – comment un paramètre individuel est nommé de manière univoque.

Probatix livre les deux selon la norme internationale :

FHIR R4 est le format HL7 pour les données cliniques. Un résultat arrive sous forme de bundle, dans lequel vous trouvez de manière structurée :

DiagnosticReport — le résultat de synthèse (statut, date d’analyse, conclusion).
Observation par paramètre — valeur, unité, plage de référence, code LOINC, flags (high/low/critical).
Patient / Practitioner — métadonnées référentielles.

Les codes LOINC identifient chaque paramètre de manière univoque. Exemple : « Glucose dans le sérum ou le plasma » reçoit le code LOINC 2345-7 – dans le monde entier. Quel que soit le système côté destinataire : ce code est compris. Cela vaut pour le cholestérol (2093-3), l’HbA1c (4548-4) et des milliers d’autres paramètres.

Avantage pour vous : si vous transmettez des résultats à un système tiers (caisse, EHR, serveur FHIR), vous économisez le mapping des paramètres. La prise en charge du résultat fonctionne « out of the box ». C’est ce qui fait la différence entre un PDF que quelqu’un doit mapper et un objet de données qui peut s’intégrer automatiquement.

Webhooks plutôt que polling

Au lieu de demander régulièrement le statut, nous vous contactons – à votre URL webhook, avec une charge utile signée. Cela économise des ressources et maintient votre application synchronisée en temps réel. Remarque : l’interface webhook est actuellement en version bêta ; nous mettons à disposition la spécification, le procédé de signature et la logique de retry directement aux partenaires dans le programme bêta. Le polling via la REST API est possible en parallèle à tout moment.

Workflow flexible

L’API n’est pas le seul schéma d’intégration. Vous pouvez combiner :

API pure — votre application orchestre tout le flux.
Portail partenaire — gestion opérationnelle quotidienne dans l’UI ; API uniquement pour les données de résultats.
Intégration webshop — commande de kits via des modules prêts à l’emploi dans votre boutique.

Le pilotage du résultat est également configurable :

Résultat à votre application — vous l’affichez dans votre UI.
Résultat à l’utilisateur final — via le portail patient Probatix (white-label).
Résultat à la télémédecine/au médecin conventionné — transmission directe au système du cabinet (notamment pour les modèles selon §116b/117).

Time-to-Result

Pour la plupart des tests, le résultat est disponible dans les 48 heures suivant la réception de l’échantillon au laboratoire. Ce qui influence cette fourchette :

Spécificités du paramètre (certaines méthodes nécessitent des temps d’incubation).
Nombre de paramètres (taille du panel).
Routage des laboratoires (charge des laboratoires connectés).

Les webhooks de statut vous tiennent informé à chaque étape.

Effort d’intégration

De manière réaliste :

Cas d’usage minimal (créer une commande + polling de statut + récupérer le PDF du résultat) : quelques jours de développement.
Intégration FHIR approfondie (mapping dans votre propre serveur FHIR, logique de paramètres dans l’UI) : 1 à 3 semaines.
Intégration complète du programme (UI, flux applicatif, pilotage des résultats, reporting) : 4 à 8 semaines avec phase de test et de conformité.

Si vous n’avez pas d’équipe de développement : le portail partenaire couvre tous les workflows — vous pouvez démarrer immédiatement et ajouter la connexion API par la suite.