Notifications
Clear all
General Discussion
12
Posts
5
Users
0
Reactions
108
Views
Topic starter
Hi all,
As the year gets into full swing and we all try to use the CQR I was thinking it may be beneficial to have one running thread of quirks and oddities people encounter with the CQR data itself. I think things that are truly bugs could be left to separate/independent threads but we've noticed some strange behavior that I think everyone should know, and I am sure others have found the same. Hopefully we can gather this all in one place and have a defacto CQR knowledge base since there isn't much on the GE service portal.
1. We have large denominators for encounter specific measures. Working backwards from the denominator exports from the CQR we determined that any office visit, office procedure or home care visit a provider contributes to (in anyway) is being counted. This is an issue for us as one of our providers appears to have had 550 visits since the 1st of January - this is because this provider is a PCP of many elderly patients and he signs their home care notes and other documents that come into the system indicating he reviewed them - this is showing as a unique encounter under his user. We've found any of the activity in the doccontb table - including appending, changing properties (dates) and additional signatures. The documentation kept the vague terminology "Seen by" - apparently signing off on a home care or specialist note is the same as seeing a patient in the office.
This also means when a PCP second signs an NPs office visit that office visit now counts for the EP. This is a long time workflow to indicate that information is being reviewed by the supervising MD.
2. CPOE. Samples are showing on the CQR in the denominator (and numerator as well). The documentation does not say samples should count. We ran a CPOE crystal report with no filters on medication entry type and it matched up exactly with the CQR CSV export - that provider had multiple samples.
3. Demographics: The documentation on how it is supposed to work specifically says that Patient Declined is an acceptable entry for demographics. In our testing we found it was not. On a round table we asked what was happening and were told it actually was not acceptable. We moved on with the CQR to Live because, quite frankly, we could only delay so long. The hope is the cause of this and/or fix will be known and since demographics is a unique patient field we'll just repush all the data once it is fixed at some point in the year.
This leads me to a major concern: GE seems to have some bad documentation on how this all works (and may not truly know themselves) and we are trying to train workflows that will pass (reminds me of training students to take tests not to learn but I digress...) - who is to say GE won't notice an error in their calculation in June or July, change the data extraction and flip our numbers on their head?
That's enough for me today, hopefully this thread lives on for a little while about potential pitfalls/things to watch out for that grows as the community learns more about the CQR but if not at least I got to vent!
Thanks,
Mike
Posted : February 10, 2015 7:59 am
We need to be provided with the algorithms that GE is using. Unless we understand what is happening on their end, we are totally in the dark in attempting to correct problems with CQR data submission. If we fail in CQR data submission, the penalties are non-trivial. If problems are to be corrected, GE needs the participation of the CHUG community.
Posted : February 10, 2015 8:12 am
Topic starter
I wholeheartedly agree and was very sad to see in the CQR Algorithms thread that GE basically rejected the request of another user. I will have our organization push for this as well.
Posted : February 10, 2015 8:21 am
Can I throw a log on your fire?
In item #3 above, are you talking about Patient Declined for Ethnicity? If so, you need to make sure that EMR/CPS database spelling and case is exactly what CQR is looking for.
Specifically, CQR is looking for "Patient Declined" versus "PATIENT DECLINED". It took us a long time working with GE to get this resolved. Once fixed, our compliance for Patient Demographics shot up.
As a default, when installing CPS12, the value in the database was created as "PATIENT DECLINED". We had to manually change this and other Ethnicities to reflect this upper/lower case.
Posted : February 10, 2015 9:57 am
Topic starter
Hi Jim,
Fortunately (or unfortunately? At least we'd know...) we are seeing Patient Declined spelled properly with the proper mixed case for all three (language, race, ethnicity). We did have a GE rep reach out to us and schedule a meeting for tomorrow related to this, I will post when (and if) we get to the bottom of the issue.
Thanks,
Mike
Posted : February 11, 2015 8:22 am
Topic starter
As an update - the GE rep who reached out gave us a sql statement that can remove non-factory languages from our database (since the 9.8 database for language is populated by any free text languages ever put into the system - on a side note 3 patients speak "baby talk"). However this sql statement will only work once the languages are removed from the patient - we have 1.2 million rows in our person table so this will not work.
I am going to pull a crystal report of all of our "custom" languages and we'll have to create a sql cross walk that will map them all to appropriate languages if the matches are clear (engrish to english, for example) - I cannot think of another solution.
Thanks,
Mike
Posted : February 17, 2015 8:46 am
Hi Mike,
I am about to start a meeting but will go back to read through all of this in a bit. Here is one issue we have found. I am not in a technical role, so I'm copying this directly from an email from one of our analysts regarding an issue we found with med rec data in CQR:
"I have been working with GE on this and there is an error in the documentation that will be corrected sometime this month in the definition for “Seen By”. CQR continues to use some of the same attribution methodology that was used on the old MQIC site. Currently patients are linked to physicians by the physician signing a document that indicates an encounter regardless of whether or not the physician saw the patient or not. So for example if a patient saw Dr. A. during the reporting period and Dr. A. routed the document to Dr. B. or it was sent to her via cc: and she signed the document (not append but co-signed), she would be linked to that patient as would Dr. A.
A number of clinics have requested that the link only count the physician who is the responsible provider for the document. SPR62252 is addressing this request.
For now, until the SPR is addressed, patients do not have to see the physician to be linked for CQR reporting."
Again, I did not get a chance yet to read through this thread. So, it may have already been mentioned.
Thanks,
Paula
Posted : May 29, 2015 4:04 am
Topic starter
Just adding a few other things we have noticed:
1. Patient education: For some reason all of our providers are doing quite well at this measure even though, candidly, they have all admitted they don't use the truven button and have stopped the hated workflow of printing the prescription information sheet. What we ended up determining is that if the prescription print out was ever printed for the patient - even 4 or 5 years ago - that patient counts as receiving patient education.
While CMS does not expressly state that education has to be given during the reporting period we feel going back that far is somewhat against the spirit of the rule. What I am wondering is if the CQR does use some form of "back in time" evaluation but only evaluates the MUACtivityLog time-stamp, not the actual time it was printed. The reason I wonder this is that the MUactivitylog time-stamp for "old" actions is set as the day/time we upgraded to 9.8 (there were apparently a ton of prescription handouts printed at 2 am that morning).
2. eRX: The CQR does not evaluate if the user who entered the electronic prescription was credentialed. CMS doesn't expressly state they need to be but based on the wording of the CPOE measures we feel that is against the spirit of the measure.
3. TOC: Sending the Summary of Care through the patient portal does not count as giving the SOC to the patient (the 50% part). We are less concerned about this as we are kind of all in on the proposed rule change but still, c'mon.
4. The message Kryptic generates back to the EMR indicating a patient has consented to using the portal counts as a message to every single provider that saw that patient during the reporting period. Again, CMS proposed rule sort of eliminates this but still concerning - that is an easy fix (tie in the receiving providers home location).
5. Portal Access: Having Declined in "PATPORTALPIN" counts as access when it should not.
Some of these are beneficial, others our own fault due to workflow yet we are concerned nonetheless - to comply with the CQR reporting method we would have to drastically change workflow across the board - and in some cases abandon workflow all together.
One of our biggest concerns was in my first post and reiterated by Paula above: the GE crystal reports used responsible provider of the document for all of stage 1 - the change to "any activity" is a huge disruption and should have been highlighted and communicated a year ago.
All of this and I didn't even mentioned the random missing data, not being able to reset CQR PWs (even as the admin), lack of a good enterprise dashboard, no ability to have tiered access (ex. grant an office manager access to all their providers but not all practices), the confusing and complicated data ingestion auditing etc...
And don't get me started on the lack of technical documentation. At least with the crystal reports we could open them up and see the logic/how the data was being evaluated - with the CQR we are effectively limited to guess and check (24 hrs later).
Thanks
Mike
Posted : May 29, 2015 7:55 am
Large Denominators: We are experiencing this issue too, although it isn't too extreme (340 vs. 362). In this particular provider's case, she is the Responsible Provider for documents for 340 unique patients, but has signed documents for 362 unique patients. This continues the CQR theme that we have seen where signing an Office Visit (primary or secondary) counts the patient in the provider's population.
Demographics: The MD I'm looking at right now has not had any patient with "Patient Declined", so I can't speak to that. We did miss a few patients due to the Ethnicity value of "Other or Undetermined". Luckily for us, it looks like our patients are providing this info. If it is a case-sensitivity issue as described above (Patient Declined vs. PATIENT DECLINED), that's pretty bad on the GE side.
Patient Education: I envy your awesome Educational Numbers; ours are bad because our providers would rather not provide what they consider to be inferior educational materials to patients. I'm working on a solution where they can print our own educational material and still get credit using the MEL function ADD_MUACTIVITY_LOG.
Portal Access: We are getting credit for DECLINED as well.
Posted : June 1, 2015 10:13 am
Hi Craig,
See this answer from our MIS lead on our workaround for patient education:
http://centricityusers.com/forum/carenotes-handout-print-from-vfe-action-button/
We have added multiple handouts from ExitCare, AAP, ACOG, etc. (will rarely utilize Truven content). Not sure how many forms you have or how many different forms for diffferent providers.
Unfortunately, we have quite a few, and this will be a huge undertaking, but we are hoping it will pay off. Our providers would never have adhered to the GE prescribed workflow and subpar content to meet MU, at least not in time to attest this year. So, this was our only forseeable option.
Posted : June 1, 2015 11:18 am
Hi Paula,
Thanks for the info! GE recently told us about the ADD_MUACTIVITY_LOG function and we plan to start using it soon.
Posted : June 2, 2015 2:41 am
Topic starter
Thanks for the info - it's nice (I guess?) that the strange logic is across the board on both platforms, maybe they will be more likely to fix it - or at least publish the technical specs. A man can dream, can't he?
Mike
Posted : June 2, 2015 3:47 am
