Bringing a new medicine to the market requires preparation of documents with well-structured and appropriate content. All medicines progress through different clinical testing and authorization. Throughout their lifecycle, thousands of documents are created. All these documents must comply with a wide range of internal and external regulations. The ultimate goal is to produce a drug from a promising compound and bring it to the market in the shortest time possible.

The product life cycle also includes the creation of PDF files. PDF as a file format ensures that the information in the documents is cross-platform, consistent, and that the documents are ready to be digitally signed.

PDF files are stored with the original documents in the Document Management System(s). Those that need to be sent to health authorities (e.g. FDA, EMA, PMDA etc.) are included in a submission package. The submission package provides a uniform and transparent structure to the regulatory authorities.

These regulatory authorities have a lot of different formal requirements for submissions and for PDF documents. For example: FDA accepts PDF versions from 1.4 to 1.7 and PDF/A-1 and A-2. EMA in Europe accepts PDF 1.4 and possibly 1.5 – 1.7 in some regions. PMDA, the Japanese health authority, states that the bookmarks in the PDF files must be open to the 3rd level.

If the organization wants to have a medicine approved in different regions, separate PDF versions of all these documents must be created. A single submission consists of thousands of documents and there may be more concurrent submissions at a time. This is not limited to any other documents related or unrelated to the above processes, which must also be transformed into PDF formats.

”Transforming documents into PDFs throughout the document lifecycle
is crucial in Life Sciences.”

PDF transformation does not make a snapshot of a document. The purpose of transforming into PDF is to store the content (text and graphics) of a document in a device and resolution independent format. This allows the document to be opened and displayed on any device, regardless of when and where.

PDF files or the Submission packages are produced by built-in or separate rendition engines. Let’s look at what these rendition engines are and what they achieve.

Rendition engine is a software that is responsible for transforming one file format into another format. Most of the rendering engines use native applications.  For example, if you want to perform a Word to PDF transformation, your rendering engine needs to use Microsoft Word as a native application.

Here is more information on the rendition stages during a Word to PDF transformation, when a native application is used.

First, the Word file is retrieved from where it resides. For large organizations, contents are usually stored in multiple places: Document Management Systems (DMS) like: OpenText Documentum, Veeva, Microsoft SharePoint, Box etc.

The rendering solution needs to connect with the existing Document Management System(s) and pull the Word file(s) from there.

This is where open connectivity comes into play. The rendering solution must support existing Document Management System(s) and beyond. This provides enough flexibility in most challenging cases. If the Document Management System(s) is replaced or upgraded, rendering solution must adapt to that immediately. This saves additional hours and costs, while reducing the risk.

On the server, the rendering solution calls the native applications to open the source file and save it as PDF. Once the PDF is created, the solution sends it back to the Document Management System(s) or wherever the PDF needs to be stored.

The process looks flawless and easy on paper. But is that the reality?

”Using native applications during the rendition process involves a variety of risks.  Avoiding these risks can save a lot of time and money.”

From our experiences, risks and complications start with calling the native application(s) to initiate the rendering process. We have compiled those risks for you.

1. Each native application on the server needs a license. Number of documents that are sent to the server to be rendered and the organization size impact licensing costs. These native applications must also be upgraded, patched and validated. All in all, licenses are huge (overlooked) costs for most organizations.
2. Apart from the costs, rendering with native applications introduce risks. These risks can immensely slow down the rendition process or even cause the entire rendering service to completely shut down. For example: users in a company were using a newer version of the native application while an older version was installed on the server causing rendering jobs to fail. The latter is an obvious organizational issue that must be considered. Constant coordination between different groups must be there to avoid or eliminate such errors.
3. Rendering with native applications is a slow approach: the source file needs to be opened in the native application every single time. This is the core process of rendering with native applications.
4. One server = One Microsoft Word instance is too costly and introduces risks. Here are a few pitfalls we faced with this approach.

• A single server can run multiple instances of Microsoft Word but with the same settings which will result in only one single transformation type with those specific Microsoft Word settings. This means that if two departments have two different requirements for displaying the same feature in a PDF (e.g track changes in balloon or inline), creating these PDFs requires two separate rendition servers with two separate Microsoft Word instances with two separate settings. This doubles the previously described license, validation, operation and upgrade costs.
• In many cases, we have seen that the rendition server inherited specific Microsoft Word settings of a few files opened by Microsoft Word on the server. This created a lot of faulty renditions afterwards. It took a lot of manual work to rectify the situation, minimize the delays and eliminate troubles. Microsoft Word settings had to be reconfigured in order to restore normal operation.

In many scenarios, multiple business units (marketing, HR, labelling, regulatory etc.) make use of rendered documents. As rendering involves many departments, a slow or failed rendition process becomes very costly. Regardless of the industry, avoiding these problems is a must. Rendering should be easy, automated and as cost-efficient as possible.

‘’Rendering with Native Applications: Costly and Risky.
Is there a more efficient way?’’

DocShifter found a brilliant answer to this question. They have managed to produce the perfect PDF file that is identical to the source document. The rendition occurs without opening the native application.

This innovative approach:

• eliminates indirect costs (licensing, infrastructure etc.)
• speeds up the rendition process by 10x
• reduces associated risks
• generates consistent, high-quality output

DocShifter has an easy to use, transparent user interface. With modular blocks, workflows for different rendition requirements are easily defined and run in parallel. DocShifter’s modular approach makes it easy to prepare the rendition for same documents for different regions. With one workflow, renditions for PMDA, EMA, FDA etc. are easily defined.

DocShifter offers more: selecting an email account as an input and specifying the processing of your emails. Control over PDF versions (1.4, 1.5, etc.), complex bookmarks, security options, special character replacement, hyperlink management, font embedding and many more. All achievable with DocShifter to create the perfect technically compliant PDF.

The DocShifter solution also enables the automated generation of large amounts of documents. Simply design a template file in the tools you are used to and DocShifter will merge the data from backend applications. It is also possible to convert images, videos and audio files, so you can generate more than 60 output formats from more than 300 input file formats.

Thanks to the architectural lightweight, DocShifter drastically reduces infrastructure costs. Same rendering capacity is achieved by using roughly ⅓ of the current infrastructure. At a faster pace, as DocShifter renders your content 10x faster than comparable solutions.

Contact us to learn more about how DocShifter can speed up your content conversion requests while reducing your licensing and infrastructure costs.

06/11/2019