Conoce FSH: El Lenguaje que Hace los Perfiles FHIR Soportables

Si alguna vez abriste un StructureDefinition JSON de FHIR, probablemente tuviste una de estas dos reacciones:

• "Vaya, esto es... verboso."
• "Tiene que haber una forma mejor."

La hay. Se llama FHIR Shorthand (FSH).

A pesar de su nombre, FSH no es otro estándar de interoperabilidad. No reemplaza a FHIR ni cambia cómo los sistemas intercambian datos. Es simplemente un lenguaje diseñado para que la autoría de artefactos FHIR sea agradable para humanos en lugar de para máquinas.

En lugar de editar miles de líneas de JSON, escribes definiciones concisas y legibles que describen tu intención. Un compilador llamado SUSHI luego traduce tus archivos FSH a los artefactos JSON de FHIR requeridos por el IG Publisher.

¿Por qué se creó FSH?

FHIR está diseñado para computadoras. Las Guías de Implementación las escriben humanos. Son audiencias muy diferentes.

Tomemos un requisito simple:

Cada paciente en mi país debe tener un identificador nacional.

Expresar eso como restricciones dentro de un StructureDefinition JSON se vuelve rápidamente difícil de leer y mantener. Con FSH, la misma idea se convierte en algo mucho más cercano a documentación que a programación:

Profile: MyPatient
Parent: Patient

* identifier 1..*
* identifier.system = "https://mycountry.gov/patient-id"

Te concentras en qué quieres restringir, no en la mecánica del JSON subyacente.

¿Qué puedes crear con FSH?

La mayoría asocia FSH con perfiles, pero puede definir casi cualquier artefacto involucrado en una Guía de Implementación:

• Perfiles
• Extensiones
• Modelos Lógicos
• Value Sets
• Code Systems
• Instancias
• Invariantes
• Mappings

Si estás construyendo una Guía de Implementación, lo más probable es que pases la mayor parte del tiempo escribiendo FSH en lugar de editar JSON directamente.

El ecosistema FSH

Una de las cosas que me confundió al principio fue entender dónde encaja FSH en la cadena de herramientas FHIR. Es más fácil pensarlo como un flujo de trabajo de autoría:

FSH no es otro estándar de interoperabilidad. Es simplemente el lenguaje que usas mientras escribes una Guía de Implementación.

Tu primer perfil

Creemos el perfil más pequeño posible:

Profile: SimplePatient
Parent: Patient

* active = true

Eso es todo. Ejecutar SUSHI genera un StructureDefinition válido que representa la misma restricción como un perfil FHIR. SUSHI es el compilador de referencia que transforma FSH en los artefactos JSON consumidos por el resto de la cadena de publicación FHIR.

Agregando restricciones

El verdadero poder de FSH aparece a medida que tus perfiles crecen. En lugar de editar estructuras JSON anidadas, las restricciones se mantienen concisas y legibles.

Por ejemplo, puedes:

• Cambiar cardinalidades
• Fijar valores
• Restringir tipos de datos
• Vincular ValueSets
• Definir slices
• Crear invariantes
• Referenciar extensiones

Cada una de estas cosas generalmente puede expresarse en una sola línea en lugar de docenas de elementos JSON.

Creando extensiones

Los perfiles restringen recursos existentes. Las extensiones agregan información que no forma parte de la especificación base de FHIR. Afortunadamente, la sintaxis es muy similar:

Extension: Nationality
Id: nationality

* value[x] only CodeableConcept

Una vez compilado, esto se convierte en un StructureDefinition FHIR normal que representa una Extensión.

De FSH a JSON con SUSHI

Una vez que hayas escrito tus archivos .fsh, generar los artefactos FHIR es sencillo:

sushi .

SUSHI lee el proyecto FSH, procesa cada definición y produce los recursos FHIR correspondientes como JSON. También se integra naturalmente con el HL7 IG Publisher, que genera el sitio web final de la Guía de Implementación.

También puedes inicializar un nuevo proyecto con:

sushi init

Esto crea la estructura de proyecto recomendada, incluyendo el directorio input/fsh donde viven tus archivos FSH y el archivo de configuración necesario para la compilación.

Consejos desde la experiencia

En lugar de aprender primero todas las palabras clave de FSH, aprende el flujo de trabajo. Entiende estas cuatro piezas:

1. Recursos FHIR
2. Perfiles
3. FSH
4. SUSHI

Una vez que esos conceptos encajan, el lenguaje en sí es sorprendentemente pequeño. También recomiendo:

• Visual Studio Code con la extensión FSH
• Git para control de versiones
• Un archivo .fsh por perfil o extensión
• Aliases desde el principio — te ahorrarán mucho tipeo
• RuleSets cuando notes que repites las mismas restricciones en múltiples perfiles

¿Qué sigue?

En las próximas guías veremos:

• Construir un proyecto FSH completo
• Perfilar Observations
• Escribir extensiones reutilizables
• ValueSets y bindings de terminología
• Slicing sin perder la cordura
• Publicar una Guía de Implementación