Notifications
Clear all
General Discussion
13
Posts
5
Users
0
Reactions
148
Views
Topic starter
Hello guys,
I have been seeing an irregular issue where a user's Prescription printer selection changes on its own. Our setup is all users access CPS through a Remote Desktop (RDS) farm. The other printers stay set pretty well but every now and then the prescription printer changes. I have made sure that my "UseClientName" is set to true in the emr.ini files for each server. Is something changing this printer (Service Provider, etc) or is this a bug within CPS? Anyone else experienced this?
Just for a little setup info...
Any clinical (reception, nurse, prescription) printer is installed locally onto each RDP server using the same naming convention and the clinical staff prints to them from that. Business and support staff all use a product called TSPrint (similar to ScrewDrivers) to print from the RDP session to their local printer at their desk. Centricity manages its printer selections per-computer in the "Printers" table from what i can tell. Naming the printers the same on each server allows the employees to be placed on an any server in the farm and still have the correct printer settings for their workstation.
Posted : March 27, 2017 6:25 am
We have a similar problem. Sometimes it works, sometimes it doesn't. Sometimes it prints to our label printer and prints through nearly the entire ribbon of labels before it gets noticed... I'm in for a solution as well.
Posted : March 27, 2017 6:32 am
I don't know which printers and/or drivers you are using but if you want to do some troubleshooting you can try to use the built in print drivers from Windows, like the HP5 driver. Those drivers work with any PCL enabled hardware even from other manufacturers like Canon, Lexmark, Kyocera... I used HP4 for many years then graduated to HP5 when I started setting things up with multiple trays. I do make sure that every pritner I buy has PCL capability though.
It seems like those drivers will give you the least amount of headaches in a TS/Citrix environment. I learned that the hard way after some really weird CPS problems.
Mike
Posted : March 27, 2017 7:55 am
Keeping in mind that Centricity settings are for the workstation, not the user...
We also ran into a lot of problems getting printing to work well. Sometimes Centricity gets confused - at which case it just prints to the default printer in the environment. This was exacerbated by our providers who will "steal" the RDS session from one workstation to another. An additional problem is that 2008 R2 terminal services will not reliably set the default printer so that it is the same every time the user logs in.
We purchased Printer Logic which will force the default printer to be something useful - instead of the label printer (been there, done that).
Fortunately in Vermont we are able to use the microprinting feature of CPS so it is not necessary for us to use specific prescription paper. If we were unable to print prescriptions to any printer that would greatly complicate the issue. We do have scripts to set all the workstation printers at a site to the same settings, but this would still be occasionally ignored by Centricity.
Steve
Posted : March 27, 2017 8:03 am
Topic starter
You are 100% correct on printers being stored by Workstation, and the odd thing is I've only had two or three (out of 40) providers complain about the printer changing itself.
The way i got around the default printer deal was to run a batch file that sets the default printer to a dummy printer on user login using group policy. Without that, since users were not checking their printer settings, people were randomly printing all over the place depending on where their default printer was randomly set to.
When you mention a script to set the printers for a certain location, do you mean in SQL?
Posted : March 28, 2017 3:00 am
Topic starter
All of our printers are PCL compatible, but unless i am msising something you are saying, that's not our issue. The printers print just fine, but Centricity sometimes "forgets" what printer a said workstation is set to print prescriptions to. For example, the workstation could be set to print scripts to "Pediatrics Prescription Printer" and randomly when you go print , it will be changed to "Family Practice Nurses".
Posted : March 28, 2017 3:03 am
Topic starter
Are you running a similar environment?
Posted : March 28, 2017 3:04 am
Yes, just SQL scripts to update the database.
Steve
Posted : March 28, 2017 3:59 am
Topic starter
Nice, just out of curiosity, how are you identifying the location? By address or computer name or are you using a trigger within SQL?
Posted : March 28, 2017 5:04 am
Our inventory shows us what client is in what site and which floor. It is a little more complicated as we have one site with long floors, so we also know what side of the building. Then we just force the printers to the ones close.
Steve
Posted : March 28, 2017 5:27 am
Topic starter
Interesting, must be a very complicated script. Using host_name()?
Posted : March 28, 2017 5:53 am
We are experiencing a similar issue in a similar environment. We have a 4 server RDS farm that users connect to from a virtual desktop. After speaking with Centricity they recommended turning off "UseClientName" in the emr.ini file. Apparently doing so causes the printers to be stored using TCP Session #. They seemed to be aware that this is a problem when users end up taking over another user's session. Our providers seem to be noticing it most when working with patient information. Has anyone found a good solution for this?
Posted : June 1, 2017 8:55 am
Topic starter
From my experience, turning off the UseClientName worked worse since the session # changes everytime you login. To get around the "stolen session" deal we just enabled the setting that allows each login to have multiple sessions. That seems to work pretty well for us except that once in a while occasion when a printer will "change itself". That being said, it also requires more resources on the rds server too since each user in our environment can have 4-5 sessions open at a time.
Posted : June 2, 2017 5:26 am
