Notifications
Clear all
General Discussion
7
Posts
4
Users
0
Reactions
88
Views
Topic starter
Our providers have noticed that their DEA# is sometimes missing when printing their scheduled drug prescriptions, as these cannot be sent electronically in our state. They have confirmed they are set to the correct state when filling and printing scheduled drugs, so are using the correct Rx report form.The DEA# is not included when printing a regular med that needs to be faxed to a non-electronic pharmacy.
I'm wondering if the scheduled meds where the DEA# is missing is because Centricity is not recognizing the med as scheduled, for example Tramodol and Protonics.
Can anyone confirm if the DEA# printing on scheduled meds but not regular meds is the expected function of the prescription form? And the missing DEA# on some meds is due to Centricity is not recognizing the meds in these instances as being scheduled?
Thanks
Posted : September 10, 2014 3:28 am
Looking in a few of the prescription reports, I see the following formula called auth_DEA:
if not IsNull({USRINFO.DEANUMBER})
and {USRINFO.DEANUMBER} <> ""
and ({MEDINFO.classcode}<> "")
then
" DEA:" & {USRINFO.DEANUMBER};
Assuming the provider has a DEA number, the first two lines are insignificant. The third is the one to look at, I believe. I would look up the med in the MEDINFO table and see what the classcode field is set to. If it's empty, that DEA isn't going to display because the report doesn't think it's scheduled. That seems like the most likely scenario to explain what your docs are seeing.
If you wanted to cut to the chase and make the number appear on all prescriptions, you could comment that line out by putting a // before it.
Posted : September 10, 2014 4:53 am
Has anyone ever changed these values in the database? Seems simple enough to set the classcode to what it's supposed to be, but I don't want to run into problems with the next knowledgebase or something like that.
We were told Tramadol would be updated in the August KB update. It was not. So we're having the same trouble. Seems funny the GE's kb updates for <month> come out at the very end of that month. It's almost as if they are a month behind compared to what Medispan has provided.
Posted : September 10, 2014 1:07 pm
Unfortunately I haven't a clue what the effect of changing those values would be, or whether they'd stick.
Posted : September 10, 2014 9:42 pm
We had this issue and GE's response was they only coded the Rx Crystal Reports to Federal Law and not state as far as scheduled drugs were concerned. You could always remove that third test line about the classcode and just have the DEA number print on every Rx, if that wouldn't upset the pharmacies.
Posted : September 11, 2014 2:20 am
Yea, there was a recent change to the classification of Tramadol (and probably a few others too). That's why this is coming up as an issue for a lot of people. I would think a KB update would fix it, but it wasn't included in the August KB. I think we're more so trying to come up with a way to fix it in the short term rather than wait for the update.
Posted : September 11, 2014 2:23 am
Topic starter
Thank you for the good advise and conversation around this. I'll mention this to our Medical Director and CEO and see if they would be ok with having the DEA on all scripts, and then see if this has any effect on electronic scripts.
Posted : September 11, 2014 5:27 am
