2010-03-25 16 views
21

Los registros médicos electrónicos se componen de diferentes tipos de datos. La información de la visita (fecha/ubicación/información del seguro) parece prestarse a un RDMS. Otros tipos de información médica, como informes de laboratorio, rayos X, fotografías y firmas electrónicas, se basan en documentos y parecen ser un buen candidato para una base de datos 'orientada a documentos', como MongoDB.¿Alguien que usa bases de datos NoSQL para el almacenamiento de registros médicos?

Tradicionalmente, los datos binarios se almacenaban como BLOB en un RDBMS. Un enfoque híbrido que utilice un RDBMS tradicional junto con una base de datos 'orientada a documentos' parecería una buena alternativa a esto. Otra alternativa sería algo así como DB2 purexml.

La respuesta final podría ser que 'depende', pero realmente solo quería obtener algunos comentarios/ideas generales sobre esto.

¿Alguien está usando el enfoque NoSql para los registros médicos?

** Pregunta aclaratoria ** Para aclarar: ¿alguien está utilizando bases de datos nosql como: mongoDB, Cassandra, CouchDB para registros médicos, en un entorno de producción?

+1

No tengo claro cuál es la pregunta. – RedFilter

+0

no solo no es claro sobre la pregunta, sino que se preguntan cómo se obtienen 4 votaciones al alza ... – KevinDTimm

+0

Consulte http://kousikraj.wordpress.com/2012/06/05/mongo-db-and-its-application-a -case-study-of-mongodb-in-healthcare/donde he captado las razones por las que uso MongoDB para el desarrollo de mi producto y algunas métricas a su alrededor. Gracias, Kousik Rajendran. – kousikraj

Respuesta

0

Sugeriría lo siguiente, dado que está viendo múltiples opciones [SQL o NoSQL]. Mientras leía en magento me encontré con http://en.wikipedia.org/wiki/Entity-attribute-value_model, lo cual tiene sentido cuando tienes una gran cantidad de atributos [columnas en el día al idioma] de los cuales la mayoría serán nulos. Lea la página wiki y observe la parte que específicamente se relaciona con los informes de laboratorio.

4

Quizás la base de datos original de NoSQL era MOMPS, que data de antes de que Codd ideara sus reglas (es decir, la década de 1960). Como su nombre indica (M assachusetts Hospital General U tilidad M en última P rogramación S istema), su propósito original era el almacenamiento de documentos médicos. Aparentemente MUMPS todavía está en uso en algunos sistemas de salud y otros entornos. Find out more.

Pero en cuanto a la erupción más reciente de bases de datos NoSQL, me sorprendería si hubiera alguna implementación, aún. La mayoría de estos productos aún son extremadamente beta y, al ser en su mayoría de código abierto, carecen de soporte. Las aplicaciones médicas inevitablemente serán extremadamente conservadoras, porque las personas podrían morir si el sistema de TI falla.

+0

con respecto a MUMPS, he leído que tiene un cierto tipo de fama ... http://thedailywtf.com/Articles/Classics-Week-A-Case-of-the-MUMPS.aspx – akavel

+0

Las aplicaciones médicas son conservadoras no por la gente muriendo de un error EMR, pero más bien de TI corporativo que no le gusta la innovación. Las aplicaciones innovadoras que difieren exigen más recursos para la integración y los presupuestos de TI hospitalarios siempre son difíciles. En cuanto a morir, tenemos mucho de eso con IT media actual. – kd4ttc

5

Un puñado de grandes proveedores de software para el cuidado de la salud utilizan alguna versión de MUMPS, definitivamente una base de datos que no es SQL. Epic, Meditech, GE y VA's VistA usan implementaciones de MOMP. MUMPS se presta bien a las soluciones de salud, en parte debido a su rendimiento y escalabilidad.

Sé que algunas implementaciones de MOMPS (estoy pensando específicamente en Intersystems Caché) le permiten consultar la base de datos con SQL, pero eso requiere un conocimiento técnico profundo para asignar su modelo de datos no relacionales a tablas relacionales.

Trabajo para un gran proveedor de EMR que usa MOMP y puedo decirle que no es una experiencia "divertida". Con eso me refiero a que no hay grandes herramientas que me permitan mejorar funciones increíbles en unas pocas líneas de código (no hay LINQ-To-M en .NET). Pero reconozco que el precio que pago por escribir más código para consultar datos vale la cuota de mercado.

Si está iniciando un negocio de EMR y diseñando su arquitectura, debe pensar en sus objetivos finales. Si está buscando crear un EMR completo que pueda abarcar múltiples áreas y especialidades, necesitará MUCHAS características al mismo tiempo que vigila el rendimiento, la confiabilidad y la escalabilidad.También necesitará unos miles de desarrolladores para llevar su producto al mercado lo antes posible porque con el nuevo estímulo de atención médica, los hospitales están comprando ahora.

Si está buscando una aplicación especializada de nicho, donde su base de usuarios será pequeña y centrada, puede elegir entre cualquier tecnología de base de datos, buscando más herramientas y un desarrollo rápido.

0

Estoy usando NeoDatis ODB, que es una base de datos orientada a objetos (no está orientada a documentos como CouchDB o MongoDB). Tiene un espacio de memoria muy bajo y es compatible con el cifrado de archivos de base de datos.

1

estamos utilizando MongoDB (a través de MongoMapper y Ruby/Rails) para un sistema que agrega mensajes HL7 + de sistemas dispares (~ 15000 por día) a información significativa para médicos y consultorios.

No puedo decir suficientes cosas buenas sobre MongoDB. Puedes encontrar más en mi blog.

+0

http://technicaldebt.com/category/mongodb/? –

+0

@AlexNolasco si se está preguntando si los 33 GB de "mensajes" mencionados en la publicación del blog fueron datos de atención médica del paciente (mensajes HL7, por cierto), sí. –

Cuestiones relacionadas