Saltar al contenido principal

Legit.Health Plus

En esta sección, presentamos ejemplos prácticos de flujos de trabajo que pueden integrarse en sus sistemas, utilizando los datos proporcionados por la API de nuestro dispositivo.

Reconocemos que incorporar datos de nuestra API en sus sistemas existentes puede ser una tarea compleja, especialmente si esta es la primera experiencia de su organización con un dispositivo de este tipo. Estos ejemplos están diseñados para asistirle y guiarle a través de este proceso de integración.

Tenga en cuenta que la flexibilidad de nuestra API permite una amplia gama de implementaciones de flujos de trabajo. Los ejemplos aquí no son exhaustivos y no deben interpretarse como los únicos métodos o como endosos de prácticas particulares. Cada organización tiene necesidades y requisitos únicos. En consecuencia, es crucial que las organizaciones gestoras desarrollen flujos de trabajo que se alineen con sus mejores prácticas internas y cumplan con las directrices establecidas por sus profesionales médicos.

Piezas de un rompecabezas​

Considere la salida de nuestro dispositivo como piezas de un rompecabezas. El dispositivo genera un archivo JSON, abundante en datos, organizados bajo diversas claves. Estas claves sirven como elementos fundamentales en su proceso de diseño de flujos de trabajo. Puede considerar cada clave como una rama distinta en un árbol de toma de decisiones o, de manera más creativa, como una pieza única de un rompecabezas. Esta analogía destaca la flexibilidad y adaptabilidad de los datos; puede organizar e integrar estas piezas en numerosas configuraciones para satisfacer sus necesidades específicas de flujo de trabajo.

Lectura adicional

Por favor, lea la sección <Output/> de las Instrucciones de uso para obtener más información.

Claves del endpoint DiagnosisSupport​

Claves del endpoint SeverityMeasure​

Hay más piezas de rompecabezas

La API devuelve muchos más campos que los mostrados aquí. Estos ejemplos solo destacan un pequeño subconjunto de claves que son especialmente útiles para triaje y enrutamiento operativo.

Flujos de trabajo por objetivo clínico y operativo​

La misma salida puede soportar flujos de trabajo muy diferentes. Un flujo de triaje centrado en la seguridad podría depender en gran medida de urgentReferralProbability, mientras que un flujo orientado a la capacidad puede usar entropy y la gravedad para decidir qué casos pueden permanecer en vías de menor intensidad.

En la práctica, las organizaciones generalmente combinan varios objetivos a la vez: reducir los casos graves perdidos, proteger la capacidad de especialistas y mantener el seguimiento de bajo riesgo manejable. Los ejemplos a continuación ilustran cómo las mismas piezas se pueden organizar de manera diferente dependiendo del objetivo operativo.

1. Empoderamiento de la atención primaria: Triaje​

Objetivo: Reducir las primeras consultas con dermatología filtrando casos benignos o sencillos en el nivel de atención primaria.

Este flujo usa urgentReferralProbability como la primera señal de escalada, highPriorityReferralProbability como el siguiente filtro de derivación, y entropy como una puerta de incertidumbre.

2. Habilitación de telemedicina: Remoto frente a presencial​

Objetivo: Decidir qué consultas pueden resolverse de forma segura de manera remota y cuáles requieren una consulta presencial, minimizando visitas innecesarias al hospital.

Los cuatro resultados posibles son:

  • Atención primaria, remota (🤳): R1.
  • Atención primaria, presencial (🏥🚶): P1.
  • Atención secundaria, remota (🤳): R2.
  • Atención secundaria, presencial (🏥🚶): P2.

Las organizaciones pueden reservar la capacidad de especialista presencial para casos que son tanto de alto riesgo como difíciles de clasificar.

3. Optimización de seguimientos de pacientes crónicos​

Objetivo: Reducir el volumen de visitas de seguimiento innecesarias, particularmente en patologías crónicas, verificando si la condición persiste y evaluando su gravedad.

Los dos resultados posibles son:

  • Progresando como se esperaba: OK.
  • Anomalía: !.

Al incorporar el historial del paciente, podemos determinar si una condición diagnosticada previamente aún está presente y evaluar si la gravedad indica una anomalía.

4. Enrutamiento de sub-especialidad y cross-especialidad​

Objetivo: Derivar al paciente directamente al especialista apropiado específico. Esto podría ser un dermatólogo con una sub-especialidad dedicada (como una unidad monográfica para lesiones pigmentadas, melanoma u hidradenitis supurativa), o un especialista de otro campo médico (como gastroenterología, reumatología, alergología o genética) cuando la lesión dermatológica es una manifestación de una enfermedad sistémica subyacente, una comorbilidad o una condición rara.

Este enrutamiento se basa en evaluar métricas específicas como pigmentedConditionProbability o analizar el array hypotheses. Las organizaciones pueden definir criterios para desencadenar estas derivaciones precisas, como verificar si una probabilidad supera un cierto umbral, si un código específico aparece en los resultados Top-1 o Top-3, o incluso basándose en la suma de probabilidades para un grupo de condiciones relacionadas. Por ejemplo, si Hidradenitis supurativa aparece como resultado Top-1, el paciente puede ser derivado directamente a la unidad monográfica de esta enfermedad.

5. Priorización de listas de espera​

Objetivo: Reordenar las listas de espera actuales dinámicamente para asegurar que los pacientes con mayores necesidades clínicas sean atendidos primero.

6. Campañas de prevención y salud ocupacional​

Objetivo: Implementar flujos de trabajo de cribado automatizados durante controles de salud ocupacional o campañas de prevención pública.

Estudios de casos del mundo real​

Una compañía de seguros de salud: Triaje de atención primaria frente a secundaria​

En este escenario, la organización (una compañía de seguros de salud) divide los casos en dos resultados para gestionar efectivamente su flujo de pacientes entre niveles de atención primaria y secundaria.

Los dos resultados posibles son:

  • Atención primaria: resultado 1.
  • Atención secundaria: resultado 2.

Aquí está su flujo de trabajo configurado con umbrales operacionales reales:

Este flujo usa urgentReferralProbability como la primera señal de escalada, entropy como la puerta de incertidumbre, highPriorityReferralProbability como el siguiente filtro de derivación, e intensidad de signo como el discriminador final cuando está disponible.

Un proveedor de telemedicina: Habilitación de telemedicina a través de protocolos clínicos​

En este escenario, la organización combinó los resultados de la IA con cuestionarios clínicos tradicionales, como el listado de 7 puntos (7PC), para determinar el método de consulta más apropiado.

El listado de 7 puntos (7PCL) es recomendado por NICE para uso rutinario en práctica general para identificar lesiones clínicamente significativas que requieren derivación urgente.

Establecimiento de umbrales​

Como puede ver, las piezas del rompecabezas a veces requieren decidir sobre un umbral a partir del cual se pueden tomar diferentes acciones. Los diferentes casos de uso pueden requerir diferentes umbrales, generalmente dependiendo de los posibles resultados del flujo de trabajo.

Cómo decidir un umbral​

Para medir cuál es el umbral apropiado para un parámetro, usamos matrices de confusión.

Una matriz de confusión es una herramienta fundamental en la clasificación estadística y el aprendizaje automático. Es una disposición de tabla específica que permite visualizar el rendimiento de un algoritmo, típicamente un clasificador. La matriz compara los valores objetivo reales con los predichos por el modelo, proporcionando información no solo del rendimiento del clasificador sino también de los tipos de errores que está cometiendo.

La matriz de confusión es típicamente una matriz de 2x2 para tareas de clasificación binaria:

  • Verdaderos positivos (TP): Estos son casos donde el clasificador predice correctamente la clase positiva.
  • Verdaderos negativos (TN): Estos son casos donde el clasificador predice correctamente la clase negativa.
  • Falsos positivos (FP): Estos son casos donde el clasificador predice incorrectamente la clase positiva (también conocido como error Tipo I).
  • Falsos negativos (FN): Estos son casos donde el clasificador predice incorrectamente la clase negativa (también conocido como error Tipo II).

En una tarea de clasificación, especialmente en clasificadores probabilísticos, el umbral es un concepto que debe entenderse correctamente. En esencia: un umbral es el punto en el que se decide la probabilidad de que un punto de datos esté en una clase sobre otra.

  • Cuando la probabilidad predicha por el modelo para una clase es más alta que el umbral, clasifica el punto de datos en esa clase.
  • Inversamente, si la probabilidad es más baja que el umbral, clasifica el punto de datos en la otra clase.
¿Dónde está este valor?

Nosotros proporcionamos la matriz de confusión, ya que es el resultado de las pruebas y validación extensas del dispositivo. Este valor generalmente se expresa en términos de especificidad y sensibilidad. Puede variar de una tarea a otra. Por ejemplo, la calidad de la imagen tiene un valor diferente al de la clasificación de una condición.

Con la información de sensibilidad y especificidad, cada organización puede decidir sobre un umbral específico, dependiendo de su caso de uso.

Adaptación del umbral al caso de uso​

Determinar el umbral apropiado depende totalmente del caso de uso. Por ejemplo, al decidir si derivar a un especialista o a un profesional de atención primaria:

  • Un umbral más bajo puede llevar a más casos siendo derivados a un especialista, potencialmente capturando más casos verdaderos positivos pero también aumentando falsos positivos.
  • Un umbral más alto puede reducir el número de falsos positivos pero puede llevar a perder casos verdaderos positivos.

Por lo tanto, el umbral debe ser elegido por la organización con su caso de uso específico en mente, equilibrando los resultados de falsos positivos y falsos negativos.

Umbral para malignantConditionProbability​

malignantConditionProbability es uno de los valores que emite el dispositivo para el cual una organización puede necesitar elegir un umbral.

malignantConditionProbability representa un nivel de sospecha cuantificado: cuanto mayor es el valor, mayor es la sospecha de malignidad. A diferencia de una salida binaria, esta escala continua proporciona una comprensión más matizada pero también necesita un umbral bien definido para clasificar un caso como maligno o no.

malignantConditionProbability no es un indicador binario simple sino una medida acumulativa derivada de la suma de las probabilidades de varias clases consideradas malignas por un algoritmo de clasificación multiclase. Este enfoque es significativo por varias razones:

  1. Naturaleza ambigua de las lesiones: Las lesiones pueden exhibir características que abarcan múltiples clases. En tales casos, una clasificación singular podría ser insuficiente para captar el alcance completo de la naturaleza de la lesión.
  2. Condiciones en evolución: Algunas lesiones representan condiciones en transición; por ejemplo, una lesión benigna que está en el proceso de volverse maligna.

Por eso capturar las probabilidades entre clases permite una comprensión más dinámica del estado actual de la lesión.

Ejemplo práctico​

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)

Tenga en cuenta que el número 12 en cada 100 personas no da información sobre cuántas personas en realidad enviarán imágenes malignas. Lo que esto le proporciona es conocimiento de la precisión del algoritmo, con una proporción dada de imágenes malignas a no malignas.

Umbral para imageQuality.score​

imageQuality es uno de los valores que emite el dispositivo para el cual una organización puede necesitar elegir un umbral.

imageQuality contiene diferentes aspectos de la calidad y validez de una imagen. Dentro de la clave technicalSummary, hay un objeto imageQuality que contiene el score.

A diferencia de una salida binaria, imageQuality.score proporciona una escala continua con una comprensión más matizada de la calidad de la imagen. Sin embargo, necesita un umbral bien definido para clasificar un caso como teniendo suficiente calidad o no.

Ejemplo práctico​

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)

Esto también se puede entender a través de un gráfico de aceptación. En el siguiente gráfico, verá cuántas imágenes se aceptan dependiendo del umbral del imageQuality.score. Como ejemplos, hay marcas establecidas en los umbrales para 40 y 80. En el segundo caso, se puede ver que se rechazará la mitad de las imágenes.

40 → Acceptance: 99.16%

80 → Acceptance: 49.02%

Tenga en cuenta que esto no proporciona información sobre cuántas imágenes malas en realidad enviarán los usuarios. Lo que esto le proporciona es conocimiento de la precisión del algoritmo de calidad de imagen. Explica la matriz de confusión del algoritmo DIQA, con una proporción dada de imágenes buenas a malas.

¿De dónde proviene esto?

Para determinar y verificar la precisión del algoritmo, hemos probado el algoritmo con un conjunto de datos que ha sido etiquetado por expertos en esta tarea. Así es cómo derivamos la matriz de confusión.

Lectura adicional: 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.

Priorización​

Las organizaciones pueden crear flujos de trabajo para mejorar la priorización de la atención al paciente.

Cada organización desarrolla sus propios protocolos para asignar prioridad a los pacientes. El objetivo es optimizar los procesos de derivación, asegurando que los pacientes reciban atención oportuna y apropiada de los profesionales de salud adecuados.

Con fines educativos, esta sección ofrece ejemplos de flujos de trabajo potenciales que una organización gestora podría emplear. Estos se basan en la información del informe de diagnóstico proporcionada por nuestra API, para priorizar efectivamente los episodios de pacientes.

Malignidad​

Un factor crítico en la toma de decisiones de atención médica es la evaluación del riesgo de malignidad.

La respuesta de la API incluye un segmento etiquetado como riskMetrics, que puede presentar información relevante para esta evaluación. Estos datos pueden ser instrumentales para informar el proceso de priorización, como se detalla a continuación:

Métricas de riesgo
{
  // ...
  "riskMetrics": {
    // ...
    "malignantConditionProbability": 62.0
    // ...
  }
  // ...
}

El parámetro malignantConditionProbability puede usarse para ayudar en la toma de decisiones de asignación de prioridad a los pacientes.

Aquí hay una regla sencilla para categorizar la prioridad del paciente basada en este parámetro:

  • Cuando malignantConditionProbability está entre 0 y 30%, el paciente puede ser categorizado como prioridad normal.
  • Si malignantConditionProbability supera 30%, el paciente debe considerarse prioridad alta.

Este proceso de toma de decisiones puede visualizarse usando un diagrama de flujo:

Expandiendo sobre esto:

  • Los pacientes con malignantConditionProbability que superan 30% no solo son una prioridad alta sino que también pueden ser candidatos para vía rápida.

Otro diagrama de flujo puede ayudar a ilustrar este criterio de toma de decisiones extendido:

Ordenar por malignidad

Las organizaciones pueden refinar sus estrategias de priorización ordenando casos de acuerdo con el nivel de sospecha de malignidad. Por ejemplo, dos pacientes que ambos caen en la categoría Alta prioridad debido a sus niveles de malignidad (uno a 60 y otro a 30) pueden ser triados aún más. Este enfoque implica clasificar pacientes dentro del grupo Alta prioridad de más alto a más bajo basándose en su puntuación de malignidad.

Este método permite una priorización más matizada, asegurando que aquellos con riesgos sospechados más altos sean atendidos más urgentemente.

Si la organización gestora opta por hacer esta información de malignidad visible para los profesionales de salud (HCP), el siguiente tipo de gráfico podría implementarse para facilitar este proceso de priorización refinado:

malignidad: 6%
malignidad: 62%

Otros flujos de trabajo​

Gravedad​

La gravedad de una condición es una de las variables que los profesionales de salud utilizan en su toma de decisiones.

Una respuesta de la API contiene una sección llamada findings que puede incluir la siguiente información para cada signo detectado:

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

Como puede ver, cada signo (como erythema) incluye un objeto intensity. En ese ejemplo, vemos que el signo intensity.grade es 5.8.

Una regla muy simple sería:

  • Si el intensity.grade es menor que 3, activaría el flujo de trabajo A
  • Si el intensity.grade es mayor que 7, activaría el flujo de trabajo B

Esto puede ser útil, por ejemplo, cuando un profesional de salud debe decidir si derivar o no a un paciente a un especialista. También puede ser información útil para monitorear la efectividad de un tratamiento.

En este ejemplo, el flujo de trabajo A sería el aplicable cuando la gravedad de la condición está bajo control, por ejemplo, porque está respondiendo correctamente al tratamiento.

Además, puede enriquecer el proceso añadiendo información del historial del paciente. Por ejemplo, si compara con registros anteriores, el resultado podría ser:

  • Si el intensity.grade es 5, y el registro anterior fue 8, activaría el flujo de trabajo C (mejorando)
  • De lo contrario, volvería al flujo de trabajo A

La organización gestora también puede decidir mostrar esta información al profesional de salud, en cuyo caso un gráfico como el siguiente podría implementarse:

La puntuación de gravedad se puede mostrar visualmente. La forma de hacer esto es usando los valores devueltos en intensity:

intensity.grade: 2
intensity.grade: 8

Existencia previa de la condición​

Si una condición es nueva para un paciente, o ya diagnosticada a ese paciente, es una de las variables que los profesionales de salud utilizan en su toma de decisiones.

Una respuesta de la API contiene una sección llamada hypotheses que puede incluir la siguiente información:

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

Lo que esa información muestra es que una condición tiene una probabilidad de 69.82 (69.82%). El nombre de la condición es Generalised eczematous dermatitis of unspecified type, codificada como EA89 según el sistema ICD-11.

Lo que un profesional de salud podría hacer es buscar si esa condición ha sido previamente diagnosticada al paciente, y usar esa información en su toma de decisiones.