🔥 R6: Resta mediante recursos adicionales

El problema que R6 tenía que resolver

R6 es la primera versión completamente normativa de FHIR. Una vez publicada, no se permiten cambios disruptivos. Sin embargo, muchos recursos FHIR siguen en el nivel 0–2 del FMM (FHIR Maturity Model) — no son lo suficientemente estables como para congelarlos. Congelarlos de forma normativa bloquearía su evolución o forzaría cambios disruptivos posteriores, lo que va en contra del propósito de adoptar la normatividad.

La solución: trasladar los recursos inmaduros fuera del núcleo a Implementation Guides separadas denominadas IGs incubadoras. Estos recursos se denominan recursos adicionales. Funcionan como recursos FHIR de primera clase — misma API REST, misma búsqueda, mismo perfilado — pero evolucionan en su propio ciclo de publicación, independiente de la especificación central. Por ejemplo, ViewDefinition de SQL on FHIR es un recurso adicional en R6 — se distribuye en su propia IG, no en la especificación central.

«Los comentarios del mercado son muy contundentes: los cambios adicionales en los recursos FHIR resultan cada vez más costosos, y uno de los pocos incentivos para que el mercado adopte R6 es la estabilidad.» — Grahame Grieve

Cómo funcionan

Un recurso adicional se define mediante un StructureDefinition publicado en una IG incubadora. Debe tener kind: resource, derivation: specialization, basarse en Resource o DomainResource, y disponer de una URL canónica fuera de http://hl7.org/fhir.

En JSON, las instancias de recursos adicionales incluyen una propiedad extra resourceDefinition — una referencia canónica versionada a su StructureDefinition:

{
  "resourceType": "ViewDefinition",
  "resourceDefinition": "http://hl7.org/fhir/uv/sql-on-fhir/StructureDefinition/ViewDefinition|2.0.0-pre",
  "id": "example-1"
}

Esta propiedad está ausente en los recursos del núcleo. Indica al servidor qué definición debe usar para la validación.

En los CapabilityStatements, los recursos adicionales aparecen en rest.resource como cualquier otro recurso, pero con un elemento definition que apunta al StructureDefinition específico de versión.

Todos los recursos adicionales deben estar registrados en HL7 y aprobados. Las propuestas se tramitan a través del canal de Zulip #Additional-Resource-Proposals.

Recursos adicionales frente a recursos personalizados

Los recursos adicionales y los recursos personalizados utilizan el mismo mecanismo de StructureDefinition — ambos definen kind: resource con derivation: specialization y una URL canónica fuera del núcleo. La diferencia es de gobernanza, no de tecnología.

Un recurso adicional está registrado en HL7, se le asigna un nombre oficial, se revisa su calidad y se publica en una IG incubadora. Sigue un camino hacia el núcleo. Se espera que los servidores que declaran conformidad con una IG incubadora lo soporten. Cuando madura, migra a la especificación central.

Un recurso personalizado lo define cualquier parte — un proveedor, un proyecto, un programa nacional. No está registrado en HL7, no está revisado y no sigue ningún camino hacia el núcleo. Funciona técnicamente (misma API REST, misma validación), pero no ofrece garantía de interoperabilidad más allá de las partes que acordaron utilizarlo.

La implicación práctica: si necesita un tipo de recurso que no existe en el núcleo, consulte primero las IGs incubadoras. Es posible que alguien ya lo haya definido como recurso adicional. Si no es así, puede definir un recurso personalizado, pero sepa que la interoperabilidad dependerá exclusivamente de usted.

Qué salió del núcleo

El FMG (FHIR Management Group) evaluó cada recurso mediante los niveles FMM, los datos de uso de Simplifier, el historial de commits de git, la actividad en Jira y los recuentos de referencias en ejemplos y extensiones. El resultado: aproximadamente 27 recursos se trasladaron a IGs incubadoras.

IG incubadora	Estado	Recursos
fhir-testing-ig	Trasladado	TestScript, TestPlan, TestReport
admin-incubator	Trasladado	PersonalRelationship, EncounterHistory, InsuranceProduct
oo-incubator	Trasladado	DeviceDispense, BiologicallyDerivedProductDispense, Transport, DeviceAssociation, DeviceUsage, FormularyItem, InventoryItem, InventoryReport
data-access-policies	Trasladado	Permission
cg-incubator	En revisión	GenomicStudy, MolecularDefinition, MolecularSequence
ebm-incubator	En revisión	Citation, Evidence, EvidenceVariable, ArtifactAssessment

ConditionDefinition (Patient Care) y los recursos de definición de medicamentos (MedicinalProductDefinition, PackagedProductDefinition, Ingredient, etc.) también están bajo revisión de los comités.

Algunos recursos fueron eliminados por completo — no trasladados a recursos adicionales, simplemente suprimidos: SubstanceNucleicAcid, SubstancePolymer, SubstanceProtein, SubstanceReferenceInformation, SubstanceSourceMaterial. Su contenido fue absorbido por otros recursos a cargo del Biomedical Research and Regulation (BRR) Work Group.

Problemas abiertos

Gestión de versiones. Los recursos adicionales evolucionan según su propio calendario. Un servidor que soporta el núcleo R6 y tres IGs incubadoras debe gestionar múltiples matrices de versiones. Esto añade complejidad a las pruebas de conformidad y la validación.

Herramientas. SUSHI no gestiona bien los recursos adicionales — lista automáticamente los bundles de parámetros de búsqueda de forma incorrecta y requiere snapshots que los StructureDefinitions de las incubadoras no incluyen. Existen soluciones alternativas, pero son frágiles. IG Publisher funciona si se sigue el patrón de fhir-testing-ig.

Vacíos temporales. Algunos recursos trasladados fuera del núcleo están temporalmente no disponibles mientras los grupos de trabajo configuran los CI-builds de sus IGs incubadoras. A principios de 2026, no todas las IGs están operativas.

Consent frente a Permission. Permission se trasladó a recursos adicionales; Consent permaneció en el núcleo. En contextos de la UE donde el RGPD define seis bases jurídicas para el tratamiento de datos (no solo el consentimiento), los implementadores podrían forzar el uso de Consent para cubrir lo que Permission debería gestionar — porque Permission tiene menos visibilidad al ser un recurso «adicional».

Qué implica para los implementadores

Si utiliza alguno de los recursos afectados, esto es lo que cambia en R6:

Desaparecen de la especificación central. Deberá buscarlos en su IG incubadora.
Las instancias JSON necesitan resourceDefinition. Añada la referencia canónica versionada junto a resourceType.
Los CapabilityStatements necesitan definition. Apunte al StructureDefinition específico de versión.
Los parámetros de búsqueda se trasladan con el recurso. Las URLs canónicas permanecen iguales; las versiones pueden cambiar.
Las referencias desde recursos del núcleo se convierten en extensiones. Coverage referenciaba InsurancePlan, DeviceDefinition referenciaba ChargeItemDefinition — ahora son extensiones en las IGs incubadoras.

Lo que no cambia: los recursos adicionales siguen siendo recursos FHIR. Misma API REST. Misma búsqueda. Mismo perfilado. El mecanismo es administrativo, no técnico — los recursos funcionan de la misma manera, simplemente residen en un paquete diferente. Y el camino de vuelta al núcleo existe — cuando un recurso madura, su grupo de trabajo puede solicitar la aprobación del FMG para trasladarlo de nuevo al siguiente ciclo de votación.

Para Aidbox, se trata de un cambio menor. Hemos soportado recursos personalizados desde el primer día — los recursos adicionales utilizan el mismo mecanismo. El único ajuste necesario es la validación de la propiedad resourceDefinition.

Referencias

Especificación:

Debates de la comunidad (chat.fhir.org):

HL7:

Plantilla de IG incubadora de ejemplo

Véase también: FHIR R4 vs FHIR R5.