El problema
R6 traslada unos 27 recursos inmaduros fuera de la especificación central hacia IGs de incubadora separadas, de modo que lo que permanezca en el núcleo pueda congelarse como normativo. Pero los recursos se referencian entre sí. Cuando uno se va, cada elemento que apuntaba a él se convierte en una flecha sin destino — y esos elementos residen en recursos que permanecen y que están a punto de quedar bloqueados para siempre.
Un ejemplo: StructureMap y el lenguaje de mapeo FHIR se trasladaron a una incubadora. Tres recursos que permanecen — ActivityDefinition, PlanDefinition y RequestOrchestration — declaran cada uno un elemento como canonical(StructureMap): este campo puede enlazar con un StructureMap, y nada más. El único tipo al que se le permite apuntar ha desaparecido. La seguridad tiene el mismo problema: Permission se trasladó fuera, Consent se quedó y aún hace referencia a él.
¿Qué se coloca ahora en ese elemento? No se puede dejar como está — nombra un tipo que la especificación ya no define. Y cualquier opción que se elija se vuelve permanente el día en que R6 pase a normativo. Esa es la pregunta que Brian Postlethwaite planteó al FMG: ¿simplemente eliminar la restricción de tipo, o eliminar la propiedad por completo?
Dos casos fáciles, uno difícil
Gino Canessa estableció la regla. Para dos de los tres casos, la solución es mecánica:
- Ya apunta a todos los tipos — no se necesita ningún cambio.
- Apunta a tipos del núcleo y a tipos trasladados — eliminar de la lista de destinos los que se han trasladado.
- Apunta solo a tipos trasladados — no hay una buena respuesta.
El tercero es donde reside el debate. Eliminar el último destino y la referencia se promociona a «any» — y en un recurso normativo, «any» es para siempre.
Cuatro opciones malas
Ampliar a Any. Lo que se obtiene por defecto si simplemente se elimina el tipo de destino. Seguridad está adoptando esta vía para Permission en esta votación, con la esperanza de encontrar una solución más clara posteriormente.
«Creo que la única opción es elevarlo a "any". Lo desafortunado es que lo convertirá en "any" para siempre.» — Lloyd McKenzie
Apuntar a Basic. La alternativa de Lloyd: canonical(Basic) mantiene el elemento restringido, ya que es poco probable que alguien utilice Basic salvo para exponer recursos adicionales. La objeción de Gino es que en R6 Basic no se usará para recursos adicionales en absoluto, porque estos pueden usarse directamente. La contrarréplica de Lloyd: aun así, es inocuo y mucho menos propenso a ser mal utilizado que Any.
Eliminar el elemento. Orders & Observations ya hizo esto en todos los casos en que el único destino admitido era un recurso adicional, y Grahame Grieve lo establece como orientación definitiva.
«Si un elemento solo hace referencia a un recurso que ha sido trasladado a incubación, entonces el elemento debe eliminarse.» — Grahame Grieve
Convertirlo en una extensión. Eliminar el elemento del núcleo y definir la extensión en el mismo IG de incubadora que el destino — lo cual, como señala Gino, hace que la carga de usar una extensión frente a un elemento sea prácticamente equivalente.
El consenso es una decisión de criterio, no una regla. Si la relación es genuinamente necesaria y el destino simplemente aún no es normativo, se mantiene el elemento: no tiene sentido forzar extensiones y soluciones alternativas en un recurso normativo solo porque el destino no está del todo listo. Si la existencia y el diseño del destino son todavía demasiado tempranos, una extensión es la señal honesta.
Si está migrando
- Elementos que han desaparecido. Algo que se usa en R4/R5 puede simplemente no estar en R6. Compruebe el IG de incubadora correspondiente para encontrar una extensión con el mismo significado antes de crear la suya propia.
- Elementos que se han convertido en
Any. La seguridad de tipos en la que confiaba ha desaparecido de la especificación base. Si necesita recuperarla, inclúyala en su propio perfil — a diferencia de la especificación base, usted podrá modificarlo más adelante. - Vínculos, no solo datos. Las páginas que ahora enlazan con una incubadora también llevan marcadores de cambio de votación — en la práctica, únicamente las páginas rXdiffs y la página de vínculos de documentación.
Conclusión
El objetivo de todo esto es un núcleo sólido en R6: congelar lo que es maduro, trasladar el resto fuera y ofrecer a los implementadores una base que no cambie bajo sus pies. Vale la pena hacerlo — pero la factura llega en los márgenes, en decisiones que no son en absoluto mecánicas.
Obsérvese que ninguna de las cuatro opciones es gratuita. Eliminar un elemento es un cambio disruptivo: cualquiera que haya rellenado ese campo en R5 no tiene dónde colocar los datos en R6, y sus instancias dejan de ser válidas — razón exacta por la que Lloyd advirtió que esto empuja a los implementadores hacia extensiones personalizadas. Ampliar a Any no rompe nada hoy, pero una vez que se publica en un recurso normativo, la restricción desaparece para siempre y nadie podrá restringirla después. Así que la elección es entre una ruptura visible ahora y una pérdida que nunca podrá deshacerse — y se está tomando elemento por elemento, semanas antes de una votación.
Fuente: chat.fhir.org — #fmg > R6 Review. Véase también: R6: Sustracción mediante recursos adicionales y Fecha de lanzamiento de FHIR R6 y novedades.
