¡Hola! Yo era A2A.
Daan Mulder hizo un buen trabajo de delinear las posibilidades con formatos de datos. Me gustaría proporcionar algo de información adicional.
Preguntar “¿Cuál es la mejor manera de conectar mi aplicación con EMR?” Es como preguntar cuál es el mejor vehículo para todas las carreteras. Si bien un automóvil regular es bueno para la mayoría de las aplicaciones, hay situaciones en las que un camión de basura o un automóvil deportivo sería más apropiado. Es posible que necesite una motocicleta para llegar a un lugar que un automóvil no podría caber de otra manera. Si fue un poco reacio al riesgo, incluso podría probar autos sin conductor. Los formatos de datos de la atención médica son de la misma manera. Como tal, todos los diferentes estándares de datos (HL7v2, HL7v3, DICOM, CDA, FHIR, ETL, X12, servicios web personalizados) tienen todos sus propios usos. open.epic por sí solo enumera cientos de integraciones en una variedad de medios, productos y flujos de trabajo.
Lo peor que puede hacer es ir a un hospital y preguntarles “¿Qué integraciones de datos le gustaría que hagamos?” O decirles “¡Podemos hacer cualquier integración de datos!”. A menos que ya esté en vivo con una organización determinada y / o haya establecido una buena relación, esto probablemente descalifique su producto / negocio frente a una variedad de otros productos que ofrecen servicios competitivos. No digo esto para ser superficial; Digo esto porque he visto a gente hacer esto y puedo decirle que los resultados no son los que usted desea si su objetivo es lograr que los pacientes y los médicos utilicen su producto.
Lo más valioso que aprendí mientras trabajaba en Epic es que vale la pena ser preceptivo. Si conoce la respuesta correcta, siempre es mejor brindar orientación que hacer preguntas. Como tal, lo mejor que puede hacer es contar una historia en la que un conjunto dado de integraciones agregue valor o diferencie su producto del resto del mercado . Esto hace que sea probable que la integración no sea vista como una carga y, de hecho, genere eficiencia de inmediato para una organización.
Voy a usar un ejemplo. Digamos que ha creado una nueva aplicación de telemedicina. Si eres una persona de la aplicación, probablemente hayas oído hablar del Producto mínimo viable (MVP). Hablemos de lo que sería la Integración mínima viable (MVI) con un sistema de salud.
¿Cuáles son los mejores foros para la salud ambiental?
¿Cuál es el mejor jarabe de hierro en el mercado indio para una persona que sufre de anemia?
¿Hay realmente alguna prueba de que las personas se benefician del “aire fresco” afuera?
Durante un piloto o con un uso mínimo, es posible que no requiera ninguna integración. En su mayoría, necesita obtener datos en el EHR para fines de cumplimiento y documentación legal. Esto es algo que a pequeña escala se puede hacer a través de Transcripción Manual, o como lo llamamos, “documentación doble”. Usted escribe los datos en su aplicación, alguien los escribe en el EHR. Esto no es viable en cualquier cantidad de escala, y proporciono algo de cálculo para juzgar el valor de esto aquí: ¿cómo puede un piloto de puesta en marcha de asistencia sanitaria con un proveedor de atención médica sin integrarse en su sistema de gestión de la práctica?
La integración mínima viable para una aplicación de telemedicina , entonces, requiere poder identificar a un paciente dentro de un EHR y escribir la documentación para este paciente. Esto se hace comúnmente a través de los mensajes MDM HL7v2, que devuelve una “nota” sobre la visita a la telemedicina. Esto reduce la necesidad inicial de documentación doble. Es posible que los médicos aún necesiten pasar de un sistema a otro, pero, lamentablemente, esto todavía es bastante común en la industria, por lo que es probable que sea el mejor en este momento.
Una integración ideal es aquella en la que los médicos y pacientes no necesitan saltar entre múltiples sistemas, básicamente el portal EHR / paciente y su aplicación. Esto aumenta la eficiencia y reduce la probabilidad de que la documentación pueda terminar en el paciente equivocado. Para la telemedicina, esto probablemente involucre:
- Determinar la elegibilidad para los servicios (X12)
- Poder programar citas para proveedores en el EHR (HL7v2, FHIR o servicios web personalizados)
- Realice algunos pedidos por protocolo (HL7v2 ORM)
- Ser capaz de consultar información clínica histórica específica del paciente, como medicamentos, alergias, problemas, antecedentes familiares, etc. (FHIR, CDA)
- Reciba feeds de datos en tiempo real para proporcionar notificaciones sobre resultados o eventos basados en el hospital (HL7v2 ADT, ORU).
- Escriba datos discretos, como los valores vitales evaluados (alimentaciones HL7v2 ORU), con fines analíticos.
- Recargue los cargos, tanto para facturación como para medidas de calidad (DFT HL7v2).
Esto, por supuesto, no ocurre durante la noche. Pero puede describir la historia de cómo todas estas integraciones, si 5000 médicos usaran su plataforma de telemedicina, proporcionarían valor.
Técnicamente, estas integraciones se pueden programar directamente en su plataforma o integrarse en algo parecido a un motor de integración. Necesitará un equipo de personas con experiencia en la entrega de soluciones en estas diversas tecnologías, algunas de las cuales son específicas del proveedor.
Entonces, ¿cómo llegas allí? ¿Cómo sabes lo que es correcto para tu producto? Es mucho más un viaje que solo conectar algunas API. Lo sé principalmente al hacer estas cosas. Pero, puedo ayudar. Dirijo un equipo que implementa un producto llamado Redpoint que intenta hacer esto tan simple como las API. Hay mucho trabajo, orientación y experiencia entre bastidores, pero hacemos nuestro mejor esfuerzo para guiar a nuestros clientes. para encontrar las mejores respuestas para sus productos y clientes. ¡Echale un vistazo! [1] No dudes en enviarme un correo electrónico tampoco. Feliz de ayudar. mark (at) catalyze.io.
¡Buena suerte!
Notas a pie de página
[1] Catalizar
