Legit.Health

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

Reconocemos que incorporar datos de nuestra API en vuestros sistemas existentes puede ser una tarea compleja, especialmente si es la primera experiencia de vuestra organización con un dispositivo de este tipo. Estos ejemplos están diseñados para asistiros y guiaros 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í presentados no son exhaustivos y no deben interpretarse como los únicos métodos o como respaldos 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 que cumplan con las directrices establecidas por sus profesionales médicos.

Piezas del puzle

Considere la salida de nuestro dispositivo como piezas de un puzle. El dispositivo genera un archivo JSON, abundante en datos, organizados bajo diversas claves. Estas claves sirven como elementos fundamentales en el proceso de diseño de vuestro flujo de trabajo. Puede concebir cada clave como una rama distinta en un árbol de toma de decisiones o, de manera más creativa, como una pieza única del puzle. Esta analogía resalta la flexibilidad y adaptabilidad de los datos: podéis organizar e integrar estas piezas en numerosas configuraciones para adaptarse a vuestras necesidades específicas de flujo de trabajo.

Lectura adicional

Consulte la sección <Output/> de las Instrucciones de uso para más información.

Hay más piezas del puzle

La API devuelve más de 100 filas de datos, y estos ejemplos solo utilizan 6 claves del resultado. Esto significa que hay muchas más piezas del puzle que pueden ser más útiles para vuestra organización. No dudéis en poneros en contacto con nosotros para preguntar qué puntos finales pueden ser más adecuados para vuestro caso de uso.

Organizando el puzle

Profundicemos en algunos ejemplos prácticos que muestren cómo podéis ensamblar las piezas del puzle para formular un flujo de trabajo efectivo.

Atención primaria vs. atención especializada

En este escenario demostramos un flujo de trabajo que se bifurca en dos caminos distintos: Atención primaria y Atención especializada. La decisión entre estos resultados se ilustra en la siguiente tabla:

Atención primaria	1
Atención especializada	2

Sobre esta base, un flujo de trabajo potencial podría incorporar piezas específicas del puzle que ayuden a una organización a refinar y mejorar la eficiencia de su proceso de derivación. El flujo ahora combina urgentReferral, highPriorityReferral y la entropía del modelo como puntos de decisión principales, en lugar de depender solo de malignancy:

Flujo de trabajo alternativo con Match ICD classes

Esto puede incorporar otras piezas del puzle, como coincidir con una lista particular de clases ICD. En el siguiente ejemplo, el flujo verifica una lista de clases que la organización considera que deben ser atendidas directamente por atención especializada.

Establecimiento de umbrales

Para determinar los umbrales, la organización debe tener en cuenta dos cosas:

1. Cuáles son los posibles resultados del flujo de trabajo?
2. Cuál es la sensibilidad y especificidad del parámetro?

En este caso, el resultado del diagrama de flujo siempre incluye consultar a un profesional de la salud. Debido a esto, si la organización busca reducir las listas de espera de pacientes para aumentar la seguridad del paciente, puede ser una buena idea establecer un umbral alto.

Podéis encontrar más información sobre este tema en la sección Establecimiento de umbrales, donde explicamos la matriz de confusión de algunos parámetros.

Consulta remota vs. consulta presencial

Una organización puede tener como objetivo mejorar su proceso de consulta determinando eficientemente el método más apropiado para cada caso, ya sea una consulta remota o presencial.

Para este ejemplo, continuamos con los dos resultados establecidos: Atención primaria y Atención especializada. Expandimos este proceso de toma de decisiones añadiendo la dimensión del tipo de consulta: Remota o Presencial, como se muestra en la siguiente tabla:

	🤳 Remota	🏥🚶 Presencial
Atención primaria	R1	P1
Atención especializada	R2	P2

Por qué esto es importante

Implementar una estrategia para mejorar la eficiencia de las consultas y minimizar los tiempos de espera de los pacientes podría implicar dirigir más casos a médicos de atención primaria o aprovechar métodos de consulta más rápidos. La siguiente tabla muestra la dirección deseada para cada nivel de atención y tipo de consulta:

	🤳 Remota	🏥🚶 Presencial
Atención primaria	Objetivo: Aumentar ↑	-
Atención especializada	-	Objetivo: Disminuir ↓

Ejemplo de flujo de trabajo

El flujo de trabajo diseñado para lograr estos objetivos podría estructurarse de la siguiente manera:

Esto puede complementarse con cuestionarios específicos de condiciones como la lista de control de 7 puntos (7PC). La lista de control de 7 puntos (7PCL) ha sido recomendada por NICE (2005) para uso rutinario en la práctica general del Reino Unido para identificar lesiones clínicamente significativas que requieren derivación urgente.

En el siguiente diagrama de flujo, la salida de urgentReferral es seguida por el cuestionario 7PC, para especificar mejor el método adecuado para las consultas.

Establecimiento de umbrales

Para determinar los umbrales, la organización debe tener en cuenta dos cosas:

1. Cuáles son los posibles resultados del flujo de trabajo?
2. Cuál es la sensibilidad y especificidad del parámetro?

En este caso, el resultado del diagrama de flujo siempre incluye consultar a un profesional de la salud. Debido a esto, si la organización busca reducir las listas de espera de pacientes para aumentar la seguridad del paciente, puede ser una buena idea establecer un umbral alto.

Podéis encontrar más información sobre este tema en la sección Establecimiento de umbrales, donde explicamos la matriz de confusión de algunos parámetros.

Refinando métodos de comunicación para consultas

Para optimizar aún más el proceso de consulta, podemos especificar diferentes métodos tanto para consultas remotas como presenciales, alineándolos con objetivos específicos:

	🤳 Remota		🏥🚶 Presencial
	Consulta por chat	Consulta por vídeo	Equipo interno	Equipo externo
Atención primaria	Objetivo: Aumentar ↑	-	-	-
Atención especializada	-	-	Objetivo: Disminuir ↓	Objetivo: Disminuir ↓

Seguimiento de pacientes crónicos

Las organizaciones pueden tener como objetivo mejorar la monitorización remota de pacientes crónicos para mejorar la supervisión del paciente y evaluar la efectividad del tratamiento.

En este caso, continuamos diferenciando entre Atención primaria y Atención especializada. Sin embargo, ahora tenemos en cuenta el estado de la condición del paciente, categorizado como Progresando como se esperaba o mostrando una Anomalía, como se ilustra a continuación:

Progresando como se esperaba	OK
Anomalía	!

Aunque el dispositivo no indica explícitamente si la condición de un paciente está evolucionando como se esperaba, sí proporciona una puntuación score.interpretation.intensity. Esta puntuación, compuesta por valores 0, 1, 2 y 3, indica el nivel de impacto de la condición, siendo 2 y 3 condiciones moderadas o severas.

Lectura adicional

Consulte la sección <Output/> de las Instrucciones de uso para más información.

Sobre esta base, una organización podría implementar el siguiente flujo de trabajo:

Establecimiento de umbrales

Como podéis ver, las piezas del puzle a veces requieren decidir un umbral a partir del cual se pueden tomar diferentes acciones. 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, utilizamos matrices de confusión.

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

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

• Verdaderos Positivos (VP): son casos donde el clasificador predice correctamente la clase positiva.
• Verdaderos Negativos (VN): son casos donde el clasificador predice correctamente la clase negativa.
• Falsos Positivos (FP): son casos donde el clasificador predice incorrectamente la clase positiva (también conocido como error tipo I).
• Falsos Negativos (FN): 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 cual se decide si la probabilidad de un punto de datos pertenece a una clase sobre otra.

• Cuando la probabilidad predicha por el modelo para una clase es mayor que el umbral, clasifica el punto de datos en esa clase.
• Inversamente, si la probabilidad es menor que el umbral, lo clasifica en la otra clase.

¿Dónde está este valor?

La matriz de confusión nos la proporciona, ya que es el resultado de la extensa prueba y validación 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 un umbral específico, dependiendo de su caso de uso.

Adaptando el umbral al caso de uso

La determinación del umbral apropiado es completamente dependiente del caso de uso. Por ejemplo, al decidir si derivar a un especialista o a un médico de atención primaria:

• Un umbral más bajo puede llevar a más casos siendo derivados a un especialista, atrapando potencialmente más casos verdaderamente 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 verdaderamente positivos.

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

Umbral para malignancy

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

malignancy representa un nivel cuantificado de sospecha: 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 requiere un umbral bien definido para clasificar un caso como maligno o no.

malignancy no es un indicador binario directo sino una medida acumulativa derivada de sumar 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 puede ser insuficiente para captar la naturaleza completa 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 proceso de volverse maligna.

Por eso captar las probabilidades a través de 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 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)

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

Umbral para mediaValidity.quality.score

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

mediaValidity contiene diferentes aspectos de la calidad de una imagen. Dentro de esta clave, hay varias claves como isValid, quality.acceptable, domain.isDermatological y más importante, quality.score.

A diferencia de una salida binaria, score proporciona una escala continua con una comprensión más matizada de la calidad de la imagen. Sin embargo, requiere un umbral bien definido para clasificar un caso como que tiene 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 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)

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

40 → Acceptance: 99.16%

80 → Acceptance: 49.02%

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

¿De dónde viene esto?

Para determinar y verificar la precisión del algoritmo, hemos probado el algoritmo con un conjunto de datos etiquetados 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 la salud adecuados.

Para propósitos educativos, esta sección ofrece ejemplos de posibles flujos de trabajo 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 episodios de pacientes.

Malignidad

Un factor crítico en la toma de decisiones en el cuidado de la salud es la evaluación del riesgo de malignidad.

La respuesta de la API incluye un segmento etiquetado clinicalIndicator, 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:

Indicador clínico

{
  // ...
  "clinicalIndicator": {
    // ...
    "malignancy": 62
    // ...
  }
  // ...
}

El parámetro malignancy puede usarse para ayudar en la toma de decisiones de asignar prioridad a los pacientes.

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

• Cuando malignancy está entre 0 y 30%, el paciente puede categorizarse como prioridad normal.
• Si malignancy excede 30%, el paciente debe considerarse como prioridad alta.

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

Ampliando esto:

• Los pacientes con malignancy superior a 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 según el nivel de sospecha de malignidad. Por ejemplo, dos pacientes que ambos caen en la categoría Prioridad alta debido a sus niveles de sospecha de malignidad (uno en 60 y otro en 30) pueden ser triados aún más. Este enfoque implica clasificar los pacientes dentro del grupo Prioridad alta de mayor a menor en función de su puntuación de sospecha de malignidad.

Este método permite una priorización más matizada, asegurando que aquellos con riesgos sospechados más altos reciban atención más urgente.

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

malignancy: 6%

malignancy: 62%

Otros flujos de trabajo

Severidad

La severidad de una condición es una de las variables que los HCP utilizan en su toma de decisiones.

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

patientEvolution

{
  // ...
  "patientEvolution": {
    "alegi": {
      "score": {
        "value": 8,
        "interpretation": {
          "category": "Grade 1",
          "intensity": 1
        }
      }
      // ...
    }
    // ...
  }
}

Como podéis ver, la entrada del sistema de puntuación incluye una score.value. En ese ejemplo, vemos que la puntuación de severidad es 8.

Dentro de score.interpretation, podéis ver que el valor cae bajo la intensidad 1, lo que significa que es la severidad más baja posible. La category para esa intensidad es Grade 1, que es una interpretación semántica de la puntuación que refleja directamente la severidad.

Una regla muy simple sería:

• Si la score.interpretation.intensity es 1, activaría el flujo de trabajo A
• Si la score.interpretation.intensity es 3, activaría el flujo de trabajo B

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

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

Además, podéis enriquecer el proceso añadiendo información del historial del paciente. Por ejemplo, si también enviáis datos dentro de la clave previousMedia cuando realizáis vuestra solicitud, el resultado podría ser:

• Si la score.interpretation.intensity es 2, y la foto anterior no era 3, activaría el flujo de trabajo C
• En caso contrario, recurriría al flujo de trabajo A

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

La puntuación de severidad puede mostrarse visualmente. La forma de hacerlo es utilizando los valores devueltos en score.interpretation:

score.interpretation.intensity: 1

score.interpretation.intensity: 3

Existencia previa de la condición

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

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

Conclusión

{
  // ...
  "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
    }
    // ...
  ]
  // ...
}

Lo que esa información muestra es que una condición tiene una probabilidad de 87.77. El nombre de la condición es Mucous cyst, codificada como DA04.5 según el sistema ICD-11.

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