Bilbomática, ha asistido al seminario organizado por
Fenin Federación Española de Empresas de Tecnología Sanitaria, sobre FHIR - FAST HEALTHCARE INTEROPERABILITY RESOURCES.
Queremos agradecer tanto a
Fenin, como a todos los participantes, la oportunidad de adquirir y compartir conocimientos en el ámbito de la interoperabilidad sanitaria
HL7- FHIR. A
Francisco Perez Presidente de
HL7 España.
César Rubio, Coordinador sector
eheatlh Fenin.
Luis Javier de
Orion health.,
Arturo Romero del
Mº de Sanidad, Servicios Sociales e igualdad (MSSSI) y a
Diego Kaminker destacado participante en
HL7, cumpliendo diversos roles en HL7 International: Co-Chair del comité de Educación, miembro del Consejo Directivo, y co-chair del Comité Internacional
Recogemos la entrevista con Diego Kaminker, que ha tenido la amabilidad de responder a nuestras inquietudes en el ámbito de FHIR:
¿ Como definirías Fast Healthcare Interoperability Resources FHIR, desde el punto de vista de la evolución que ha sufrido HL7 ?
Es producto de la adaptación a los tiempos, quizás un poco tardía, y del aprendizaje que resultó del poco impacto que ha tenido la versión 3 de mensajería y las dificultades para la implantación del estándar para documentación clínica CDA R2 (dificultades que han retrasado pero no impedido su éxito).
FHIR aprovecha los conceptos actuales en cuanto a generación de APIs, especialmente REST, y la noción de ‘recurso’ haciendo que la mayoría de los desarrolladores jóvenes lo entiendan sin mayor problema. Justo lo contrario acontecía con los estándares de HL7 posteriores a la familia V2.x: los entendía poca gente.
Junto con esto, se entiende el especial cuidado del FMG (FHIR Management Group) por adherir a unos principios estrictos: la especificación núcleo (lo que llamamos el core) tiene que ser de utilidad al 80% de las implementaciones, todo lo que hay que leer sobre cada recurso definido cabe en una sola página, y se proveen una buena cantidad de ejemplos de cada uno. Esto hace bajar definitivamente las barreras para la implementación, junto con la transparencia y la disponibilidad de la documentación, gratuita, y el uso de foros públicos como Stack Overflow y plataformas modernas como Skype para las discusiones (espíritu opuesto a las teleconferencias cerradas y a las reuniones cara a cara como única opción)
¿ Por que consideras, que es importante alinear los desarrollos en el ámbito sanitario con FHIR, cuando todavía no es un estándar ?
Porque 1) No creo que haya cambios tan sustanciales entre el DSTU 2 (lo que se está aprobando en los próximos 2 meses ) y el estándar definitivo y 2) Cuanto antes comencemos a desarrollar antes sabremos que es lo que necesitamos que modifiquen para que funcione. Si esperamos al estándar definitivo podemos descubrir que algo que nos era imprescindible...no está. Hay que participar para poder reclamar...
¿ Como aligera FHIR, la implementación de procesos de integración respecto a HL7 v2 , realmente es FAST?
Es una pregunta difícil de contestar puesto que las interfaces HL7 v2 tienen un grado de madurez luego de tantos años que hace que ‘bien tratadas’ y con la gente correcta una interfaz pueda estar funcionando en menos de una semana. También existe lo contrario, como dice el
Coronel Kurtz en Apocalypse Now “He visto horrores…horrores que tu has visto”.
Lo que permite FHIR, y es algo que hemos aprendido en HL7 con los años, es hacer más explícitas y computables a través del recurso Conformance tanto las extensiones (que ahora están admitidas y no repudiadas) y las restricciones a los recursos existentes, por lo cual la compatibilidad puede ser ‘descubierta’ y verificada (como se decía de los servicios web a través de WSDL)
Por otra parte, las frecuentes ‘Connecthathon’ como medio de prueba tanto del estándar como de su implementación por los desarrolladores permite pensar que a la hora de la verdad…las cosas serán más fáciles. Espero comprobarlo en los próximos meses.
¿ Cual es la infraestructura mínima, para poder comenzar con implementación con FHIR? ¿ La especificación FHIR Es gratuita?
La infraestructura mínima es alguna base de datos (SQL o NOSQL) para extraer o almacenar los recursos, y algún lenguaje de programación moderno. Hay varias implementaciones de referencia y de código abierto en Java, C#, Pascal, iOS y Node.JS. He experimentado el uso tanto de los servidores como de los clientes y realmente sin programar demasiado pude implementar pilotos con bastante velocidad.
La especificación y las implementaciones de referencia son gratuitas.
¿ FHIR, da solución a los nuevos desarrollos de APP moviles y al consumo de servicios y datos de los HIS, existentes, pero FHIR, permite mucho mas en el ámbito de las integraciones sanitarias ?
Está especialmente pensada para mHealth, pero no excluye ninguno de los paradigmas preexistentes en cuanto a interoperabilidad con estándares HL7: mensajería, documentos, y servicios.
Así que si estáis pensando en reemplazar algún esquema actual de flujo de trabajo con una interfaz moderna, o externalizar algo que ahora se resuelve en forma interna, FHIR es un candidato ideal.
Yo soy muy escéptico en general, y mi convicción es que como regla de oro, una interfaz que funciona no se reemplaza salvo por causa mayor (cambios en las aplicaciones que se integran, o cambios mayores en el workflow), pero en este caso creo que las cosas están dadas para que apenas entendamos que esto es mucho más fácil, lo adoptemos masivamente. Especialmente en el ámbito de la IoT (Internet de las cosas), en el mHealth y en el manejo de la salud poblacional, pero no como ‘cosa juzgada’ (conocer que pasa con la salud de la población después de un mes), sino ‘minuto a minuto’, enterarse de las cosas en el momento en que pasan, FHIR va a constituir una solución ideal.
