Legit.Health
Dans cette section, nous présentons des exemples pratiques de workflows 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 workflows. 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 dirigeantes développent des workflows qui s'alignent avec leurs meilleures pratiques internes et qui adhèrent aux directives établies par leurs professionnels de santé.
Pièces de 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 workflow. Vous pouvez envisager chaque clé comme une branche distincte dans un arbre de décision ou, de manière plus créative, comme une pièce de puzzle unique. Cette analogie souligne la flexibilité et l'adaptabilité des données. Vous pouvez assembler et intégrer ces pièces dans de nombreuses configurations pour répondre à vos besoins spécifiques de workflow.
Veuillez lire la section Installation Manual des Instructions d'utilisation pour plus d'informations.
L'API retourne plus de 100 lignes de données, et ces exemples n'utilisent que 6 clés de la sortie. Cela signifie qu'il y a beaucoup plus de pièces de puzzle qui pourraient être plus utiles à votre organisation. N'hésitez pas à nous contacter pour nous demander quels endpoints pourraient être adaptés à votre cas d'usage.
Assembler le puzzle
Voyons des exemples pratiques montrant comment vous pouvez assembler les pièces du puzzle pour formuler un workflow efficace.
Soins primaires vs. soins secondaires
Dans ce scénario, nous démontrons un workflow qui se bifurque en deux chemins distincts: Soins primaires et Soins secondaires. La décision entre ces résultats est illustrée dans le tableau suivant:
| Soins primaires | 1 |
|---|---|
| Soins secondaires | 2 |
En s'appuyant sur cela, un workflow potentiel pourrait incorporer des pièces de puzzle spécifiques qui aident une organisation à affiner et à améliorer l'efficacité de son processus de référence. Le flux combine maintenant urgentReferral, highPriorityReferral et l'entropie du modèle comme points de décision principaux, au lieu de se fier uniquement à malignancy:
Workflow alternatif avec Correspondance des classes ICD
Correspondance des classes ICDCeci peut incorporer d'autres pièces de puzzle, comme la mise en correspondance d'une liste particulière de classes ICD. Dans l'exemple suivant, le flux vérifie une liste de classes que l'organisation estime devoir être vues directement par les soins secondaires.
Pour déterminer les seuils, l'organisation doit tenir compte de deux choses:
- Quels sont les résultats possibles du workflow?
- Quelle est la sensibilité et la spécificité du paramètre?
Dans ce cas, le résultat de l'organigramme inclut toujours voir un professionnel de santé. De ce fait, si l'organisation cherche à réduire les listes d'attente pour augmenter la sécurité des patients, il peut être judicieux d'établir un seuil élevé.
Vous pouvez trouver plus d'informations sur ce sujet dans la section Seuils de décision, où nous expliquons la matrice de confusion de certains paramètres.
Consultation à distance vs. en personne
Une organisation peut viser à améliorer son processus de consultation en déterminant efficacement la méthode la plus appropriée pour chaque cas, qu'il s'agisse d'une consultation à distance ou en personne.
Pour cet exemple, nous continuons avec les deux résultats établis: Soins primaires et Soins secondaires. Nous élargissons ce processus décisionnel en ajoutant la dimension du type de consultation: À distance ou En personne, comme illustré dans le tableau suivant:
| 🤳 À distance | 🏥🚶 En personne | |
|---|---|---|
| Soins primaires | R1 | P1 |
| Soins secondaires | R2 | P2 |
Pourquoi cela importe
La mise en œuvre d'une stratégie pour améliorer l'efficacité des consultations et réduire les temps d'attente des patients pourrait impliquer de diriger plus de cas vers des médecins de soins primaires ou d'exploiter des méthodes de consultation plus rapides. Le tableau ci-dessous montre la direction souhaitée pour chaque niveau de soins et type de consultation:
| 🤳 À distance | 🏥🚶 En personne | |
|---|---|---|
| Soins primaires | Objectif: Augmenter ↑ | - |
| Soins secondaires | - | Objectif: Diminuer ↓ |
Exemple de workflow
Le workflow conçu pour atteindre ces objectifs pourrait être structuré comme suit:
Ceci peut être complété par des questionnaires spécifiques à la condition, comme la liste de contrôle des 7 points (7PC). La liste de contrôle des 7 points (7PCL) a été recommandée par NICE (2005) pour une utilisation systématique en médecine générale au Royaume-Uni afin d'identifier les lésions cliniquement significatives qui nécessitent une référence urgente.
Dans l'organigramme suivant, la sortie de urgentReferral est suivie du questionnaire 7PC, pour spécifier davantage la bonne méthode pour les consultations.
Pour déterminer les seuils, l'organisation doit tenir compte de deux choses:
- Quels sont les résultats possibles du workflow?
- Quelle est la sensibilité et la spécificité du paramètre?
Dans ce cas, le résultat de l'organigramme inclut toujours voir un professionnel de santé. De ce fait, si l'organisation cherche à réduire les listes d'attente pour augmenter la sécurité des patients, il peut être judicieux d'établir un seuil élevé.
Vous pouvez trouver plus d'informations sur ce sujet dans la section Seuils de décision, où nous expliquons la matrice de confusion de certains paramètres.
Affinage des méthodes de communication pour la consultation
Pour optimiser davantage le processus de consultation, nous pouvons spécifier différentes méthodes pour les consultations à distance et en personne, en les alignant sur des objectifs spécifiques:
| 🤳 À distance | 🏥🚶 En personne | |||
|---|---|---|---|---|
| Consultation par chat | Consultation vidéo | Équipe interne | Équipe externe | |
| Soins primaires | Objectif: Augmenter ↑ | - | - | - |
| Soins secondaires | - | - | Objectif: Diminuer ↓ | Objectif: Diminuer ↓ |
Suivi des patients chroniques
Les organisations peuvent viser à améliorer le suivi à distance des patients chroniques pour améliorer la surveillance des patients et évaluer l'efficacité du traitement.
Dans ce cas, nous continuons à différencier entre Soins primaires et Soins secondaires. Cependant, nous tenons maintenant compte de l'état de la condition du patient, catégorisée comme En progression attendue ou affichant une Anomalie, comme illustré ci-dessous:
| En progression attendue | OK |
|---|---|
| Anomalie | ! |
Bien que l'appareil ne déclare pas explicitement si la condition d'un patient évolue comme attendu, il fournit un score score.interpretation.intensity. Ce score, comprenant les valeurs 0, 1, 2 et 3, indique le niveau d'impact de la condition, avec 2 et 3 représentant des conditions modérées ou sévères.
Veuillez lire la section Installation Manual des Instructions d'utilisation pour plus d'informations.
En se basant sur cela, une organisation pourrait implémenter le workflow suivant:
Seuils de décision
Comme vous pouvez le voir, les pièces de puzzle nécessitent parfois de décider d'un seuil à partir duquel différentes actions peuvent être entreprises. Différents cas d'usage peuvent nécessiter différents seuils, généralement selon les résultats possibles du workflow.
Comment décider 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 cibles 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 connue sous le nom d'erreur de type I).
- Faux négatifs (FN): Ce sont les cas où le classificateur prédit incorrectement la classe négative (également connue sous le nom d'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.
La matrice de confusion nous est fournie, car c'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 sensibilité et de spécificité. 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, selon 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, pour décider s'il faut référer à un spécialiste ou à un praticien de soins primaires:
- Un seuil plus bas peut entraîner plus de cas référés à un spécialiste, rattrapant potentiellement plus de vrais positifs mais aussi augmentant les faux positifs.
- Un seuil plus élevé peut réduire le nombre de faux positifs mais peut entraîner l'oubli de vrais positifs.
Par conséquent, le seuil doit être choisi par l'organisation avec son cas d'usage spécifique à l'esprit, en équilibrant les résultats des faux positifs et des faux négatifs.
Seuil pour malignancy
malignancy est l'une des valeurs en sortie de l'appareil pour laquelle une organisation peut avoir besoin de choisir un seuil.
malignancy représente un niveau de suspicion quantifié: plus la valeur est élevée, plus grande est la suspicion de malignité. Contrairement à une sortie binaire, cette échelle continue offre une compréhension plus nuancée mais nécessite aussi un seuil bien défini pour classer un cas comme malin ou non.
malignancy n'est pas un indicateur binaire simple mais une mesure cumulative dérivée de la somme des probabilités de diverses classes considérées comme malignes par un algorithme de classification multi-classe. Cette approche est significative pour plusieurs raisons:
- Nature ambiguë des lésions: les lésions peuvent présenter des caractéristiques qui s'étendent sur plusieurs classes. Dans ces cas, une classification unique peut être insuffisante pour capturer l'étendue complète de la nature de la lésion.
- 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 sur 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 , 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 sur le nombre de personnes qui soumettront réellement des images malignes. Ce que cela vous donne est une connaissance de la précision de l'algorithme, avec un rapport donné d'images malignes à non-malignes.
Seuil pour mediaValidity.quality.score
mediaValidity est l'une des valeurs en sortie de l'appareil pour laquelle une organisation peut avoir besoin de choisir un seuil.
mediaValidity contient différents aspects de la qualité d'une image. À l'intérieur de cette clé, il existe plusieurs clés telles que isValid, quality.acceptable, domain.isDermatological et surtout, quality.score.
Contrairement à une sortie binaire, score fournit une échelle continue avec une compréhension plus nuancée de la qualité de l'image. Cependant, elle 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 will be accepted.
In this case, due to the threshold of , 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 par un graphique d'acceptation. Dans le graphique suivant, vous verrez combien d'images sont acceptées selon le seuil de mediaValidity.quality.score. À titre d'exemples, il y a des marques définies aux seuils de 40 et 80. Dans le deuxième 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 sur le nombre d'images mauvaises que les utilisateurs enverront réellement. Ce que cela vous donne est une connaissance de la précision de l'algorithme de qualité d'image. Il explique la matrice de confusion de l'algorithme DIQA, avec un rapport donné d'images bonnes à mauvaises.
Pour déterminer et vérifier la précision de l'algorithme, nous avons testé l'algorithme avec un ensemble de données étiqueté par des experts dans cette tâche. C'est ainsi que nous dérivons la matrice de confusion.
Lectures supplé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 workflows 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 de référence, en s'assurant que les patients reçoivent des soins opportuns et appropriés des bons professionnels de santé.
À titre éducatif, cette section propose des exemples de workflows potentiels qu'une organisation gestionnaire pourrait employer. Ceux-ci sont basés sur les informations du rapport diagnostique fournies par notre API, pour prioriser efficacement les épisodes des patients.
Malignité
L'un des facteurs critiques dans la prise de décision en santé est l'évaluation du risque de malignité.
La réponse API comprend un segment appelé clinicalIndicator, qui peut présenter des informations pertinentes pour cette évaluation. Ces données peuvent être déterminantes pour informer le processus de priorisation, comme détaillé ci-dessous:
{
// ...
"clinicalIndicator": {
// ...
"malignancy": 62
// ...
}
// ...
}
Le paramètre malignancy peut être utilisé pour aider à la prise de décision d'assigner la priorité aux patients.
Voici une règle simple pour catégoriser la priorité des patients en fonction de ce paramètre:
- Lorsque
malignancyest de0à30%, le patient peut être catégorisé comme priorité normale. - Si
malignancydépasse30%, le patient doit être considéré comme priorité élevée.
Ce processus décisionnel peut être visualisé à l'aide d'un organigramme:
En allant plus loin:
- Les patients avec
malignancydépassant30%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 décisionnel étendu:
Les organisations peuvent affiner leurs stratégies de priorisation en triant les cas en fonction du niveau de suspicion de malignité. Par exemple, deux patients qui entrent tous deux dans la catégorie Priorité élevée en raison de leurs niveaux de suspicion de malignité (l'un à 60 et un autre à 30) peuvent être triés davantage. 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 suspicion de malignité.
Cette méthode permet une priorisation plus nuancée, en s'assurant que ceux qui ont des risques suspectés plus élevés sont traités plus rapidement.
Si l'organisation gestionnaire choisit de rendre ces informations de suspicion de malignité visibles aux professionnels de santé (HCP), le type de graphique suivant pourrait être implémenté pour faciliter ce processus de priorisation affiné:
Autres workflows
Sévérité
La sévérité d'une condition est l'une des variables que les professionnels de santé (HCP) utilisent dans leur prise de décision.
Une réponse de l'API contient une section appelée patientEvolution qui peut inclure les informations suivantes:
{
// ...
"patientEvolution": {
"alegi": {
"score": {
"value": 8,
"interpretation": {
"category": "Grade 1",
"intensity": 1
}
}
// ...
}
// ...
}
}
Comme vous pouvez le voir, l'entrée du système de scoring inclut un score.value. Dans cet exemple, nous voyons que le score de sévérité est 8.
À l'intérieur de score.interpretation, vous pouvez voir que la valeur tombe sous l'intensité 1, ce qui signifie que c'est la sévérité la plus basse possible. Le category pour cette intensité est Grade 1, qui est une interprétation sémantique du score qui reflète directement la sévérité.
Une règle très simple serait:
- Si la
score.interpretation.intensityest1, cela déclencherait le workflow A - Si la
score.interpretation.intensityest3, cela déclencherait le workflow B
Cela peut être utile, par exemple, lorsqu'un professionnel de santé doit décider s'il doit ou non référer un patient à un spécialiste. Cela peut aussi être des informations utiles pour surveiller l'efficacité d'un traitement.
Dans cet exemple, le workflow A serait celui applicable lorsque la sévérité 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 envoyez également des données à l'intérieur de la clé previousMedia lorsque vous faites votre demande, le résultat pourrait être:
- Si la
score.interpretation.intensityest2, et la photo précédente n'était pas3, cela déclencherait le workflow C - Sinon, elle reviendrait au workflow A
L'organisation gestionnaire peut aussi décider de montrer ces informations au professionnel de santé, auquel cas un graphique comme celui-ci pourrait être implémenté:
Le score de la sévérité peut être affiché visuellement. La façon de faire cela est d'utiliser les valeurs retournées dans la score.interpretation:
Existence antérieure de la condition
Qu'une condition soit nouvelle pour un patient ou qu'elle ait déjà été diagnostiquée chez ce patient est l'une des variables que les professionnels de santé utilisent dans leur prise de décision.
Une réponse de l'API contient une section appelée conclusion qui peut inclure les informations suivantes:
{
// ...
"conclusion": [
{
"code": {
"coding": [
{
"system": "https://icd.who.int/browse/2025-01/mms/en",
"systemDisplay": "ICD-11",
"code": "DA04.5",
"display": "Mucous cyst"
}
],
"text": "Mucous cyst"
},
"probability": 87.77
}
// ...
]
// ...
}
Ce que ces informations montrent est qu'une condition a une probabilité de 87.77. Le nom de la condition est Mucous cyst, codé comme DA04.5 selon le système ICD-11.
Ce qu'un professionnel de santé peut faire est de vérifier si cette condition a été déjà diagnostiquée chez le patient, et utiliser ces informations dans sa prise de décision.