Errores de Cardinalidad y Slicing en FHIR

Los Dos Errores Que Todo Implementador de FHIR Acaba Encontrando

Conviertes un registro, lo validas y el informe vuelve en rojo con mensajes como minimum required = 1, but only found 0 o This element does not match any known slice. Son errores de cardinalidad y de slicing — los dos fallos más comunes, y más malentendidos, en la conformidad FHIR. No son tanto fallos de tus datos como un desajuste entre lo que enviaste y lo que exige un perfil. Esta guía explica exactamente qué significa cada error, por qué se dispara y cómo corregirlo, para que el próximo informe rojo sea una corrección de treinta segundos en lugar de una tarde. Puedes reproducir cada ejemplo en nuestro Validador de Recursos FHIR, que se ejecuta por completo en tu navegador.

Cardinalidad — Leer los Números Tras Cada Elemento

Abre cualquier página de recurso en hl7.org/fhir — por ejemplo el recurso Patient — y junto a cada elemento verás un par de números como 0..1, 1..1 o 0..*. Esto es la cardinalidad, y se define en la sección de la especificación FHIR sobre la Element Definition (las propiedades ElementDefinition.min y ElementDefinition.max). El primer número es el mínimo de veces que el elemento debe aparecer; el segundo es el máximo, donde * significa ilimitado.

• 0..1 — opcional, como mucho una vez. La mayoría de los elementos. Puedes omitirlo; no puedes repetirlo.
• 1..1 — obligatorio, exactamente una vez. Observation.status y Observation.code son 1..1 en la especificación base.
• 0..* — opcional, repetible. Patient.name y Observation.identifier son arrays.
• 1..* — obligatorio y repetible. Al menos uno debe estar presente. Los perfiles suelen endurecer un elemento a 1..*.

El error cardinalidad mínima no cumplida significa que un elemento cuyo min es 1 (o más) apareció cero veces. El error cardinalidad máxima superada significa que aportaste más ocurrencias de las que permite max — normalmente un array donde la especificación admite un único valor. Ambos son errores bloqueantes: un servidor conforme rechazará el recurso.

Por Qué un Campo Que Sí Aportaste Sigue Leyéndose como "Found 0"

Los fallos de cardinalidad más confusos ocurren cuando estás seguro de que el campo está ahí. Tres causas explican casi todos. Primero, un valor vacío sigue contando como ausente — "status": "" o "identifier": [] no satisface nada, porque las reglas de FHIR sobre elementos vacíos (descritas en la página "Elements" de la especificación) dicen que un elemento sin valor se trata como no presente. Segundo, pusiste el valor en el nivel de anidamiento equivocado; code en la raíz de una Observation no es lo mismo que component.code. Tercero — el sutil — un perfil vinculado a tu recurso elevó el mínimo. La base dice que Patient.identifier es 0..*, pero US Core lo restringe a 1..*, así que un Patient sin identificador es perfectamente válido contra la base e inválido contra US Core. La ruta de error del validador te dice qué elemento, y la URL del perfil en el mensaje te dice qué regla.

Los Perfiles Son Donde la Cardinalidad Se Endurece

Un perfil es una versión restringida de un recurso base, publicada como StructureDefinition. La promesa definitoria del perfilado, según la página "Profiling" de la especificación FHIR, es que un perfil solo puede estrechar la base — puede elevar un mínimo de 0 a 1, bajar un máximo de * a 1, o fijar un valor, pero nunca puede relajar lo que la base exige. Por eso tu recurso puede pasar una comprobación de recurso desnudo y fallar en cuanto lo validas contra una guía de implementación como US Core o el International Patient Summary.

Vale la pena memorizar ejemplos concretos de US Core porque los encontrarás constantemente. En el perfil US Core Patient, name se eleva a 1..* e identifier a 1..*; un Patient sin ninguno falla con dos errores de cardinalidad mínima. En US Core Observation, category pasa a 1..* y code debe llevar un código reconocido. Estas restricciones existen porque los sistemas aguas abajo — los que consumen tus datos para tratamiento o reporte — dependen de que esos campos estén siempre presentes. El validador hace cumplir un contrato, no pone pegas.

Slicing — Cuando un Elemento de Array Debe Significar Algo Específico

El slicing es el concepto más difícil, y la fuente del críptico mensaje does not match any known slice. El problema que resuelve es este: un elemento como Patient.identifier es un array repetible, pero un perfil puede necesitar decir "una de estas entradas debe ser un Número de Historia Clínica y otra debe ser un Número de Seguridad Social." No puedes expresar eso solo con cardinalidad, porque la cardinalidad solo cuenta ocurrencias — no puede decir qué debe ser cada ocurrencia. El slicing, definido en la página "Profiling" de la especificación FHIR bajo "Slicing," particiona un elemento repetible en slices con nombre, cada uno con sus propias restricciones y su propia cardinalidad.

Cada definición de slice incluye un discriminador — la regla que el validador usa para decidir a qué slice pertenece una entrada del array. Los discriminadores tienen un tipo y una ruta. Los tipos comunes, listados en la especificación, son value (coincidir con un valor fijo, p. ej. un sistema de codificación), pattern (coincidir con un patrón estructural), type (coincidir con el tipo de dato) y profile (la entrada debe conformar a un perfil con nombre). Para los identificadores de US Core Patient, el discriminador suele ser un pattern sobre identifier.system, así que cada entrada se clasifica en un slice por su URL de sistema.

Descifrar "Does Not Match Any Known Slice"

Este mensaje significa que el validador tomó una de tus entradas del array, la pasó por el discriminador de cada slice y ninguno coincidió. Imagina un perfil que divide Patient.identifier en un slice MRN (discriminado por system = http://hospital.example.org/mrn) y un slice SSN (system = http://hl7.org/fhir/sid/us-ssn). Si envías un identificador con system a http://hospital.example.org/MRN — en mayúsculas, una errata, o simplemente un sistema que el perfil nunca definió — esa entrada no coincide con ningún slice. Que esto sea un error o una advertencia depende del ajuste rules del slicing: el slicing open tolera entradas extra sin coincidencia, mientras que el slicing closed las rechaza de plano. La sección de slicing de la especificación documenta open, closed y openAtEnd con precisión.

El segundo fallo de slicing es un error de cardinalidad a nivel de slice, y se lee casi como el de nivel de recurso: Slice 'MRN' — minimum required = 1, but only found 0. Esto dice que el slice en sí es obligatorio y no aportaste ninguna entrada que coincida con su discriminador. La corrección no es añadir cualquier identificador — es añadir uno cuyo campo discriminante coincida con el slice exactamente. Un caso común y enloquecedor es enviar el valor correcto pero el system equivocado: el dato está "ahí", pero como el discriminador es la URL del sistema, el validador no puede asignarlo al slice, así que el slice cuenta como vacío.

Una Lista de Corrección para los Tres Modos de Fallo

Cuando aparece un error de cardinalidad o slicing, trabaja en este orden. La ruta de elemento del validador — algo como Patient.identifier[0].system u Observation.component[1].code — te dice exactamente dónde mirar, igual que para las comprobaciones estructurales cotidianas que cubre nuestro Validador de Recursos FHIR.

• Cardinalidad mínima no cumplida (nivel de recurso) — confirma que el elemento está presente, no vacío y en el nivel de anidamiento correcto. Si parece presente, comprueba si un perfil elevó el mínimo; el mensaje nombra la StructureDefinition. Añade el elemento obligatorio con un valor real.
• Cardinalidad máxima superada — enviaste un array donde corresponde un único valor, o más repeticiones de las que permite el perfil. Colapsa el array a un valor, o elimina las entradas sobrantes.
• No coincide con ningún slice conocido — inspecciona el discriminador (tipo y ruta) del elemento ofensor. Haz que el campo discriminante de la entrada coincida exactamente con un slice definido. Cuidado con la sensibilidad a mayúsculas, las barras finales en las URL de sistema y los sistemas de códigos específicos de versión.
• Mínimo de slice no cumplido — un slice obligatorio no tiene entrada coincidente. Añade una entrada cuyo valor discriminante coincida con el slice, no simplemente otra entrada del mismo elemento.

Dónde Muerden Estos Errores en la Migración desde HL7 v2

Los fallos de cardinalidad y slicing se concentran fuertemente en el trabajo de migración, cuando puenteas flujos heredados de HL7 v2 hacia FHIR. Un segmento PID de v2 lleva identificadores de paciente en PID-3, a menudo varias repeticiones con códigos de tipo de identificador de la Tabla HL7 0203. Cuando los mapeas a un US Core Patient, cada identificador tiene que aterrizar en el slice correcto con la URL de system correcta — y las fuentes v2 son notoriamente laxas con los tipos de identificador, así que un MRN etiquetado como identificador genérico no se clasificará en ningún slice. Este es exactamente el tipo de defecto que conviene atrapar antes de que el recurso llegue a un servidor. Nuestro Conversor HL7 v2 a FHIR produce el recurso, y validar la salida de inmediato saca a la luz un identificador mal slice-ado como una ruta precisa en lugar de un rechazo vago del servidor. Para el contexto de cómo se relacionan ambos estándares, nuestra guía complementaria ¿Qué Es FHIR? Guía de Healthcare IT recorre los recursos, R4 y la mentalidad de validación.

Por Qué Validar en Local Importa para la PHI

Los errores de cardinalidad y slicing son, por su naturaleza, cosas que depuras de forma iterativa — pega, lee la ruta, corrige, vuelve a validar, repite una docena de veces. Cada una de esas iteraciones implica un recurso real lleno de información médica protegida: identificadores, nombres, fechas de nacimiento, diagnósticos. Enrutar ese bucle por un validador alojado significa transmitir datos identificables del paciente a un tercero en cada pasada, una preocupación clara bajo la Regla de Seguridad de HIPAA y el RGPD. Un validador en el navegador mantiene todo el bucle de depuración en tu máquina — puedes confirmar en la pestaña de red que nada sale — que es lo que hace seguro pegar recursos de producción mientras persigues un desajuste de slice obstinado.

Conocer los Límites de una Comprobación Ligera

Sé honesto sobre el alcance. Un validador rápido de navegador está hecho para la pregunta constante de "¿están mis elementos presentes y correctamente slice-ados?" Para la conformidad completa contra una guía de implementación publicada — resolviendo cada StructureDefinition, consultando servidores de terminología para la pertenencia a value sets y evaluando invariantes FHIRPath — el validador oficial de HL7 sigue siendo la referencia. Usa la comprobación local rápida para iterar a velocidad y atrapar los errores de cardinalidad y slicing que representan la inmensa mayoría de los rechazos reales, luego ejecuta el validador pesado una vez para la certificación formal. Los dos son complementarios: uno te mantiene en movimiento, el otro da el visto bueno.

Conclusión

La cardinalidad es contar — cuántas veces un elemento puede o debe aparecer, expresado como min..max y endurecido por los perfiles. El slicing es identidad — qué cosa específica debe ser cada entrada de un elemento repetible, hecho cumplir por discriminadores. Cardinalidad mínima no cumplida significa que un elemento o slice obligatorio falta o está vacío; no coincide con ningún slice conocido significa que el campo discriminante de una entrada no coincidió con nada que el perfil definiera. Lee la ruta de elemento, comprueba el perfil, alinea tus discriminadores, y estos errores dejan de ser un misterio. Ten abierto el Validador de Recursos FHIR mientras trabajas, combínalo con el Conversor HL7 v2 a FHIR durante las migraciones, y corregirás el próximo informe rojo antes de que llegue a un servidor — con los datos del paciente sin salir nunca de tu navegador.