What (almost) every healthcare IT Analyst Should Know About MUMPS Programming

I’ve found that different software vendors require different levels of customization.  Some make their money more on charging for customizations than for regular support.  Others are the other way around.  Regardless, I think it helps a lot to learn how to customize the software you support by learning the programming language it is written in.

In my case, I happened to learn MUMPS back in 1997.  If you were alive at that time, you may recall that this was during the .com bubble and I happened to be in Silicon Valley!

Well, I had just gotten married and had just gotten my bachelor’s degree.  That meant that I had a lot of pressure to find a decent paying job fast.  My wife was supporting us and I felt really embarrassed that she had to do that.

So, one of the hospitals in Silicon Valley hired me.  I think they had a hard time finding someone to do healthcare IT when there were all these .com jobs around.

Anyway, I was happy to take their offer to learn MUMPS and finally be able to support the family.  Since then, knowing MUMPS has helped me multiple times because it turned out that some of the biggest players in healthcare IT wrote their software in MUMPS.  I’m pretty sure the last 6 job offers I got were all heavily influenced by my MUMPS programming skills.

So, here are a few things that you can learn about MUMPS that will help you A LOT in at least reading the code.

1) Learn how to read comments in MUMPS.  Anything after a “;” on a line is a comment.

2) “s” means SET, so learn how this command works.  It is just to set a variable to a value.

3) “q” means QUIT, it stops execution at that level and pops you to the next level up or out of the routine.

Start with that.  Let me know if you want a few more of the most common commands in MUMPS.

If you’re interested in learning more, a good place to start is this Intersystems’ tutorial.  This actually teaches you ObjectScript, which is a slightly different than MUMPS, but I understand some of the major software vendors are heading this direction.  So, its probably a good idea to learn this.

If you already program in MUMPS, what are some other common MUMPS commands?  Please share in the comments.

If you don’t program in MUMPS, what are you greatest fears in learning MUMPS?  Please share your answers in the comments.

I look forward to hearing from you!

Solutions

Something kind of cool happened this morning that I’d like to share.  We were able to solve a problem in about 52 minutes that had been lingering for about 4-5 months.

I was assigned to a user request to enhance a process related to diabetic patients’ diets.  Doesn’t sound very impressive, but someone else had been working on this request since the summer.  That person could not work on it any longer, so I was assigned to it.

Well, a couple of my colleagues who were familiar with the request met with me this morning to get me up to speed.  They explained that my predecessor had a solution, but the physician community shot it down because it would have caused them some confusion.  They told me that we were back to square one.

I asked them what the current workflow was and wrote it down as they spoke just using pen and paper.  I also asked specific questions that were not central to the problem just so I could have a clear and complete picture in my mind (like “who carries the tray of food to the patient?”).

Then, I asked them what was wrong with the current workflow and documented that.

Next, I got a fresh sheet of paper and started drawing out what I understod (at a high level) they wanted the new workflow to be like.  I asked them some more questions and we agreed on a workflow that would meet the users’ needs.  Now, the question was how to make this happen within our EMR.

To recap, we nailed down the following:

1. The current state
2. The desired state
3. The limitations
4. Previous solutions that didn’t work and why

With this, getting the solution was relatively easy.  I proposed a fix that seemed very straightforward in my mind.  We started discussing it.  One of my colleagues immediately started poking around the system to gather information as we discussed it.  We bounced ideas off of each other and verified assumptions by looking in the system in real time.

Amazingly, we found a good solution that seemed viable within about 52 minutes.  The next steps are to test and iterate.

My colleagues clearly were happy that we had such a productive meeting and were able to come up with a solution in one sitting that they had been grappling with since the summer.

Lessons:

• When researching solutions to problems, you can get more done in a team than by yourself.
• Document the current state and get a clear picture in your mind of this.
• Identify limitations or restrictions your solution must abide by.
• Document the future state and verify that everyone agrees.
• Review previous ideas to solve the problem and why they didn’t work.
• Share ideas as a team and test/verify as quickly as possible (in realtime, if possible).

That’s what happened this morning! 🙂

Now, please let me know how you solve Healthcare IT problems related to your users’ workflows!