Printing packets in EBMS - User Overview

Unless and until we come up with a better term, we'll use "board member package" to mean the total of all documents printed for a board member. Package contents include one or more packets for the one or more topics that board member will review.

• Contents of each packet in a package
  
  • Documents associated with the packet
    A board manager can attach zero or more documents to a packet. These are not copies of the journal articles, but other documents created or selected by the board manager. The most common document associated with a packet is a Microsoft Word conversion of the CDR Summary for the topic. The board manager decides whether a Summary should be included, what version of the CDR Summary to include, and whether to include it unmodified or to add notes or make changes.

    In order to print a document the system must have a program that can format that document type for printing, and that program must be capable of being driven by a controller program, without requiring a human to enter print commands from an application.

    It currently looks like we can get software to print PDF, text, and Microsoft Word on either Linux or Windows. If there are other document types that are required, we'll need to know what they are.

  • Journal articles in the packet
    The system will print all of the articles in each packet, including the following for each article:
    • Review response sheet
      These will be generated programmatically, customized for each board member and article.
      • Programmatically generated parts
        
        • Date
          
        • Board member name
          
        • Editorial board name
          
        • Summary topic name
          
        • Journal article identifying info
          
      • Constant part
        The form for recording a response. This will always includes all of the parts that only appear in the electronic version when a board member checks specific boxes.
    • Journal article
      The PDF that we have stored for the article.

We will provide a way to print packages for a single board member without printing packages for all board members. The package will have all of the packets it should contain.

We will provide a way to print a single packet for a single board member, with all of the documents, response sheets, and articles that are normally included in a package.

We will NOT provide any special software for printing single documents. That can be done from a workstation in the normal way that a document is called up and then printed from whatever application opens that document.

It was decided in our meetings that the EBMS will not have any special capability for printing cover letters to accompany packages as a whole or to accompany individual packets.

Some board managers distribute Level of Evidence statements on colored paper, one statement with each package. It would be nice ("WBN") to have this capability, but we decided at a recent CDR status meeting that this isn't required. For now, Bonnie can print a batch of these and manually include one in each package she sends out.

It will still be possible for a board manager to include any document she likes, so long as it is in a supported format, in a packet. So if there is some case that requires a cover letter, that can be associated with the packet using the EBMS facility for that purpose, and it will be printed with the packet.

We won't be printing for everyone, only for those board members who prefer printed packets over electronic access to the documents. Board members who always want printouts should have an indication set in a profile record. These should probably be entirely under the control of the OCE staff since 1) Board members who don't want to interact with the system online won't be able to change their preferences, and 2) Board members who make a mistake online might stop seeing the articles they need.

We will provide a way to print individual packages and packets (see the section on the User Interface below), so it should not be necessary to have any special mechanism for overriding the stored preference in the profile.

The user printing preference records should have the following information:

• Board member ID
  
• Printing start date
  When a board member is registered to receive print packages, he must be given a "print start date". This date will not be the date that printing starts for him, but the date, before which, packets should not be printed.

  This is really only important for a board member who was not registered for printing in the past but wants to change his preference to start receiving printouts. He may be associated with many packets going back months or years that have never been printed for him.

  When we bring up the system, each board member who wishes from the beginning to receive printouts can be assigned a print start date of the first day that the new system is live. That will prevent any old packets converted from the legacy system from being reprinted.

  New board members just joining the PDQ boards and prefering printouts can have their start date set to the date they joined the boards.

  After that, if any board member who previously interacted electronically switches to printouts, the board manager should consider what date to use to start that board member's packet printing, probably in consultation with the board member. For example, there could be a user who was not initially registered for printing who went for several months and rarely or never logged on to read his packets. He might want to have his start date set back to the beginning to get printouts of all of his packets.

• Printing stop date?
  This is potentially useful if we want to keep a record of when board members received printouts in cases where a member received printouts and then changed to electronic.

  We might not care about that information - in which case we don't need this field.

  For most board members, the stop date would be null unless and until they actually decide to stop receiving printouts.

We need to store information about what was printed so that we can find old packages for re-printing if requested, so we won't accidentally print anything twice. A discussion of how to do that is a design issue, beyond the scope of this user perspective.

• Printing is board specific
  The system will print packages or packets for one editorial board at a time. To print everything available, the print program will have to be told to print each of the boards. This enables a board manager to determine her own schedules for printing.

  If a single person is on two boards, then even if we print everything for both boards, he will get two separate packages (which could still be in one envelope), one for each board.

• Everything for a board can be printed with one command
  If so requested, the system will need to find all of the board members for the selected board(s) who are to receive printouts, then assemble and print a package for each.
• Reprinting of print batches is allowed
  Normally, when printing everything for a board, only packages of packets that have not been printed before will be printed. However, a user must be able to reprint everything, for example if all of the printouts are accidentally destroyed.
• Printing of any single package or packet is always allowed
  Whether it has been printed before or not, we can always print a single package or a single packet.

To print packages or their components we need a user interface to direct the printing. It should be organized as follows:

• Select one or more editorial boards
  A list of boards will be presented. The user may select one or more of them.
• Select "new", "previous", or "on demand" for packages
  
  • New
    "New" creates packages for the members of the selected board(s) that have not been printed for those members. The packet selection criteria for creating new packages are a bit complex, see "Creating new packages" below.
    • Use cases
      This is the normal mode of operation, used regularly throughout the year.
  • Previous
    If "previous" is selected, the user enters a date range and the system selects all packages for the specified board(s) that were previously printed at any time between the upper and lower date boundaries.
    • Use cases
      The main, perhaps the only, use case for "previous" is a printing catastrophe. We printed all of the packages but then realized that the printer was low on ink and most of them are light grey instead of black, or there is a black stripe that runs through all of them, or a water pipe in the ceiling burst and soaked them, or the mail truck caught fire on the way to the post office, or someone accidently dropped them all in the recycling bin.
  • On demand
    "On demand" ignores the printing history and ignores the board member's preferences for printing vs. electronic use. It is intended for printing packages or individual packets for a particular board member.
    • Use cases:
      I need my package printed for this month only. I'm going to Hawaii and I need reading matter, but won't have Internet access.

      My dog ate my package, can you send me another one?

      I never received the package that you say you sent me.

    • Interface for printing on demand
      
      • Select a board member - required
        The user must identify a particular board member. The system will print a package or individual packet (see below) assigned to the board member, regardless of his profile printing preferences and printing history.
      • Optionally enter a package ID for a previously printed package
        The package ID must be for one previously printed for this selected board member. The system will reprint the package as it was. This is ideal for "the dog ate my package" case. Perhaps the new printout will be on less savory paper.

        Since this package has already been printed, we don't need to record it again as being printed. However it "would be nice" to log something so that we can see later that the package was reprinted.

      • Optionally enter a date range
        If the board member doesn't normally receive printouts, there won't be any package IDs for him.

        In that case the user must enter a starting and ending date range. Only those packets of articles assigned to the board member that were created on or after the starting date and on or before the ending date will be printed - whether they were printed in the past or not.

        If the primary use case for this is printing for people who don't normally receive printouts, there's really no reason to record the fact that we printed them. However if the purpose of the printout is to get Dr. Smith his printouts early so that he'll have them when he goes to Hawaii, it would be useful to record that so that the packets won't be printed again.

        Let's assume for now that, if a date range is selected, we will at least record any packet that was not printed before for this board member in order to prevent needless re-printing.

      • Optionally select a specific packet
        If an individual packet is selected, the system will print just that one packet, regardless of whether the board member normally gets printouts and regardless of whether it has already been printed for this board member. It will be printed again.
    • Notes
      A user must select either a specific previously printed package, or a date range for packets, or a specific packet. One and only one of these must be selected.

      The packet(s) selected for printing will only be ones that have been assigned to the specific board member. The packets will contain response sheets for that board member, plus any Summary or other documents associated with the packet. If it is desired to print articles for someone who has not been assigned to review them, that should be done outside this printing subsystem. For example, a user may call up an article in Acrobat reader, print it, and mail it to a board member. No response sheet will be included. No record will be made that this article was printed for this board member.

      [We might need to discuss the printing of FYI articles - if that is indeed a requirement.]

• Request the print processing
  Initiating the request will cause all of the requested documents to be selected and organized for printing. No printing will be done yet. Some feedback (to be determined) will be be produced to tell the user something about what will be printed, perhaps a count of packages, packets, and total documents - or something that will at least give the general dimensions of what will happen when printing starts.
• Submit the print job
  The user should check that the printer is on and has paper, then click a submit button to begin the full processing of the print job.

The system will be setup for a standard print configuration, probably two sided printing, to save money on paper and mailing, and to reduce environmental impact. No provision will be made for printing some packages or packets or documents with specialized configurations.

The technique that worked best for mailers was to produce a batch of documents as ready to print files, and a queue of print commands to cause them to print in order. The same technique will be used for EBMS printing.

When the queue has been sent for printing, the software will update the database to indicate that everything was printed. The program won't actually know whether the printing worked or not. All it can do is assume that everything worked. See "Handling errors" next below.

If something goes wrong, for example a paper jam or a printer failure, the user will take whatever steps are necessary outside the system to fix the problem and restart printing. If some of the printouts were destroyed, the workstation disk crashed, or some other catastrophe occurred, the user can go back into the system and request the entire job be redone (the "previous" otion), or request specific packages or packets to be reprinted (the "on demand" option), or in the simplest case, find the specific document that jammed and just print that using other EBMS techniques for printing individual documents, and restart the rest of the queue.

Since we currently plan to download all of the materials to print to the user's workstation, re-printing or re-starting can often be done without going back to the server at all. If the printing fails, the documents and print command queue will probably still exist on the workstation, at least for some period of time.