Recurso FHIR Condition explicado, con un ejemplo

Respuesta corta: Condition es el recurso FHIR para un diagnóstico, un problema de salud o un síntoma que ha alcanzado un nivel de preocupación: este paciente tiene diabetes tipo 2, activa, confirmada, desde 2019. Sus dos campos de estado son lo que lo hacen útil. clinicalStatus indica dónde se encuentra la condición en su curso (activa, recurrencia, recaída, inactiva, remisión, resuelta); verificationStatus indica cuán seguro está alguien (no confirmada, provisional, diferencial, confirmada, refutada, ingresada con error). category separa los elementos de la lista de problemas de larga duración de los diagnósticos de encuentro registrados para una visita. El código suele ser SNOMED CT, a menudo con un código ICD-10 al lado para informes.

Un ejemplo válido de FHIR R4

Un recurso Condition válido de FHIR R4 necesita una referencia al sujeto y, a menos que se haya introducido por error, un estado clínico (clinicalStatus); en la práctica, también lleva un estado de verificación (verificationStatus), una categoría (elemento de lista de problemas o diagnóstico de encuentro), un diagnóstico codificado y un inicio (onset). El ejemplo a continuación registra diabetes tipo 2 confirmada y activa con un código SNOMED CT y un código ICD-10 uno al lado del otro.

{
  "resourceType": "Condition",
  "id": "t2dm",
  "clinicalStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active"}]},
  "verificationStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed"}]},
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-category", "code": "problem-list-item"}]}],
  "severity": {"coding": [{"system": "http://snomed.info/sct", "code": "6736007", "display": "Moderate"}]},
  "code": {
    "coding": [
      {"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"},
      {"system": "http://hl7.org/fhir/sid/icd-10", "code": "E11", "display": "Type 2 diabetes mellitus"}
    ],
    "text": "Type 2 diabetes"
  },
  "subject": {"reference": "Patient/example"},
  "onsetDateTime": "2019-03",
  "recordedDate": "2019-03-18",
  "recorder": {"reference": "Practitioner/gp-42"},
  "asserter": {"reference": "Practitioner/gp-42"},
  "note": [{"text": "Diet-controlled at diagnosis; metformin started 2021."}]
}

Los elementos que importan

Los elementos de Condition que más importan son el estado clínico (clinicalStatus, dónde se encuentra la condición en su evolución), el estado de verificación (verificationStatus, cuán seguro es el diagnóstico), la categoría (elemento de lista de problemas o diagnóstico de encuentro), el código (generalmente SNOMED CT, a menudo con ICD-10 al lado), el inicio (onset) y la remisión (abatement), la fecha de registro (recordedDate), y el registrador (recorder) y el declarante (asserter), que indican quién introdujo la condición y quién la reclama.

clinicalStatus es obligatorio siempre que la condición no sea ingresada con error, y sus valores siguen el curso de una enfermedad. resolved es para condiciones que terminaron (una fractura que sanó); remission para aquellas que pueden regresar; inactive para un problema que ya no se está gestionando. Cambiarlo es cómo una lista de problemas se mantiene veraz sin eliminar el historial.
verificationStatus registra la certeza. provisional y differential son diagnósticos de trabajo durante una evaluación; confirmed una vez establecido; refuted cuando se descarta, lo que mantiene el registro de lo que se consideró. Una entrada a nivel de síntoma a menudo es unconfirmed.
category: problem-list-item para la lista permanente que un médico de cabecera mantiene; encounter-diagnosis para de qué se trataba esta visita. La misma enfermedad puede aparecer en ambos casos, vinculada a diferentes encuentros.
code es un CodeableConcept, por lo que puede llevar un concepto SNOMED CT para el significado clínico y un código ICD-10 para estadísticas uno al lado del otro. Ver CodeableConcept y Coding y SNOMED CT vs ICD-10.
bodySite, severity y stage (con referencias de evaluación) califican la condición; evidence apunta a las Observaciones o informes que la respaldan.
onset[x] y abatement[x] pueden ser una fecha y hora, una edad, un período, un rango o una cadena ("infancia"), porque los pacientes rara vez conocen las fechas exactas. recordedDate es cuando entró en el registro, lo que puede ser años después.
recorder la ingresó; asserter es quien la reclama, que puede ser el propio paciente.

Condition vs Observation

En FHIR, una Observation es un único punto de datos medido o informado, como una lectura de presión arterial o un dolor de cabeza registrado, mientras que una Condition es la interpretación clínica persistente que se gestiona a lo largo del tiempo, como la hipertensión o la migraña. Las Observations proporcionan evidencia; una Condition es una afirmación sobre el paciente realizada por un médico o el propio paciente.

Una lectura de presión arterial es una Observación. Hipertensión es una Condición. Un síntoma que el paciente registra ("dolor de cabeza, 6/10, desde el martes") es una Observación; el juicio de un médico de que los dolores de cabeza son migraña es una Condición. Regla general: las Observaciones son puntos de datos; las Condiciones son la interpretación clínica que persiste y se gestiona. Anpheros registra los síntomas como Observaciones y solo crea una Condición para un diagnóstico que un médico hizo o que la persona informó según se le indicó; la aplicación nunca deriva una Condición de los síntomas. Ver Síntomas como Observaciones y Condiciones como registros.

Diagnósticos de encuentro y la lista de problemas

En FHIR, un diagnóstico de encuentro (encounter diagnosis) es una Condition vinculada desde Encounter.diagnosis para una visita, con un uso como diagnóstico de admisión o alta y un rango, mientras que la lista de problemas (problem list) es el conjunto permanente de Conditions con la categoría problem-list-item y un estado clínico activo (clinicalStatus). La misma enfermedad puede aparecer en ambos roles, vinculada a diferentes encuentros.

Un Encounter apunta a sus diagnósticos a través de Encounter.diagnosis, cada uno con un use (diagnóstico de admisión, diagnóstico de alta, queja principal, comorbilidad, facturación) y un rank. La lista de problemas es el conjunto de Condiciones con la categoría problem-list-item y un clinicalStatus de activo o similar. Reconciliar los dos (¿el diagnóstico de alta se convirtió en un nuevo problema?) es trabajo clínico que FHIR registra pero no automatiza. Ver FHIR Encounter explicado.

Qué no incluir en una Condición

Una Condition de FHIR solo debe contener un diagnóstico, problema o síntoma que alguien afirme sobre el paciente. El historial familiar pertenece a FamilyMemberHistory, las alergias a AllergyIntolerance, los riesgos y puntuaciones a Observation o RiskAssessment, y los procedimientos completados a Procedure. Cualquier cosa inferida por el software sin que un médico o el paciente la afirme no pertenece en absoluto a una Condition.

Historial familiar (eso pertenece a FamilyMemberHistory).
Alergias (AllergyIntolerance tiene su propio modelo de criticidad y reacción).
Riesgos y puntuaciones (Observation o RiskAssessment).
Procedimientos que se realizaron (Procedure).
Cualquier cosa que el software infirió sin que un médico o el paciente la afirmaran; una Condición es una afirmación sobre el paciente, y asserter dice de quién es.

En Anpheros

Anpheros crea recursos Condition de FHIR en la Plataforma Anpheros solo a partir de la escritura de una clínica a través de la API, de un documento codificado con procedencia que apunta a él, o de un diagnóstico que la persona informa que le han dado. Cada Condition se muestra con su estado y fuente, y la aplicación nunca diagnostica ni marca una Condition como confirmada por sí sola.

Los médicos ven la misma Condition con sus códigos, que es lo que hace que el registro sea legible por cualquier sistema FHIR.

Páginas relacionadas

Fuentes

Preguntas frecuentes

¿Debo usar SNOMED CT o ICD-10 en Condition.code?

Ambos, cuando tenga ambos. SNOMED CT lleva el significado clínico para la atención; ICD-10 (o su variante nacional) lleva la clasificación para informes y facturación. Ponga cada uno como un Coding en el mismo CodeableConcept; los perfiles indican cuál es obligatorio.

¿Cómo registro que un diagnóstico fue incorrecto?

Establezca verificationStatus en refuted si la condición se descartó después de ser considerada, o entered-in-error si se registró por error. No elimine el recurso; el historial es parte del registro.

¿Dónde va un síntoma, Condition u Observation?

Como una Observación mientras es un punto de datos reportado (puntuación del dolor, duración, desencadenante). Como una Condición solo cuando un médico o el paciente la afirman como un problema a gestionar, con el verificationStatus apropiado.

¿Tiene Condition una fecha en que fue diagnosticada?

onset[x] es cuando comenzó la condición, que puede ser aproximada; recordedDate es cuando se ingresó. No hay una fecha de diagnóstico separada; muchas guías usan recordedDate o una referencia de Encounter para eso.

Anpheros Platform

Pruébalo gratis en el sandbox

Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.

Crear un sandbox gratis Leer las guías para desarrolladores →

Gratis · 30 pacientes sintéticos · sin tarjeta

Esta guía es informativa y no sustituye la consulta médica. Para decisiones sobre tu salud, habla con tu médico. En una emergencia, llama al número de emergencias local (112 en Europa).

Escrito por

El equipo de Anpheros

Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.

Sobre Anpheros →