Grahame Grieve publicó una entrada en su blog sobre la persistencia de recursos FHIR — léala aquí. La pregunta principal que aborda es cómo almacenar recursos FHIR: ¿deberíamos guardarlos en una base de datos «tal cual» usando JSON (ProtoBuf, etc.), o crear un esquema específico?
Formato para la persistencia
La primera afirmación de Grahame es que el formato FHIR fue diseñado para el intercambio de información, no para la persistencia. Nosotros (Health Samurai) estamos debatiendo con la comunidad FHIR la posibilidad de utilizar la especificación de formato FHIR para la persistencia. Sin embargo, ¡Grahame no niega esta posibilidad en su entrada! Por tanto, este es uno de los temas a tratar en nuestra pista de connectathon — Storage & Analytics on FHIR.
Sistemas especializados vs. genéricos
Grahame distingue entre sistemas especializados con un modelo fijo y sistemas más genéricos (es decir, repositorios de datos clínicos). En el primer caso, es posible diseñar un esquema más eficiente para almacenar y consultar los datos. Sin embargo, cuanto más genérico se vuelve el sistema, más atractivo resulta almacenar los recursos FHIR tal cual.
Me gustaría compartir algunas reflexiones al respecto.
Complejidad estructural de la informática sanitaria
En mi opinión, uno de los problemas más complejos de la informática sanitaria es disponer de un buen modelo de información.
¿Qué hace que un modelo de información sea bueno? Un buen modelo es resistente a los cambios en los requisitos y los casos de uso porque mantiene relaciones objetivas con el mundo real. Cualquiera que haya trabajado en informática sanitaria sabe lo difícil que es lograrlo. Nuestro dominio es complejo. Uno de los valores que ofrece FHIR es un modelo de información listo para usar que es suficientemente bueno. Si usted no es un experto en informática sanitaria con muchos años de experiencia y desea desarrollar la próxima aplicación de salud digital, le recomiendo comenzar con el modelo de datos FHIR, que ha acumulado una gran cantidad de conocimiento experto. En este punto, contar con un marco técnico bien adaptado sería muy conveniente.
Isomorfismo y transformaciones
Si desea tener su propio esquema/modelo y admitir FHIR, se enfrentará a una transformación entre su modelo y FHIR, y viceversa. Este tipo de transformación es trivial si su modelo es isomorfo a FHIR. Sin embargo, si los modelos a traducir no coinciden entre sí, entonces tendrá un gran problema. Existe un conocido desajuste de impedancia objeto-relacional. Otro ejemplo del ámbito de la informática sanitaria: la traducción de HL7 v.2 a FHIR es bastante sencilla —son similares—, pero la traducción de HL7 v.3 a FHIR es una pesadilla, ya que están diseñados de forma completamente diferente.
Documentos vs. tablas
Los recursos FHIR están diseñados como agregados del diseño orientado al dominio. El movimiento NoSQL afirmó que el uso de bases de datos de documentos está bien alineado con el enfoque de agregados. Si intenta crear una base de datos relacional normalizada para recursos FHIR, obtendrá miles de tablas generadas. Trabajar con tantas tablas no es trivial. La mayoría de las operaciones requieren un recurso como agregado, y obtener o manipular un recurso desde una docena de tablas no es sencillo y tiene implicaciones en el rendimiento.
Abierto vs. cerrado
Otro aspecto crítico a tener en cuenta es si su sistema es abierto o cerrado.
En un sistema abierto, potencialmente se permite la extensión flexible del modelo: añadir nuevos atributos y restricciones a las entidades existentes. En FHIR contamos con extensiones para los recursos FHIR. Los sistemas reales suelen evolucionar hacia sistemas abiertos. Construir un sistema abierto con un esquema estricto es un desafío considerable. El enfoque documental facilita mucho más la flexibilidad y la extensibilidad.
Bases de datos documentales/relacionales
La mayoría de las bases de datos relacionales principales (PostgreSQL, Oracle, MySQL y MS SQL) y las bases de datos modernas como Spark, BigQuery y Spanner permiten utilizar tanto SQL, relaciones y documentos. Por tanto, se puede adoptar un enfoque híbrido: almacenar los recursos de forma eficiente tal cual (sin capas de transformación) y aprovechar a la vez el poder de SQL así como otras funcionalidades de las bases de datos (transacciones, indexación, etc.).
Conclusión
Creo que almacenar recursos FHIR «tal cual» usando tecnologías modernas como PostgreSQL/jsonb o BigQuery/ProtoBuf es un enfoque muy prometedor, que merece la pena considerar si está iniciando un nuevo sistema de informática sanitaria o una plataforma analítica.
¡Únase a la conversación!
Para debatir este tipo de temas, forme parte de nuestros grupos Analytics on FHIR y Storage on FHIR. Encuéntrenos en persona en la pista de connectathon Storage & Analytics. No dude en unirse a nuestras conversaciones y compartir sus reflexiones.
Véase también: SQL on FHIR: una mirada desde dentro y Preparando FHIR para producción.
