Publicado el 1 de abril de 2017 por Pavel Smirnov
¿Por qué necesita innovar?
La innovación en salud digital dentro de una organización sanitaria no es tarea sencilla. Llevar a cabo actividades de investigación y desarrollo cuando las principales preocupaciones giran en torno a una interminable normativa, la seguridad y la seguridad del paciente supone un enorme desafío. Introducir startups de salud digital, con culturas completamente distintas, en un entorno hospitalario conservador resulta difícil. Pero ¿por qué necesita innovar en primer lugar? ¿No sería suficiente con implementar una historia clínica electrónica (EHR) de un proveedor grande y de reconocido prestigio?
Al implementar una EHR de un gran proveedor, los clientes reciben todos los módulos; tanto los buenos como los que no lo son tanto. Elegir un sistema de este tipo supone siempre un compromiso, ya que ningún sistema por sí solo puede satisfacer todos los requisitos de los usuarios. Abrir la puerta a la innovación, por el contrario, permite a su organización sanitaria elegir exactamente lo que necesita y desea sin tener que transigir. Con las tecnologías modernas, esto puede lograrse empleando significativamente menos recursos. Existen excelentes equipos de desarrollo capaces de ofrecer a su organización lo que necesita de forma ágil. Pueden hacer más con menos. Pueden resolver los problemas que afectan a su organización, pero que no preocupan a otros clientes de su proveedor de EHR. Y no hablo de tareas menores: conozco pequeños equipos multifuncionales de menos de 10 personas que han desarrollado con éxito productos EHR modernos en la nube, portales para médicos y pacientes, sistemas de coordinación asistencial e HIE.
Sin embargo, la innovación sigue siendo difícil, costosa y considerada arriesgada por muchos. Estos capaces equipos de desarrollo tienen dificultades para acceder a los hospitales y se ven frenados por la necesidad de integrar sus aplicaciones modernas en un ecosistema aislado de software heredado. ¿Es posible facilitar todo el proceso de innovación en salud digital?
La receta para la innovación
Creo que hoy en día existe una forma de facilitar la innovación en salud digital en un hospital sin comprometer los aspectos críticos de sus sistemas de información. Abra las puertas de su organización sanitaria a las tecnologías innovadoras, pero únicamente a aquellas que cumplan con los estándares actuales del sector. No pierda su tiempo en engorrosas integraciones personalizadas con aplicaciones vistosas que no son interoperables de serie.
En primer lugar, establezca una infraestructura moderna para las soluciones sanitarias de próxima generación. Elija y despliegue una plataforma con un repositorio de datos clínicos compatible con FHIR que garantice la vigencia de sus productos a futuro. A continuación, configure entornos de producción y de sandbox con datos reales y de prueba, respectivamente. Ponga a disposición de las empresas que le consideren como cliente potencial estos entornos sandbox con datos de prueba, y permítales integrar su software mediante una API FHIR estándar. Configure su entorno de producción de forma similar a los sandbox, de modo que pueda trasladar fácilmente a producción cualquier tecnología desarrollada en ellos que le resulte de interés. Después, simplemente promocione sus sandbox en las comunidades de innovación y esté atento a las grandes ideas.
Los hospitales que comiencen a construir un ecosistema de aplicaciones sanitarias conectadas ahorrarán dinero en la integración de nuevas tecnologías gracias a la estandarización. Esto ampliará el número y la variedad de tecnologías que pueden incorporarse. Y, por último, pero no menos importante, se darán los pasos necesarios para cumplir los requisitos de API abierta del Meaningful Use stage 3 exigidos por CMS.
Posibles preocupaciones
1. La integración de una plataforma FHIR con un ecosistema heredado existente es un desafío. Puede serlo para algunos sistemas de software heredado o para datos sanitarios específicos, pero los datos médicos comunes —como el conjunto de datos estándar de meaningful use— suelen traducirse al estándar FHIR sin grandes esfuerzos. Gran parte de los datos sanitarios pueden recibirse en tiempo real desde fuentes HL7 v.2, presentes en todos los hospitales. Existen muchas herramientas para traducir HL7 v.2 a HL7 FHIR. Algunos motores HL7, como iFW Iguana, son capaces de hacerlo. E incluso si su motor HL7 aún no es compatible con el estándar FHIR, puede utilizar un traductor de HL7 v2 a FHIR de otras empresas. Nuestro backend FHIR Aidbox puede recibir mensajes HL7 v.2 y traducirlos a FHIR.
2. El estándar HL7 FHIR no está maduro y sigue evolucionando. La migración a nuevas versiones consume mucho tiempo.
Cualquier solución informática que no esté obsoleta cambia constantemente. Esto es aplicable a todos los demás sectores de las TI y debería serlo también para la tecnología de la información sanitaria. Considere todos esos cambios como una señal positiva: está invirtiendo en una tecnología que no será reemplazada mañana. En cuanto a la migración, la comunidad HL7 FHIR reconoce esta necesidad. Grahame Grieve (el creador de FHIR) mencionó en la conferencia HIMSS17 en Orlando que está pensando en ofrecer scripts que permitan migrar los datos sanitarios a versiones más recientes del estándar FHIR. En Health Samurai también lo hacemos para nuestros clientes.
3. ¿Cómo puedo hacer que una nueva infraestructura sea fiable, escalable y segura? No me siento cómodo con la nube.
En primer lugar, los estándares de interoperabilidad no condicionan su elección de infraestructura. Si desea seguir utilizando su antiguo centro de datos sanitarios interno, simplemente despliegue allí una plataforma HL7 FHIR. Pero la nube puede aportar un nivel completamente nuevo de fiabilidad y escalabilidad a su organización sanitaria. Por ejemplo, nuestro backend FHIR Aidbox se despliega habitualmente en varios servidores ubicados en diferentes zonas geográficas o en distintos proveedores de infraestructura en la nube (IaaS). Los datos sanitarios se replican entre estos servidores, de modo que incluso el cierre completo de una región de AWS no provocaría la caída de Aidbox. Una instalación de Aidbox en la nube incluye también, por defecto, otras propiedades de infraestructura: copias de seguridad automatizadas, cifrado de todos los datos sanitarios en reposo y en tránsito, registros de auditoría detallados con interfaz gráfica, e incluso un servicio de recuperación a un punto en el tiempo que revierte cualquier cambio y repara los datos sanitarios tras errores humanos perjudiciales.
¡No espere a su proveedor de EHR!
Hay otra consideración que me gustaría compartir con usted: no espere a los proveedores de EHR ni a sus marketplaces de HL7 FHIR. La mayoría de las empresas de EHR tienen otras prioridades antes que disruptir sus propios modelos de negocio mediante la construcción de un ecosistema de aplicaciones sanitarias conectadas procedentes de terceros. Llevan años trabajando en la API HL7 FHIR, pero aún solo ofrecen acceso mediante API a un subconjunto limitado de datos sanitarios y únicamente en modo de solo lectura. Usted puede innovar mucho más rápido por su cuenta con productos HL7 FHIR comerciales disponibles en el mercado, y no tardará tanto como podría pensar.
Véase también: La guía FHIR para CTO.
