Aller au contenu principal

Cas d'usage

L'iframe retourne une charge utile JSON via le callback analysis_completed, et le rapport diagnostique complet peut être récupéré depuis l'API en utilisant le anonymousDiagnosticReportId qu'il porte. Ce JSON est la matière première que votre application hôte utilise pour piloter les workflows.

D'où vient le JSON

L'application hôte obtient le rapport en écoutant analysis_completed puis en appelant Output, API Endpoint. Le schéma du JSON est décrit dans la section Output, JSON Schema.

1. Tri du cancer de la peau dans une application patient​

Objectif: Lorsque l'iframe est intégrée dans une application face aux patients, router automatiquement le patient vers le niveau de soins approprié, sans jamais leur montrer la sortie clinique brute.

Ce schéma combine deux paramètres iframe:

  • isForPatient=1: simplifie les formulations du questionnaire pour les utilisateurs non-cliniques.
  • enableResult=0: masque le résultat diagnostique à l'utilisateur, afin que l'application hôte soit le seul consommateur du JSON.

L'application hôte reçoit le rapport via analysis_completed, évalue les clés retournées sous result, et décide ce que le patient voit ensuite: un message d'auto-soin, un écran de réservation en soins primaires, ou un renvoi urgent chez un dermatologue.

Plutôt que de se fier à malignancy seul, le tri combine plusieurs signaux retournés par le dispositif:

  • result.preliminaryFindings.urgentReferral: probabilité (0 à 100) que le patient doive être vu par un médecin dans les 48 heures suivantes. Pilote la branche de renvoi urgent.
  • result.preliminaryFindings.highPriorityReferral: probabilité (0 à 100) que le patient doive être vu dans les 15 jours suivants. Capture les cas qui ne sont pas urgents à 48 heures mais qui justifient quand même un rendez-vous accéléré.
  • result.metrics.entropy: une mesure de la confiance de l'IA dans sa réponse. Une entropie plus basse signifie une confiance plus élevée ; les cas au-dessus du seuil d'entropie sont remontés à un clinicien comme filet de sécurité afin que les rapports incertains ne soient jamais routés vers l'auto-soin.
  • result.scoringSystems[]: lorsque l'algorithme d'assistance diagnostique atteint une confiance suffisante, le système de notation pertinent est calculé (pour les lésions pigmentées, c'est généralement la liste de contrôle à 7 points, code sevenPc). Chaque entrée porte une valeur score.severity.value de 1 (bas), 2 (modéré) ou 3 (élevé).
  • result.preliminaryFindings.hasCondition: probabilité qu'une condition soit présente du tout - utilisée à la toute fin de la cascade pour décider entre les soins primaires et l'auto-soin.

Le patient ne voit jamais les probabilités sous-jacentes ; il ne voit que l'action que votre application affiche.

Écouteur de l'application hôte (web)
window.addEventListener("message", async function (event) {
  if (event.data.message !== "analysis_completed") return;

  const report = await fetchReportFromApi(event.data.id);
  const { preliminaryFindings, scoringSystems, metrics } = report.result;

  const sevenPc = scoringSystems?.find((s) => s.scoringSystem.code === "sevenPc");

  if (preliminaryFindings.urgentReferral > 60) {
    showUrgentDermatologistScreen();
  } else if (metrics.entropy != null && metrics.entropy > 0.5) {
    // Confiance du modèle faible - remonter comme filet de sécurité.
    openDermatologyBooking();
  } else if (preliminaryFindings.highPriorityReferral > 30) {
    openDermatologyBooking();
  } else if (sevenPc?.score?.severity?.value === 3) {
    openDermatologyBooking();
  } else if (preliminaryFindings.hasCondition > 70) {
    openPrimaryCareBooking();
  } else {
    showSelfCareGuidance();
  }
});
Les seuils sont définis par l'organisation

Les valeurs X, Y, Z et E (et les valeurs 60 / 30 / 70 / 0.5 affichées ci-dessus) sont illustratives. Chaque organisation de gestion doit choisir ses propres seuils en fonction de ses protocoles cliniques et du compromis entre les faux positifs et les faux négatifs. Consultez la section Thresholding dans la page des workflows Legit.Health Plus pour des conseils, y compris un exemple de matrice de confusion fonctionnant.

2. Surveillance longitudinale de la sévérité​

Objectif: Suivre la façon dont l'état d'un patient évolue au fil du temps en stockant les scores de sévérité retournés par l'iframe et en affichant une tendance dans l'application hôte.

L'iframe elle-même ne conserve pas les informations sur les utilisateurs, elle ne peut donc pas lier deux rapports pour le même patient. Pour activer la surveillance longitudinale, l'application hôte doit:

  1. Passer un identifiant de patient stable via extraData chaque fois que l'iframe est lancée (consultez la page Personnaliser).
  2. Sur analysis_completed, récupérer le rapport et conserver les valeurs de sévérité pertinentes de result.scoringSystems[] (la score.value, la scoringSystem.code telle que sevenPc, apasiLocal ou aladinLocal, et le bucket score.severity.value) dans sa propre base de données, indexée par cet identifiant.
  3. Afficher un graphique historique des scores conservés. Cette visualisation est construite et maintenue par l'application hôte ; l'iframe ne la fournit pas.
Écouteur de l'application hôte (web)
window.addEventListener("message", async function (event) {
  if (event.data.message !== "analysis_completed") return;

  const report = await fetchReportFromApi(event.data.id);
  const patientId = report.extraData;

  for (const entry of report.result.scoringSystems ?? []) {
    await db.severityScores.insert({
      patientId,
      scoringSystemCode: entry.scoringSystem.code,
      scoringSystemName: entry.scoringSystem.name,
      score: entry.score?.value,
      severityValue: entry.score?.severity?.value,
      reduction: entry.reduction,
      timestamp: report.createdAt,
    });
  }
});
Delta intégré

Chaque entrée de système de notation expose déjà un champ reduction: le changement en pourcentage par rapport au rapport précédent pour le même patient. C'est null sur le premier rapport et rempli par la suite, afin que l'application hôte puisse afficher rapidement un indicateur "s'améliorant / s'aggravant" sans calculer elle-même le delta.

Une fois les données stockées, l'application hôte peut construire des fonctionnalités cliniques dessus. Par exemple, elle peut comparer le score le plus récent à la ligne de base au démarrage du traitement, signaler les trajectoires d'aggravation à un clinicien, ou afficher au patient un graphique longitudinal de son propre état.

Combiner avec l'autre workflow

Les deux schémas sont complémentaires: le flux de tri intelligent décide quoi faire maintenant, tandis que la surveillance longitudinale construit le contexte historique qui permet à un clinicien d'interpréter le score d'aujourd'hui par rapport à la trajectoire propre du patient.