Hi All,
Has anyone tried to figure out where the CQR is obtaining the entering user of a Lab or Rad order from? The Orders table only seems to reflected the signing user and the authorizing user (pubuser and usrid seem to just be the signing user, authorizing user is it's own field). Additionally in both the DOCCONTB and the Audit tables only record the action as "Contributed to Document" not what was actually done. I've been trying to reproduce the CQR results and it is driving me up a wall... I want to be able to target when an order isn't meeting MU but it "looks" like it should - IE a non-credentialed user entered(selected) it but a credentialed user signed it - right now we just have a roundabout approach of:
"Non Credentialed user contributed to the document, that must be it"
which is of course not a very satisfactory explanation.
Thanks
Mike
The DOCCONTB table has this information.Link DOCCONTB.USRID to USRINFO.PVID (or USR.PVID if it is not in a crystal report)
CONTB_ACTION = 12,
DATA_DESC = 'Ord'
NEW_VAL = 'Order: '
Hi RWilliams -
When I pulled those two fields they returned Null for me. I linked Order to DOCCONTB via the SDID and those fields are blank. In fact I didn't see any Contb_Actions of 12. I then just opened up the report to our whole database and tried to pull any activity of 12 - I only return Obs type Data_Desc. Is there any chance that these fields are no longer used? Have you successfully used them? Or am I just way off in how I am try to link it back to the order itself?
Thanks
Mike
My apologies, I had it slightly wrong before.
There are definitely items in our DOCCONTB with CONTB_ACTION as 12. The NEW_VAL does not have the word "Order" in front of it as I originally thought, it has just the order name. The way you can tell it is an order is based on the DATA_DESC being "Ord".
Here is a query I used:
select PERSON.SEARCHNAME, DOCTYPES.ABBR, DOCUMENT.SUMMARY, ml.convert_id_to_date(DOCUMENT.CLINICALDATE) CLNDATE, DOCCONTB.DATA_DESC, DOCCONTB.NEW_VAL, USRINFO.SEARCHNAME from DOCUMENT
INNER JOIN DOCTYPES on DOCUMENT.DOCTYPE = DOCTYPES.DTID
INNER JOIN PERSON on DOCUMENT.PID = PERSON.PID
INNER JOIN DOCCONTB on (DOCUMENT.SDID = DOCCONTB.SDID and DOCCONTB.CONTB_ACTION= 12)
INNER JOIN USRINFO on DOCCONTB.USRID = USRINFO.PVID
where PERSON.EXTERNALID = '335544-1-IMA'
and DOCTYPES.ABBR Like 'Ofc Visit'
and DOCCONTB.DATA_DESC Like 'Ord'
and DOCUMENT.CLINICALDATE > ml.convert_date_to_id(to_date('01/01/2014','mm/dd/yyyy'))
ORDER BY CLNDATE DESC
You will need to replace the PERSON.EXTERNALID with some identifying information in your DB to limit your results. You will also potentially need to change the date or document type you are looking for. (or remove the criteria all together)
You also have the field DOCCONTB.USERNAME which is the actual name of the user who contributed to it so you do not need to link to the USR table if you just need a name. Even if the users name changes, the name will not change in the USERNAME field.
Hi RWilliams,
I appreciate the help but unfortunately it looks like my DB is returning NULL in those fields (for the most part). I ended up just running a report that only looked at the DOCCONTB table and when I filtered it to CONT_ACTION = 12 I only returned about 15 values (and they were all Obs type from the same date in 2010 for some reason) - something I did not expect. I have opened a ticket with GE, hopefully they can provide some insight (I'll update if they get back to me in case anyone else wants to know/has a similar issue).
Thanks again for taking the time to help out and help me confirm what I was seeing.
Mike
That is strange. What version and service pack are you on and are you on EMR or CPS?
I do not remember seeing the data when I first started writing reports using DOCCONTB so the data may not have always been there, it could have been part of an upgrade/update. If I right click on a document and "View contributors List" I can see the users that added OBS and Order info which is where I found out how to query on it.
We are on 9.8.6 - what version are you on? That looks like CEMR to me, right? I wish we had that, it would make what we are trying to do so much easier... all we see in the contributors list is "Contributed to document" which we can infer is adding the order but is not a real audit trail to prove to the "innocent" what they did...
We are on CEMR 9.8.7_5. I will see if I can locate the release notes for this version to see if it was added since 9.8.6.
I just thought about it and this release was created to fix a bunch of issues with CQR reporting we were having. Upgrading to this release, we had to run a SQL procedure that inserted a bunch of data into the database and it took around 12 hours to run. Perhaps it was this data that it was adding into the system. When our CQR people get back to their desk I will ask them about it.
Thank you, I appreciate the help very much! I would not be surprised if we had something missing from our update...
I was wrong, the SQL script that ran all night was not part of the 9.8.7 update, it was a separate script that we received from the CQM people. This script went through the database and added rows to the system so that CQM worked properly. There is a good possibility that this is why there is a difference.
Thanks for the help rwilliams - hopefully GE will get back to my ticket and let me know if this is the case or not (and how we fix it). I will post the solution if/when I hear back.
Mike
Ok, so I finally found the release notes for 9.8.7 and that looks like it has what you are looking for.
The system now counts CPOE for the licensed/credentialed user who entered the lab
or radiology order or prescription/refill. That person can be the Eligible Professional or
a licensed/credentialed staff person. Previously, it counted CPOE only for the user who
signed the document.
Interesting. We decided to take the CQR patch (that was supposed to be the CQR related piece of the 9.8.7 update) instead of the full update to save on downtimes (we have a large enterprise system, downtimes are no bueno and we try to limit them) but maybe that was not a part of the CQR fix.
The other interesting piece, at least to me, is that somehow the CQR is calculating correctly without that table - I still haven't heard back from GE but I will be sure to update when I do.
Thanks again for all the help, it is very much appreciated! Trying to deconstruct the CQR is the greatest and worst puzzle I've ever undertaken...
Mike
Hi All,
As a bit of an update there is a stored procedure GE uses to determine the entering user of a RAD/LAB order for the CPOE measure - it is effectively the same code that RWilliams has above (well done by the way!) but unfortunately it is still returning blank for us and I am even more convinced it is because we are on 9.8.6. We are upgrading our Test system shortly to 9.8.10 and the first thing I want to test is this, I will post if that is the solution (getting above 9.8.6).
Thanks
Mike