Most languages have workarounds for things that aren't natively supported. MUMPS programmers can use loops with no looping conditions and GOTOs or QUITs to exit the loop, simulating a 'while' loop. You can also copy arrays into new arrays that are sorted the way you want, or "insert a value in the middle" by creating array element "3.5" between 3 and 4. Likewise, you can attempt to enforce data types by layering a type-enforcing API on top of MUMPS and then hoping everyone uses the API instead of ignoring it.

A good programmer considers each language/environment to be a tool and uses the right tool for the job. In safety-critical systems where invalid data could kill someone, using a typeless, schema-less system with nonstandard language conventions as a starting point seems irresponsible. Why not start with a normalized relational database and a language designed to encapsulate and protect data from inadvertent data-entry or programming errors?

Epic may not allow you to store an address in a numeric column, but that's only because the application goes through the Cache SQL API, and either the app or the API will disallow it. If you can write MUMPS/Objectscript, you can simply write directly to the underlying data and nothing will stop you. Contrast that with any SQL database, where you can't write "XYZ" to an INTEGER column no matter what your access level

MUMPS is only used in healthcare/financial systems because those institutions developed applications in the 1970s and are still maintaining them. There is zero interest in MUMPS for any new development. At the time (the 1970s), MUMPS offered a lot of features that other languages didn't. It is basically a hierarchical key/value datastore (like the windows registry, or a filesystem), coupled with a minimalist programming language (it still doesn't support 'while' loops, switch statements or variable scoping). There is no concept of relationships (except between layers of the hierarchy), no way to enforce datatypes, no way to sort an array, no way to search the hierarchy for anything, no way to create discrete objects or associate methods with data.

It does contain some advanced features (for the 1970s); multi-threading, distributed data, and the ability to abbreviate all language commands down to 1-2 letters so your program can fit into 4k of RAM.

EPIC, the medical records product used by many hospitals in the US, is built on top of Intersystems Caché. Caché adds relational features to the MUMPS database, object-ish features to the MUMPS language and supports SQL queries. Internally, it converts all queries to MUMPS, and you could totally bypass the API and write anything you like directly to the database (violating any constraints the API would have imposed on you).

If you are interested in schema-less/noSQL databases, I would suggest you have a look at MongoDB. It has all the features MUMPS does, but without the ancient programming language attached to it. It also has powerful searching capabilities, can store terabytes of data and supports transparent replication and distributed storage.

If you are interested in a schema-less database for a MEDICAL ENVIRONMENT, where accuracy matters and the difference between having a '12' in the dosage column vs. "123 any street, anytown, usa" (silently converted to 123 when treated as a number) could kill somebody, then please consider an alternate profession.