|
8 min de lectura
|

Reducción de la complejidad en los formularios de admisión de pacientes con FHIR SDC

Resumir este artículo con:
ChatGPTPerplexityClaudeGrok

El problema con los formularios de admisión de pacientes tradicionales

Muchas personas conocen esta situación: acude a una clínica por primera vez y recibe un formulario de admisión de pacientes de cinco páginas. Debe responder decenas de preguntas, aunque algunas de ellas claramente no le corresponden.

Los formularios médicos digitales basados en FHIR SDC pueden ayudar a resolver este problema. Sin embargo, trasladar un formulario del papel a una pantalla no lo mejora automáticamente. Un formulario digital puede seguir siendo extenso, estar mal estructurado y resultar difícil de entender. En algunos casos, puede incluso parecer más confuso que la versión en papel. El papel, al menos, no abre otra sección cuando se pulsa el botón equivocado.

La redacción compleja y las secciones irrelevantes empeoran la experiencia. Tras enviar el formulario, el profesional sanitario puede volver a hacer las mismas preguntas porque encontrar las respuestas dentro de un formulario extenso y complicado requiere demasiado tiempo.

Esto importa porque un formulario de admisión suele ser uno de los primeros puntos de contacto entre un paciente y una clínica. El respeto hacia los pacientes no se limita a la atención médica o a un trato amable. También incluye la manera en que se recopila la información.

Un buen formulario de admisión debe tratarse, por tanto, como parte de la experiencia global del paciente. Incluso un formulario sencillo y claro puede crear un tono positivo para las siguientes interacciones del paciente con la clínica.

Traditional patient intake form with a long and complex structure

Un formulario debe ser dinámico, no estático

¿Qué puede hacer que el proceso de cumplimentación del formulario sea más cómodo?

El primer paso, y el más importante, es hacer el formulario dinámico. Los pacientes no deberían tener que responder preguntas que no les son relevantes. De hecho, ni siquiera necesitan verlas.

FHIR Questionnaire admite lógica condicional mediante enableWhen. Controla si una pregunta o grupo está habilitado en función de una respuesta dada en otro lugar del formulario. FHIR SDC también ofrece enableWhenExpression para condiciones más avanzadas que no pueden representarse fácilmente con la estructura estándar de enableWhen. Los elementos deshabilitados normalmente se ocultan o quedan inaccesibles, y sus reglas de obligatoriedad no se aplican mientras están deshabilitados.

En Formbox, los autores de formularios pueden configurar estas condiciones mediante un generador visual de condiciones. Las reglas simples pueden crearse sin necesidad de escribir FHIRPath. Para lógica más compleja, el generador puede convertir las condiciones a FHIRPath, mientras que un editor de expresiones sigue disponible cuando se necesita un control directo.

Esto significa que un autor de formularios puede crear tanto condiciones simples como combinaciones más amplias de reglas AND y OR sin necesidad de que cada miembro del equipo se convierta de la noche a la mañana en un experto en FHIRPath.

Un ejemplo sencillo de enableWhen

Considere una sección sobre el consumo de tabaco y nicotina.

El formulario pregunta primero:

¿Consume actualmente productos que contengan tabaco o nicotina?

Cuando el paciente selecciona , el formulario puede mostrar preguntas adicionales, como:

  • ¿Cuántos cigarrillos fuma al día?
  • ¿Cuántos años lleva usando estos productos?
  • ¿Qué productos de tabaco o nicotina consume?

Cuando el paciente selecciona No, toda la sección de seguimiento permanece oculta.

Un paciente que no fuma no debería tener que responder cuántos cigarrillos fuma al día. La cifra correcta podría ser cero, pero formular la pregunta igualmente añade trabajo innecesario y hace que el formulario parezca más largo de lo que realmente es.

Con la visualización condicional, el formulario inicial tiene un aspecto más limpio y menos intimidante. El paciente ve únicamente las preguntas relevantes para su situación actual.

El mismo enfoque puede aplicarse a muchas otras secciones:

  • Preguntas relacionadas con el embarazo
  • Cirugías previas
  • Alergias
  • Medicación actual
  • Historial médico familiar
  • Consumo de alcohol o sustancias
  • Detalles sobre un síntoma específico

Por ejemplo, no tiene sentido mostrar los campos correspondientes a la fecha y el tipo de una cirugía anterior hasta que el paciente confirme que ha tenido una cirugía previa.

Conditional display using enableWhen in a patient intake form

Las preguntas obligatorias deben usarse con prudencia

Otro factor importante es el número de preguntas obligatorias.

Un formulario de admisión de pacientes debe contener el menor número razonable de preguntas obligatorias. Una pregunta debería ser obligatoria normalmente solo cuando la clínica necesita realmente la respuesta para continuar el flujo de trabajo, proporcionar una atención segura, identificar al paciente o cumplir un requisito legal u operativo.

Hacer obligatorio cada campo puede parecer que mejora la exhaustividad de los datos. En la práctica, puede producir el efecto contrario. Los pacientes que no entienden una pregunta pueden introducir una respuesta aproximada o incorrecta simplemente porque el formulario no les permite continuar.

FHIR define required a nivel de pregunta o grupo. Un elemento habilitado y obligatorio debe responderse antes de que el QuestionnaireResponse pueda marcarse como completado. Sin embargo, cuando un elemento está deshabilitado por la lógica condicional, su restricción de obligatoriedad se ignora. Esta combinación resulta útil: una pregunta puede ser obligatoria cuando es relevante sin serlo para todos los pacientes.

Por ejemplo, el nombre de un medicamento puede ser obligatorio después de que el paciente confirme que toma medicación. No debería bloquear a los pacientes que ya han seleccionado Actualmente no tomo ningún medicamento.

Required questions configured only when clinically relevant

No muestre todo el formulario de una sola vez

La lógica condicional no es la única manera de reducir la complejidad visual. El formulario también puede dividirse en grupos claros que los pacientes abren a medida que avanzan en el proceso.

Un estado inicial práctico podría tener este aspecto:

  • La sección Datos del paciente está expandida.
  • Las secciones restantes son contraíbles.
  • Dichas secciones posteriores están contraídas de forma predeterminada.

Formbox admite elementos contraíbles y permite al autor del formulario elegir si su estado inicial es Contraído o Expandido.

Esto no reduce el número real de preguntas, pero sí reduce la cantidad de información mostrada en pantalla en un momento dado. En lugar de ver un cuestionario enorme, el paciente ve un pequeño conjunto de pasos manejables.

Por qué esto importa

Mostrar menos preguntas en el momento adecuado ofrece varias ventajas.

En primer lugar, el formulario resulta más fácil de entender. El paciente puede centrarse en un tema relevante en lugar de recorrer una página extensa e intentar decidir qué campos puede ignorar.

En segundo lugar, reduce el riesgo de errores. Las preguntas irrelevantes pueden dar lugar a valores aleatorios, respuestas contradictorias o explicaciones en texto libre innecesarias.

Por último, el formulario resulta más fácil de mantener. La mayoría de las preguntas están ocultas de forma predeterminada, pero el autor del formulario puede seguir viendo la estructura completa en el esquema. Esto facilita encontrar cualquier sección, revisar su lógica y editar el formulario cuando sea necesario.

Completar el formulario puede ser un proceso compartido

No todos los detalles tienen que ser introducidos por el paciente antes de la cita.

Algunos datos pueden ser difíciles de describir con precisión para el paciente. El profesional sanitario también puede descubrir información adicional durante la consulta. Por ejemplo, el paciente puede recordar el color y el propósito de un comprimido, pero no su nombre ni su dosis.

Cuando Formbox genera un enlace para un QuestionnaireResponse existente, la opción allow-amend puede permitir que la respuesta se edite y se vuelva a enviar.

Con los controles de acceso y el flujo de trabajo adecuados, un profesional sanitario puede añadir, aclarar o corregir información durante la cita o después de ella. La respuesta puede enviarse entonces con un estado amended en lugar de obligar al paciente a completar todos los detalles por su cuenta. Formbox también actualiza los recursos vinculados cuando una respuesta enmendada se extrae de nuevo en su flujo de trabajo de extracción basado en observaciones.

Este enfoque convierte el formulario en una fuente de información compartida en lugar de en una tarea que el paciente debe completar a la perfección antes de que alguien pueda consultarla.

Practitioner amending a patient-submitted QuestionnaireResponse

¿Qué ocurre después de enviar el formulario?

Una interfaz de usuario mejorada resuelve solo una parte del problema.

Las respuestas no deberían quedar bloqueadas dentro de un QuestionnaireResponse, donde otros flujos de trabajo clínicos pueden tener dificultades para encontrarlas o utilizarlas. Una respuesta completada está estructurada, pero sigue siendo principalmente un registro del formulario y sus respuestas.

La extracción de datos (Data Extraction) permite a los usuarios emplear las respuestas del cuestionario para crear o actualizar otros recursos FHIR. Dependiendo del enfoque de extracción y las asignaciones, el resultado puede ser un único recurso o un Bundle que contenga varios recursos relacionados.

Formbox admite varios enfoques de extracción, incluida la extracción basada en observaciones, basada en definiciones y basada en plantillas. La extracción basada en definiciones asigna las respuestas a rutas en los recursos de destino, mientras que la extracción basada en plantillas puede utilizar plantillas de recursos y expresiones FHIRPath para generar una salida más compleja.

Para un formulario de admisión de pacientes, los recursos extraídos pueden incluir:

  • Patient para información demográfica y de contacto
  • AllergyIntolerance para las alergias y reacciones declaradas
  • MedicationStatement para la medicación que el paciente declara tomar
  • MedicationRequest cuando el flujo de trabajo representa un pedido o prescripción de medicación real
  • Observation para valores como el estado de fumador, el peso, la talla u otras mediciones clínicas

La extracción de datos no es automática simplemente porque un cuestionario utilice FHIR SDC. El cuestionario debe contener la configuración de extracción correcta, y una operación de extracción o un flujo de trabajo de soporte debe procesar la respuesta. Sin embargo, una vez que esta configuración existe, un único formulario puede hacer más que recopilar respuestas. Puede convertirse en una fuente de información clínica estructurada que otros sistemas FHIR pueden buscar, comparar, validar y reutilizar.

Esto también puede reducir la entrada de datos repetida. En lugar de leer una respuesta y copiar manualmente cada alergia o medicación en otra pantalla, el sistema puede crear los recursos pertinentes según las asignaciones definidas. El profesional sanitario sigue necesitando revisar la información clínicamente importante, pero el sistema puede encargarse del trabajo de copia más mecánico.

Questionnaire answers extracted into new FHIR resources

Conclusión

Utilizando varias características de FHIR SDC de forma conjunta, hemos transformado un formulario de admisión extenso y abrumador en un cuestionario claro, estructurado y amigable para el paciente, que muestra únicamente lo necesario.

La lógica condicional con enableWhen nos permitió eliminar aproximadamente el 70 % de las preguntas irrelevantes de la vista inicial. Estas preguntas quedan ahora ocultas y aparecen solo cuando las respuestas previas del paciente las hacen relevantes.

Los grupos contraíbles también contribuyen a reducir la carga visual. Cuando se abre el formulario, el paciente ve únicamente un número reducido de preguntas —alrededor de diez— en lugar de todo el cuestionario a la vez. Esto facilita comenzar sin la sensación de que la primera cita se ha convertido inesperadamente en un examen. Las secciones restantes pueden abrirse paso a paso.

Por último, la opción de enmienda da margen a los pacientes para cometer errores. Cualquier persona puede necesitar ayuda para completar un formulario médico, especialmente cuando las preguntas incluyen términos clínicos, fechas, medicamentos o afecciones pasadas. Durante la cita, el profesional sanitario puede revisar las respuestas, aclarar los detalles poco claros y realizar las actualizaciones necesarias. Esto contribuye a mejorar la precisión y exhaustividad de la información recopilada.

En conjunto, estas características hacen que el formulario de admisión de pacientes sea más fácil de completar para los pacientes y más fácil de revisar y utilizar para los profesionales sanitarios. El resultado no es simplemente un formulario de apariencia más breve, sino una forma más práctica y fiable de recopilar información clínica estructurada.

Recursos adicionales

Vídeo

Ver el recorrido por el formulario de admisión de pacientes en YouTube

Compartir este artículo
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.