Respuesta corta: los recursos FHIR base son deliberadamente flexibles: casi todo es opcional y la mayoría de los códigos son solo ejemplos, para que un estándar sirva a todos los países. Un perfil es una StructureDefinition que ajusta un recurso para un uso específico: en este contexto, Patient debe tener un identificador de este tipo, Observation.code debe ser un código LOINC de esta lista, este elemento debe ser compatible, aquel no puede aparecer. Una extensión añade un elemento que el recurso base no tiene, identificado por una URL y definido por su propia StructureDefinition. Las guías de implementación (US Core, IPS, guías nacionales) son colecciones de perfiles, extensiones, conjuntos de valores y ejemplos. Un recurso indica qué perfiles afirma seguir en meta.profile, y un validador lo comprueba.
Qué puede cambiar un perfil
Un perfil de FHIR solo puede cambiar un recurso limitándolo: ajustando la cardinalidad, marcando elementos como 'must-support' (deben ser compatibles), fijando valores o patrones, vinculando elementos a conjuntos de valores con una fuerza, dividiendo listas en partes con nombre, restringiendo tipos de elección, añadiendo invariantes FHIRPath y limitando objetivos de referencia. Un perfil no puede añadir elementos, renombrar nada ni relajar la especificación base.
| Restricción | Qué hace | Ejemplo |
|---|---|---|
| Cardinalidad | Hace que elementos opcionales sean requeridos o los prohíbe | Patient.identifier 1..*; Patient.photo 0..0 |
| Debe soportar | Los receptores deben poder almacenar y mostrar el elemento si se envía | US Core marca birthDate como must-support |
| Valor fijo o patrón | Bloquea un elemento a un solo valor | Observation.category fijo a vital-signs |
| Vinculación | Señala un elemento a un conjunto de valores con una fuerza | Observation.code vinculado a la lista de signos vitales, requerido |
| Segmentación | Divide una lista en partes con nombre y sus propias reglas | Presión arterial: componente segmentado en sistólica y diastólica |
| Restricción de tipo | Limita una opción | value[x] restringido a valueQuantity |
| Invariante | Una regla FHIRPath que debe cumplirse | "effective[x] debe estar presente" o "value o dataAbsentReason" |
| Destino de referencia | Limita a qué puede apuntar una referencia | subject solo Patient, y solo pacientes que cumplan este perfil |
Un perfil solo puede restringir. No puede añadir elementos (para eso están las extensiones), renombrar nada ni flexibilizar la base.
Fuerza de vinculación
FHIR define cuatro fuerzas de vinculación. required (requerido): el código debe provenir del conjunto de valores. extensible (extensible): usa el conjunto de valores si un concepto encaja; de lo contrario, se permite otro código. preferred (preferido): recomendado, no obligatorio. example (ejemplo): solo ilustrativo, que es lo que tienen la mayoría de los recursos base. Confundir extensible con required es una fuente común de errores de validación falsos.
Un extracto de perfil legible
Un perfil de FHIR es una StructureDefinition cuyo diferencial lista solo las restricciones que difieren del recurso base, mientras que su instantánea lista cada elemento. El extracto legible a continuación restringe Observation a la presión arterial en casa: el código está fijado a LOINC 85354-9 y el componente se divide en exactamente una parte sistólica y una parte diastólica.
El diferencial de un perfil lista solo lo que cambió respecto a la base; el snapshot lista todo. Este diferencial dice que una Observation de presión arterial debe llevar LOINC 85354-9 y exactamente dos componentes:
{
"resourceType": "StructureDefinition",
"url": "https://example.org/fhir/StructureDefinition/bp-home",
"name": "HomeBloodPressure",
"status": "active",
"kind": "resource",
"abstract": false,
"type": "Observation",
"baseDefinition": "http://hl7.org/fhir/StructureDefinition/Observation",
"derivation": "constraint",
"differential": {"element": [
{"id": "Observation.code", "path": "Observation.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "85354-9"}]}},
{"id": "Observation.component", "path": "Observation.component", "min": 2, "max": "2",
"slicing": {"discriminator": [{"type": "pattern", "path": "code"}], "rules": "closed"}},
{"id": "Observation.component:systolic", "path": "Observation.component", "sliceName": "systolic", "min": 1, "max": "1"},
{"id": "Observation.component:systolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}},
{"id": "Observation.component:diastolic", "path": "Observation.component", "sliceName": "diastolic", "min": 1, "max": "1"},
{"id": "Observation.component:diastolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}}
]}
}
Los perfiles rara vez se escriben a mano; los autores usan FHIR Shorthand (FSH) con SUSHI, o herramientas como Forge y Simplifier, y publican con el IG Publisher de HL7. Las guías se distribuyen como paquetes (hl7.fhir.us.core#6.1.0, hl7.fhir.uv.ips#1.1.0) que los validadores y servidores cargan.
Extensiones
Una extensión es un elemento clave-valor colocado en extension (o modifierExtension cuando cambia el significado del recurso y no debe ignorarse). Su url es la URL canónica de su StructureDefinition; su valor es un value[x] tipado, o extensiones anidadas. Birth place es una extensión definida por HL7 en Patient:
{
"resourceType": "Patient",
"id": "example",
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {"city": "Lyon", "country": "FR"}
}],
"name": [{"family": "Doe", "given": ["Jane"]}]
}
Reglas de buenas prácticas: busca una extensión existente (el registro de HL7 y las guías nacionales) antes de definir una; dale una URL bajo un dominio que controles; defínela en una StructureDefinition para que otros puedan validarla; nunca uses una extensión para algo que un elemento base ya cubre.
meta.profile y validación
meta.profile es la lista de URLs canónicas a las que un recurso FHIR afirma conformarse, y afirmar no es probar. Un validador comprueba el recurso contra la especificación base y contra cada perfil reclamado, o contra un perfil que nombres. El validador de referencia de HL7 se ejecuta localmente con paquetes, y los servidores FHIR exponen una operación $validate que acepta un parámetro de perfil.
meta.profile lista las URLs canónicas a las que un recurso afirma conformarse. Afirmar no es probar: un validador comprueba el recurso contra la especificación base y contra cada perfil afirmado (o contra un perfil que le pidas usar). El validador de referencia de HL7 (validator_cli.jar) se ejecuta localmente y carga paquetes; los servidores ofrecen POST /Observation/$validate?profile=…; el IG Publisher valida todos los ejemplos en una guía. Un recurso puede conformarse a varios perfiles a la vez (un perfil nacional de Patient y el IPS Patient) siempre que no se contradigan.
Dos reglas prácticas: un servidor que declara un perfil en su CapabilityStatement debe rechazar recursos que fallen en él; un cliente que recibe recursos no debe rechazar extensiones desconocidas o elementos extra que un perfil no haya prohibido, porque la especificación base los permite.
En Anpheros
Anpheros Platform es un servidor FHIR R4 que utiliza LOINC para observaciones, ATC para medicamentos y SNOMED CT cuando es aplicable, y ofrece un validador gratuito que comprueba la estructura de un recurso contra FHIR R4. Cuando una clínica envía recursos con meta.profile establecido en un perfil nacional o IPS, la afirmación se conserva para que un sistema posterior pueda validarla.
El validador gratuito está en el sitio para desarrolladores. Para las guías en sí, consulta Guías de implementación de FHIR explicadas.
Páginas relacionadas
- Guías de implementación FHIR explicadas
- CodeableConcept y Coding en FHIR
- Recurso Observation de FHIR explicado
- Recurso Patient de FHIR explicado
- Servidores de terminología explicados
- Validador FHIR (sitio para desarrolladores)
Fuentes
- HL7 FHIR R4: Perfilado de FHIR
- HL7 FHIR R4: Extensibilidad
- HL7 FHIR R4: StructureDefinition
- HL7 FHIR R4: Vinculaciones de terminología
- HL7 FHIR Shorthand
- Validador FHIR de HL7
- HL7 FHIR R4: extensión patient-birthPlace
Preguntas frecuentes
¿Puede un perfil añadir un nuevo elemento a un recurso?
No. Los perfiles solo restringen. Los datos nuevos van en una extensión, que el perfil puede entonces requerir o prohibir como cualquier otro elemento.
¿Qué exige realmente "must-support"?
La guía de implementación lo define; típicamente, que un remitente complete el elemento cuando tenga los datos y un receptor lo almacene y pueda mostrarlo. No hace que el elemento sea obligatorio.
Si un recurso no tiene meta.profile, ¿es inválido?
No. meta.profile es una afirmación, no un requisito. Un servidor o una guía pueden requerirlo; la especificación base no. Se puede pedir a los validadores que comprueben contra un perfil que el recurso no declara.
¿Cómo sé qué perfil usar en mi país?
Cada comunidad nacional de FHIR publica una guía principal (US Core, UK Core, nl-core, los Basisprofile alemanes, etc.); la página de guías de implementación explica cómo encontrarlas. Los resúmenes transfronterizos usan el IPS.
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.
Gratis · 30 pacientes sintéticos · sin tarjeta
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 →