Aaron Berdofe, MHI – Health Informatics

How many of you have already achieved Stage 2 for Meaningful Use?  Still working on it, huh?  Shooting for 3rd or 4th quarter?  Don’t worry, you aren’t alone.  Most sites I’ve talked to are relying on Iatric, Acmeware, and Medisolv to take care of all of the Meaningful Use reporting for them.  That’s a shame really, because running the SQL statements that Meditech put out for each measure isn’t THAT hard.  Then again, not everyone has a resource versed in SQL.  Here’s some follow-up to the first post on MU Stage 2.

If you do decide to run it on your own, Meditech really does provide some good instruction for how to run the reports even for those who can’t fully interpret what is in the SQL statements.  Assuming you already have DR setup and the latest table update for all relevant MU DR Tables, the next steps just involve copying and pasting SQL scripts (Just edit the reporting date range).

The documentation will have you run two set up scripts for the Core/Menu measures and then on top of that you will need to update which queries you are using for things like your Ethnicity, and Language queries.  Here’s where the documentation overly complicates things for a novice user.  The documentation has you updating the SQL scripts themselves which is really just asking for some accidental keystrokes.  Instead, I would open up the CoreMenuReportConfigurationTable in MS SQL Server and manually type in the query names into the table.  This saves your information in and you don’t need to keep reloading the SQL script.  Additionally, I will reiterate the fact that every single row in this table needs to have an entry in it in the Parameter Value column.  If no query or value exists, make sure to put the null character (ø) in otherwise your report will error out.

The setup for the CQMs is pretty much the same except you’ll be plugging your query values into the eCQMConfigurationTable instead.  The other difference is that you’ll need to download the latest pull of the Value Sets used in the CQMs (address is on the Meditech documentation) and follow their instructions to run a quick script to load that in.

I’ve only seen two errors come up when running through all the queries.  The first is when the script isn’t being run in the correct database (Make sure you’ve started a new query in your Live db).  The second is when not every row has a Parameter Value in your configuration tables.  Otherwise, the results seem to be valid.

Of course, there is one exception to all this setup that must be handled uniquely and that is the Patient List generation requirement.  The whole point of this measure is to hint at that fact that maaaaayyybbee these reports you are generating would be more helpful if you can actually do something with the data instead of looking at static final numbers.  Dynamic. Not say, a Meditech report viewer which is about as effective as printing a report onto paper (Archaic, I know).

Given this subtle hint, Meditech completely ignored it and decided to create a special tool specifically to meet this measure.  Once you load in the Meditech ARRA Report Manager, your first thought will be “Oh! Maybe I can just run all of the reports out of…No? You can’t do that? Just for this one report then?”  Again, the instructions for loading the ARRA Report Manager and setting it up are great.  Following them is a snap.  However, you may soon have a couple of thoughts.  First, is that since the person who is managing your Meaningful Use reporting is probably not in your IT department and can’t log on to your DR server to find the local page that hosts the ARRA Report Manager, how will you let them access it?  The easiest way is a bit of a rough hack; you simply give them the following address: http://nn.nn.nn.nn/MtArraWebTool/Login.aspx where the ‘n’s are replaced by the IP address of your DR server. That will bring you to the second thought: This isn’t a very secure way to handle PHI is it?

Those somewhat technically inclined may notice that there is no ‘s’ after the ‘http’ in the address which is the first indication.  I’m sure there is a way to have a more secure way to link to this page, but I don’t know one off the top of my head and I have a hard time thinking the IT departments of most small hospitals know a way either (Email me if you have ideas).   However, once you get past that part of the security situation, then you run into how shockingly bad the login is for the tool.  There are zero password requirements that a user must adhere to when creating a password.  Anyone want to Google unsecure HTML password hacks?  Unfortunately, unless Meditech makes a change, there is nothing you can do in regards to this.  Your PHI will be slightly vulnerable to anyone who is already on your network.

All that aside, it’s a shame Meditech didn’t take the extra two steps and allow you to run the other MU reports from a (more secure) tool like this.  Maybe they’ll get there by Stage 3. And maybe, just maybe they’ll figure out how this whole internet thing works before they get someone to try their pending web-based EHR.

[Electronically sending MU report results is still pending…]