How to take PDF Rendering to warp speed in 2020

How to take PDF Rendering to warp speed in 2020

Introduction

Compliance is never far away in the Life Sciences industry. The different health authorities across the globe have set out very specific guidelines when it comes to providing documentation and data. For the right reasons. Life Sciences (pharma, biotech and medical devices) companies spend time and effort to ensure that the information supplied meets these requirements. Not an easy task, as documents live in different systems, versions, digital file formats etc. And that is where standardization comes in. The transformation to a neutral, generally recognized file format such as PDF plays a big role here.

During the entire product life cycle in Life Sciences, PDF files (amongst other formats) are created. PDF ensures consistency, helps to standardize across different departments and platforms. Thus, it helps increase efficiency in document centric processes.

The conversion of different file formats to PDF is often also referred to as ‘document rendering’. Converting documents is generally handled by very specific applications & systems, the so called ‘rendition engines’. This ensures the transformation of one digital file format into another, f.e. PDF.

Document rendering can be done in different ways. The most common approaches are:

  1. By making use of the ‘authoring’ application that was used to author the original document (Microsoft Word, OpenOffice, Microsoft Excel, etc.)
  2. Standalone document rendering, without using the authoring application(s).

Both approaches are very different, and vary greatly in terms of speed, quality, configurability. This article further explains the inherent differences of both. 

Rendering through the use of the authoring application (f.e. Office, Adobe, …)

This approach is being used today by most organizations and is the most common way of creating a PDF. As an example, this is what happens during a Word to PDF conversion with this approach.

  1. The first step is to retrieve the Word file from where it resides. Within large organizations, content can be stored in multiple places: Document Management Systems (DMS) such as: OpenText Documentum, Veeva, Microsoft SharePoint, Box, Alfresco, Generis CARA, Hyland etc. 
  2. The rendering engine connects to the existing Document Management System(s) and pulls the original Word file from there. Or the file is being sent over.
  3. The rendering engine then calls the authoring application (for a Word file, the authoring application is Microsoft Word. For PowerPoint, is Microsoft PowerPoint etc.) to open the original source file.
  4. Subsequently it performs a Print to Postscript action using an Adobe Distiller or other printer driver. 
  5. The rendering server then starts Adobe Distiller or equivalent and the Postscript file loaded, which is then converted to PDF. 
  6. All authoring and Adobe applications are finally closed, and the PDF is sent back to the Document Management System(s). 
  7. The PDF file is stored as a rendition to the original Word document or as a new object. 
  8. The process then repeats for the next Word file.

PDF conversion

So far, so good. The conversion of a Word file to PDF through the authoring application. But, what happens in reality?

” Rendering by using the authoring application
introduces risks.”

Based on the conversations with industry experts, and our customers, this approach has drawbacks:

  1. The authoring applications (Office and Adobe tools and everything else) need licenses. And these come at a price. The number of documents to be converted and the organization size impacts licensing cost. All these authoring applications must also be upgraded, patched and validated. All in all, this brings big (and often overlooked) costs for most organizations. Especially when you consider how many different formats should be converted to PDF. (PowerPoint, Excel, Word etc.)
  2. Rendering through the use of the authoring applications introduces risks. A simple version difference (Word version installed on the desktop vs. Word version installed on the rendition server) can cause all PDF conversions to fail, potentially bringing the entire process to a stop. In some cases, Word documents containing specific settings, have caused the rendition server to inherit these settings, causing incorrect renditions.
  3. Rendering through the use of the authoring applications is slow and burdensome: For every PDF conversion request, the authoring application opens the source file(s). This process, multiplied by thousands of documents for each submission package, can add up to weeks or longer.

Document conversion is being used by many departments (marketing, HR, labelling, regulatory etc.) throughout a large organization. A slow or failed conversion process quickly becomes very costly

Time to market is critical, so coming up with solutions to the above challenges is key.  PDF conversion should be easy, automated and as cost-efficient as possible.

‘’Rendering through the authoring applications is risky, expensive and slow. Is there a more efficient way?’’

Standalone document rendering

There is. DocShifter doesn’t need any authoring applications to perform PDF or any other conversions. Thanks to this architecture, our customers see a 66% cost reduction in IT infrastructure. (licensing, number of servers etc.) Risks associated with authoring applications (slow conversions, extra costs, manual interventions etc.) are simply eliminated. 

PDF conversion

Moreover, DocShifter doesn’t need any authoring applications to run. This significantly improves the conversion speed: 10x faster than comparable solutions.

Docker container technology further empowers the document conversion capabilities of DocShifter. When organizations have the pressure to convert thousands or millions of documents in a very short amount of time, peak loads are easily dealt with.

DocShifter’s standard configurations for FDA, PMDA, EMA and other health authorities allow consistent and automated submission-ready PDF creation. In one go. 

Thanks to native integrations and open API’s, DocShifter connects with any DMS or RIM system. This open connectivity greatly reduces the risk and increases the efficiency, as content is stored in multiple repositories. Document conversion is centralized in 1 platform, for all departments. 

 

About the author – Paul Ireland 

Paul Ireland - VP Life Sciences - DocShifter

20+ years in helping to provide regulatory software and service solutions to Life Sciences organisations globally. Industry and commercial experience in delivering Content Rendering, Regulatory Information Management, Submission and Report-level Publishing, and Electronic Document Management solutions. 

About DocShifter

Speed, quality, scalability, and configurability are reasons why Life Sciences organizations choose DocShifter to generate technically compliant, submission-ready PDF. High volume, high-quality document conversion, on-premises, or in the cloud. Super easy to set up. Automate. Centralize. Eliminate manual intervention. Reduce Risk. Reduce IT infrastructure costs.

Interested to see how? Check our 30-min. webinar on how modern rendering saves time and reduces risk of non-compliance. See real-life examples from your peers and how Life Sciences companies of any size benefit from modern rendering technologies.

You can easily register below to access the recording.

modern rendering