header title imageheader spacer image

Inside This Issue

    VCS Practice Expertise
    Cerner

  • HNA Classic™
  • HNA Millennium
  • Project Management
  • Integration
  • Vitalize Logic Library

 

Cerner Practice Newsletter
Volume 3 Issue 1, Page 3

HOUSTON, WE HAVE A CERNER PRINTING PROBLEM
By Gus Lowry


I have a folder called “Re-sends” that contains e-mail of subjects that come up over and over again. Cerner® printing is just one of those subjects, I hear about on a regular basis. Order requisitions printing in the cafeteria or not at all, face sheets pulling from the sheet label drawer, pharmacy fill lists rolling out label at a time for hours, and the ever popular – “it prints now, now it doesn't, it prints now”. While not to be construed as a comprehensive checklist, the list below contains some of the topics often not reviewed until just prior to conversion. A good migration plan to Microsoft® 2003 printserver takes weeks and the budget for printers can only flex so far without good capacity planning. DNS naming standards in themselves often take several weeks (or months!) to update and longer to alias in the network without affecting legacy applications. It is unfortunately often discovered or reviewed at the end of the project, when the clinicians discover that it is impossible to find their printer in the drop down bar. The resulting database work to incorporate new naming conventions can push conversion by several weeks. So…start early, create a naming committee that includes members of the applications team, conduct a good inventory, remember to test everything together or at least in components prior to conversion, plan for support issues, and always remember that printing needs to be reviewed prior to go live.

Cerner printing can be broken down into different categories from the technical perspective: back-end stream printing from a VMS/AIX host, front-end MS printing from Citrix® or a desktop, and chartserver printing (a pc for formatting jobs using a word template). Cerner printing also has an application component which is also closely related to and based upon the database build of the product. For example:

  • PM Documents
  • Face sheets
  • Labels
  • Wristbands
  • Consent Forms
  • Order requisitions
  • Order sheets
  • Order labels
  • Dietary labels
  • Pharmacy labels
  • Collection labels
  • Clinical Reporting (Charting) Distributions batch runs (OPS job specifies printers)

Start early with the tasks that take the most time to change, focus on building a good technology layer ahead of the implementation:

  • Establish DNS naming standards for desktops, printers, and servers. The printer names affect the order of the printer listings in Cerner’s database building tools and end user applications and can cause confusion for the users.
  • Implement device control libraries or forms to make printing from the different systems compatible in format. (i.e) the original face sheet or the reprint should look similar regardless which system generates the output.
  • Ensure that your Citrix server farm is upgraded to Presentation server 4.0 or higher to take advantage of the universal print driver.
  • Wireless devices and printers have separate printing issues which must be accounted for outside of the clinical information system that pulls them into the network.

Upgrade your printserver now. Remember that a 2003 printserver is 10-40% faster and will allow you to better manage charting jobs. The Cerner application database will have the printer/printserver name and will require database re-work if the printserver is implemented after the build is complete.
Review the database build using a spreadsheet or an Access database to check all of the printers are entered correctly prior to testing in the field.

Review the types of labels and the anticipated volumes for each printer to confirm printer suitability and capacity. It is common for the application design to change as the builders become more familiar with the applications. The parameters used for originally specifying the printer may no longer be accurate.
Create floor maps with the printers marked on them. This can be used to validate workflow assumptions with the clinicians and will avoid post-conversion printer emergencies.
Review the network capacity for bottlenecks, and remember the additional ports needed for the print devices. Ensure that the volume test includes representative printing, if possible.
Conduct a training session with the Inventory team or Desktop team that will manage and support Cerner printing.
Train your support teams on hp web jet admin and other remote support tools
It is essential that a device inventory is conducted. Each printer should be clearly identified and labeled. Color can be used as an easy device to indicate last year / date inventoried. All required identifiers should be large and clearly
identified. During this inventory, staff should:

  • label the printer
  • check on anti-virus
  • fix the push client
  • create the printer map for applications
  • correct the printer/device name (if necessary)
  • add the PC to wtslocation
  • Test that the PC is correctly entered by using the Millennium Application (ie PowerChart®)Performing a test print from the backend that will include a sample chart form, sample ccl print job or label)

The capacity of the printers also needs to be reviewed. Focus on the capacity of dot matrix or batch printers switched to zebra printers. For example:
Pharmacy fill labels and Pharmacy satellite printers.
Face sheet reprints (where multiple stocks are used, ensure that the right stock is pulling for the right forms)
Preference for left to right printers for sheet labels, anything that pulls labels and bends it will eventually fail on any brand of label stock (i.e. 8250’s for high volume sheet labels)

After inventory, it is key to ensure that printing costs are controlled and support is ready for conversion. This is the time to make sure that equal support is available for bar code printers and to stabilize your support contracts. Evaluate the costs of a printer pool vs. the same day service for printers, direct connect jet directs for bar code printers or swappable connections for laserjets can make this a simple operation. Make sure that checklists are ready for upgrading, removing, and adding a printer as it usually takes several people to add/remove a printer from a mixed clinical application environment. Ensure that you have adequate spare printers for device swaps. Critical printers (ie pharmacy fill labels) must have an immediate backup plan. Ensure that sufficient supplies of label stock are on hand and backup supplies available on short notice. Remember that you will need plenty of stock for testing activities prior to conversion as well.

Printer troubleshooting classes should be given to help desk personnel, and flow diagrams should be created to facilitate support. Help desk resolution codes are should be specific enough to identify whether a point was resolved by training, application, or hardware change. Resolution codes are essential in creating a stable print environment as they allow you to track and potentially eliminate recurring problem areas. Sites with help desk systems unable handle resolution codes or unable to track multiple Cerner domains and issues should consider upgrading the software ahead of implementation. Finally, it is a good idea to keep troubleshooting in mind when designing forms. Routing criteria (ie patient location, ordering location, chart distribution) should be printed on the form wherever possible. This greatly simplifies troubleshooting when trying to determine what is printing where. Create a simple label, chart form, and postscript form that will always qualify whenever called (no ccl coding exclusions) and that will include the basic print criteria used. Be sure to test the performance of items with graphics included: some postscript graphics can take extra time to print due to the inclusion of high resolution images into the print jobs. A rom attachment may be required for the printer.