MUMPS ("Massachusetts General Hospital Utility Multi-Programming System"), o M , es un lenguaje de programación imperativo de alto nivel con una base de datos clave-valor de procesamiento de transacciones integrada . Fue desarrollado originalmente en el Hospital General de Massachusetts para administrar los registros médicos de los pacientes y los sistemas de información de laboratorio del hospital.
Desde entonces, la tecnología MUMPS se ha expandido hasta convertirse en la base de datos predominante para los sistemas de información de salud y los registros médicos electrónicos en los Estados Unidos. Los sistemas de información basados en MUMPS, como Epic Systems , brindan servicios de información de salud a más del 78 % de los pacientes en todo Estados Unidos [1].
Una característica única de la tecnología MUMPS es su lenguaje de base de datos integrado , que permite un acceso de lectura y escritura directo y de alta velocidad al almacenamiento en disco permanente. [2]
MUMPS fue desarrollado por Neil Pappalardo , Robert A. Greenes y Curt Marble en el laboratorio del Dr. Octo Barnett en el Hospital General de Massachusetts (MGH) en Boston durante 1966 y 1967. [3] Surgió de la frustración, durante un proyecto de sistemas de información hospitalaria de apoyo de los Institutos Nacionales de Salud (NIH) en el MGH, con el desarrollo en lenguaje ensamblador en un PDP-1 de tiempo compartido por el contratista principal Bolt Beranek & Newman, Inc. (BBN). MUMPS surgió de un proyecto interno de " skunkworks " en el MGH por Pappalardo, Greenes y Marble para crear un entorno de desarrollo alternativo. Como resultado de la demostración inicial de capacidades, la propuesta del Dr. Barnett al NIH en 1967 para la renovación de la subvención del proyecto informático del hospital dio el paso audaz de proponer que el sistema se construyera en MUMPS en el futuro, en lugar de depender del enfoque BBN. Se financió el proyecto y se inició la implementación seria del sistema en MUMPS.
El sistema MUMPS original se construyó, como Unix unos años después, sobre un DEC PDP-7 . Octo Barnett y Neil Pappalardo obtuvieron un PDP-9 compatible con versiones anteriores y comenzaron a utilizar MUMPS en el ciclo de admisiones y en los informes de pruebas de laboratorio. MUMPS era entonces un lenguaje interpretado , pero incluso entonces incorporaba un sistema de archivos de base de datos jerárquico para estandarizar la interacción con los datos y abstraer las operaciones del disco de modo que solo las realizara el propio lenguaje MUMPS. MUMPS también se utilizó en sus inicios en un sistema experimental de entrada de notas de progreso clínico [4] y en un sistema de entrada de informes de radiología [5] .
Algunos aspectos de MUMPS se pueden rastrear desde JOSS de RAND Corporation hasta TELCOMP y STRINGCOMP de BBN . El equipo de MUMPS decidió incluir la portabilidad entre máquinas como un objetivo de diseño.
Una característica avanzada del lenguaje MUMPS que no era ampliamente compatible con los sistemas operativos o el hardware informático de la época era la multitarea . Aunque la compartición de tiempo en los ordenadores mainframe era cada vez más común en sistemas como Multics , la mayoría de los miniordenadores no ejecutaban programas en paralelo y el subprocesamiento no estaba disponible en absoluto. Incluso en los mainframes, la variante del procesamiento por lotes en la que se ejecutaba un programa hasta su finalización era la implementación más común para un sistema operativo de multiprogramación.
Pasaron algunos años hasta que se desarrolló Unix. La falta de hardware de gestión de memoria también significaba que todo multiprocesamiento estaba plagado de la posibilidad de que un puntero de memoria pudiera cambiar algún otro proceso. Los programas MUMPS no tienen una forma estándar de hacer referencia a la memoria directamente, a diferencia del lenguaje C , por lo que, dado que la multitarea era impuesta por el lenguaje, no por ningún programa escrito en el lenguaje, era imposible tener el riesgo que existía para otros sistemas.
El sistema DEC MUMPS-15 de Dan Brevik fue adaptado a un DEC PDP-15 , donde permaneció durante algún tiempo. Se instaló por primera vez en Health Data Management Systems de Denver en mayo de 1971. [6] La portabilidad resultó útil y MUMPS recibió una subvención de investigación del gobierno, por lo que MUMPS se lanzó al dominio público, lo que era un requisito para las subvenciones. MUMPS pronto se trasladó a varios otros sistemas, incluido el popular DEC PDP-8 , el Data General Nova y el DEC PDP-11 y la minicomputadora Artronix PC12 . La noticia sobre MUMPS se extendió principalmente a través de la comunidad médica y su uso se extendió, a menudo modificándose localmente para sus propias necesidades.
En 1970 y 1971, los líderes técnicos Dennis "Dan" Brevik y Paul Stylos [6] de DEC reescribieron versiones del sistema MUMPS. A principios de los años 70, había muchas y variadas implementaciones de MUMPS en una variedad de plataformas de hardware. Otra plataforma notable fue DEC MUMPS-11 de Paul Stylos [6] en el PDP-11 y MIIS de MEDITECH . En el otoño de 1972, muchos usuarios de MUMPS asistieron a una conferencia en Boston que estandarizó el lenguaje, que entonces estaba fragmentado, y para ello se creó el Grupo de Usuarios de MUMPS y el Comité de Desarrollo de MUMPS (MDC). Estos esfuerzos resultaron exitosos; en 1974 se completó un estándar y se aprobó, el 15 de septiembre de 1977, como estándar ANSI , X11.1-1977. Casi al mismo tiempo, DEC lanzó DSM-11 (Estándar Digital MUMPS) para el PDP-11. Éste dominó rápidamente el mercado y se convirtió en la implementación de referencia de la época. Además, InterSystems vendió ISM-11 para el PDP-11 (que era idéntico al DSM-11).
A principios de los años 1980, varios proveedores lanzaron al mercado plataformas basadas en MUMPS que cumplían con el estándar ANSI. Las más importantes fueron:
En este período también se produjo una considerable actividad del MDC. El 15 de noviembre de 1984 se aprobó la segunda revisión de la norma ANSI para MUMPS (X11.1-1984).
Al director ejecutivo de InterSystems no le gustaba el nombre MUMPS y pensaba que representaba un serio obstáculo de marketing. Por lo tanto, favorecer a M hasta cierto punto se identificó como una alineación con InterSystems. El estándar ANSI de 1990 estaba abierto tanto a M como a MUMPS y, después de una discusión "mundial" en 1992, los grupos de usuarios de Mumps cambiaron oficialmente el nombre a M. La disputa también reflejó la rivalidad entre organizaciones (la Asociación de Tecnología M, el Comité de Desarrollo de MUMPS, los Comités de Estándares ANSI e ISO) sobre quién determina el nombre "oficial" del lenguaje. [ cita requerida ]
A partir de 2020, la ISO todavía menciona tanto M como MUMPS como nombres aceptados oficialmente. [15]
El Hospital General de Massachusetts registró "MUMPS" como marca comercial en la USPTO el 28 de noviembre de 1971 y la renovó el 16 de noviembre de 1992, pero la dejó expirar el 30 de agosto de 2003. [16]
MUMPS es un lenguaje pensado y diseñado para crear aplicaciones de bases de datos. Se incluyeron características de lenguaje secundario para ayudar a los programadores a crear aplicaciones utilizando recursos informáticos mínimos. Las implementaciones originales se interpretaron , aunque las implementaciones modernas pueden compilarse total o parcialmente . Los "programas" individuales se ejecutan en "particiones" de memoria . Las primeras particiones de memoria de MUMPS estaban limitadas a 2048 bytes, por lo que la abreviatura agresiva ayudó en gran medida a la multiprogramación en hardware con recursos muy limitados, porque más de un trabajo MUMPS podía caber en las memorias muy pequeñas existentes en el hardware de la época. La capacidad de proporcionar sistemas multiusuario fue otra característica de diseño del lenguaje. La palabra " Multi - Programación " en el acrónimo apunta a esto. Incluso las primeras máquinas que ejecutaban MUMPS admitían la ejecución de varios trabajos al mismo tiempo. Con el cambio de minicomputadoras a microcomputadoras unos años más tarde, incluso una "PC de usuario único" con una única CPU de 8 bits y 16K o 64K de memoria podía admitir múltiples usuarios, que podían conectarse a ella desde terminales de visualización de video (no gráficas ) .
Como la memoria era limitada originalmente, el diseño del lenguaje para MUMPS valoraba el código muy conciso. Por lo tanto, cada nombre de comando o función de MUMPS podía abreviarse de una a tres letras de longitud, por ejemplo, Quit (salir del programa) como Q , $P = $Piece function, R = Read command, $TR = $Translate function. Los espacios y los marcadores de final de línea son significativos en MUMPS porque el alcance de línea promovía el mismo diseño de lenguaje conciso. Por lo tanto, una sola línea de código de programa podía expresar, con pocos caracteres, una idea para la que otros lenguajes de programación podrían requerir de 5 a 10 veces más caracteres. La abreviatura era una característica común de los lenguajes diseñados en este período (por ejemplo, FOCAL-69 , los primeros BASIC como Tiny BASIC , etc.). Un desafortunado efecto secundario de esto, junto con la necesidad temprana de escribir código minimalista, fue que los programadores de MUMPS rutinariamente no comentaban el código y usaban abreviaturas extensas. Esto significaba que incluso un programador experto en MUMPS no podía simplemente hojear una página de código para ver su función, sino que tendría que analizarla línea por línea.
La interacción con bases de datos está incorporada de forma transparente en el lenguaje. El lenguaje MUMPS proporciona una base de datos jerárquica formada por matrices dispersas persistentes , que se "abre" implícitamente para cada aplicación MUMPS. Todos los nombres de variables prefijados con el carácter de intercalación ( ) utilizan almacenamiento permanente (en lugar de RAM), mantendrán sus valores después de que la aplicación salga y serán visibles para (y modificables por) otras aplicaciones en ejecución. Las variables que utilizan este almacenamiento compartido y permanente se denominan globales en MUMPS, porque el alcance de estas variables está "globalmente disponible" para todos los trabajos del sistema. El uso más reciente y más común del nombre "variables globales" en otros lenguajes es un alcance más limitado de los nombres, que proviene del hecho de que las variables sin ámbito están "globalmente" disponibles para cualquier programa que se ejecute en el mismo proceso, pero no se comparten entre varios procesos. El modo de almacenamiento MUMPS (es decir, las variables globales almacenadas como matrices dispersas persistentes) le da a la base de datos MUMPS las características de una base de datos orientada a documentos . [17]^
Todos los nombres de variables que no tienen como prefijo el carácter de intercalación ( ^
) son temporales y privados. Al igual que las variables globales, también tienen un modelo de almacenamiento jerárquico, pero solo están "disponibles localmente" para un solo trabajo, por lo que se denominan "locales". Tanto las "globales" como las "locales" pueden tener nodos secundarios (llamados subíndices en la terminología MUMPS). Los subíndices no se limitan a los números: cualquier carácter ASCII o grupo de caracteres puede ser un identificador de subíndice. Si bien esto no es poco común en los lenguajes modernos como Perl o JavaScript, era una característica muy inusual a fines de la década de 1970. Esta capacidad no se implementó universalmente en los sistemas MUMPS antes del estándar ANSI de 1984, ya que el estándar solo requería que se permitieran subíndices numéricos canónicos. [18] Por lo tanto, la variable llamada 'Auto' puede tener los subíndices "Puerta", "Volante" y "Motor", cada uno de los cuales puede contener un valor y tener subíndices propios. La variable ^Car("Door")
podría tener un subíndice de variable anidado de "Color", por ejemplo. Por lo tanto, podría decir
SET ^Car("Puerta", "Color")="AZUL"
para modificar un nodo secundario anidado de ^Car
. En términos de MUMPS, "Color" es el segundo subíndice de la variable ^Car
(tanto los nombres de los nodos secundarios como los nodos secundarios en sí mismos también se denominan subíndices). Las variables jerárquicas son similares a los objetos con propiedades en muchos lenguajes orientados a objetos . Además, el diseño del lenguaje MUMPS requiere que todos los subíndices de las variables se mantengan automáticamente en orden ordenado. Los subíndices numéricos (incluidos los números de punto flotante) se almacenan del más bajo al más alto. Todos los subíndices no numéricos se almacenan en orden alfabético después de los números. En la terminología de MUMPS, este es el orden canónico . Al usar solo subíndices enteros no negativos, el programador de MUMPS puede emular el tipo de datos de las matrices de otros lenguajes. Aunque MUMPS no ofrece de forma nativa un conjunto completo de características de DBMS como esquemas obligatorios, se han creado varios sistemas DBMS sobre él que brindan a los desarrolladores de aplicaciones características de base de datos relacional, de red y de archivo plano .
Además, hay operadores integrados que tratan una cadena delimitada (por ejemplo, valores separados por comas ) como una matriz. Los primeros programadores de MUMPS solían almacenar una estructura de información relacionada como una cadena delimitada y analizarla después de leerla; esto ahorraba tiempo de acceso al disco y ofrecía considerables ventajas de velocidad en algunos equipos.
MUMPS no tiene tipos de datos. Los números se pueden tratar como cadenas de dígitos, o las cadenas se pueden tratar como números mediante operadores numéricos ( conversión , en la terminología de MUMPS). Sin embargo, la conversión puede tener algunos efectos secundarios extraños. Por ejemplo, cuando se convierte una cadena, el analizador convierte la mayor parte de la cadena (empezando por la izquierda) en un número y luego descarta el resto. Por lo tanto, la declaración IF 20<"30 DUCKS"
se evalúa como TRUE
en MUMPS.
Otras características del lenguaje están pensadas para ayudar a las aplicaciones MUMPS a interactuar entre sí en un entorno multiusuario. Los bloqueos de bases de datos, los identificadores de procesos y la atomicidad de las transacciones de actualización de bases de datos son requisitos de las implementaciones estándar de MUMPS.
A diferencia de los lenguajes de la tradición C o Wirth , algunos caracteres de espacio entre las sentencias MUMPS son significativos. Un solo espacio separa un comando de su argumento, y un espacio, o nueva línea, separa cada argumento del siguiente token MUMPS. Los comandos que no aceptan argumentos (por ejemplo, ELSE
) requieren dos espacios siguientes. El concepto es que un espacio separa el comando del argumento (inexistente), el siguiente separa el "argumento" del siguiente comando. Las nuevas líneas también son significativas; un comando IF
, ELSE
o FOR
procesa (o saltea) todo lo demás hasta el final de la línea. Para que esas sentencias controlen varias líneas, debe usar el DO
comando para crear un bloque de código.
Un programa sencillo de "¡Hola, mundo!" en MUMPS podría ser:
¡escribe "Hola, mundo!",!
y se ejecutaría con el comando do ^hello
después de haberlo guardado en el disco. Para la ejecución directa del código, se necesita una especie de "etiqueta" (cualquier cadena alfanumérica) en la primera posición de la línea del programa para indicarle al intérprete de mumps dónde comenzar la ejecución. Dado que MUMPS permite que los comandos se encadenen juntos en la misma línea y que los comandos se pueden abreviar a una sola letra, esta rutina podría hacerse más compacta:
w "¡Hola, mundo!",!
El ' ,!
' después del texto genera una nueva línea. Este código volvería al mensaje de solicitud.
ANSI X11.1-1995 proporciona una descripción formal y completa del lenguaje; una versión anotada de esta norma está disponible en línea. [19]
Las características del lenguaje incluyen:
a<b
produce 1 si a es menor que b, 0 en caso contrario.SET:N<10 A="FOO"
Establece A en "FOO" si N es menor que 10; DO:N>100 PRINTERR,
realiza PRINTERR si N es mayor que 100. Esta construcción proporciona una condición cuyo alcance es menor que una línea completa.GREPTHIS() NUEVO CONJUNTO,NUEVO,ENTONCES,SI,MATAR,SALIR CONJUNTO SI="MATAR",CONJUNTO="11",MATAR="11",SALIR="REGRESAR",ENTONCES="MATAR" SI SI=ENTONCES HACER ENTONCES SALIR:$SALIR SALIR SALIR ; (salir)ENTONCES SI SI,SET&KILL SET SET=SET+KILL SALIR
GREPTHIS() NS,N,T,I,K,QSI="K",S="11",K="11",Q="R",T="K" II=TDT Q:$QQQTII,S&K SS=S+KQ
para i=10000:1:12345 establecer sqtable(i)=i*iestablecer dirección("Smith", "Daniel")="[email protected]"
^abc, ^def
Estos se almacenan en el disco, están disponibles para todos los procesos y son persistentes cuando finaliza el proceso de creación. Los globales muy grandes (por ejemplo, de cientos de gigabytes) son prácticos y eficientes en la mayoría de las implementaciones. Este es el principal mecanismo de "base de datos" de MUMPS. Se utiliza en lugar de llamar al sistema operativo para crear, escribir y leer archivos.@VBL
se puede utilizar y sustituye eficazmente el contenido de VBL en otra instrucción MUMPS. SET XYZ="ABC" SET @XYZ=123
Establece la variable ABC en 123. SET SUBROU="REPORT" DO @SUBROU
Realiza la subrutina denominada REPORT. Esta sustitución permite la evaluación diferida y la vinculación tardía, así como el equivalente operativo efectivo de los "punteros" en otros lenguajes.$PIECE(STRINGVAR,"^",3)
significa "la tercera parte separada por un cursor de STRINGVAR ". La función de fragmento también puede aparecer como un objetivo de asignación (comando SET).$PIECE("world.std.com",".",2)
rendimientosETS.ESTABLECER X="[email protected]"
SET $P(X,"@",1)="office"
hace que X se convierta en "[email protected]" (tenga en cuenta que $P es equivalente a $PIECE y podría escribirse como tal).Establecer cosas(6)="xyz",cosas(10)=26,cosas(15)=""
$Order(stuff(""))
rendimientos6, $Order(stuff(6))
rendimientos10, $Order(stuff(8))
rendimientos10, $Order(stuff(10))
rendimientos15, $Order(stuff(15))
rendimientos"".Establecer i="" Para establecer i=$O(cosas(i)) Salir:i="" Escribir !,i,10,cosas(i)
stuff(i)
GTM>S n=""GTM>S n=$orden(^nodex(n))GTM>zwrnn="edificio"GTM>S n=$orden(^nodex(n))GTM>zwrnn=" nombre:gd"GTM>S n=$orden(^nodex(n))GTM>zwrnn="%kml:guid"
MUMPS admite varios usuarios y procesos simultáneos incluso cuando el sistema operativo subyacente no lo hace (por ejemplo, MS-DOS ). Además, existe la posibilidad de especificar un entorno para una variable, por ejemplo, especificando un nombre de máquina en una variable (como en SET ^|"DENVER"|A(1000)="Foo"
), lo que puede permitirle acceder a datos en máquinas remotas.
Algunos aspectos de la sintaxis de MUMPS difieren fuertemente de la de los lenguajes más modernos, lo que puede causar confusión, aunque esos aspectos varían entre las diferentes versiones del lenguaje. En algunas versiones, no se permiten espacios en blanco dentro de las expresiones, ya que terminan una declaración: 2 + 3
es un error y debe escribirse 2+3
. Todos los operadores tienen la misma precedencia y son asociativos por la izquierda ( 2+3*10
evalúa a 50). Los operadores para "menor o igual que" y "mayor o igual que" son '>
y '<
(es decir, el operador de negación booleano '
más un operador de comparación estricta en la dirección opuesta), aunque algunas versiones permiten el uso de los operadores <=
y más estándar >=
respectivamente. Los puntos ( .
) se utilizan para sangrar las líneas en un bloque DO, no los espacios en blanco. El comando ELSE no necesita un IF correspondiente, ya que opera inspeccionando el valor en la variable de sistema incorporada $test
.
Las reglas de alcance de MUMPS son más permisivas que las de otros lenguajes modernos. Las variables locales declaradas se delimitan mediante la pila. Una rutina normalmente puede ver todas las variables locales declaradas de las rutinas que se encuentran debajo de ella en la pila de llamadas, y las rutinas no pueden impedir que las rutinas que llaman modifiquen sus variables locales declaradas, a menos que el que llama cree manualmente un nuevo nivel de pila ( do
) y cree un alias para cada una de las variables que desea proteger ( . new x,y
) antes de llamar a cualquier rutina secundaria. Por el contrario, las variables no declaradas (variables creadas mediante su uso, en lugar de la declaración) están dentro del alcance de todas las rutinas que se ejecutan en el mismo proceso, y permanecen dentro del alcance hasta que el programa finaliza.
Debido a que las referencias a la base de datos MUMPS difieren de las referencias a variables internas solo en el prefijo de cursor, es peligrosamente fácil editar involuntariamente la base de datos o incluso eliminar una "tabla" de la base de datos. [20]
El Departamento de Asuntos de Veteranos de los Estados Unidos (anteriormente la Administración de Veteranos) fue uno de los primeros en adoptar el lenguaje MUMPS. Su trabajo de desarrollo (y las contribuciones posteriores al código base de la aplicación gratuita MUMPS) ejercieron influencia sobre muchos usuarios médicos en todo el mundo. En 1995, el sistema de admisión, seguimiento y alta de pacientes del Departamento de Asuntos de Veteranos, el Programa Informático Hospitalario Descentralizado (DHCP), recibió el Premio Computerworld Smithsonian al mejor uso de la tecnología de la información en medicina. En julio de 2006, el Departamento de Asuntos de Veteranos (VA) / Administración de Salud de Veteranos (VHA) recibió el Premio a las Innovaciones en el Gobierno Americano presentado por el Instituto Ash de la Escuela de Gobierno John F. Kennedy de la Universidad de Harvard por su extensión de DHCP en la Arquitectura de Tecnología y Sistemas de Información de Salud de Veteranos ( VistA ). Casi todo el sistema hospitalario del VA en los Estados Unidos, el Servicio de Salud Indígena y partes importantes del sistema hospitalario CHCS del Departamento de Defensa utilizan bases de datos MUMPS para el seguimiento de datos clínicos.
Otras empresas de TI sanitarias que utilizan MUMPS incluyen:
Muchos laboratorios de referencia, como DASA, Quest Diagnostics [22] y Dynacare, utilizan software MUMPS escrito por Antrim Corporation o basado en código de la misma. Antrim fue adquirida por Misys Healthcare (ahora Sunquest Information Systems ) en 2001. [23]
El sistema MUMPS también se utiliza ampliamente en aplicaciones financieras. El sistema MUMPS ganó popularidad en el sector financiero y se utiliza en muchos bancos y cooperativas de crédito. Lo utilizan el Banco de Inglaterra y el Barclays Bank . [24] [25] [26]
Desde 2005, las implementaciones más populares de MUMPS han sido Greystone Technology MUMPS (GT.M) de Fidelity National Information Services y Caché, de Intersystems Corporation. La Agencia Espacial Europea anunció el 13 de mayo de 2010 que utilizará la base de datos Caché de InterSystems para apoyar la misión Gaia . Esta misión tiene como objetivo cartografiar la Vía Láctea con una precisión sin precedentes. [27] InterSystems está en proceso de sustituir gradualmente a Caché en favor de Iris. [28]
Otras implementaciones actuales incluyen:
{{cite press release}}
: CS1 maint: unfit URL (link)