¿Qué compañía de software diseñó su sistema de registro médico electrónico para tener un límite de 1000 caracteres?

Respetuosamente, si Epic tiene una limitación de 1000 caracteres, entonces el culpable más probable es el lenguaje de programación MUMPS con el que entiendo que se desarrolló Epic. No tiene nada que ver con el backend RDBMS.

Una pequeña historia:
MUMPS se desarrolló a mediados de la década de 1960 como un lenguaje de programación de cuidado de la salud interpretado, multitarea y multiusuario con una base de datos jerárquica incrustada que almacenaba sus datos en arrays dispersos persistentes, una solución elegante a las limitaciones de las arquitecturas de máquinas de esa época. MUMPS se convirtió en el lenguaje de desarrollo de facto para las aplicaciones de cuidado de la salud de los años 1960 y 1970, al igual que COBOL, que se desarrolló a fines de la década de 1950, se convirtió en el lenguaje de programación de negocios de facto de esa época.

Actualmente, muchos sistemas de información de atención médica en uso se basan en MUMPS: el EMR VistA desplegado por la Administración de Veteranos, el Sistema Compuesto de Atención Médica (CHCS) del Departamento de Defensa diseñado por SAIC a un costo de más de $ 2 mil millones y el SunQuest LIS (clínica sistema de información de laboratorio) utilizado por muchos de los laboratorios de referencia clínica en el país, incluidos Stanford, TriCore, PAML y Quest.

Fui director de inteligencia de negocios para un laboratorio regional de referencia clínica que usa SunQuest, y mi mayor desafío fue trabajar para compensar las limitaciones de los componentes internos de MUMP de SunQuest LIS.

El límite de 1.000 caracteres no es el único muro que los ingenieros de software han atacado con MUMPS. La estructura jerárquica de la base de datos utilizada por MUMPS presenta problemas importantes de almacenamiento y recuperación de información, almacenamiento de datos y análisis clínicos, que se abordaron en 1970 cuando EF Codd publicó su artículo seminal que describe el modelo relacional.

No tengo idea de qué compañía es esta, aunque creo que cada programador de computadoras puede entender por qué sucedió esto.

Estás viendo este límite de personaje desde la perspectiva equivocada. Esta decisión se tomó pensando en la facilidad de programación, no en el usuario final.

Lo que probablemente sucedió:
Al leer caracteres de un campo de entrada (como el campo “evaluación del paciente”), debe especificar un límite de caracteres en la computadora para que la computadora sepa cuánta memoria necesita para almacenar el resultado.

Entonces , ¿por qué el programador no estableció un límite de un millón?
Porque eso desperdiciaría espacio / podría colapsar la computadora / causar todo tipo de problemas, dificultando la vida del programador.

Ok, suena razonable. Pero ¿por qué demonios pensaría que solo 1000 caracteres eran suficientes?
Él no. Solo tenía que establecer un límite que no sea demasiado alto, y no demasiado pequeño. Y probablemente el número 1000 sonaba razonable, y después de todo, si no es lo suficientemente largo, el departamento de control de calidad seguramente descubrirá esto.

Pero eso fue tonto de él, ¡seguramente 1000 caracteres no es suficiente!
De hecho, dudaría en llamar a este límite de 1000 caracteres una decisión. El programador acaba de ingresar “1000” como el tamaño del campo sin pensarlo dos veces.
Además, si es demasiado pequeño, el programador simplemente podría agregar otro cero para hacerlo 10 000 más tarde, un cambio que toma un segundo para hacer.

Bien, pero ¿cómo puede la empresa justificar que no se pruebe el software en un entorno hospitalario profesional?
En aras de la simplicidad, digamos que el producto es solo para archivar la información del paciente y recuperarla más tarde. Básicamente, este sistema funciona si puede almacenar información (evaluación del paciente, imágenes CT, etc.) y recuperar la misma información más adelante. Desde el punto de vista de la prueba, realmente no importa lo que coloque en los campos del paciente, siempre que obtenga la misma información. Si la “evaluación del paciente” es real hecha por un MD, o si es simplemente una receta favorita de los evaluadores para las cookies, no importa. (La prueba de la interfaz de usuario / características es una historia diferente).

– Pero esto es malo para la compañía, ¡esto debería haberse descubierto antes!
Digamos que más del 99% de la evaluación del paciente tiene menos de 1000 caracteres. Tenga en cuenta que este límite de 1000 caracteres es un error, no una característica.
Dado que el error raramente está presente (después de todo, el error solo aparecerá en la superficie por menos del <1% de los pacientes), la compañía simplemente no estaba al tanto de que existía este error.

Como nota al margen no relacionada, errores similares a este (“búferes de límite fijo”), es una de las razones principales de fallas de seguridad en programas / sistemas operativos. Eso es algo a tener en cuenta la próxima vez que Windows / Mac OS X / Firefox / Adobe Reader / etc. le pida que descargue un parche de actualización / seguridad.