Pregunta

Algunos asociados y yo estamos comenzando un proyecto de EMR (Electronic Medical Records). He oído hablar en el pasado, y más recientemente, sobre un formato de registro estándar para facilitar la transferencia de registros cuando sea apropiado (HIPAA) de una instalación a otra. ¿Alguien ha visto alguna información sobre esto?

¿Fue útil?

Solución

Puede buscar en HL7 la interoperabilidad entre sistemas ( http://www.hl7.org/ ) . Se puede pasar información demográfica del paciente y notas de texto. He estado fuera del espacio EMR demasiado tiempo para saber si algún grupo de estándares ha hecho algo interesante últimamente. Un formato estándar que mantiene el significado semántico es un problema muy, muy difícil. Consulte SnoMed ( http://www.nlm.nih.gov/research/ umls / Snomed / snomed_main.html ) para un esfuerzo ontológico de larga duración, apenas el comienzo de un rico formato de intercambio.

Una palabra de advertencia de alguien que pasó varios años con un proveedor emergente de EMR ... Este es un negocio muy difícil. Los ciclos de ventas para grandes sistemas de salud literalmente pueden tomar años, y la cantidad de mano que se requiere para prácticas médicas más pequeñas pueden erosionar rápidamente los márgenes. La integración con los sistemas de gestión de prácticas existentes no es estándar, incluso si esos proveedores afirman lo contrario. Abundan más y más problemas. No estoy seguro de que sea un espacio prudente para que una start-up sin fondos ingrese.

Otros consejos

Creo que es un error considerar que HL7 es un estándar en el sentido que parece querer decir. Está muy personalizado y puede ser muy diferente de un cliente a otro. Es uno de esos estándares con demasiada flexibilidad.

Te recomiendo que leas el estándar (que debería tomarte un tiempo), luego trata de encontrar una comunidad de desarrolladores que trabajen con el estándar. Pídales historias de terror y prepárese para lo que escuchará.

Un mes tarde, pero ...

El estándar para disparar es definitivamente HL7. Se utiliza en muchos campos, por lo que es altamente personalizable, pero existe un estándar bien definido para la atención médica. Cada mensaje (ACK, DSR MCF), segmento (PID, PV1, OBR, MSH, etc.), secuencia y tipo de evento (A08, A12, A36) tiene un significado específico independientemente de su sistema de elección.

No hemos tenido problemas para conectar MiSYS, Statlan, Oacis, Epic, MUSE, GE Centricity / Lastword y otros que envían información DICOM, ADT, PACS entre los sistemas que tenemos en uso. La mayoría de estos sistemas se configurarán con un motor de interfaz para ajustar los mensajes donde sea necesario, por lo que sería imprescindible agregar una forma de filtrar los mensajes HL7 a medida que ingresan a su sistema y a medida que se dirigen hacia abajo.

Incluso si hubiera un nuevo " estándar presidencial " para la interoperabilidad, y me arriesgaría a suponer que será HL7 de todos modos, construiría el sistema con mensajes HL7 ya que este es actualmente el estándar aceptado por la industria.

Al resolver la interoperabilidad, no solo debe preocuparse por el formato de intercambio, los formatos de almacenamiento local también deben estandarizarse, para simplificar la transformación al formato de intercambio y viceversa.

openEHR es un gran formato para el almacenamiento, es más expresivo que HL7 v2, v3 y CDA, por lo que se puede transformar fácilmente a cualquiera de ellos. Las especificaciones están abiertas y aquí: http://openehr.org/programs/specification/releases/ 1.0.2

Para el formato de intercambio, cualquiera de HL7 v2, v3 y CDA son buenos. Considere también CCR y CCD. http://www.aafp.org/practice-management/health-it /astm.html

Si quiere salir del pensamiento HL7 y está buscando un EMR o EHR completo con un formato de registro especificado en lugar de un formato de intercambio de mensajes de extracción de registros, eche un vistazo a openEHR, http://www.openehr.org/ . El estándar de extracto ISO 13606 es (casi) un subconjunto de openEHR. También encontrará bibliotecas de referencia de código abierto e implementaciones de openEHR de diferente madurez disponibles en Java, .NET, Ruby, Python, Groovy, etc.

Algunas organizaciones también están produciendo artefactos HL7 como CDA como salida de sistemas EHR / EMR basados ??en openEHR.

Eche un vistazo al Registro de Continuidad de Atención - IIRC, eso es lo que Google Health usa como información. No es un estándar de la familia HL7 (hay un estándar de la familia HL7 de la competencia; no recuerdo lo que se llama fuera de la parte superior).

Probablemente no habrá un formato estándar de registro médico hasta que el gobierno dicte el formato de uno y requiera su uso por la fuerza de la ley.

Eso casi seguro no sucederá sin una atención sanitaria nacional socializada. Entonces, en realidad, cero posibilidades.

es la respuesta correcta, pero creo que algunos agregan sobre el uso significativo de emr ..... Los funcionarios anuncian & # 8216; Uso significativo, & # 8217; Criterios de certificación de EHR La semana pasada, CMS publicó las regulaciones propuestas que definen el & # 8220; uso significativo & # 8221; de registros de salud electrónicos, informes de Reuters (Wutkowski / Heavey, Reuters, 31/12/09).

Además, la Oficina del Coordinador Nacional de TI de Salud publicó una regla final provisional que describe los estándares de certificación requeridos para la tecnología EHR (Simmons, HealthLeaders Media, 31/12/09).

Según el paquete de estímulo económico federal de 2009, los proveedores de atención médica que demuestren el uso significativo de EHR certificados calificarán para pagos de incentivos a través de Medicaid y Medicare.

Los funcionarios ofrecerán un período de comentarios públicos de 60 días después de que ambas regulaciones se publiquen en el Registro Federal el 13 de enero. La regla final interina sobre la certificación EHR entrará en vigencia 30 días después de la publicación (Goedert, Health Data Management, 30/12/09). http://www.myemrstimulus.com/

Este es un problema muy difícil porque la recopilación de datos comienza con un MD y la única codificación que conocen (ICD y CPT) tiene que ver con la facturación, no es probable que sea de utilidad entre los proveedores (especialmente en un formulario donde el MD puede ser considerado legalmente responsable). Y odian incluso tanto papeleo.

Agregue a eso el hecho de que HIPAA dicta que el paciente, no el proveedor, posee los datos. No es que pudieran entenderlo o hacer algo útil con él si lo tuvieran.

Buena suerte. Pase lo que pase resultará de la coerción del gobierno y tardará mucho tiempo en llegar en mi humilde opinión.

Curiosamente, la única fuente de información médica sólida resulta ser el VA (porque no tienen los problemas adversos de pago y responsabilidad legal). Sin embargo, ese podría ser un buen lugar para comenzar con un estándar con cualquier dato existente y algo de impulso. Aquí hay otra pregunta con información.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top