Meaningful Use / MACRA and MIPS

(Tony McCormick) #1

Since LibreEHR is a heavily used in the US I am frequently asked about this. We chose at the start of the project NOT to give MU any focus, due in part to the status of the code, cost of meeting the criteria, political climate and the general unhappiness providers about the extra staff effort to do this.

The testing process is onerous. I ran the MU-1 project (successfully) and the first 1/2 MU-2 project for OpenEMR, which as you can see from the post below is STILL not certified, even with herculean effort on the teams part.

MU2 Update: The “Certification Body Review” application was submitted to ONC on 12/14/2016, and we just got a reply today that 5 items have issues that need to be addressed. Although it’s not good news, it’s definitely not bad news since there are really just 2 central issues to address(ie. we are really close and there are no showstoppers):

  1. Several fixes need to be done in the ccda reports.
  2. A server time fix. I don’t have a estimated time to completion yet, but guessing just several weeks. Will know more in a couple days. Will also keep placing updates on the barometer: -brady OpenEMR

All that said it is a worthwhile thing to discuss for the LibreHealth community. Therefore I am starting a thread about it.

Couple of starting questions:

  1. Should we consider certification at all, or recommend OpenEMR to those that need MU?
  2. Should we consider some kind of modular certification approach? ie: LibreHealth provides some, but not all the the modules needed for MU (2 or 3) and we help identify and integrate with other projects for the rest?

(Kevin Yeh) #2

The issue with MU (now APM I think under MIPS) is that it’s a lot of work both for the vendor and the user, for a small incentive (maximum of 4-9% higher reimbursement depending on year.)

However, avoiding the 4% medicare penalty in 2019 by just reporting on one quality measure in 2017 should be much easier.

One relatively easy way to achieve this would be to make it easier to document CPT2 codes in LibreEHR, and then Art’s PQRS Pilot package can take care of the rest.

A 15 minute or less demo could show everything needed to take care of MIPS reporting, that could drive adoption by US providers. Very much in contrast with what is needed to achieve APM for bonuses.

(Judy Gichoya) #3

The problem with CPT codes is they are proprietary and owned by the AMA – We cannot use them without explicit permission and $$$

@akanter is an expert on terminologies

(Kevin Yeh) #4

LibreEHR already includes paraphrased versions of some of the basic CPT codes (E/M) for billing. This is a practice which the AMA considers “fair use.”

Adding a handful of additional CPT2 would also be acceptable on this basis. My product will only use a few CPT codes. Do I need a license?

You should evaluate whether your proposed use of CPT falls within “fair use.”

The U.S. Copyright Law, under Chapter One, Section 107, exempts certain limited use of copyrighted works, referred to a “fair use” and such uses are permissible without a license.

The law requires that you make a good faith determination based on the balance of 4 statutory factors. These factors are subject to interpretation, and careful analysis is required. Consulting your legal advisor is a good idea. For more information on fair use and the copyright law, see the U.S. Copyright Office website.

(Kevin Yeh) #5

The general approach is to add “PQRS status” as part of the billing workflow or the basic clinical documentation for a handful of NQF measures. It doesn’t have to be “tagged” as a CPT2 code necessarily, the descriptions could be paraphrased from the quality measures themselves.

The “lowest hanging” fruit might be BMI. If there is a height and weight recorded for the majority of patients during a reporting period, generating data for NFQ 0421 would be trivial.

(Art Eaton) #6

Judy is absolutely correct. Of course CPT4 codes are also proprietary…but providers must use them for daily billing as well as CPT2…which means that we cannot provide the codes, and the AMA does not provide them in a particularly useful format (or even a comprehensible format) even when you buy the electronic versions directly from them. Total scam when we could all just be using ICD10 PCS, but that is the corporate overlord reality. The APA gets away with publishing (very bad interpretations) of ICD10-CM in their “DSMV” publication, but the AMA has the stranglehold. HOWEVER… There is no way to get around this fact. The process involves ICD10, HCPCS, and both CPT4 as well as CPT2. Unless you have a totally parallel system that they are using along with the billing system, essentially doing double entry, the software must have SOMETHING to interpret as indicating that the office visit etc… has occurred. We cannot know what they have done without the software being CPT code aware…which means it must be part of the software to do the job at all. There is no possibility of making a parallel code system without a comparison table.

-So…while the 1983 legal monopoly is a reality, and the providers usually wind out buying a book or something with the codes in them…this is an expense they usually swallow. The files available are not in an easy to swallow format, and for the purposes we propose, them buying a copy directly doesn’t help much. Getting meaningful use out of the copy means we would need to format it as well as providing some hard-coded stuff. That means they would need to buy it through us, and the licenses are per user which gets really crazy. So, to do this stuff, you need HCPCS, ICD10, CPT 4 and 2. Options:
Turn LibreHealthEHR into a business and provide the digested package mostly shipping the money straight to the AMA gangsters. Use the opportunity to make the package worth it to the providers. Include everything we can.

Leave the clinics responsible for providing their own CPT code sets (as they already are), with an importer tool that is capable of swallowing the goofy format they use, and require them to use a vendor to manage the actual measure calculation (which is my business model, and the only way I could figure out how to make the service available).

No other mixed approach can actually work. I have spent month attempting to figure out a practical scheme. Unless every form and element in the system already knows what sort of thing the clinician may actually ever do, and use those actions to figure out what has been done, you cannot tap directly into the workflow that the billing process already owns without including a crosswalk that joins the Pirates of the AMA.

(Art Eaton) #7

You might be right Kevin, but… Here is the unique code breakdown for measure calculations: 129 CPT2 3652 CPT4 118 HCPCS 8061 ICD10

(Tony McCormick) #8

we should consider this as an option for LibreHealth EHR …®-certified-2015-certification-criteria

(Art Eaton) #9

Too bad it is so incomplete and nearly impossible to use or even deploy.

(Kevin Yeh) #10

CMS is having a Webinar that would be of interest. In particular “EHR certification requirements” is on the agenda.

I’m not going to be able to attend live, but will checkout the recording once it’s available here:

A presentation on: Merit-based Incentive Payment System (MIPS) Overview (11/29/16) Is available on that site too interested parties should checkout.

(Art Eaton) #11

Yeah, I told Beth I would be on that call, but I don’t think the agenda is going to be very interactive. I don’t think Sophia and Dr. Green are presenting anything for that, despite MIPS being covered.

(Judy Gichoya) #12

Here is a good summary on MACRA and MIPS that i love and comes from someone i really respect,-c-,-macra-primer

(Tony McCormick) #13

One of the MU requirements is audit logging. In LibreEHR (and OpenEMR) we did this by inserting a log writer in front of all SQL queries.

I wonder if we could use something more native to the MYSQL (or other database). I am not a DB expert, but it seems that some combination of of Native Transaction Logs and simple meta data in the application might be a lot more effecient. MIght even figure a way to remove the meta data part and use data mining instead for “log reports” …

Thoughts? @aethelwulffe @yehster @sunbiz etc …

(Saptarshi Purkayastha) #14

The MySQL audit logs requires an enterprise version, which I dont think should become a requirement. MariaDB on the other hand, has a nice plugin that does a great job - Does LibreHealth EHR work on MariaDB? We can then put the log through splunk and get some good visualization and analysis.

(Tony McCormick) #15

Yes it works fine in MariaDB…

(Art Eaton) #16

Yeah, XAMPP rel (somewhere out there) is Maria, and Maria is a drop-in mySQL in all cases TMK.

(Kevin Yeh) #17

There will be some trade-offs, but it’s probably worth investigating.

The biggest “advantage” of the current mechanism is that we have more control over it. We add some additional context, such as the LibreEHR UserID, which would be trickier with the database native loging mechanism, as it doesn’t have access to things like the PHP session. We need to log more than just the “raw query” which is what I suspect the database does out of box.

(Tony McCormick) #18

So I was thinking about the user id issue and wondering if it might be worth investigating more direct model, instead on one “master user and password” for the clinic database, you create a user in the db for each user in the system. This would also allow the user to be given “read-only” permissions at some level of granularity and handle the ‘userid’ issue for logging.

Optionally we just make sure that all table have both “updated” and “by user” columns.

(Kevin Yeh) #19

Managing both an application userid/password and a database userid/password seems like more hassle than it would be worth. The db user would not work if it was purely read-only, as they would need some update permissions. My next thought is that having all of those users creates a big security liability.

Simply adding “updated and user” columns doesn’t work easily as it means modifying every query to update them. Also it won’t log “viewing” of data with select statements which is required as part of auditing capabilities.

From an “efficiency” standpoint, the big issue I see with the current mechanisms is that the makes two separate calls to the database which means two network round trips for every query. When DB and webserver are on different machines, that starts to add up a lot. Instead of the audit log going to the audit_log table, it might be more efficient to use something like log4php.

(Art Eaton) #20

The CMS repo for QPP measure reporting (formerly known as PQRS, now part of MIPS/MACRA): I will be contributing there as time goes on…currently involved in issue discussions. This is the first time we will be able to directly affect the implementation of the actual business logic for any of these related programs. I encourage the open-source medical IT community to show they are interested, and want to be involved, and appreciate having the repos public.