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

Printing issues in CPS10

Trading Post

Last Post by Anonymous 1 second ago

8 Posts

4 Users

0 Reactions

71 Views

RSS

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

Topic starter

I have an interesting scenario and I'm curious if anyone else is in a similar boat.

I have printers (Ricoh SP4100) with three trays installed. I like them alot. They are efficient and have always served us well.

Since going live on EMR in CPS 10 (have been live in PM for over a year), I've learned that CPS may be the worst software on the planet in regards to print job creation.

I have a Windows 2008 print server where I have created a printer for each tray on the printer. Tray 1 is superbills. Tray 2 is white paper. Tray 3 is Rx paper. For instance, Bldg1-Pedi-SB, Bldg1-Pedi-BW, Bldg1-Pedi-RX.

Then in the options for each printer, I have forced each to their specific tray. Our old emr, windows, and other applications use this perfectly fine. They print exactly as you would expect. If choose Bldg1-Pedi-BW as my printer, my job is rendered onto white paper from the 2nd tray, easy peasy.

But in centricity, it depends on where you print from. For instance, if I print an RX, as long as the printer was selected in the Printing Options, it prints from tray 3, no problem. But if I use the print dialog box from the chart, say to print a chart summary or document, the job always goes to tray 1 no matter what.

Superbills print fine from the Schedule module, but that's because they are in tray 1. The schedule module doesn't behave any better than the chart module does.

I've played with different drivers, printer settings, etc. It's maddening. And this behaves the same from a fat or thin client. These issues are not citrix related.

Does anyone print to discrete trays in CPS10 from the print dialog box like I'm describing? If so, what are your printers and what driver do you use?

Thanks.

Posted : May 9, 2012 3:03 am

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

Topic starter

I meant to add that I've spoken to GE and they've admitted to having terrible printing from CPS. The tech told me that the CPS does not specify page size in the print job, but I can't see why that would matter much. My Ricoh rep believes that it may throw all other details of a print job 'out the window' if it sees a job without page size specified, but I'm not going to replace any of printers until I've confirmed this issue is specific to my Ricohs.

The other suggestion my rep gave was to just buy a bunch more printers for each type of paper source I need. Yeah right! (that'd be like 25 extra printers laying around everywhere).

Posted : May 9, 2012 3:08 am

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

You've been having these issues the whole time? Even while you were using just the PM side? We ran into printing issues once we upgraded from PM04 to CPS 9.0. The problems continued after upgrading to CPS 10. We do not use the EMR, so your problem could be different.

Like you, we set up multiple printers on our server for printing to specific trays, duplexing, hole punching, etc. The user just had to choose the correct printer based on what they were printing. Worked flawlessly in PM04. After upgrading, printing pretty much broke except on a couple of computers, mine included. After looking at why my computer was printing fine while others wouldn't I noticed that my default printer was different than the other users. What appeared to be happening in our case was, if the default printer used the same driver as the selected printer, the print job would use the default printer settings instead of the selected printer settings. If the driver was different, then the selected printer settings would work fine. We created a workaround by installing an HP LaserJet 2100 on our print server that did not exist, and set it to be the default printer for all users.

Now, this worked with 32-bit drivers only. 64-bit drivers seemed to have a completely different issue. Print jobs to a printer using 64-bit drivers resulted in the print job ONLY being sent to the default printer regardless of what printer was selected. So, if the default printer was located in another building, and the user chose to print to the printer next to their desk, the print job would be sent to the printer in the other building. Extremely frustrating.

This appears to be related to the newer version of Crystal that's embedded in the program. Reports had to be edited because margins got screwed up after upgrading. Patient letters never had the problem since they use Word.

Posted : May 9, 2012 3:49 am

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

Topic starter

We went live on PM last year on version 9.5. But it just happened that from PM, we never tried to print to these printers. The only group who uses these three tray, multipaper setups are our clinical teams.

PM was used by reception, admin, and billing staff only. In these scenarios, they are always printing to printers with regular paper as the only paper type. So I believe it was 'just as broken' the whole time but it was never a problem because we didn't have crazy paper requirements in PM. (except for printing to our custom pre-printed superbills, but again, those have always been in the top tray, so the issue never presented itself).

It's interesting to hear about your issues. Thank you so much for sharing.

I'm not sure about the default printer/print driver scenario you spoke about in 32 bit (I'll have to think on that some more), but I know that I've printed to a printer that is not the default printer for the workstation in 64bit and the job arrives at the correct printer just fine, just not the right tray in that printer, as specified by the driver.

It is however VERY interesting to hear that these issues arrived at version 9. I was confounded by the idea that GE, as large a company as they are, with as many customers as they have, could have an entirely broken print subsystem. Knowing that it's only been broken in the later versions at least helps explain a bit, although sadly it doesn't get me any closer to a resolution of my problem.

Thank you so much for sharing and I'll take a second look at my environment and see if your findings have any correlation with the problems I'm having.

Posted : May 9, 2012 4:37 am

tnc

(@tnc)

Posts: 517

Honorable Member

Oddly enough I have done printing the same way in EMR 5.6/PM04,EMR2005/PM04,CPS9.0.1,CPS9.5,and now CPS 10 and it has always worked despite the myriad of CPS 10 related issues. I set up printers based on which tray they are supposed to print to. I use TCP/IP based printing with no print queues. The only down side is I have to be involved to add new printers but my users never did them themselves anyway. They are instructed to learn how to pick the paper trays for the printers labeled as "HCFA", "Prescription", or "plain paper" though but it always works.

Not sure if this is the reason for the minimal printing problems I have had or not but it may be worth a try.

Mike Zavolas

Tallahassee Neurological Clinic

Posted : June 5, 2012 3:15 am

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

We have the printing problem with multiple trays too. HP P3005 printers with the manual feed tray and 2 other trays. Certain areas of CPS conform to the tray selections (superbill, patient profile when printed from the schedule), but anything printed from the reports module totally disregards the tray selection. Spent hours trying to resolve it, but in the end, I couldn't figure out what else I could do with it. The proper tray was showing up in the properties for the printer, but CPS simply didn't process the job to the correct tray.

Posted : August 8, 2012 1:00 am

Anonymous

(@Anonymous)

Posts: 0

New Member Guest

Topic starter

psinc-- this has been my experience as well. While only a small comfort, it's nice to know I'm not alone!

Mike Z-- I'm printing TCP/IP but not without print queues. I'll explore that and see if that helps. May I ask, what printers are you using? Are you dealing with 32 vs 64 bit print drivers? If so, has that ever been a factor in CPS printing for you?

Posted : August 8, 2012 8:14 am

tnc

(@tnc)

Posts: 517

Honorable Member

Mike Z– I'm printing TCP/IP but not without print queues. I'll explore that and see if that helps. May I ask, what printers are you using? Are you dealing with 32 vs 64 bit print drivers? If so, has that ever been a factor in CPS printing for you?

Sorry for the delayed reply....

We know how important PCL drivers are and it took me a while to deviate from the standard HP hardware to Canon multifunction printers. I took a detour with Konica Minolta and that was a bad deal but Canon is working fine for us. Canon makes much, if not all of HP hardware, BTW.

We use Canon 3045 and 1025if hardware with the Canon 64 bit drivers for Windows 7. We are also using Windows XP 32 bit in many places still but are upgrading as I write this. The only complaints I have had is with not using print queues but the crystal generated reports from CPS all seem to work with little or no editing. We did have to do some editing but only to some already customized forms. The GE forms work fine.

If I were to ask GE about my configuration they would say that it is "not supported" since it is not actually HP hardware. Since this hardware is Canon you can get away with using a HP5 driver or something like that and just tell GE that is what the hardware is to get that off the table. I was not able to do that with the Konica Minolta I tried a while back. I have not had to use the HP drivers though as the Canon drivers work great, even the 64 bit drivers.

I did all this to get away from buying/supporting the many HP printers we had to support. We lease the larger Canon machines and bought the 1025s off-lease with low usage and we have service agreements for all of them which takes that off our helpdesk support burden. The per page cost for the leased equipment is much less than what we paid for the HP even with the service agreement and we don't have to troubleshoot/fix them in house (woohoo!).

I will probably go back to queuing at some point, though, so I would not recommend doing away with queues. I would love to use linux queues to save the MS fees 🙂

Mike Zavolas

Tallahassee Neurological Clinic

Posted : August 15, 2012 1:37 am

24 Forums
9,942 Topics
39.9 K Posts
0 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