Legit.Health Plus

Dans cette section, nous présentons des exemples pratiques de flux de travail qui peuvent être intégrés dans vos systèmes, en utilisant les données fournies par l'API de notre appareil.

Nous reconnaissons que l'intégration de données de notre API dans vos systèmes existants peut être une tâche complexe, en particulier si c'est la première expérience de votre organisation avec un tel appareil. Ces exemples sont conçus pour vous aider et vous guider tout au long de ce processus d'intégration.

Veuillez noter que la flexibilité de notre API permet une large gamme d'implémentations de flux de travail. Les exemples présentés ici ne sont pas exhaustifs et ne doivent pas être interprétés comme les seules méthodes ou comme des approbations de pratiques particulières. Chaque organisation a des besoins et des exigences uniques. Par conséquent, il est crucial que les organisations de gestion développent des flux de travail qui s'alignent sur leurs meilleures pratiques internes et respectent les directives établies par leurs professionnels de la santé.

Pièces du puzzle

Considérez la sortie de notre appareil comme des pièces d'un puzzle. L'appareil génère un fichier JSON, riche en données, organisé sous diverses clés. Ces clés servent d'éléments fondamentaux dans votre processus de conception de flux de travail. Vous pouvez envisager chaque clé comme une branche distincte dans un arbre de prise de décision ou, de manière plus créative, comme une pièce de puzzle unique. Cette analogie met en évidence la flexibilité et l'adaptabilité des données; vous pouvez arranger et intégrer ces pièces dans de nombreuses configurations pour répondre à vos besoins spécifiques de flux de travail.

Lectures complémentaires

Veuillez lire la section <Output/> des Instructions For Use pour plus d'informations.

Clés du point de terminaison DiagnosisSupport

Clés du point de terminaison SeverityMeasure

Il y a plus de pièces de puzzle

L'API retourne bien d'autres champs que ceux présentés ici. Ces exemples mettent en évidence uniquement un petit sous-ensemble de clés qui sont particulièrement utiles pour le tri et l'acheminement opérationnel.

Flux de travail par objectif clinique et opérationnel

La même sortie peut soutenir des flux de travail très différents. Un flux de tri axé sur la sécurité peut fortement s'appuyer sur urgentReferralProbability, tandis qu'un flux axé sur la capacité peut utiliser entropy et la gravité pour décider quels cas peuvent rester dans des voies moins intensives.

En pratique, les organisations combinent généralement plusieurs objectifs à la fois: réduire les cas graves manqués, protéger la capacité des spécialistes et maintenir le suivi à faible risque gérable. Les exemples ci-dessous illustrent comment les mêmes pièces peuvent être arrangées différemment en fonction de l'objectif opérationnel.

1. Autonomiser les soins primaires: Tri

Objectif: Réduire les premières visites en dermatologie en éliminant les cas bénins ou simples au niveau des soins primaires.

Ce flux utilise urgentReferralProbability comme premier signal d'escalade, highPriorityReferralProbability comme filtre d'orientation suivant, et entropy comme porte d'incertitude.

2. Faciliter la télémédecine: Distanciel vs En personne

Objectif: Décider quelles visites peuvent être résolues en toute sécurité à distance et lesquelles nécessitent une consultation en personne, en réduisant les visites inutiles à l'hôpital.

Les quatre résultats possibles sont:

• Soins primaires : Distanciel (🤳): R1.
• Soins primaires : En personne (🏥🚶): P1.
• Soins secondaires : Distanciel (🤳): R2.
• Soins secondaires : En personne (🏥🚶): P2.

Les organisations peuvent réserver la capacité des spécialistes en personne pour les cas à la fois à haut risque et difficiles à classer.

3. Optimiser les suivis des patients chroniques

Objectif: Réduire le volume de visites de suivi inutiles, en particulier dans les pathologies chroniques, en vérifiant si la condition persiste et en évaluant sa gravité.

Les deux résultats possibles sont:

• Évolution conforme: OK.
• Anomalie: !.

En incorporant l'historique du patient, nous pouvons déterminer si une condition précédemment diagnostiquée est toujours présente et évaluer si la gravité indique une anomalie.

4. Acheminement spécialisé et multi-spécialité

Objectif: Orienter le patient directement vers le spécialiste approprié. Cela pourrait être un dermatologue ayant une sous-spécialité dédiée (comme une unité monographique pour les lésions pigmentées, le mélanome ou l'hidradénite suppurée), ou un spécialiste d'un autre domaine médical (comme la gastro-entérologie, la rhumatologie, l'allergologie ou la génétique) lorsque la lésion dermatologique est une manifestation d'une maladie systémique sous-jacente, une comorbidité ou une condition rare.

Cet acheminement repose sur l'évaluation de métriques spécifiques comme pigmentedConditionProbability ou l'analyse du tableau hypotheses. Les organisations peuvent définir des critères pour déclencher ces orientations précises, tels que vérifier si une probabilité dépasse un certain seuil, si un code spécifique apparaît dans les résultats Top-1 ou Top-3, ou même en fonction de la somme des probabilités pour un groupe de conditions connexes. Par exemple, si Hidradénite suppurée apparaît comme le résultat Top-1, le patient peut être orienté directement vers l'unité monographique pour cette maladie.

5. Prioriser les listes d'attente

Objectif: Réorganiser dynamiquement les listes d'attente actuelles pour assurer que les patients ayant des besoins cliniques plus élevés sont vus en premier.

6. Campagnes de prévention et santé au travail

Objectif: Mettre en œuvre des flux de dépistage automatisés lors des contrôles de santé au travail ou des campagnes de prévention publiques.

Études de cas du monde réel

Une compagnie d'assurance maladie: Tri soins primaires vs secondaires

Dans ce scénario, l'organisation (une compagnie d'assurance maladie) divise les cas en deux résultats pour gérer efficacement le flux de patients entre les niveaux de soins primaires et secondaires.

Les deux résultats possibles sont:

• Soins primaires: résultat 1.
• Soins secondaires: résultat 2.

Voici leur flux de travail configuré avec des seuils opérationnels réels:

Ce flux utilise urgentReferralProbability comme premier signal d'escalade, entropy comme porte d'incertitude, highPriorityReferralProbability comme filtre d'orientation suivant, et l'intensité des signes comme discriminateur final lorsqu'il est disponible.

Un fournisseur de télémédecine: Faciliter la télémédecine via les protocoles cliniques

Dans ce scénario, l'organisation a combiné les sorties de l'IA avec des questionnaires cliniques traditionnels, tels que la liste de contrôle à 7 points (7PC), pour déterminer la méthode de consultation la plus appropriée.

La liste de contrôle à 7 points (7PCL) est recommandée par NICE pour un usage courant en médecine générale afin d'identifier les lésions cliniquement significatives nécessitant une orientation urgente.

Définition des seuils

Comme vous pouvez le voir, les pièces du puzzle exigent parfois de décider d'un seuil à partir duquel différentes actions peuvent être prises. Différents cas d'usage peuvent nécessiter des seuils différents, généralement en fonction des résultats possibles du flux de travail.

Comment décider d'un seuil

Pour mesurer quel est le seuil approprié pour un paramètre, nous utilisons des matrices de confusion.

Une matrice de confusion est un outil fondamental en classification statistique et apprentissage automatique. C'est une disposition de tableau spécifique qui permet de visualiser la performance d'un algorithme, généralement un classificateur. La matrice compare les valeurs réelles avec celles prédites par le modèle, fournissant un aperçu non seulement de la performance du classificateur, mais aussi des types d'erreurs qu'il commet.

La matrice de confusion est généralement une matrice 2x2 pour les tâches de classification binaire:

• Vrais positifs (TP): Ce sont les cas où le classificateur prédit correctement la classe positive.
• Vrais négatifs (TN): Ce sont les cas où le classificateur prédit correctement la classe négative.
• Faux positifs (FP): Ce sont les cas où le classificateur prédit incorrectement la classe positive (également connu comme erreur de type I).
• Faux négatifs (FN): Ce sont les cas où le classificateur prédit incorrectement la classe négative (également connu comme erreur de type II).

Dans une tâche de classification, en particulier pour les classificateurs probabilistes, le seuil est un concept qui doit être correctement compris. En essence: un seuil est le point auquel la probabilité qu'un point de données appartienne à une classe plutôt qu'à une autre est décidée.

• Lorsque la probabilité prédite par le modèle pour une classe est supérieure au seuil, il classe le point de données dans cette classe.
• Inversement, si la probabilité est inférieure au seuil, il classe le point de données dans l'autre classe.

Où est cette valeur?

La matrice de confusion nous est fournie, car elle est le résultat du test et de la validation extensive de l'appareil. Cette valeur est généralement exprimée en termes de spécificité et de sensibilité. Elle peut varier d'une tâche à l'autre. Par exemple, la qualité d'image a une valeur différente de celle de la classification d'une condition.

Avec les informations de sensibilité et de spécificité, chaque organisation peut décider d'un seuil spécifique, en fonction de son cas d'usage.

Adapter le seuil au cas d'usage

Déterminer le seuil approprié est entièrement dépendant du cas d'usage. Par exemple, en décidant si orienter vers un spécialiste ou un praticien des soins primaires:

• Un seuil plus bas peut conduire à l'orientation de plus de cas vers un spécialiste, en attrapant potentiellement plus de vrais cas positifs mais en augmentant aussi les faux positifs.
• Un seuil plus élevé peut réduire le nombre de faux positifs, mais peut conduire à manquer de vrais cas positifs.

Par conséquent, le seuil doit être choisi par l'organisation en tenant compte de son cas d'usage spécifique, en équilibrant les résultats des faux positifs et des faux négatifs.

Seuil pour malignantConditionProbability

malignantConditionProbability est l'une des valeurs produites par l'appareil pour laquelle une organisation peut avoir besoin de choisir un seuil.

malignantConditionProbability représente un niveau de suspicion quantifié: plus la valeur est élevée, plus la suspicion de malignité est grande. Contrairement à une sortie binaire, cette échelle continue fournit une compréhension plus nuancée, mais nécessite également un seuil bien défini pour classer un cas comme malin ou non.

malignantConditionProbability n'est pas un simple indicateur binaire, mais une mesure cumulative dérivée de la somme des probabilités de diverses classes jugées malignes par un algorithme de classification multi-classe. Cette approche est significative pour plusieurs raisons:

1. Nature ambiguë des lésions: les lésions peuvent exhiber des caractéristiques qui s'étendent sur plusieurs classes. Dans de tels cas, une classification unique peut être insuffisante pour capturer la portée complète de la nature de la lésion.
2. Conditions évolutives: Certaines lésions représentent des conditions en transition; par exemple, une lésion bénigne qui est en train de devenir maligne.

C'est pourquoi capturer les probabilités dans les classes permet une compréhension plus dynamique de l'état actuel de la lésion.

Exemple pratique

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)

Gardez à l'esprit que le chiffre 12 pour 100 personnes ne donne pas d'aperçu du nombre de personnes qui soumettront réellement des images malignes. Ce que cela vous donne, c'est une connaissance de la précision de l'algorithme, avec un ratio donné d'images malignes à non malignes.

Seuil pour imageQuality.score

imageQuality est l'une des valeurs produites par l'appareil pour laquelle une organisation peut avoir besoin de choisir un seuil.

imageQuality contient différents aspects de la qualité et de la validité d'une image. À l'intérieur de la clé technicalSummary, se trouve un objet imageQuality qui contient le score.

Contrairement à une sortie binaire, imageQuality.score fournit une échelle continue avec une compréhension plus nuancée de la qualité d'image. Cependant, cela nécessite un seuil bien défini pour classer un cas comme ayant une qualité suffisante ou non.

Exemple pratique

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)

Cela peut aussi être compris à travers un graphique d'acceptation. Dans le graphique suivant, vous verrez combien d'images sont acceptées en fonction du seuil du imageQuality.score. À titre d'exemples, il y a des marques définies aux seuils 40 et 80. Dans le second cas, on peut voir que la moitié des images seront rejetées.

40 → Acceptance: 99.16%

80 → Acceptance: 49.02%

Gardez à l'esprit que cela ne donne pas d'aperçu du nombre d'images de mauvaise qualité que les utilisateurs enverront réellement. Ce que cela vous donne, c'est une connaissance de la précision de l'algorithme de qualité d'image. Cela explique la matrice de confusion de l'algorithme DIQA, avec un ratio donné d'images bonnes à mauvaises.

D'où cela vient-il?

Pour déterminer et vérifier la précision de l'algorithme, nous avons testé l'algorithme avec un ensemble de données qui a été étiqueté par des experts dans cette tâche. C'est ainsi que nous dérivons la matrice de confusion.

Lectures complémentaires: 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.

Priorisation

Les organisations peuvent créer des flux de travail pour améliorer la priorisation des soins aux patients.

Chaque organisation développe ses propres protocoles pour assigner la priorité aux patients. L'objectif est d'optimiser les processus d'orientation, en garantissant que les patients reçoivent des soins opportuns et appropriés des bons professionnels de la santé.

À titre d'éducation, cette section offre des exemples de flux de travail potentiels qu'une organisation de gestion pourrait employer. Ceux-ci sont basés sur les informations du rapport de diagnostic fournies par notre API, pour prioriser efficacement les épisodes patients.

Malignité

Un facteur critique dans la prise de décision médicale est l'évaluation du risque de malignité.

La réponse de l'API inclut un segment libellé riskMetrics, qui peut présenter des informations pertinentes à cette évaluation. Ces données peuvent être un outil important pour informer le processus de priorisation, comme détaillé ci-dessous:

Métriques de risque

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

Le paramètre malignantConditionProbability peut être utilisé pour aider à la prise de décision d'assigner une priorité aux patients.

Voici une règle simple pour catégoriser la priorité des patients en fonction de ce paramètre:

• Quand malignantConditionProbability est de 0 à 30%, le patient peut être catégorisé comme priorité normale.
• Si malignantConditionProbability dépasse 30%, le patient doit être considéré comme priorité élevée.

Ce processus de prise de décision peut être visualisé à l'aide d'un organigramme:

En développant cela:

• Les patients avec malignantConditionProbability dépassant 30% ne sont pas seulement une priorité élevée, mais peuvent aussi être des candidats pour un traitement accéléré.

Un autre organigramme peut aider à illustrer ce critère de prise de décision étendu:

Ordonner par malignité

Les organisations peuvent affiner leurs stratégies de priorisation en classant les cas en fonction du niveau de suspicion de malignité. Par exemple, deux patients qui tombent tous deux dans la catégorie Priorité élevée en raison de leurs niveaux de malignité (l'un à 60 et un autre à 30) peuvent être davantage triés. Cette approche implique de classer les patients dans le groupe Priorité élevée du plus élevé au plus bas en fonction de leur score de malignité.

Cette méthode permet une priorisation plus nuancée, en garantissant que ceux ayant des risques suspectés plus élevés sont traités plus rapidement.

Si l'organisation de gestion choisit de rendre ces informations de malignité visibles aux professionnels de la santé (PDS), le type de graphique suivant pourrait être implémenté pour faciliter ce processus de priorisation raffiné:

malignité: 6%

malignité: 62%

Autres flux de travail

Gravité

La gravité d'une condition est l'une des variables que les professionnels de la santé utilisent dans leur prise de décision.

Une réponse de l'API contient une section appelée findings qui peut inclure les informations suivantes pour chaque signe détecté:

Résultats

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

Comme vous pouvez le voir, chaque signe (comme erythema) inclut un objet intensity. Dans cet exemple, nous voyons que le signe intensity.grade est 5.8.

Une règle très simple serait:

• Si le intensity.grade est inférieur à 3, cela déclencherait le flux de travail A
• Si le intensity.grade est supérieur à 7, cela déclencherait le flux de travail B

Cela peut être utile, par exemple, quand un professionnel de la santé doit décider s'il faut ou non orienter un patient vers un spécialiste. Cela peut aussi être des informations utiles pour surveiller l'efficacité d'un traitement.

Dans cet exemple, le flux de travail A serait celui applicable quand la gravité de la condition est sous contrôle, par exemple, parce qu'il répond correctement au traitement.

De plus, vous pouvez enrichir le processus en ajoutant des informations sur l'historique du patient. Par exemple, si vous comparez avec les dossiers antérieurs, le résultat pourrait être:

• Si le intensity.grade est 5, et le dossier précédent était 8, cela déclencherait le flux de travail C (amélioration)
• Sinon, ce serait un retour au flux de travail A

L'organisation de gestion peut aussi décider d'afficher ces informations au professionnel de la santé, auquel cas un graphique comme celui-ci pourrait être implémenté:

Le score de gravité peut être affiché visuellement. La façon de le faire est d'utiliser les valeurs retournées dans intensity:

intensity.grade: 2

intensity.grade: 8

Existence antérieure de la condition

Que la condition soit nouvelle pour un patient ou déjà diagnostiquée chez ce patient est l'une des variables que les professionnels de la santé utilisent dans leur prise de décision.

Une réponse de l'API contient une section appelée hypotheses qui peut inclure les informations suivantes:

Hypothèse

{
  // ...
  "hypotheses": [
    {
      "identifier": "Dermatite eczémateuse",
      "concepts": [
        {
          "name": "Dermatite eczémateuse généralisée de type non spécifié",
          "code": "EA89",
          "terminologySystem": "icd-11"
        }
      ],
      "probability": 69.82
    }
    // ...
  ]
  // ...
}

Ce que ces informations montrent, c'est qu'une condition a une probabilité de 69.82 (69,82%). Le nom de la condition est Dermatite eczémateuse généralisée de type non spécifié, codée comme EA89 selon le système ICD-11.

Ce qu'un professionnel de la santé pourrait faire est de vérifier si cette condition a été précédemment diagnostiquée chez le patient, et d'utiliser ces informations dans sa prise de décision.