MUMPS

MUMPS (Massachusetts General Hospital Utility Multi-Programming System) holds a remarkable position in computing history: a language created in the 1960s for hospital information systems that reportedly still underpins a majority of electronic health records in the United States today.

History & Origins

In the mid-1960s, at Massachusetts General Hospital’s Laboratory of Computer Science, Neil Pappalardo, Robert A. Greenes, and Curt Marble were working on an NIH-funded hospital information systems project. Frustrated with the limitations of the existing assembly-language approach developed by BBN on a PDP-1, they created MUMPS as an alternative development environment beginning in 1966, initially running on a DEC PDP-7.

What set MUMPS apart from other languages of its era was a radical design decision: the language included an integrated hierarchical database as a core part of the language itself. Variables in MUMPS could be either local (in-memory) or global (persistent on disk), with the same syntax for both. This tight coupling of language and database made it exceptionally well-suited for the kind of data-intensive, interactive applications that hospitals needed.

The Name

The acronym MUMPS stands for Massachusetts General Hospital Utility Multi-Programming System. In 1995, “M” was accepted as an alternate name in the ANSI X11.1-1995 standard, though “MUMPS” remains the formal name. Both names are used interchangeably in practice.

Why MUMPS Still Matters

Healthcare’s Hidden Infrastructure

MUMPS-based systems reportedly process health information for a large share of patients across the United States. Epic Systems, the dominant electronic health records vendor, runs on InterSystems IRIS (a MUMPS implementation). The Veterans Affairs’ VistA system, one of the largest healthcare IT systems in the world, is built entirely in MUMPS.

The Integrated Database

MUMPS’s most distinctive feature is its built-in hierarchical database using “globals” – sparse, multidimensional arrays that are automatically persisted to disk. This eliminates the impedance mismatch between application code and database that plagues most other languages:

 ; Store a patient record - no SQL, no ORM, no separate database
 set ^patient(12345,"name")="Smith, John"
 set ^patient(12345,"dob")="1990-03-15"
 set ^patient(12345,"allergies",1)="Penicillin"

Key Language Features

• Typeless variables - One universal data type, automatically coerced as needed
• Hierarchical globals - Persistent sparse arrays as a native data structure
• Pattern matching - Built-in pattern matching with a unique syntax
• Abbreviations - All commands can be abbreviated to their first letter (w for write, s for set)
• Case insensitivity - Commands are case-insensitive
• String processing - Strong string manipulation capabilities inherited from STRINGCOMP

Modern MUMPS Implementations

For this tutorial series, we’ll use YottaDB via Docker, as it’s open source and actively maintained.

Getting Started

MUMPS source files use the .m extension. A MUMPS file is called a “routine,” and the routine name must match the filename (e.g., a routine named hello is stored in hello.m).

MUMPS has some unique syntax rules:

• Lines starting in column 1 are labels (routine/subroutine names)
• Executable code must be indented (start with a space or tab)
• Commands are separated by spaces, and each command is followed by a single space before its argument

The typical workflow with YottaDB:

1
2

# Run a routine
yottadb -run routinename

Continue to the Hello World tutorial to write your first MUMPS program.