Zum Hauptinhalt springen

Anwendungsfälle

Das iframe gibt eine JSON-Payload durch den analysis_completed-Callback zurück, und der vollständige Diagnosebericht kann aus der API mittels der anonymousDiagnosticReportId abgerufen werden. Dieses JSON ist das Rohmaterial, das Ihre Host-Anwendung zur Steuerung von Workflows verwendet.

Woher kommt das JSON

Die Host-App erhält den Bericht, indem sie auf analysis_completed wartet und dann den Output -> API Endpoint aufruft. Das Schema des JSON wird im Abschnitt Output -> JSON Schema beschrieben.

1. Hautkrebs-Triage in einer Patient-App​

Ziel: Wenn das iframe in einer patientenorientierten App eingebettet ist, Patienten automatisch auf die entsprechende Versorgungsstufe leiten, ohne ihnen die rohe klinische Ausgabe zu zeigen.

Dieses Muster kombiniert zwei iframe-Parameter:

  • isForPatient=1: vereinfacht Fragebogen-Wording für nicht-klinische Benutzer.
  • enableResult=0: verbirgt das diagnostische Ergebnis vor dem Benutzer, sodass die Host-App der einzige Konsument des JSON ist.

Die Host-App erhält den Bericht über analysis_completed, bewertet die unter result zurückgegebenen Schlüssel und entscheidet, was der Patient danach sieht: eine Selbstpflege-Nachricht, einen Termin-Buchungsbildschirm oder eine dringende Überweisung an einen Dermatologen.

Anstatt sich nur auf malignancy zu verlassen, kombiniert die Triage mehrere Signale, die vom Gerät zurückgegeben werden:

  • result.preliminaryFindings.urgentReferral: Wahrscheinlichkeit (0 bis 100), dass der Patient innerhalb der nächsten 48 Stunden von einem Arzt gesehen werden sollte. Steuert den Notfall-Überweisungs-Zweig.
  • result.preliminaryFindings.highPriorityReferral: Wahrscheinlichkeit (0 bis 100), dass der Patient innerhalb der nächsten 15 Tage gesehen werden sollte. Erfasst Fälle, die nicht dringend (48 Stunden), aber dennoch schnell bearbeitet werden müssen.
  • result.metrics.entropy: ein Maß dafür, wie sicher sich die KI bei ihrer Antwort ist. Eine niedrigere Entropie bedeutet höhere Sicherheit; Fälle über dem Entropie-Schwellwert werden einem Kliniker als Sicherheits-Fallback zugewiesen, sodass unsichere Berichte nie zur Selbstpflege weitergeleitet werden.
  • result.scoringSystems[]: wenn der diagnostische Unterstützungsalgorithmus ausreichende Sicherheit erreicht, wird das relevante Bewertungssystem berechnet (für pigmentierte Läsionen ist dies typischerweise die 7-Punkte-Checkliste, Code sevenPc). Jeder Eintrag trägt einen score.severity.value von 1 (niedrig), 2 (moderat) oder 3 (hoch).
  • result.preliminaryFindings.hasCondition: Wahrscheinlichkeit, dass eine Bedingung überhaupt vorhanden ist - wird am Ende der Kaskade verwendet, um zwischen Primärversorgung und Selbstpflege zu entscheiden.

Der Patient sieht nie die zugrunde liegenden Wahrscheinlichkeiten; er sieht nur die Aktion, die Ihre App anzeigt.

Host-App-Listener (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) {
    // Low model confidence - escalate as a safety fallback.
    openDermatologyBooking();
  } else if (preliminaryFindings.highPriorityReferral > 30) {
    openDermatologyBooking();
  } else if (sevenPc?.score?.severity?.value === 3) {
    openDermatologyBooking();
  } else if (preliminaryFindings.hasCondition > 70) {
    openPrimaryCareBooking();
  } else {
    showSelfCareGuidance();
  }
});
Schwellwerte sind organisationsdefiniert

Die Werte X, Y, Z und E (sowie die oben gezeigten 60 / 30 / 70 / 0.5) sind illustrativ. Jede verwaltende Organisation muss ihre eigenen Schwellwerte basierend auf ihren klinischen Protokollen und dem Kompromiss zwischen False Positives und False Negatives wählen. Siehe den Abschnitt „Thresholding" auf der Seite „Legit.Health Plus-Workflows" für Anleitung, einschließlich eines durchgerechneten Verwirrungs-Matrix-Beispiels.

2. Longitudinale Schweregrad-Überwachung​

Ziel: Verfolgen Sie, wie sich die Erkrankung eines Patienten im Laufe der Zeit entwickelt, indem Sie vom iframe zurückgegebene Schweregrad-Werte speichern und einen Trend in der Host-Anwendung rendern.

Das iframe selbst speichert keine Informationen über Benutzer, daher kann es zwei Berichte für denselben Patienten nicht verknüpfen. Um longitudinale Überwachung zu ermöglichen, muss die Host-App:

  1. Bei jedem Start des iframes einen stabilen Patienten-Identifier über extraData übergeben (siehe Customize-Seite).
  2. Bei analysis_completed den Bericht abrufen und die relevanten Schweregrad-Werte aus result.scoringSystems[] (der score.value, das scoringSystem.code wie sevenPc, apasiLocal oder aladinLocal, und der score.severity.value-Bucket) in ihrer eigenen Datenbank speichern, gekennzeichnet durch diesen Identifier.
  3. Einen historischen Chart aus den persistierten Werten rendern. Diese Visualisierung wird von der Host-Anwendung erstellt und gepflegt; das iframe bietet sie nicht.
Host-App-Listener (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,
    });
  }
});
Eingebautes Delta

Jeder Scoring-System-Eintrag stellt bereits ein reduction-Feld zur Verfügung: die prozentuale Änderung gegenüber dem vorherigen Bericht für denselben Patienten. Dies ist null beim ersten Bericht und wird danach gefüllt, sodass die Host-App schnell einen „verbessert / verschlechtert" Indikator anzeigen kann, ohne das Delta selbst zu berechnen.

Sobald die Daten gespeichert sind, kann die Host-App klinische Funktionen darauf aufbauen. Zum Beispiel kann sie den neuesten Wert gegen den Basiswert am Anfang der Behandlung vergleichen, sich verschlechternde Verläufe einem Kliniker markieren oder dem Patienten ein longitudinales Chart ihrer eigenen Erkrankung zeigen.

Mit dem anderen Workflow kombinieren

Die beiden Muster ergänzen sich: der intelligente Triage-Fluss entscheidet, was jetzt zu tun ist, während die longitudinale Überwachung den historischen Kontext aufbaut, der einem Kliniker hilft, den heutigen Wert gegen die Patienteneigene Entwicklung zu interpretieren.