Mi padre es un doctor. Insiste en escribir una base de datos para almacenar información no crítica del paciente, sin antecedentes de programación [cerrado]

Entonces, mi padre está actualmente en el proceso de "piratear" una base de datos usando FileMaker Pro, una herramienta de base de datos basada en GUI para su pequeña práctica (4 médicos). La base de datos se utilizará para ayudar a aliviar la carga de los informes de las máquinas médicas, simplificando un proceso bastante torpe.

No tiene experiencia en programación y parece estar haciendo todo lo posible para no aprender las cosas correctamente. Tiene tipos de datos duplicados, sin relaciones forzadas por la base de datos (restricciones de clave primaria / externa) y una docena de otros problemas. Lo está haciendo todo a mano a través de la herramienta GUI usando videos de Youtube.

Mi problema es que, aunque quiero que tenga éxito al 100%, no creo que sea apropiado para él manejar este tipo de decisiones. ¿Cómo puedo convencerlo de que sin algún tipo de educación en estos temas, una solución pirateada es una mala idea? Puede ser bastante terco y creo que ve este tipo de trabajos como "juegos de niños"

¿Cómo debería abordar esto? ¿Es una idea tan mala, o estoy en lo cierto al pensar que debería contratar a un DBA / desarrollador adecuado para manejar esto para que no se convierta en una pesadilla de mantenimiento?

NB: Soy un consultor desarrollador de 4 años y he visto mi parte de implementaciones de clientes dolorosas.

Actualizar:

Ahora son unos años más tarde y he tenido tiempo de reflexionar sobre esta pregunta. Mi padre terminó implementando una solución usando Google Docs, FileMaker Pro y algunos enlaces de correo electrónico. Él mismo lo configuró todo y dice que está obteniendo un inmenso valor de ello.

Si usted es un desarrollador experimentado, tal vez esté leyendo esa descripción y encogiéndose. Pero aprendí una buena lección de todo el asunto: que a la gente solo le importan los resultados y no la implementación. Lo único que le importa a mi padre es el hecho de que no necesita ingresar la información del paciente en papel manualmente, y en su lugar puede completar rápidamente un formulario de documentos de Google. Lo bueno es que está buscando contratar a una persona de desarrollo / operaciones junior para centrarse únicamente en la automatización dentro de su práctica.

He estado diseñando soluciones de atención médica durante muchos años. No entraré en todas las diferentes razones por las que tu padre no debería estar haciendo esto; La mayoría de las razones son académicas: es decir, si has estado en la industria el tiempo suficiente, sabes cómo estas cosas se disparan y desarrollan una vida propia.

En cambio, su padre, como médico, necesita comprender las razones profesionales y las razones de la vida real, no académicas, por las cuales lo que está haciendo es peligroso y posiblemente mortal; peligroso para sus colegas, peligroso para la privacidad y la identidad de sus pacientes, y peligroso para su práctica desde un punto de vista legal.

El peligro es multifacético:

1. privacidad del paciente (HIPAA, ARRA, uso significativo, cumplimiento de HITECH)
   • ¿Cuáles son los campos que se consideran campos de identificación de pacientes? (Muchos profesionales en la industria no entienden esto, y solo porque eliminas algunos de los campos obvios como el apellido, la dirección y el código postal, todavía hay muchos otros campos que lo harían es fácil asociar datos clínicos a un paciente específico; esto, en sí mismo, es difícil; hay compañías que están haciendo mucho dinero desidentificando datos clínicos: es un dominio completo en sí mismo).
2. HIPAA, HITECH y la legislación más nueva explican claramente cómo
   • la auditoria debe hacerse
   • la seguridad debe hacerse
   • requisitos de contraseña
   • En caso de que los datos en reposo sean encriptados
   • En caso de que los datos transmitidos sean encriptados y cómo
   • debe considerar los controles si está utilizando algún tipo de servicio alojado (IaaS, PaaS)
   • ¿Tiene BAA y DSA adecuados en su lugar?
   • ¿Cómo controlan el acceso los que alojan sus servidores?
   • cómo manejan la tenencia múltiple (se sorprendería de cómo algunas de estas grandes entidades NO manejan esto adecuadamente)
   • Si rescinde el contrato con los que alojan su infraestructura, ¿cómo garantizarán la eliminación permanente de sus datos (regulaciones NIST)
3. ¿Cuáles son los controles de gobierno establecidos para su desarrollo?
   • ¿tienes un sdlc en su lugar
   • ¿tiene trazabilidad desde los requisitos hasta el código para el control de calidad?
   • ¿Validas el uso 'previsto' de tu aplicación / dispositivo médico?
4. es su software QA'd, y tiene un entorno de prueba de aceptación de usuario (UAT)
   • ¿Cómo protege este entorno, porque utilizará datos reales del paciente?
5. ¿va a manejar pacientes de Medicare? Si es así, ¿planea usar su base de datos para informar?
   • el gobierno tiene controles estrictos para el intercambio de estos datos a su Intercambio de información de salud (HIE)
   • lo que lleva a cómo implementará su propio intercambio si quiere aprovechar su repositorio de datos clínicos (CDR)
6. ¿Entiende las regulaciones particulares del NIST que debe cumplir para la seguridad de los datos?
   • como la eliminación permanente de datos (si se usa una infraestructura alojada)
7. mencionaste que tomará datos de máquinas médicas
   • ¿Entiende los nuevos estándares de dispositivos médicos de la FDA?
   • a partir de 2013, cualquier sistema digital que muestre datos de dispositivos médicos puede clasificarse como un dispositivo médico ... esto significa que debe cumplir con los requisitos reglamentarios de la FDA para dispositivos médicos
8. ¿Su equipo y su personal tomarán decisiones médicas basadas en los datos de su base de datos?
   • ¿Ha desarrollado un modelo de datos clínicos sólido, lo suficientemente flexible como para manejar los requisitos siempre cambiantes (es decir, estándares de codificación ICD-9 a ICD-10 a ICD-11)?
   • ¿Cómo va a versionar el modelo de datos y mantenerlo sincronizado con los datos (es decir, si cambia el modelo de datos clínicos, ¿cómo se representarán los datos más antiguos?)
   • ¿podrá su sistema producir una instantánea exacta de los datos clínicos tal como se vio el día en que se tomó una decisión clínica? hay repercusiones legales si no puede
   • ¿conoce la diferencia entre una eliminación real y una eliminación lógica, y las implicaciones para su modelo de datos? a sus requisitos de almacenamiento; a las políticas de su práctica?
   • ¿Tiene una solución de vocabulario para manejar todos los diferentes servicios que necesitará usar? Gran parte de los datos deben codificarse (a diferencia del texto libre), porque querrá aprovechar su CDR para producir informes que cumplan con la CIE-9. Y luego debe tener en cuenta el cambio de estos estándares; por ejemplo, ICD-9 a ICD-10.
   • para vocabulario, terminología o Diccionario de datos de salud (todos básicamente sinónimos), ¿cómo implementará y se asegurará de que la antigua terminología se pueda representar para las viejas decisiones clínicas?
9. ¿almacenará datos de alergia?
   • ¿Cómo se almacenarán sus definiciones de 'terminología médica' o 'vocabulario'?
   • ¿se integrará con otros sistemas terminológicos como LOINC y First Data Bank?
   • ¿comprende los servicios de terminología (es decir, Health Data Dictionary)?
10. ¿Deseará que los datos se interconecten en su sistema y tal vez en un intercambio de información de salud (HIE)?
    • en caso afirmativo, ¿comprende HL7 y su impacto en su base de datos?
    • ¿Entiende los motores de interfaz y todo lo que conlleva?
11. ¿Entiende cómo desidentificar la información?
    • Esto es importante en la fase de desarrollo y en la fase de corrección de errores.

Estas son solo algunas preguntas, y de ninguna manera deben considerarse una lista completa. Y por cada respuesta habrá innumerables preguntas más.

En una base de datos de Healthcare no debe haber ninguna eliminación o sobreescritura de datos anteriores. Esto significa que nunca habrá 'eliminar de donde ...' o 'conjunto de actualizaciones ...'. En cambio, solo tendrá inserciones. Puede imaginar cómo esto cambia su modelo de datos y sus consultas. Ahora puede ser creativo y encontrar diferentes soluciones para lograr este objetivo, pero el hecho es que este es un requisito exclusivo del repositorio de datos clínicos de atención médica.

Solo un pensamiento más con respecto al lado potencialmente mortal de este problema:

Tomemos, por ejemplo, información sobre alergias; Lo planteo porque las instituciones que han estado haciendo esto digitalmente durante años han aprendido que sus procesos deben garantizar que se capturen los datos de alergia y que no podemos asumir que debido a que la tecnología capturó los datos en una base de datos, de alguna manera es inherentemente correcta para siempre . Es por eso que a los pacientes se les pregunta por sus alergias cada vez que se mueven de un departamento a otro, incluso dentro del mismo hospital. Las alergias de un paciente no se pueden eliminar (las actualizaciones en una fila eliminan la información anterior). Una decisión clínica basada en datos digitales necesita capturar lo que se 'presentó' al médico en el momento de la decisión.

Sé que gran parte de esto puede parecer orientado a una gran institución. Sin embargo, las partes reguladoras no lo son. Y, en cualquier caso, los sistemas de información sanitaria son intrínsecamente complejos. La ingeniería del sistema de atención médica depende y reconoce la experiencia y la experiencia de buenos médicos. Sin embargo, hay un desajuste de impedancia mayor que el promedio (para tomar prestada la terminología de la tecnología ORM) en el dominio de TI de atención médica ... Me atrevo a decir más grande porque cada dominio tiene sus desajustes.

¡Buena suerte!

Una solución pirateada no siempre es mala. Si se trata de resolver su problema, no me molestaría demasiado. Probablemente haya 10 soluciones hackeadas de trabajo en File Maker y Access para cada solución de base de datos profesional. Después de todo, para eso están Filemaker y Access. Claro, la mayoría de las soluciones pirateadas son horribles bajo el capó. Pero existen para resolver problemas, no para ganar concursos de belleza. A menudo, el alcance de estas soluciones crece, y ahí es cuando se contrata a alguien para crear una solución profesional.

Lo que puede hacer para ayudar a sus posibilidades de éxito es expresar interés en su proyecto y ofrecerle sentarse y ayudarlo a definir la base de datos y recorrer todo. Si no quiere tu ayuda ... déjalo y déjalo estar. ¿Qué vas a hacer, tejón a tu padre? Si / cuando se mete por encima de su cabeza, te lo hará saber.

Otra cosa a tener en cuenta es que si este es un problema común entre los médicos, es posible que tenga una muy buena oportunidad de negocio para crear una solución genérica.

Como diseñador de software con más de 25 años de experiencia, todavía puedo ver la atracción de crear algo usted mismo. Explicar cosas a alguien no versado en esa industria puede ser una carga enorme.

Entonces, ¿qué pasa si la base de datos no está normalizada o podría hacerse más rápido? Una gran cantidad de software no crítico (especialmente en la era ágil) sigue el principio wabi-sabi. Hace lo que debe hacer y no más.

Tenga en cuenta que no todo el software tiene que gritar junto con una interfaz perfecta, un acceso a la base de datos ultrarrápido y una GUI impecable.

Mi problema es que, aunque quiero que tenga éxito al 100%, no creo que sea apropiado para él manejar este tipo de decisiones.

Filemaker comenzó como una base de datos que cualquiera podría usar, y todavía funciona muy bien en ese rol. Si su padre sabe lo que quiere y se siente cómodo al armarlo, ¿qué le preocupa? Si funciona como él quiere, él gana. Si no funciona como él quiere, lo arreglará.

Tendría razón en preocuparse si estuviera construyendo una base de datos para todos los médicos que trabajan para Kaiser Permanente, pero si solo está construyendo una herramienta para usar en su propia práctica, parece que probablemente sea la persona adecuada para manejar estos decisiones

No dejes que lo perfecto sea enemigo de lo bueno.

Mi consejo es fingir que esto no existe o de lo contrario te volverá loco. Tengo un pariente que ha hecho algo similar con su lista de clientes, y lo que ha creado por su cuenta es una monstruosidad. Inicialmente me ofrecí a ayudar y él pensó que mi cita (que tenía un fuerte descuento "familiar") era escandalosa. Después de echarle un vistazo, le sugerí un montón de cambios, que me pidió que hiciera a cambio de "un par de cervezas". Familia o no, Homie no juegues eso. Le dije que debería contratar a alguien para hacerlo, pero nunca lo hizo. Simplemente tuve que desconectarme por completo y fingir que no existe, solo para evitar que lo horrible del proyecto me afectara.

Deberías dejar que lo intente. Sin embargo, debe hacerle saber que, cuando llegue a un punto muerto, es su problema y cualquier desarrollador que decida contratar en ese momento tendrá que comenzar desde cero.

Me gusta mucho hackear cosas, como muebles e incluso plomería. Lo disfruto y no veo nada malo en ello. Nunca me atrevería a pedirle a un hábil artesano que saltara por mí cuando me atascara, simplemente porque creo que vomitarían al ver mis creaciones.

Así que deja que tu padre haga lo que le gusta, pero trata de que comprenda los riesgos. Solo explíquele que cuando en algún momento contrata a un desarrollador capacitado para "solo agregar una pequeña característica", es como pedirle a artesanos experimentados que "solo arreglen un par de cosas" en una casa donde se ha realizado la mayor parte del cableado y la plomería. con cinta adhesiva, papel de aluminio, plastilina y buena fe.

él ve este tipo de trabajos como "juego de niños"

Soy un consultor desarrollador de 4 años.

Por su propio bienestar y el desarrollo personal de su padre, deje que fracase. La respuesta de John es sólida y debes mencionar lo suficiente para evitar que tu padre se ponga del lado equivocado de la ley, o al menos lo suficiente como para que él sepa más. Pero todo este asunto de la "humildad" no es algo que puedas darles a las personas y esperar que aprendan. Es una lección de vida muy importante para intentar su máximo esfuerzo y fracasar por completo. El fracaso es un maestro muy poderoso. Y podría ganar algo de respeto por la profesión de su hijo.

Y oye, si logra improvisar algo que funciona lo suficientemente bien (y no viola ninguna ley), tanto más poder para él.

Es su negocio. Y si está decidido, lo hará funcionar. Y mucha gente ha creado soluciones de varias tecnologías para que todo funcione.

Hace años, revisé el código de un amigo mío que creó una aplicación web con PHP y algún software de tablón de anuncios. Lo personalizó en gran medida para satisfacer sus necesidades. El código fue una abominación. Además de ser apenas la primera forma normal, tenía etiquetas HTML con datos en su base de datos. No hay separación MVC. Pero que Dios lo bendiga. Su solicitud funcionó y pudo pagar sus facturas con los ingresos de ese sitio web.

Mi consejo para él fue este: si está contento de ordeñar su aplicación para obtener ingresos el mayor tiempo posible, entonces no la refactorice utilizando buenas técnicas de diseño de software y deje en paz "lo suficientemente bien". Si desea evolucionar su aplicación para ofrecer más servicios y obtener más ingresos, tendrá que pagar y refactorizar el código. Él eligió ir con el primero. Así es la vida.

Si su padre no siente el dolor de la duplicación de datos y la integridad débil de los datos ahora, lo hará más tarde, y solo entonces aprenderá el valor de lo que está diciendo.

Creo que la respuesta a su pregunta depende principalmente de cuán crítica para su práctica médica es esta aplicación. ¿Almacenará allí solo algunos datos de pacientes que considere útiles o cualquier mal funcionamiento de esta aplicación puede tener graves consecuencias? Si puede tener graves consecuencias, entonces no debería hacerlo, pero debido a que no estamos viviendo en un mundo perfecto, convencerlo de que no es una buena idea puede ser un asunto completamente diferente.

Como usted es un consultor desarrollador, sugeriría ofrecerle ayuda en el control de calidad y el proceso de prueba. De esta manera, mantendrá una buena relación con su padre porque lo está "ayudando", pero al mismo tiempo puede asegurarse de que su aplicación esté haciendo lo que se supone que debe hacer o incluso encontrar un problema que no podrá resolver. entonces él buscará una solución más profesional.

Por cierto, he visto muchas aplicaciones terribles que estaban haciendo su trabajo y ninguna explicación de por qué es terrible convencería a cualquiera de hacer cambios reales en ella.

Como ingeniero de software recientemente retirado por un profesional de la salud sin fines de lucro grande, yo fuertemente recomiendo buscar un hospital o en la práctica gran cercano que puede, por un precio razonable permitir que él para compartir su sistema de registros médicos electrónicos que cumpla con los requisitos de la iniciativa uso significativo (y otros programas de incentivos gubernamentales).

Soy consciente de que "Epic" ( http://Epic.com ) respalda a sus clientes permitiendo que proveedores más pequeños compartan su sistema, e imagino que algunos de sus competidores también lo hacen. Cerner es su mayor competidor, pero varios otros se discuten en http://www.beckershospitalreview.com/healthcare-information-technology/50-things-to-know-about-epic-cerner-meditech-mckesson-athenahealth-and- other-major-ehr-vendors.html

Hay un subsidio del 75% de CMS para ese tipo de intercambio. Transmitimos el subsidio a nuestros clientes al hacer que el precio de suscripción sea del 25% de nuestro costo.