Aaron Berdofe, MHI – Health Informatics

We did it for the money!!!!

A long while back I reported about how to potentially get all of the Meaningful Use objectives out of LSS before Stage 1 was final and before LSS had even taken its first stab at helping their customers out.  Now that the criteria is set for Stage 1 and Stage 2, and LSS has come up with a way to report the necessary numerators and denominators out of their system, it’s time for an update. Now, LSS customers are nowhere near the attestation numbers of other major EHR vendors as I showed in my little analysis that caused a minor stir on HISTalk when it came out, but there are a few here and there attesting successfully, albeit with some difficulty.  As a CIO client of mine recently put it in regards to the approach LSS took: “…They meet the letter of the law, not necessarily the spirit.”  Needless to say, it’s clear LSS took the “Well, technically you can…” approach, instead of truly understanding what it means to meaningfully use healthcare information technology. Regardless, you want to know how those who attested did it and how much difficulty will you have in doing it? First off, you should have my Meaningful Use Checklist on hand.  This a modified and expanded (read: better) version than the one LSS provides.  On it you will find all of the core and menu objectives and the LSS recommendations as to which menu objectives you choose. I will second their recommendations as that won’t require you to dive into their untested code for the interface pieces and depending on what state you are in, it might not be an option to begin with.  You will also find the core quality measures and then you will have to select the 3 additional ones from the 44 that were put out.  Please see the links below for those. I have been in all MEDITECH platforms (6.0, C/S, MAGIC) to do this set up and it’s essentially the same, with the exception that the MAGIC Clinical Reports dictionary looks slightly different.  So please take these recommendations as being platform independent. The Meaningful Use set up revolves around two areas of the system: The System Utilization Report and the Clinical Reports, both of which are found in the APR/EAR module.

System Utilization Report

10 Core Objectives and 5 Menu Objectives are included in this report:

• CPOE (Core Objective)
• eRx (Core Objective)
• Record Demographics (Core Objective)
• Problem List (Core Objective)
• Medication List (Core Objective)
• Allergy List (Core Objective)
• Record Vitals (Core Objective)
• Smoking Status (Core Objective)
• Patient Summary Upon Request (Core Objective)
• Patient Summary at Visit (Core Objective)
• Incorporated Lab Results (Menu Objective)
• Timely Access to the EHR (Menu Objective)
• Patient Summary at Transition (Menu Objective)
• Medication Reconciliation (Menu Objective)
• Patient Education Materials (Menu Objective)

The necessary setup:  Each objective utilizes various parts of the system functionality which are listed in detail on the checklist I created (See link above.  I’m not kidding, use the spreadsheet).  However, most people neglect the last piece which is located in the APR/EAR Customer Parameter dictionary.  On the System Utilization tab/page you will also need to fill out the Admission Queries:

• Include Ethnicity with Race (Y/N): Set to Y if you combined the ethnicity responses into your required race query upon registration.
• Ethnicity (Query lookup): Only necessary if the previous field is set to ‘N’.  Enter what MIS Query you are using for ethnicity during the registration process.
• Preferred Language (Query lookup): Enter what MIS Query your preferred language query is during registration.  Be sure to make this query required.
• Decline Demographics (Query lookup):  If your race/ethnicity queries do not have a “Patient Declined” option in their group response, you should have a separate Y/N query that asks whether the patient declined to give their demographics or not.  Whether you include this in your group response for race/ethnicity or leave this as a separate query is up to you.  Either way will result in the same count because the race/ethnicity query should be required in the first place.

And the Documentation Tool Queries:

• Smoking Status (Query lookup):  Enter which MIS Query you are using to list the patient’s smoking status on your PFSH.  This does not necessarily need to be the standard Zynx query, but your responses should be the same as those.
• Patient Education (Query lookup):  Enter which MIS Queries you are using to denote that patient education materials were given out during the visit on the templates you have built.  This can be as general as a “Patient education materials given out (Y/N)’ query or creating a (Y/N) query for disease-specific education materials.  Regardless of what you do, make sure you have at least one query on the template (typically put on the Plan/Assessment section), and be sure to list all the others if you have multiple.

Regarding the Correspondence  Types.  I’m willing to be that the vast majority of LSS customers attesting did not spring for the extra interface .  So don’t worry about filling this out because you don’t have it.  5 Menu items are already worked out on the report anyway.

For the sharp-eyed (or perhaps those that can just count), 5 of the 15 total Core Objectives are not included on this report.  Never fear.  Those are accounted for in other ways.

• Interaction Query: Y/N attestation.  All you have to do is make sure it works in the system after you set it up.  When you attest, you will state that you have it in place.
• Decision Support Rule: Y/N attestation.  Ditto as above.
• Report 6 Quality Measures:  See the next section below.
• Exchange Key Clinical Information: Y/N attestation.  Utilize the ‘Generate Continuity of Care Document’ routine to create a CCD .xml or .html file.  No set up required.
• Protect and Audit Electronic Health Information: Y/N attestation. Verify that none of your purge parameters are set to purge audit trails in a time period shorter than 90 days (the attestation window).  You can check with your LSS specialist if you are unsure.  LSS passed certification by showing their audit trail reports.  I think these audit trails are mostly worthless and have quite a few gaping holes…but they technically muster enough credibility to make it a “Certified EHR”.

At this point some of you may have noticed that I did not mention the Quality Section that LSS is including as standard content these days.  The reason I didn’t mention it is because it is completely worthless and a waste of your providers’ time.  Most of the items are relating to PQRS and the remaining items are either relating to Patient Education resource queries and items relating to the 6 Clinical Quality Measures (CQMs) that you have to choose from. The most annoying part of this section is that most items are accounted for other places in the system (i.e. Do you really need a query asking whether the BMI was recorded or not when it was recorded in the Vitals?).  But that takes us to the second part of this endeavor…

Clinical Quality Measures

Listed on my Meaningful Use Checklist (Again, I really want you to have it) you’ll find the 3 required quality measures and their 3 alternatives (for pediatric patients primarily).  Additionally, you have to choose 3 more measures that you want to submit.  Therefore, you’ll have to build 9 Clinical Reports to get the necessary data.  One of my clients has built all 44 measures that you could possible choose from and more power to them, but I can tell you that the staff member assigned to building those hates her life right now.  It didn’t help that she accidentally built these reports in the Compile routine first which meant they didn’t save so she had to build them twice.  Please take care to build them in the Clinical Report dictionary and not the compile routine. And how do you build these?

This Meaningful Use team is not jumping for joy, but falling blissfully toward their deaths.

First, locate the LSS Clinical Quality report building document (MEDITECH login required).  This document does a great job of walking you step-by-step through the fields in the Clinical Reports dictionary for every single measure.  And if this document was accurate, that’s all I’d have to put about it.  But alas, there are parts that are so wrong.

Items that are woefully inaccurate:

• Drug Class for Medispan users.  If you use First Data Bank as your formulary provider, you are mostly good to go.  I’ve found a few discrepancies between what LSS lists for a drug class and what actually exists in the formulary, but common sense has fixed those corrections.  If you use Medispan though, using the Drug Class as prescribed is not an option.  You must instead use ‘Medications’ as your clinical category instead of ‘Drug Class’ and then list every single drug that could possible be prescribed for the quality measure.  For instance, instead of listing a drug class of smoking cessation agents, you would need to list all the drugs that could be prescribed by your providers for smoking cessation.  Apparently LSS can provider the RxNorm codes for the medications, but since there is no RxNorm lookup into your drug dictionary, you have to look them up yourself.  An LSS specialist’s response on how to do that: “Just Google it.”  Brilliant.  But in the real world, a license to the UMLS is a more accurate and credible resource.  Even better, is to go directly to the source of the quality measures, which is what you have to do for SNOMED codes as well.  See the next bullet for links.
• SNOMED/ICD-9/CPT codes are inaccurate/incomplete.  In the appendix of their document, LSS lists all the SNOMED/ICD-9/CPT codes for each measure, which would be really helpful if they were complete and correct.  You will be initially hesitant with the volume of codes you have to put in and then you will gasp in horror as you realize that you have to enter them all one-by-one.  As you begin the task, you will begin screaming in agony as code after code that you enter comes up as “Not found”.  All of these codes listed in the Appendix supposedly came from the NQF’s official documentation for the quality measures.  If you go to their website, which I highly recommend you do, you can get the full zip file full of spreadsheet for each measure.  To view the a measure, select the desired file and then open up the spreadsheet found inside.  The ‘Value Set Descriptors’ worksheet is where all of the goodies are.  If you filter the Code System category you can take a look at the necessary CPT, ICD-9, SNOMED, or RxNorm codes for the measure.  All LSS had to do was copy and paste from this document, but apparently that was too difficult.  So use this as your “Appendix”.  However, you will still note that some codes aren’t found in your look ups.  Don’t panic.  If the code isn’t there for someone to select in the first place, you don’t need to add it to a report to check for it.  If you’re barely finding any codes though, you should try reloading the formulary.
• Queries.  You will find that a high number of clinical reports that you build will have queries listed on them that the report compile will be checking for.  The vast majority of these are probably not in use in your system on your templates and quite frankly, don’t need to be or can be replaced by existing queries.  For instance, on one of the Diabetes measures, the queries that are checked for are asking whether a foot exam and/or and eye exam were performed.  How many of you have foot exam and eye exam included on your exam section already?  Replace the queries listed in the LSS documentation with yours.  Additionally, a Hypertension measure report has a query it checks for to see if the BP was recorded.  You know, that same BP the nurse filled out during the intake?  Do we need to answer this query?  The reports are built with a crazy level of redundancy just in case, you know, the only part of the system you are using is the Doc Tool. Therefore, if the report calls for a Clinical Category of Vitals to be put in and a measure of BP recorded, you don’t also need to have listed under the PD Queries tab a query asking the same thing.  Notice under the ‘Formula Builder’ for the report that the logic is stating the report will check either the Vitals OR the query.  Well…your users are filling out the Vitals during the intake so there’s need for a query.  Unfortunately, lots of these situations exist so you have to think through every single report you build and focus on what the report is actually checking.  This is why most of the stuff on the Quality Section is redundant and can either be moved to a logical place on the template or removed completely.

To top it all off, I’ve found in 3 different clients, on 3 different platforms, that the Clinical Quality reports are extremely buggy.  As in, even if they are set up perfectly according to the documentation and you have verified you should have patients show up for the numerator, the report doesn’t catch them.  This makes me seriously doubt that those few LSS customers who have attested already, did so honestly through Medicare.  Otherwise, I would guess they used either NPR reports or a third-party reporting tool to generate the data.  Ishould also ask the question: Why did LSS go through the trouble of laying out all the detail of how to build the quality reports when they could have just uploaded them as standard content into everyone’s system and then allowed their clients to make minor modifications?  I would not assume things will improve too much when it comes to the enhancements that will be needed to meet Stage 2 and 3.  You will certainly be able to meet the letter of the requirements, but don’t anticipate being able to meet the spirit.

Sigh.