Recurso FHIR Paciente explicado: identificadores, nombres, datos demográficos y enlaces, con un ejemplo válido

Respuesta corta: Patient es el recurso FHIR que describe a una persona que recibe atención: quién es administrativamente, no qué le ocurre. Contiene identificadores (números de historial médico, DNI), nombres, contactos de telecomunicaciones, género administrativo, fecha de nacimiento, dirección, estado civil, comunicación (idiomas), un médico de cabecera, una organización gestora y enlaces a otros registros de Patient para la misma persona. Los hechos clínicos nunca residen en Patient; residen en los recursos que apuntan a él.

Un ejemplo válido de FHIR R4

Un recurso FHIR R4 Patient válido solo necesita resourceType, pero en la práctica incluye al menos un identificador con un sistema y un valor, un nombre con partes de familia y dado, un género administrativo y una fecha de nacimiento. El ejemplo a continuación también declara el perfil IPS Patient en meta.profile y añade información de contacto, dirección, idioma preferido, médico de cabecera y organización gestora.

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

Los elementos que importan

Los elementos de Patient que más importan para la interoperabilidad son el identificador (con sistema, valor y tipo), el nombre (con uso, familia y dado), el género administrativo, la fecha de nacimiento (birthDate), el estado de fallecimiento (deceased), el estado activo (active), el contacto (contact) y el enlace (link). Los identificadores y nombres impulsan la correspondencia entre sistemas, el género y la fecha de nacimiento son hechos administrativos, y link registra cómo un índice maestro de pacientes conectó registros duplicados de una persona.

• identifier es una lista, cada una con un system (quién lo emitió) y un value. El type indica qué tipo es: MR número de historial médico, NI identificador nacional, PPN pasaporte, SS número de seguridad social, de la tabla 0203 de HL7. Un paciente suele tener varios; el número de historial médico de un hospital y un DNI son válidos, y los sistemas coinciden en ellos.
• name también es una lista con un use: official, usual, nickname, maiden, old. family es una cadena; given es una lista. Los guiones, transliteraciones y el orden de los nombres se dejan a la guía de implementación del país.
• gender es el género administrativo con cuatro valores: male, female, other, unknown. Es lo que dice el registro, utilizado para la coincidencia y los formularios. El sexo clínico, la identidad de género y los pronombres van en extensiones u Observaciones, que FHIR R5 y el proyecto Gender Harmony formalizaron.
• birthDate es una fecha, opcionalmente solo el año o el año-mes cuando la fecha exacta se desconoce. Una extensión patient-birthTime añade la hora para los recién nacidos.
• deceased[x] es un booleano o una fecha-hora. active false marca un registro que ya no debe utilizarse (duplicado, trasladado), sin eliminarlo.
• contact lista a las personas de contacto (familiares cercanos, tutores), con un código de relación; no son recursos Patient en sí mismos. Un padre que también es paciente es un RelatedPerson que apunta a ambos.
• link conecta registros de Patient que son la misma persona: replaced-by y replaces después de una fusión, refer al registro autoritativo, seealso para un registro en otro sistema. Así es como un índice maestro de pacientes expresa sus decisiones en FHIR; véase Coincidencia de pacientes.

Lo que añaden los perfiles nacionales

Los perfiles FHIR nacionales e internacionales convierten el recurso base Patient, que está poco definido, en algo utilizable al hacer obligatorios ciertos elementos y añadir extensiones específicas de cada país. US Core requiere identificador, nombre y género, y añade extensiones de raza, etnia y sexo al nacer; el perfil IPS Patient requiere nombre, género y fecha de nacimiento; los perfiles nacionales definen sistemas de identificadores y formatos de dirección.

El recurso base hace que casi todo sea opcional. Los perfiles lo hacen utilizable:

Un registro que cruzará una frontera debe cumplir el perfil de cada lado, lo que en la práctica significa llevar tanto el identificador nacional como un MRN, un nombre oficial completo y una fecha de nacimiento completa. Véase Guías de implementación de FHIR.

Operaciones que utilizará

Las operaciones FHIR más utilizadas con Patient son la búsqueda por identificador o por datos demográficos (GET /Patient con parámetros de identificador, apellido o fecha de nacimiento), la operación $everything, que devuelve al paciente y todos los recursos que lo referencian, y $match, que solicita al algoritmo de correspondencia del servidor los duplicados probables. Una operación $merge se está estandarizando en FHIR R5.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 busca un paciente por identificador; ?family=doe&birthdate=1980-05-23 por datos demográficos.
• GET /Patient/{id}/$everything devuelve el paciente y todos los recursos que lo referencian, paginados, que es como se exporta un registro completo.
• $match (donde se admite) solicita al algoritmo de coincidencia del servidor los duplicados probables; $merge se está estandarizando en R5.

Errores que rompen los registros de pacientes

Los errores que más a menudo rompen los registros FHIR Patient son: almacenar un ID nacional en el resource id en lugar de en identifier, omitir el identifier.system haciendo que choquen valores de diferentes hospitales, poner el nombre completo en text sin las partes de familia y dado, usar el género administrativo para el sexo clínico, y editar un registro fusionado directamente en lugar de enlazarlo y desactivarlo.

• Poner el DNI en id. El id del recurso pertenece al servidor y puede cambiar al importar; los identificadores pertenecen a identifier.
• Un name con todo en text y sin family/given, por lo que las búsquedas por apellido fallan.
• gender utilizado para el sexo clínico, o establecido en unknown porque el formulario no tenía campo.
• Falta identifier.system, por lo que los valores MRN-1 de dos hospitales colisionan.
• Editar un Patient in situ cuando ocurrió una fusión, en lugar de enlazar y desactivar.

En Anpheros

Anpheros representa a cada persona, el titular de la cuenta y cada perfil familiar, como un recurso FHIR Patient en la Plataforma Anpheros, y cada registro que una clínica añade a través de la API hace referencia a ese Patient. Los identificadores de la clínica se conservan como identificadores adicionales con el sistema propio de la clínica, y los datos demográficos que una persona introduce permanecen como datos administrativos de los que no se infiere nada clínico.

Cuando una clínica envía su propio identificador, se almacena como un identifier adicional con el sistema de la clínica, de modo que la misma persona puede ser encontrada desde ambos lados. Los datos demográficos que la persona introdujo en la aplicación son el nombre usual y datos administrativos; el registro nunca infiere nada clínico de ellos.

Páginas relacionadas

• Coincidencia de pacientes y el índice maestro de pacientes
• Guías de implementación de FHIR
• FHIR Encounter explicado
• FHIR Condition explicado
• Búsqueda FHIR explicada
• Ejemplo de Patient en el sitio para desarrolladores

Fuentes

• HL7 FHIR R4: Patient
• HL7 FHIR R4: Patient $everything
• HL7 Terminology: identifier type codes (v2-0203)
• HL7 US Core: Patient profile
• HL7 IPS: Patient profile

Preguntas frecuentes

¿Es Patient lo mismo que Person en FHIR?

No. Person es un recurso administrativo que enlaza al mismo ser humano a través de roles (un Patient aquí, un Practitioner allá, un RelatedPerson en otro lugar). Los recursos clínicos referencian Patient, nunca Person.

¿Dónde van las alergias y las condiciones?

En los recursos AllergyIntolerance y Condition que referencian al Patient. Patient en sí mismo solo contiene datos administrativos.

¿Cómo registro a un recién nacido sin nombre?

Con un nombre cuyo uso sea temporary o vacío, una birthDate con la extensión patient-birthTime, y un link al registro de la madre a través de RelatedPerson o la extensión patient-mothersMaidenName, según especifiquen los perfiles nacionales.

¿Puede un solo recurso Patient ser compartido por dos hospitales?

Cada sistema mantiene su propio recurso Patient con su propio id; comparten identificadores (un DNI) y pueden enlazar los registros. La coincidencia entre sistemas es trabajo de un índice maestro de pacientes, no del recurso.

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 gratisLeer las guías para desarrolladores →

Gratis · 30 pacientes sintéticos · sin tarjeta

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 →