A few years ago, I did some health IT stuff (implemented 5 RHIOs which included 80 hospitals plus various partners comprising roughly 300 data feeds).

I played with VistA. Thought maybe I could steal some of their fire. At the time, the VA was getting a lot of props for turning their act around and VistA was considered no small part.

MUMPS.

I will never willingly work on MUMPS.

I had to do a bunch of Intersystems' Cache, Ensemble, ObjectScript work. Inspired by MUMPS (the communities overlap). Complete garbage. Remember how a coding error can bork (brick) a SmallTalk runtime? Welcome to Intersystems. But without the benefits of a debugger, undo, version control, real database, an actual grammar and compiler, or rational people creating and supporting the product.

I mention Intersystems because as bad as it is, MUMPS makes it look slick.

Please understand that I am completely, utterly committed to universal healthcare with a single payer in the USA. Medicare/VA for all.

But if it means the infrastructure running VistA + MUMPS, I'll probably vote against it. (And I don't know if I'm joking.) I just can't imagine an IT migration to VistA finishing before the heat death of the universe.

Ah, yes. M: the language of indirection, post-conditional goto's, period indented block levels, and strict left-to-right order of operations (2+8*10=100). It doesn't require writing code as unreadable as this, but it sure doesn't discourage it.

Would writing a DSL that compiled down to MUMPS be out of the question?

Maybe.

MUMPS has a hierarchical data model. What the genius' at Intersystems call n-dimensional (arrays of arrays, or nested arrays). The reason MUMPS is still used is because the implementers still have hierarchy on the brain and believe that kind of work is best done in MUMPS.

I think they're wrong.

Either way, I can't think of a way to compile generic Java (or equiv) to generic MUMPS. The data models just don't line up.

The HL7 view of the data, which is just a tree graph, can be well supported in languages like Java. I wrote a code generator that compiled HL7 specs to Java code. It was awesome. Because it catches coding errors at compile time. Versus using a dynamic programming language. Or even worse, something like a declarative schema thingie, like all the ETL tools I've seen. (Think Hibernate style ORM for HL7.)

But having done that, I also think that's wrong.

We spent a lot of time reading HL7 (eg lab results), decomposing it for storage into a RDBMS, creating wicked joins to recreate the original hierarchical data, and then send it along (to a data feed or web page report).

I now think medical data should mostly be stored as documents and indexed using something like Lucene. Completely skipping SQL. Using an HL7 code generator & parser like the one I wrote, it's trivial to pull out the bits you care about. And when you have to mimic the single source of truth (eg what medications is the patient taking today?) you can tackle that with a map/reduce strategy.

That idea is a freebie for you, the world, or nobody. I'm not doing any healthcare work any more, so no longer have a dog in that fight.

Who doesn't love MUMPS?