Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

Prescription printer selections...

General Discussion

Last Post by Clay Guthrie 7 years ago

13 Posts

5 Users

0 Reactions

114 Views

RSS

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

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

Scott Forest

(@sforest)

Posts: 527

Honorable Member

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

tnc

(@tnc)

Posts: 517

Honorable Member

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

swestfisher

(@swestfisher)

Posts: 132

Estimable Member

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

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

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

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

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

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

Topic starter

Are you running a similar environment?

Posted : March 28, 2017 3:04 am

swestfisher

(@swestfisher)

Posts: 132

Estimable Member

Yes, just SQL scripts to update the database.

Steve

Posted : March 28, 2017 3:59 am

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

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

swestfisher

(@swestfisher)

Posts: 132

Estimable Member

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

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

Topic starter

Interesting, must be a very complicated script. Using host_name()?

Posted : March 28, 2017 5:53 am

cgalati

(@cgalati)

Posts: 1

New Member

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

Clay Guthrie

(@clayguthrie)

Posts: 22

Eminent Member

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

24 Forums
9,942 Topics
39.9 K Posts
10 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed