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.
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.
You might be right Kevin, but… Here is the unique code breakdown for measure calculations: 129 CPT2 3652 CPT4 118 HCPCS 8061 ICD10
we should consider this as an option for LibreHealth EHR …
https://www.osehra.org/post/new-release-pophealth®-certified-2015-certification-criteria
Too bad it is so incomplete and nearly impossible to use or even deploy.
CMS is having a Webinar that would be of interest. https://engage.vevent.com/index.jsp?eid=3536&seid=759 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.
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.
Here is a good summary on MACRA and MIPS that i love and comes from someone i really respect
http://www.radiologyleaders.org/resources/leadership-insider-podcast-episode-103,-c-,-macra-primer
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 …
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 - https://mariadb.com/resources/blog/introducing-mariadb-audit-plugin. Does LibreHealth EHR work on MariaDB? We can then put the log through splunk and get some good visualization and analysis.
Yes it works fine in MariaDB…
Yeah, XAMPP rel (somewhere out there) is Maria, and Maria is a drop-in mySQL in all cases TMK.
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.
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.
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.
The CMS repo for QPP measure reporting (formerly known as PQRS, now part of MIPS/MACRA): https://github.com/CMSgov 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.
https://groups.google.com/forum/#!forum/qpp-apis The above is the Google Group associated with the whole MIPS/MACRA thing. It really only involves the “API” (snickker), and some sort of web tool at the moment…but outreach from a government agency starts small. The CMS contract developers all seem to be young and involved, but not well supplied with ancillary data that would give them the “Big Picture”. Our community needs to meet them half-way on a great number of things. This is the best support venue CMS has ever had, and I feel that more communication here will result in a lot less time on phone-call hold waiting to speak to someone at CMS.
@aethelwulffe and the rest of the LH folks
I think we should find a way of blogging or some form of documenting … New comers coming on will have no idea of what MIPS /MACRA is …
I am excited to see open source initiatives make their way into CMS
Uh…Judy, I know you run around in Kenya, Malawi and Uganda, and I forgot you are an internist somewhere in the Mid West, so I guess I assumed you were generally free of the influence of CMS. I disliked gumming up the forum with U.S. regulatory junk like this. I guess you must be actually based out of the U.S. My condolences.
-Anywho…aside from participating in their project, getting involved in the Webinars for all this stuff (they just announced one for every month in the rest of the year), any suggestions on where/how to document more broadly? I have been posting gripe articles on Linkedin and whatnot. I suppose a “Here is what this all really is” article would be a good start, at least for our contributors here…the ones that are not wise enough to just say “Ug. More of the American Government junk…pressing…[delete]”.
We could throw up a blog somewhere – at some point but in the meantime, posts on here can suffice and we can shortlink them. We could also use the forums in a similar to the howto category on Discourse Meta. The latter has the added benefit of we don’t have to do more work (beyond setting it up).