Patient Menus Application

Application: Patient Menus (Healthcare, VI Level: L1)

Data Environment

(Describe the typical sources of data and format in this type of application.)
Typical data for this type of application would be database data from the hospital's database.

Supplemental Data

(File names and format and include any supplemental data that was used to produce the application.)
N/A

Web Integration

(If applicable, describe the process for enabling web-based data input into the application.)
Data can come from any source, no additional processing needed. Perhaps a data file might be submitted via the WEB to a print service bureau, in this case a Lytrod/VIPP workflow would be very efficient as such a small amount of information would be transferred. This scenario could be very possible when a nurse enters the patient information via a web interface.

Data Conditioning

(What, if anything, had to be done to make the data usable in your application?)
health_patient.csv: The excel file was simply saved it into a comma separated format.

Quark File Conditioning

(What if anything had to be done to the Quark file provided to make it usable in this application.)
Quark files were saved into an eps format for use in Lytrod Software's Proform Designer. Also, to make the design a more manageable task, the eps files were resampled into a low resolution files for viewing only. The original files will be used at the time of printing for best quality.

Asset Library

(Describe the architecture and formats that the static and variable assets were stored in.)
VIPP Project folder or VIPP Project Container

Coding

(Describe the business logic and coding methods for enabling the composition and assembly of variable pages.)
Lytrod's Proform Designer creates VIPP code that ultimately composes and assembles the pages. GUI based logic wizards in Proform Designer allow all business logic described above to be created.

RIP and Print Process

(Describe the production print stream and the composition, imposition, RIP and print process? Document all file names needed to load and run your application.)
The VIPP enabled engine does the composition, imposition, RIP and print process.

Provided is a VIPP Project Folder, JOB24, the project folder contains all files, including the data file, needed to run the application. Simply copy the JOB24 folder and its contents to the XGFC/Projects folder on the VIPP enabled engine.

Since not all DFEs support Project Containers, a VIPP Project Folder, JOB24, is also provided. The project folder contains all files, including the data file, needed to run the application. Simply copy the JOB24 folder and its contents to the XGFC/Projects folder on the VIPP enabled engine.

The production print stream is the data file, in this case health_patient.csv, which contains the VIPP job ticket and the line data as described above. In a production print environment, the data file would be sent to the VIPP enabled printer via LPR (this can be done via Lytrod's Proform Designer or via any standard LPR demon). For demonstration, you may simply open the project folder and "print" the data file: health_patient.csv.

It is important to note that Lytrod supports VIPP image caching which dramatically improves job processing, as the variable images are ripped only once for the entire job.

Scalability

(How large a record set can your solution support? What are the productivity implications and/or caveats associated with scaling the run to larger thresholds?)
Unlimited. Since only the data is needed to actually run the application the documents are being dynamically composed at the VIPP enabled print engine, pre-composition issues of large print runs are not experienced with the Lytrod/VIPP workflow.

Turnaround Time

(Document the time for an end-to-end process from trigger event to delivery.)
1 ½ hours.

Overall Caveats and Considerations

(Anything that we need to know about this application such as workarounds, or special conditions e.g. limited number of data formats supported, etc.)