Legit.Health Plus

In diesem Abschnitt präsentieren wir praktische Beispiele von Workflows, die in Ihre Systeme integriert werden können und die Daten nutzen, die von unserer Geräte-API bereitgestellt werden.

Wir erkennen an, dass die Integration von Daten aus unserer API in Ihre bestehenden Systeme eine komplexe Aufgabe sein kann, besonders wenn dies die erste Erfahrung Ihrer Organisation mit einem solchen Gerät ist. Diese Beispiele sind dazu konzipiert, Sie durch diesen Integrationsprozess zu unterstützen und zu leiten.

Bitte beachten Sie, dass die Flexibilität unserer API eine Vielzahl von Workflow-Implementierungen ermöglicht. Die hier gezeigten Beispiele sind nicht erschöpfend und sollten nicht als die einzigen Methoden oder als Befürwortung bestimmter Praktiken verstanden werden. Jede Organisation hat einzigartige Anforderungen und Bedürfnisse. Folglich ist es entscheidend, dass verwaltende Organisationen Workflows entwickeln, die ihren internen Best Practices entsprechen und die von ihren Fachleuten festgelegten Richtlinien einhalten.

Puzzleteilchen

Betrachten Sie die Ausgabe unseres Geräts wie Teile eines Puzzles. Das Gerät generiert eine JSON-Datei, reich an Daten, organisiert unter verschiedenen Schlüsseln. Diese Schlüssel dienen als grundlegende Elemente in Ihrem Workflow-Designprozess. Sie können sich jeden Schlüssel als einen unterschiedlichen Zweig in einem Entscheidungsbaum vorstellen oder, kreativer ausgedrückt, als ein einzigartiges Puzzleteil. Diese Analogie hebt die Flexibilität und Anpassungsfähigkeit der Daten hervor: Sie können diese Teile in zahlreichen Konfigurationen anordnen und integrieren, um Ihre spezifischen Workflow-Anforderungen zu erfüllen.

Weitere Informationen

Bitte lesen Sie den Abschnitt Installation Manual der Gebrauchsanweisung für weitere Informationen.

Schlüssel des DiagnosisSupport-Endpunkts

Schlüssel des SeverityMeasure-Endpunkts

Es gibt mehr Puzzleteile

Die API gibt viel mehr Felder zurück als die hier gezeigten. Diese Beispiele heben nur eine kleine Teilmenge von Schlüsseln hervor, die besonders nützlich für Triage und operatives Routing sind.

Workflows nach klinischem und operativem Ziel

Dieselbe Ausgabe kann sehr unterschiedliche Workflows unterstützen. Ein sicherheitsorientierter Triage-Ablauf könnte stark auf urgentReferralProbability angewiesen sein, während ein kapazitätsorientierter Ablauf möglicherweise entropy und Schweregrad verwendet, um zu entscheiden, welche Fälle in Pfade mit geringerer Intensität bleiben können.

In der Praxis kombinieren Organisationen normalerweise mehrere Ziele gleichzeitig: Vermeidung verpasster schwerwiegender Fälle, Schutz der Fachkapazität und Verwaltung von Follow-up-Terminen mit geringem Risiko. Die folgenden Beispiele zeigen, wie dieselben Teile je nach operativem Ziel unterschiedlich angeordnet werden können.

1. Stärkung der Primärversorgung: Triage

Ziel: Verringern Sie erste Besuche in der Dermatologie, indem Sie auf der Ebene der Primärversorgung harmlose oder unkomplizierte Fälle herausfiltern.

Dieser Ablauf verwendet urgentReferralProbability als erstes Eskalationssignal, highPriorityReferralProbability als nächsten Überweisungsfilter und entropy als Unsicherheitstor.

2. Telemedizin ermöglichen: Remote vs. persönlich

Ziel: Entscheiden Sie, welche Besuche sicher remote gelöst werden können und welche persönliche Konsultationen erfordern, um unnötige Krankenhausbesuche zu minimieren.

Die vier möglichen Ergebnisse sind:

• Primärversorgung, Remote (🤳): R1.
• Primärversorgung, Persönlich (🏥🚶): P1.
• Sekundärversorgung, Remote (🤳): R2.
• Sekundärversorgung, Persönlich (🏥🚶): P2.

Organisationen können persönliche Fachkapazität für Fälle reservieren, die sowohl hochriskant als auch schwer zu klassifizieren sind.

3. Optimierung der Nachsorge für chronische Patienten

Ziel: Verringern Sie die Anzahl unnötiger Nachsorgetermine, besonders bei chronischen Erkrankungen, indem Sie überprüfen, ob die Erkrankung fortbesteht, und ihren Schweregrad beurteilen.

Die zwei möglichen Ergebnisse sind:

• Verläuft wie erwartet: OK.
• Anomalie: !.

Durch Einbeziehung der Krankengeschichte des Patienten können wir bestimmen, ob eine zuvor diagnostizierte Erkrankung noch vorhanden ist, und bewerten, ob der Schweregrad eine Anomalie anzeigt.

4. Routing für Subspezialisten und Fachübergreifende Versorgung

Ziel: Überweisen Sie den Patienten direkt an den richtigen spezialisierten Facharzt. Dies könnte ein Dermatologe mit einer dedizierten Subspezialität sein (z.B. eine spezialisierte Einheit für pigmentierte Läsionen, Melanom oder Hidradenitis suppurativa) oder ein Spezialist aus einem anderen Fachbereich (z.B. Gastroenterologie, Rheumatologie, Allergologie oder Genetik), wenn die dermatologische Läsion eine Manifestation einer zugrunde liegenden Systemerkrankung, einer Komorbiditäten oder einer seltenen Erkrankung ist.

Dieses Routing basiert auf der Bewertung spezifischer Metriken wie pigmentedConditionProbability oder der Analyse des hypotheses-Arrays. Organisationen können Kriterien definieren, um diese präzisen Überweisungen auszulösen, z.B. überprüfen, ob eine Wahrscheinlichkeit einen bestimmten Schwellenwert überschreitet, ob ein bestimmter Code in den Top-1 oder Top-3 Ergebnissen erscheint, oder sogar basierend auf der Summe der Wahrscheinlichkeiten für eine Gruppe verwandter Erkrankungen. Wenn beispielsweise Hidradenitis supurativa als Top-1 Ergebnis angezeigt wird, kann der Patient direkt zur spezialisierten Einheit für diese Erkrankung weitergeleitet werden.

5. Priorisierung von Wartelisten

Ziel: Aktualisieren Sie aktuelle Wartelisten dynamisch, um sicherzustellen, dass Patienten mit höherem klinischem Bedarf zuerst behandelt werden.

6. Präventionskampagnen und Arbeitsmedizin

Ziel: Implementieren Sie automatisierte Screening-Abläufe während arbeitsmedizinischer Untersuchungen oder öffentlicher Präventionskampagnen.

Reale Fallstudien

Eine Krankenkasse: Triage zwischen Primär- und Sekundärversorgung

In diesem Szenario teilt die Organisation (eine Krankenkasse) Fälle in zwei Ergebnisse auf, um ihren Patientenfluss zwischen Primär- und Sekundärversionspfaden effektiv zu verwalten.

Die zwei möglichen Ergebnisse sind:

• Primärversorgung: Ergebnis 1.
• Sekundärversorgung: Ergebnis 2.

Hier ist ihr konfigurierter Workflow mit realen operativen Schwellenwerten:

Dieser Ablauf verwendet urgentReferralProbability als erstes Eskalationssignal, entropy als Unsicherheitstor, highPriorityReferralProbability als nächsten Überweisungsfilter und Zeichenintensität als finalen Diskriminator, wenn verfügbar.

Ein Telemedizin-Anbieter: Telemedizin durch klinische Protokolle ermöglichen

In diesem Szenario kombinierte die Organisation die KI-Ausgaben mit traditionellen klinischen Fragebögen, wie der 7-Punkt-Checkliste (7PC), um die am besten geeignete Konsultationsmethode zu bestimmen.

Die 7-Punkt-Checkliste (7PCL) wird von NICE zur routinemäßigen Verwendung in der Hausarztpraxis empfohlen, um klinisch signifikante Läsionen zu identifizieren, die dringende Überweisungen erfordern.

Schwellenwertbildung

Wie Sie sehen können, erfordern die Puzzleteile manchmal die Entscheidung über einen Schwellenwert, ab dem unterschiedliche Maßnahmen ergriffen werden können. Verschiedene Anwendungsfälle können unterschiedliche Schwellenwerte erfordern, normalerweise abhängig von den möglichen Ergebnissen des Workflows.

Wie man einen Schwellenwert wählt

Um zu messen, welcher Schwellenwert für einen Parameter geeignet ist, verwenden wir Verwirrungs-Matrizen.

Eine Verwirrungs-Matrix ist ein grundlegendes Werkzeug in der statistischen Klassifizierung und im maschinellen Lernen. Es ist ein spezifisches Tabellen-Layout, das die Visualisierung der Leistung eines Algorithmus ermöglicht, typischerweise ein Klassifizierer. Die Matrix vergleicht die tatsächlichen Zielwerte mit denen, die vom Modell vorhergesagt wurden, und bietet Einblick nicht nur in die Leistung des Klassifizierers, sondern auch in die Arten von Fehlern, die er macht.

Die Verwirrungs-Matrix ist typischerweise eine 2x2-Matrix für binäre Klassifizierungsaufgaben:

• True Positives (TP): Dies sind Fälle, in denen der Klassifizierer die positive Klasse korrekt vorhersagt.
• True Negatives (TN): Dies sind Fälle, in denen der Klassifizierer die negative Klasse korrekt vorhersagt.
• False Positives (FP): Dies sind Fälle, in denen der Klassifizierer die positive Klasse fälschlicherweise vorhersagt (auch als Fehler erster Art bekannt).
• False Negatives (FN): Dies sind Fälle, in denen der Klassifizierer die negative Klasse fälschlicherweise vorhersagt (auch als Fehler zweiter Art bekannt).

In einer Klassifizierungsaufgabe, besonders bei probabilistischen Klassifizierern, ist der Schwellenwert ein Konzept, das korrekt verstanden werden muss. Im Wesentlichen: ein Schwellenwert ist der Punkt, an dem die Wahrscheinlichkeit entschieden wird, dass ein Datenpunkt zu einer Klasse gegenüber einer anderen gehört.

• Wenn die vom Modell vorhergesagte Wahrscheinlichkeit für eine Klasse höher als der Schwellenwert ist, klassifiziert es den Datenpunkt in diese Klasse.
• Umgekehrt, wenn die Wahrscheinlichkeit niedriger als der Schwellenwert ist, klassifiziert es den Datenpunkt in die andere Klasse.

Wo befindet sich dieser Wert?

Die Verwirrungs-Matrix wird von uns bereitgestellt, da sie das Ergebnis umfangreicher Tests und Validierungen des Geräts ist. Dieser Wert wird normalerweise in Bezug auf Spezifität und Sensibilität ausgedrückt. Es kann von einer Aufgabe zur anderen variieren. Beispielsweise hat die Bildqualität einen anderen Wert als die Klassifizierung einer Erkrankung.

Mit den Informationen von Sensitivität und Spezifität kann jede Organisation einen spezifischen Schwellenwert wählen, je nach ihrem Anwendungsfall.

Anpassung des Schwellenwerts an den Anwendungsfall

Die Bestimmung des geeigneten Schwellenwerts ist vollständig vom Anwendungsfall abhängig. Zum Beispiel beim Entscheiden, ob an einen Spezialisten oder einen Hausarzt überwiesen werden soll:

• Ein niedrigerer Schwellenwert kann dazu führen, dass mehr Fälle an einen Spezialisten überwiesen werden, was möglicherweise mehr echte positive Fälle erfasst, aber auch falsch positive Ergebnisse erhöht.
• Ein höherer Schwellenwert kann die Anzahl falsch positiver Ergebnisse reduzieren, kann aber zum Übersehen echter positiver Fälle führen.

Daher muss der Schwellenwert von der Organisation mit ihrem spezifischen Anwendungsfall im Auge gewählt werden, um ein Gleichgewicht zwischen falsch positiven und falsch negativen Ergebnissen zu erreichen.

Schwellenwert für malignantConditionProbability

malignantConditionProbability ist einer der Werte, die vom Gerät ausgegeben werden, für den eine Organisation möglicherweise einen Schwellenwert wählen muss.

malignantConditionProbability stellt ein quantifiziertes Verdachtsniveau dar: Je höher der Wert, desto größer der Verdacht auf Malignität. Im Gegensatz zu einer binären Ausgabe bietet diese kontinuierliche Skala ein differenzierteres Verständnis, erfordert aber auch einen gut definierten Schwellenwert, um einen Fall als bösartig zu klassifizieren oder nicht.

malignantConditionProbability ist kein einfacher binärer Indikator, sondern ein kumulatives Maß, das aus der Summierung der Wahrscheinlichkeiten verschiedener Klassen abgeleitet wird, die von einem Mehrklassen-Klassifizierungsalgorithmus als bösartig erachtet werden. Dieser Ansatz ist aus mehreren Gründen bedeutsam:

1. Mehrdeutige Natur von Läsionen: Läsionen können Merkmale aufweisen, die sich über mehrere Klassen erstrecken. In solchen Fällen könnte eine einzige Klassifizierung unzureichend sein, um den vollständigen Umfang der Natur der Läsion zu erfassen.
2. Sich entwickelnde Erkrankungen: Einige Läsionen stellen Erkrankungen in Übergangsphasen dar; beispielsweise eine benigne Läsion, die dabei ist, bösartig zu werden.

Dies ist der Grund, warum die Erfassung von Wahrscheinlichkeiten über Klassen hinweg ein dynamischeres Verständnis des aktuellen Zustands der Läsion ermöglicht.

Praktisches Beispiel

Imagine 100 people ask for a consultation, but only 12 of them actually have a malignant condition. If we refer or prioritise cases where isMalignantSuspicion is higher or equal to 05101520253035404550556065707580859095100, then...

12 🙌 Are prioritised and should be prioritised True positives (TP)	88 😅 Are prioritised but should not be prioritised False positives (FP)
0 😣 Are not prioritised but should be prioritised False negatives (FN)	0 👏 Are not prioritised and should not be prioritised True negatives (TN)

Denken Sie daran, dass die Zahl 12 in jeweils 100 Menschen keinen Aufschluss darüber gibt, wie viele Menschen tatsächlich bösartige Bilder einreichen werden. Was Ihnen dies bietet, ist Wissen über die Genauigkeit des Algorithmus mit einem bestimmten Verhältnis von bösartigen zu nicht-bösartigen Bildern.

Schwellenwert für imageQuality.score

imageQuality ist einer der Werte, die vom Gerät ausgegeben werden, für den eine Organisation möglicherweise einen Schwellenwert wählen muss.

imageQuality enthält verschiedene Aspekte der Qualität und Gültigkeit eines Bildes. Innerhalb des technicalSummary-Schlüssels gibt es ein imageQuality-Objekt, das die score enthält.

Im Gegensatz zu einer binären Ausgabe bietet imageQuality.score eine kontinuierliche Skala mit einem differenzierteren Verständnis der Bildqualität. Sie erfordert jedoch einen gut definierten Schwellenwert, um einen Fall als ausreichend qualitativ zu klassifizieren oder nicht.

Praktisches Beispiel

Imagine 100 images are sent to the device. Each image has a mediaValidity.score between 1 and 100. In order to separate good quality images from bad quality images, any image with a mediaValidity.score higher than 0%10%20%30%40%50%60%70%80%90%100% will be accepted.

In this case, due to the threshold of 0%10%20%30%40%50%60%70%80%90%100%, out of the 100 images, only 87 have enough image quality. As a result:

84 📸👌 Have enough quality and are proccessed True positives (TP)	6 😅📸 Have enough quality but are discarded False positives (FP)
3 😅📸 Don't have enough quality but are processed False negatives (FN)	8 📸👏 Don't have enough quality and are discarded True negatives (TN)

Dies kann auch durch ein Annahme-Diagramm verstanden werden. Im folgenden Diagramm sehen Sie, wie viele Bilder je nach Schwellenwert der imageQuality.score akzeptiert werden. Als Beispiele gibt es Markierungen bei den Schwellenwerten von 40 und 80. Im zweiten Fall sehen Sie, dass die Hälfte der Bilder abgelehnt wird.

40 → Acceptance: 99.16%

80 → Acceptance: 49.02%

Denken Sie daran, dass dies keinen Aufschluss darüber gibt, wie viele schlechte Bilder Nutzer tatsächlich einreichen werden. Was Ihnen dies bietet, ist Wissen über die Genauigkeit des Bildqualitäts-Algorithmus. Es erklärt die Verwirrungs-Matrix des DIQA-Algorithmus mit einem bestimmten Verhältnis von guten zu schlechten Bildern.

Woher kommt das?

Um die Genauigkeit des Algorithmus zu bestimmen und zu überprüfen, haben wir den Algorithmus mit einem Datensatz getestet, der von Fachleuten bei dieser Aufgabe gekennzeichnet wurde. Auf diese Weise leiten wir die Verwirrungs-Matrix ab.

Weitere Lektüre: Dermatology Image Quality Assessment (DIQA): Artificial intelligence to ensure the clinical utility of images for remote consultations and clinical trials. Journal of the American Academy of Dermatology.

Priorisierung

Organisationen können Workflows erstellen, um die Priorisierung der Patientenversorgung zu verbessern.

Jede Organisation entwickelt ihre eigenen Protokolle für die Zuweisung von Priorität an Patienten. Das Ziel ist die Optimierung von Überweisungsprozessen, um sicherzustellen, dass Patienten zeitnah und angemessen Versorgung durch die richtigen Fachleute erhalten.

Für Bildungszwecke bietet dieser Abschnitt Beispiele potenzieller Workflows, die eine verwaltende Organisation einsetzen könnte. Diese basieren auf der von unserer API bereitgestellten Information aus dem Diagnosebericht, um Patientenepisoden effektiv zu priorisieren.

Malignität

Ein kritischer Faktor bei der Entscheidungsfindung im Gesundheitswesen ist die Bewertung des Malignität-Risikos.

Die API-Antwort enthält einen Abschnitt mit dem Namen riskMetrics, der Informationen relevant für diese Bewertung enthalten kann. Diese Daten können von Nutzen sein, um den Priorisierungsprozess zu informieren, wie nachstehend detailliert dargelegt:

Risk metrics

{
  // ...
  "riskMetrics": {
    // ...
    "malignantConditionProbability": 62.0
    // ...
  }
  // ...
}

Der Parameter malignantConditionProbability kann verwendet werden, um bei der Entscheidungsfindung zur Zuweisung von Priorität an Patienten zu helfen.

Hier ist eine einfache Regel, um Patientenprioritäten basierend auf diesem Parameter zu kategorisieren:

• Wenn malignantConditionProbability zwischen 0 und 30% liegt, kann der Patient als Priorität normal kategorisiert werden.
• Wenn malignantConditionProbability über 30% hinausgeht, sollte der Patient als Priorität hoch betrachtet werden.

Dieser Entscheidungsprozess kann mit einem Flussdiagramm visualisiert werden:

Darauf aufbauend:

• Patienten mit malignantConditionProbability über 30% sind nicht nur hohe Priorität, sondern können auch Kandidaten für schnelle Bearbeitung sein.

Ein weiteres Flussdiagramm kann diese erweiterten Entscheidungskriterien veranschaulichen:

Sortierung nach Malignität

Organisationen können ihre Priorisierungsstrategien verfeinern, indem sie Fälle nach dem Grad des Malignität-Verdachts ordnen. Beispielsweise können zwei Patienten, die beide in die Kategorie Hohe Priorität aufgrund ihrer Malignität-Werte fallen (einer bei 60 und ein anderer bei 30), weiter triagiert werden. Dieser Ansatz beinhaltet die Einstufung von Patienten in der Gruppe Hohe Priorität von höchstem zu niedrigstem basierend auf ihrem Malignität-Wert.

Diese Methode ermöglicht eine differenziertere Priorisierung und stellt sicher, dass Patienten mit höherem Verdacht auf Risiko dringender betreut werden.

Falls die verwaltende Organisation es sich entscheidet, diese Malignität-Information für Fachleute im Gesundheitswesen (HCPs) sichtbar zu machen, könnte der folgende Charttyp implementiert werden, um diesen verfeinerten Priorisierungsprozess zu erleichtern:

malignancy: 6%

malignancy: 62%

Andere Workflows

Schweregrad

Der Schweregrad einer Erkrankung ist eine der Variablen, die HCPs in ihrer Entscheidungsfindung verwenden.

Eine Antwort von der API enthält einen Abschnitt namens findings, der möglicherweise die folgende Information für jedes erkannte Zeichen enthält:

Findings

{
  // ...
  "findings": [
    {
      "signIdentifier": "erythema",
      "intensity": {
        "grade": 5.8,
        "gradingScale": "Legit.Health"
      }
      // ...
    }
  ]
}

Wie Sie sehen, enthält jedes Zeichen (wie erythema) ein intensity-Objekt. In diesem Beispiel sehen wir, dass das Zeichen intensity.grade 5.8 ist.

Eine sehr einfache Regel würde sein:

• Wenn intensity.grade niedriger als 3 ist, würde es Workflow A auslösen
• Wenn intensity.grade höher als 7 ist, würde es Workflow B auslösen

Dies kann nützlich sein, beispielsweise wenn ein HCP entscheiden muss, ob ein Patient an einen Spezialisten überwiesen wird oder nicht. Es kann auch nützliche Information sein, um die Wirksamkeit einer Behandlung zu überwachen.

In diesem Beispiel würde Workflow A derjenige sein, der anwendbar ist, wenn der Schweregrad der Erkrankung unter Kontrolle ist, beispielsweise, weil er richtig auf die Behandlung anspricht.

Darüber hinaus können Sie den Prozess durch Hinzufügen von Informationen aus der Krankengeschichte des Patienten bereichern. Beispielsweise, wenn Sie mit vorherigen Aufzeichnungen vergleichen, könnte das Ergebnis sein:

• Wenn intensity.grade 5 ist und die vorherige Aufzeichnung 8 war, würde es Workflow C auslösen (verbessernd)
• Andernfalls würde es zu Workflow A zurückfallen

Die verwaltende Organisation kann auch beschließen, diese Information dem HCP zu zeigen, wobei ein Chart wie das folgende implementiert werden könnte:

Der Wert für den Schweregrad kann visuell angezeigt werden. Die Art und Weise, dies zu tun, ist die Verwendung der im intensity zurückgegebenen Werte:

intensity.grade: 2

intensity.grade: 8

Frühere Existenz der Erkrankung

Ob eine Erkrankung neu für einen Patienten ist oder bereits diagnostiziert wurde, ist eine der Variablen, die HCPs in ihrer Entscheidungsfindung verwenden.

Eine Antwort von der API enthält einen Abschnitt namens hypotheses, der möglicherweise die folgende Information enthält:

Hypothesis

{
  // ...
  "hypotheses": [
    {
      "identifier": "Eczematous dermatitis",
      "concepts": [
        {
          "name": "Generalised eczematous dermatitis of unspecified type",
          "code": "EA89",
          "terminologySystem": "icd-11"
        }
      ],
      "probability": 69.82
    }
    // ...
  ]
  // ...
}

Was diese Information zeigt, ist, dass eine Erkrankung eine Wahrscheinlichkeit von 69.82 (69,82%) hat. Der Name der Erkrankung ist Generalised eczematous dermatitis of unspecified type, kodiert als EA89 gemäß dem System ICD-11.

Was ein HCP tun könnte, ist nachschlagen, ob diese Erkrankung dem Patienten bereits zuvor diagnostiziert wurde, und diese Information bei ihrer Entscheidungsfindung nutzen.