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!

Understanding the Reason for a Customer Request

Before you start doing the work your customer has requested, first try to understand why they want you to do it.

This helps for 3 main reasons:

1) You get a chance to talk to your user and develop or nurture a relationship.

2) They feel happy that you understand what they want and care enough to ask them.

3) If something doesn’t work exactly the way the customer expects (which usually happens), you already know what their actual goal is so you can make appropriate adjustments.

Once a customer asked me to create a tool to help pharmacists track their conversations with oncology patients.  Well, I talked directly to the user about exactly why she wanted this. It turned out there was as huge issue with patient compliance for these medications.  That made me feel really good to work on a project that would aid in patient care.  More importantly, my user is very happy with the tool and regularly sends me accolades.

What do you think?  Have you seen this work?  Have your customers ever said the following?

“Shut up and just do what I’m saying.  Don’t worry about why I want this!”

Human Customer Support Representative

Call me crazy, but I think you should be nice to your software vendor’s support representative.

I know people can have a tendency to be rough with them since their organization is paying big bucks for support. But I think you’re better off being nice to them for the following reasons:

1) They are usually human beings. (I think humans should be nice to each other.)
2) They almost always are overloaded with work and pressure from clients. Being mean to them will probably not decrease their workload or pressure.
3) If your support rep is happy, he/she will probably perform better at his/her job.
4) If you get on their bad side, he/she can easily make decisions (consciously or subconsciously) to avoid helping you. People naturally are inclined to someone who is soft and caring and they naturally turn away from someone who is harsh.
5) They are more likely to go the extra mile for you when you need them to.
6) If you need them to come up with a creative solution to a problem you are having with the software, they will be relaxed and able to brainstorm better.

Are these enough reasons?

If your support rep is truly incompetent, you probably need to escalate that with your management and the software vendor’s management.

I’ve found that winning your support rep’s heart is the best way to have a good relationship with him/her. In turn, you can get a lot more done and still feel good about it.

Story Time:
A software vendor support rep once told me that throughout the day, he has many points at which he chooses which client’s issues to work on. The ones who are jerks get chosen last.

What do you think? Do you have examples where being nice to your support rep has worked well? What about examples where yelling at your support rep won the day?

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!

“You’re not the boss of me! Oh wait, actually, you are.”

I’ve found that there is sometimes a strange tension between worker bees and their bosses.  I’m not sure why this is the case, my guess is that this is a very Western phenomenon.  I noticed that when I was in Syria, it wasn’t that way.  Bosses were treated with a lot of respect.

I’ll let the philosophers duke out what is really happening, my point is just to emphasize that you should see your boss as your ally.

The way I approach it is that my boss is the person my organization chose to represent them to me.  So, since I work for this organization, I should do everything in my power to keep my boss happy.

Obviously, you can end up with a difficult boss once in a while, but you have the option to find a new position on a different team/department/organization.

I’ve found that if you make sure you take care of your boss, your boss will take care of you.

Let me know what you think. 🙂

A Shared Screen is worth a Thousand Words

I’ve found that you can cut out a lot of confusion and heart-ache by viewing your user’s screen.

When I’m on call and am assigned to an issue, one of the first things I try to do (after talking to the user) is to connect to their computer.  We have a tool we use that let’s us connect to any computer on our network.  So the conversation usually goes like this:

ME: [smile] Hello, this is Yousuf from the Health IT department.  May I speak with so-and-so?

USER: Yes, this is so-and-so.

ME: I just got this ticket that says you are having a problem with X.  Is that still happening?

USER: Yes, it was fine yesterday and now it’s not working correctly.

ME: Okay, let’s see if we can figure this out.  Do you mind if I connect to your computer so you can show me what’s wrong?

USER: Of course, please do connect!

ME: Okay, what is your computer name?

USER: It’s blah-blah-blah.

ME: Great, now I’m connected and I can see your screen.  Go ahead and show me what’s wrong.

USER: Well, whenever I try to do Y, it is supposed to let me do Z, but it won’t work.

ME: So, you are trying to do Z, but it won’t let you.

USER: Yes.

ME: I think I see what the problem is.  Would you try to do A?

USER: Yes, that’s what I needed! It works perfect now!  So, I just have to do A and it will work?

ME: Yep.

USER: Excellent!  Thank you so much!

ME: [smile] No problem, have a great day!

Lessons:

1. Call the user.  That lets them know that someone is working on their issue and eases their anxiety/frustration.
2. Smile when you talk because they can hear your smile.
3. Confirm that the issue still exists (many times they figure it out on their own before you get a chance to call).
4. Ask them for permission to connect to their computer.  That let’s them feel that they are in control.
5. Listen very carefully to whatever they are saying and confirm with them that you understood the issue. That will save you a lot of time/heart-ache because sometimes you can misunderstand the issue.
6. Watch what they do carefully.  You can take screenshots, if needed, at this point.

This trick has literally saved me HOURS of time.  In the past, it would take a long time to understand what the user is saying because they don’t use the same terms as you do.  You can then still totally misunderstand the issue and spend hours solving the wrong problem.

So let me know if you have any stories where you either misunderstood your user’s issue or helped a user based on them sharing their screen with you.

I look forward to hearing from you!

The Weakest Ink

Always be ready to take notes.  I prefer paper (when not at a computer) since paper and pen don’t need batteries, memory or a processor.

Here are some scenarios…

• At work/office, but not at desk: Clipboard with recycled paper (only one side printed on, so I use the blank side).  I carry a Pilot Dr. Grip gel pen that writes nicely.
• At work/office, at desk: Depends, but MS Word is good because you can quickly paste screenshots into it.  Notepad and “sticky notes” in Outlook also work fine for a quick fix.
• Outside of work/office: Right now I’m using a hipster PDA because of its extreme simplicity and it’s working great!  I also like pocket-sized Moleskines, but they can get a little bulky.  Write with Pilot Dr. Grip gel.
• Emergencies: I carry a Fisher Space Pen refill in my wallet for emergencies.  I also have business cards that I can always use the back of in a pinch.

WARNING: Don’t waste time figuring out the tools – just pick something that works and stick with it.  Otherwise, you can easily waste a lot of time.

Why do this?

“The weakest ink is stronger than the strongest memory.”  (I don’t know the origin of this quote, but I first read it in Imam Zarnuji’s classic work, The Training of the Student.)

1) You can capture thoughts, ideas, instructions (especially from your manager) & good advice.
2) Others feel that you are planning to act on what you tell them you’ll do (you’re not relying on your memory which we all know is not bullet-proof).
3) Peace of mind knowing that you won’t have to scramble for something to write with.

Story Time

Well, there have been many many incidents where everything went fine because I needed to write something down and I was able to!  But that’s not very exciting.

How about the time when my manager suddenly wanted to talk to me about something and I didn’t bring by clipboard with, but then I was still able to write down stuff because I had my pocket notebook?  Is that exciting?

I guess the most exciting thing about this is that you won’t have any negative excitement from dropping the ball because you couldn’t remember what you were supposed to do.

Anyway, I’ve never regretted making sure I have paper/pen, but I have seen many people suddenly scramble for paper/pen (at which point I let them borrow my paper/pen).

Certification for Vendor’s Software

Tricks.  I like tricks when they help you do more with less.

Sometimes you have to get certified in a particular software by an outside vendor.  Here are some tricks that helped me:

1) Skim through the manual before you attend the training class.

2) Pay attention during class (don’t read email or surf the web).

3) Schedule your exam for the first Tuesday following the first weekend after your training.  If you can schedule it for about 9 am, you’ll probably be more fresh.  Then, get there at about 8 am to settle in and calmly review your notes.

4) Study for your exam on the weekend before.  If it is an open book exam, focus on skimming through the manual to get a good sense of where everything is in the manual.  If there are practice questions at the end of each chapter, test yourself by not looking at the answers until you try to guess first.  (Read the questions/answers out loud to yourself.)

5) On exam day, get to the exam location early so you can settle in and relax before your exam starts.

6) After your exam, if you also have to do a project, start on it right away and give yourself a 1 week deadline to finish it.

Story: I waited on one of my certification’s exam/projects and ended up spending about 100 hours on it because I had forgotten the material.  I had to take the exam twice to pass it.  Once I followed the system above, I’m able to get certified within 1-3 weeks.

Use Spreadsheets as Tools (Even If They’re Boring)

No one ever bought popcorn and stared at a spreadsheet for 90 minutes.

That’s okay, though, because we just want to track our technical build successfully.  Spreadsheets are usually the easiest way to do this. 

Let’s say you need to update 100 records in your Electronic Medical Record system that are similar but have slight variations.  Well, you have a few things you’ll need to manage:

1) Save notes about all your changes so that you can reference them later without relying on memory.

2) Describe your changes as part of your change control process.

3) Be able to use your notes to quickly redo all the changes in a test environment and then in a production environment.

I have found the best tool to do this is a spreadsheet for the following reasons:

• It’s fast and easy to populate with build information.
• It’s easy to read.
• Allows for easy copying and pasting.
• You can easily put filters on the columns to focus on specific pieces of information.  (This article explains filtering in more detail.)
• It’s easy to sort your data.

Here is a sample spreadsheet for ya.

Lesson: Use spreadsheets to track your build.

Story: I recently had to create an electronic flowsheet at work for a pharmacist.  I spent hours preparing the spreadsheet because there was some logic based upon which certain records would appear or not.  It paid off because I understood the exactly what was going on with each piece of the build and had that all recorded in the spreadsheet.  Doing the actual build was easy because I just worked down my spreadsheet.  Thankfully, my user LOVES it!

Dangle Your Fingers

After working at a computer for over a decade, my poor ergonomics caught up with me.  My left hand started to feel like it was on fire whether I was typing or not.

I complained to my manager and they got me an ergonomic assessment.  Finally, after about a decade, someone told me how to type without injuring myself:

• Dangle Your Fingers Over Your Keyboard

That’s it!  Don’t wrest your wrists on anything, just let your hands float gently over your keyboard and type.  It makes a huge difference.

I think this change was the single most effective “treatment” that prevented my carpal tunnel from getting worse.