In the insurance industry, document generation is typically complex. There are hundreds of rules and thousands of templates, all of which are based on a plethora of text modules. The problem is that this process is subject to a multitude of changes, usually the result of new insurance terms and conditions or products. The text and layout need to be modified and checked (add, switch and remove text modules).
Deviations can also arise from release changes to the systems that generate the text. In this case, the challenge is to review every document for legal and technical accuracy. Do the documents look exactly the same after the update? Do they also meet all the corporate identity (CI) and compliance criteria standards in the new software version? For many insurers, document compliance after software accounts for the majority of quality assurance work.
Reading time: 4 min
But considering the complexity of the task how is it possible to check every document, in all its versions, reliably? Many insurers assign extra employees to the task. But in practical terms, they usually just print a random document (candidate) and the related template (reference) and compare the two with the naked eye.
Of course, that is hardly 100% reliable. But reliable quality assurance is essential for every insurer. Because they are more efficient and reliable, software tools that perform automatic tests are better. They validate documents against a defined set of rules, compare them with one another directly, and identify how the changes affect the quality of the final document. The advantage is that documents are checked not only for visual deviations but also deviations in content at the textual level. Compliance check software solutions of this type detect even the smallest outlier, even those that can't be seen with the naked eye.
Many checking tools are available, and several even offer two critical benefits: They are designed for high throughput and also allow for defining tolerance limits and excluding areas from the check. This batch processing ability and the flexibility to define check criteria are definitely advantageous to insurance companies with high volumes of documents containing a lot of variable data.
Incidentally, these checking tools also resolve the inevitable conflict: on the one hand, to cover as much as possible for any quality problems (keeping the risk of undetected errors as low as possible); versus skipping sections of the document that are irrelevant for quality (avoid unnecessary effort). The check is designed to identify how changes affect the content and layout of a document. In the final analysis, not every change is relevant.
Compliance and 100% Quality Assurance
Learn How to Reap the Benefits of an Automated Document Quality Assurance
The following is one possible scenario that some insurance companies actually use. The responsible department defines the test cases (review task), providing the criteria for testing. The IT department is responsible for technical execution. That way the reviewer can concentrate on the content without having to worry about the actual execution, which occurs automatically.
The document is then checked for content: Are the data correct (XML format)? Are the correct text modules used? Do they go together? That means the system analyzes if the specific document contains the values defined for a specific template. If the XML dataset has not been saved, it is created as a new review task in the correspondence system. For many insurance companies, the automatic generation of test cases is an important component of document generation.
The test itself is performed by the review software, which is controlled by a separate application. The application checks the database connected to the text system for any outstanding review jobs and then passes the data needed for the test to the checking software. Such information may include: Where are the reference and candidate documents? What users are involved; is there an existing comparison profile? Where should the test result be saved?
Other review parameters may include: Should a full text comparison be run or just a structural analysis? What areas of the document should be excluded from the comparison? In sum, all the criteria can be passed to the compliance check software through the separate control software. The compliance test results are automatically transferred to the database. The reviewer can then display the results on his screen as a PDF comparison file or XML file that shows deviations down to the pixel level.
The software lists which documents were correct, where any changes occurred, and which ones affected the quality of the document. If the deviations did not affect CI, compliance or technical accuracy, the checked documents (candidates) are released. The application is configured to automatically retrieve and make available the test results in definable intervals.
But there are organizational and technical issues within document processing to clarify prior to implementing the checking software. What type of test result is needed (PDF differences file or XML file)? At what point during document production should the test be conducted? What parameters are important, which ones can be ignored (tolerance)? These are questions that must be answered in the specialist departments. Implementation should therefore always be a joint project and include the technical departments, IT department, and the central output instance, if there is one.
A platform independent and scale-able application for various document testing methods. These include checking against sets of rules (CI, compliance), direct document comparison at visual and content level, and methods such as regression, iteration and conversion tests. In direct comparison, the application lists the differences in the form of log files and also makes them graphically visible in a screen mask (visual comparison). In visual comparison, the documents to be checked are rastered into pixel images of the same resolution and the converted pixel images are compared with each other - similar to a light table where both documents are placed on top of each other in order to be able to detect deviations between them.
The software reads two files, for example in AFP, PDF or PostScript format, compares the original document with the changed one and displays the differences found in seconds. Pixel-level comparisons identify changes and their position. Structure-level comparisons evaluate text strings, font attributes, and other features that affect output.
An advantage of DocBridge® Delta is that inspection criteria from different countries can be stored as rule sets and certain areas of a document (variable fields such as address, customer number, etc.) can be excluded from the inspection (masking). In addition, the software allows the greatest possible tolerance in checking without neglecting (fuzzy methodology) absolute correctness in content, corporate identity (fonts, layout, etc.) and compliance (legal requirements). The tolerance parameters can be set individually as desired.
DocBridge® Delta checks both intended and accidental changes and even points out places in the document that are not visually obvious but could in principle lead to production difficulties. The software can compare documents of the same format, but also of different formats. It offers two different testing models: an interactive interface for ad-hoc testing, and the command-line driven call for automation.
In addition: The Compart solution is designed for a high degree of usage and automation and can be adapted to the individual needs of the user (business department, development/IT, production). Even complex tests can be configured relatively easily thanks to the intuitive operation. The solution supports existing output management structures (legacy) and can be used at any point in document production.
