Technical FAQs

Question

How do I store and retrieve documents in subdirectories of the configured documents directory in PrizmDoc PAS?

Answer

You can retrieve documents from subdirectories when dealing with local files. Simply pass the subfolder in the fileName parameter when creating the viewing session. You can test this by manually placing a document inside a subfolder and making the following POST request:

`http://localhost:3000/ViewingSession`

    {
        "source": {
            "type": "document"
            "fileName": "folder/document.pdf"
        }
    }
Question

I am receiving a 401 Unauthorized when trying to use PrizmDoc Cloud. What could be the issue?

Answer

This error is likely the result of neglecting to specify your API key.

To fix this, specify your API key in the headers of your request to create a viewing session.

Question

When doing a text search in a document in PrizmDoc, the highlight color for the search results is a light blue background. Is there a way to change the highlight color for search results in the PrizmDoc Viewer?

Answer

You can change the highlight color specifically in the PrizmDoc Viewer file viewer.js file located in the viewer-assets\js folder of your project/application.

You will need to locate 2 instances of the search term “highlightColor: undefined” in the code block below located close to line 4400. The actual line number will vary depending on the version of viewer.js you are using. You can replace “undefined” with a hexadecimal color value which you can look up from the following site: https://htmlcolorcodes.com/

// This is a request for a new searchQuery triggered by the search input field.
// Generate new search terms, and save them globally.
prevMatchingOptions = _.clone(matchingOptions);

if (matchingOptions.exactPhrase) {
    // We need to match the exact string, as is
    if (queryString.length) {
        searchTerms.push({
            searchTerm: queryString,
            highlightColor: undefined,
            searchTermIsRegex: false,
            contextPadding: 25,
            matchingOptions: matchingOptions
        });
    }
} else {
    // Split up multiple words in the string into separate search term objects
    var queryArr = queryString.split(' ');
    queryArr = _.unique(queryArr);
    _.forEach(queryArr, function(query){
        if (query.length) {
            searchTerms.push({
                searchTerm: query,
                highlightColor: undefined,
                searchTermIsRegex: false,
                contextPadding: 25,
                matchingOptions: matchingOptions
            });
        }
    });
}         
Question

I want to load an HTML document in PrizmDoc with UTF-8 encoding. Can this be done automatically in the product?

Answer

Currently, no. We have a parameter for .txt files which does that (detailed here), but this “textFileEncoding” intentionally only works for .txt, not .html files. There is a feature request for this:

https://ideas.accusoft.com/ideas/PDV-I-546

In the meantime, this can be fixed manually by adding charset = “utf-8” to the meta tag of the HTML document. One POC way this might be done programmatically is below in Python 3.7 (need obvious polishing like checking for the tag already existing, multiple “meta” tags, etc):

with open(filename, "r") as file:
    content = file.read()

index = content.find("meta") + len("meta")

new_content = content[:index] + " charset=\"utf-8\" " + content[index:]

with open(filename, "w") as file:
    file.write(new_content)
Question

Can I remove your branding without the additional advanced features such as eSignature and annotation?

Answer

Yes, please contact us for more information on this request.

PrizmDoc Viewer HTML5

Adding viewing and document conversion capabilities to an application can be a daunting task, especially when a development team is facing resource constraints and a tight schedule. That’s why many developers turn to API-based viewing integrations like Accusoft PrizmDoc Viewer instead of building those features from the ground up. By leveraging the versatile power of HTML5 viewing, they can quickly expand software capabilities without having to rethink the basic framework of their products.

What’s Under the Hood of PrizmDoc Viewer?

To understand how PrizmDoc Viewer goes about rendering documents in a web application, it’s helpful to take a closer look at its underlying architecture. There are two primary components that work in concert with the application’s web server: the HTML5 viewer and the backend.

The HTML5 viewer is integrated to run in the browser, typically via a web page or portal that serves as the front-facing aspect of the application. This is where document content is rendered as SVG elements. Since the viewer uses HTML5 to display content, it isn’t dependent upon any specific word processing software or imaging program.

Most of the heavy lifting is handled by the PrizmDoc Viewer backend, which consists of the PrizmDoc Server and PrizmDoc Application Services (PAS). PrizmDoc Server is the core computing component. It performs the actual conversion process to convert document pages to SVG, but it doesn’t have any permanent storage. Converted content and annotation markups are instead stored in PAS. The PAS component primarily handles long-term storage and hands files off to the server for conversion or processing. 

Critically, PAS also has privileged access to other storage locations used by the application, such as file systems or databases. This allows it to easily retrieve source documents and hand off tasks to the server.

The Role of the Web Application

The web application server sits between the HTML5 viewer component and the backend component. It functions as a reverse proxy that relays requests between the two, passing content requests from the viewer to the backend and then delivering converted SVG content from the backend to the viewer.

PrizmDoc Viewer doesn’t actually work with the source documents in the application’s storage. They remain safely unaltered while the backend generates a converted version for viewing and annotation. The web application typically only makes REST API calls to PAS. Background conversion that doesn’t involve the viewer, however, can be performed by making a direct call to PrizmDoc Server.

Making the HTML5 Magic Happen: Viewing a Document

When the web application has to open a stored document for viewing, each component of PrizmDoc Viewer plays a special role in the process. Everything begins with the web application sending a request to PAS to create a new viewing session. How this session is created depends upon how the backend is deployed. In most cases, it will be self-hosted as part of an on-premises deployment or through PrizmDoc Cloud services.

Once that session is created, PAS generates a new viewing session ID and passes it back to the application. All of this happens before any conversion or viewing begins, but the application can begin rendering to the HTML5 viewer by configuring it to use the viewing session ID. This brings up the viewing UI immediately, which will ultimately save time as the document is prepared.

The web application then uploads a copy of the source document to PAS, which can be in any number of formats supported by PrizmDoc Viewer. As soon as PAS receives the document, it begins handing off pages to PrizmDoc Server for conversion to SVG. Since pages are converted one at a time, PrizmDoc Viewer is able to open and view documents in the browser before the entire file is converted. That means less time is spent waiting around for large documents to be prepared for viewing.

As soon as the HTML5 viewer loads in the browser, it begins proxying requests to PAS through the web application for the first pages of content. Once the converted SVG content is available, PAS hands it back to the web application, which then passes it along to the HTML5 viewer, which displays that content in the browser. Additional pages are delivered as they’re ready, and the viewer may make subsequent requests as the user continues to interact with the document.

While the viewing process involves several steps, it is typically performed so quickly that the end user doesn’t experience any significant delays. Larger documents may take more time to render as SVG content, but even in these cases, PrizmDoc Server’s ability to render and deliver each page to the HTML5 viewer as it becomes available allows users to begin viewing documents within their browser right away.

Enhance Application Viewing Performance with PrizmDoc Viewer

As an API-based HTML5 viewing solution, PrizmDoc Viewer can be integrated into most web-based applications to support a broad range of file formats. Developers can use its annotation, redaction, document comparison, and conversion capabilities to deliver a full range of document management tools within their software platforms rather than having to build them from scratch.

To see how PrizmDoc Viewer will function in your application environment, sign up for a free evaluation trial. We provide ready-to-run Docker images in addition to installers for Windows and Linux. 

 

Printers, scanners, and other imaging devices have long been a source of headaches and frustration for developers and users alike. All too often, multiple software tools are required to connect an application to a device and acquire image files from them. This not only slows down workflows, but also creates opportunities for human error. Files can easily be misplaced or imported using the wrong parameters under these conditions.

Thanks to ImageGear’s TWAIN scanning support, however, developers can ensure that their application makes acquiring images from compatible devices both straightforward and mistake free. 

What Is TWAIN?

Developed in 1992 by a consortium of software developers and hardware manufacturers, the TWAIN standard is a standard software protocol and API that facilitates communication between imaging devices and software applications running on a computer. The word itself refers to a famous line in the Rudyard Kipling poem “The Ballad of East and West” that reads “never the twain shall meet.” Although sometimes alleged to stand for “Technology Without An Interesting Name,” the term is not actually an acronym despite being capitalized.

The name is well chosen because the TWAIN standard helped to solve the enduring problem of getting imaging devices and computers to connect and send data between one another. Most commonly used for scanners and digital cameras, TWAIN made it possible to request an image file to be imported into an application without having to utilize additional software or input commands using the physical device.

Implementing TWAIN Scanning with ImageGear

As a versatile image processing SDK, ImageGear fully supports the TWAIN specification, which allows developers to support any TWAIN-capable device directly into their applications. In most instances, this will involve adding a “Scan” button or option somewhere in the platform’s interface so that users can quickly and easily instruct their scanner to capture an image and pass it along to the application’s storage or workflow. Developers can also use the integration to adjust device settings directly from their application, such as changing the scanning area, modifying brightness and contrast, or increasing/decreasing dots-per-inch (resolution). 

ImageGear’s TWAIN scanning feature works with three external elements to facilitate image file transfers:

  • The Device: Usually a scanner or digital camera, this is the primary imaging source. The device must be compliant with TWAIN protocol.This is typically indicated by the manufacturer.
  • Data Source: Although ImageGear’s TWAIN scanning features can connect an application to a scanner, the device still needs a software driver that allows it to communicate with the computer’s operating system.
  • Data Source Manager: The TWAIN manager software provides a universal mechanism for managing and using data sources from different device manufacturers. Developed by the TWAIN consortium, it can be downloaded for free and installed wherever the application is running.

(Both the device’s data source driver and TWAIN data source manager should be included with its installation software. They are not provided by the ImageGear SDK).

Acquiring an Image Using TWAIN Scanning

ImageGear can configure an application to gather an image or set of images from a connected device with a few simple steps.

Step 1: Open the Data Source

Developers can set the application to automatically open a default Data Source. This is typically the best choice when only one scanner is available, as is often the case in a small workplace. They can also use the Data Source Manager to provide a list of all available Data Sources and let the user select the one they need.

Step 2: Adjust Settings

ImageGear’s TWAIN scanning features allow image acquisition parameters to be set through the application. Parameters such as page count and image size can be set to a common default, but developers can also give the option to obtain the various capabilities (listed as “ScanCaps”) and display them for users to select from. ImageGear supports a wide range of TWAIN-related capabilities.

Step 3: Acquire Image

After all settings are configured, the image can be scanned and loaded into an ImGearPage Class object. When acquiring a multi-page image, ImGearPages are loaded into an ImGearDocument Class object instead.

How ImageGear TWAIN Scanning Looks in Code

As an example, here’s what the C# code may look like when using ImageGear to help an application import an image from a TWAIN Data Source:

using System;
using ImageGear.Core;
using ImageGear.TWAIN;

public ImGearPage AcquireImage(IntPtr Handle)
{
    ImGearPage igPage = null;
    ImGearTWAIN igTWAIN = new ImGearTWAIN();

    igTWAIN.WindowHandle = Handle;
    igTWAIN.UseUI = true;

    try
    {
        // Open the data source selection dialog
        igTWAIN.OpenSource(String.Empty);

        // Initialize the scanning
        igPage = igTWAIN.AcquireToPage();
    } 

    catch(ImGearException e)
    {
        // Handle the exception ...
    }

    finally
    {
        if(igTWAIN.DataSourceManagerOpen == true)
        {
            igTWAIN.CloseSource();
        }
    }

    return igPage;
}

Expand Your Application’s TWAIN Support with ImageGear

Accusoft’s ImageGear SDK provides comprehensive support for a broad range of TWAIN devices, which makes it easier than ever for developers to control the scanning process directly from their applications. Integrating TWAIN scanning can streamline workflows and significantly improve the software user experience by completely eliminating the need to turn to external programs for image acquisition. ImageGear is fully compatible with multiple generations of the TWAIN standard, including TWAIN v1.6, v1.7, v1.8, v1.9, and v2.4.

In addition to TWAIN scanning support, ImageGear provides powerful image and document processing capabilities that can transform your application workflows. With extensive file conversion and compression features, it’s the best way to quickly integrate content management features into your platform. To get a glimpse of what ImageGear can do for your .NET application, download a free trial today and start building.

Despite its reputation for being slow to adapt and held back by outdated, legacy technology, the insurance industry is undergoing a tremendous period of digital transformation. A new generation of InsurTech applications are helping insurers respond more quickly to a dynamic market and empowering customers to become more engaged with their policies. InsurTech digital collaboration is a key industry trend.

Digital collaboration tools are critical to this dramatic shift, which has created a unique opportunity for InsurTech developers. By deploying features that allow insurers to streamline workflows and improve communication both with internal stakeholders and customers, developers can capitalize on an emerging need and establish their applications as the “new standard” for digital collaboration in the insurance industry.

Creating Better Digital Collaboration Tools for InsurTech Software

Accessible Viewing

The ability to easily access and view insurance documents is increasingly important to insurance agents and customers alike. When assembling a policy bundle, insurance agents must reference multiple pieces of information about customers as well as detailed actuarial data from a variety of sources. By building HTML5 viewing capabilities into InsurTech applications, developers can help underwriters reference all relevant information within their existing workflow. Rather than ponderously requesting documents from other departments and receiving them via email, and opening them with an external program, they can simply request, search for, receive, or view files without ever exiting their secure application.  

Customers, meanwhile, expect to be able to access their insurance records quickly and easily. Whether it’s a detailed description of their policy or a copy of their proof of insurance, they want the ability to log into a web-based application that allows them to locate and view records related to their account. This can greatly improve communication with their insurer since they’re able to quickly reference different aspects of their policy and identify their needs more clearly. Developers can build viewing features into an InsurTech application so customers can access their essential documents without having to download anything or take any additional steps. Insurers can also use the same features to easily provide updates about policies or rates. 

Annotations

Building an insurance policy or evaluating claims can be a lengthy and confusing process without the right digital collaboration tools in place. Documents often need to be reviewed by people in different departments before bundled services and rates can be finalized. If an InsurTech application lacks collaboration features, insurers may need to resort to emailing documents back and forth along with their comments. There is ample space for miscommunication in this scenario, with vital comments potentially going unnoticed or the wrong document being sent as an attachment.

Built-in annotation tools allow insurers to leave comments, highlight areas of concern, and provide helpful notes directly on the files themselves. Developers can also make it possible to share and view those documents entirely within the application environment, which reduces the risk that someone will overlook important comments or compromise privacy by opening a file with poorly secured software. Annotation markups are stored separately from the original file until they need to be burned into a new copy. This protects the integrity of the source document throughout the collaboration process.

Version Control

One of the biggest challenges with digital collaboration is maintaining version control over documents. When multiple people are working on a file, it’s important to make sure that everyone is using the most up-to-date version of it. This is especially true of insurance documents because rates and risk adjustments can sometimes change quite rapidly. The last thing an organization (or their customers) want is to have inconsistencies spread across several documents due to poor version control.

Developers can combat version confusion by keeping every stage of document workflows within their InsurTech applications. Version problems are usually caused by people downloading documents, working on them in isolation with a separate program, and then uploading their changed versions back into the application. By making it possible to view and annotate content within the application, developers can help ensure that everyone is working from the most up-to-date version of every file. 

Conversion

InsurTech applications must be able to handle a wide range of file types if they’re going to effectively facilitate digital collaboration. Customers often need to upload images as part of their insurance claims and will often provide documents as scanned images that can’t be searched for key text. Without the ability to convert files into more manageable formats, collaboration can quickly become an exercise in frustration and confusion.

Conversion tools not only make files more accessible, but also make it easier to manage content. Several small documents, for instance, could be combined into a single file for faster access, review, and markup. Developers can also incorporate Optical Character Recognition (OCR) into their InsurTech application to extract the text from a document image and use it to create a searchable PDF for more convenient reference. These conversion tools provide a great deal of workflow customization that allows their customers to set up efficient processes that help them deliver better services.

Boost InsurTech Digital Collaboration with PrizmDoc Viewer

Accusoft’s PrizmDoc Viewer is an HTML5 that integrates smoothly into your InsurTech application to deliver a powerful array of digital collaboration tools. Using a sophisticated collection of REST APIs, PrizmDoc Viewer provides support for multiple file types and can easily convert between formats to simplify insurance workflows. It also features a full range of annotation and redaction tools as well as OCR text extraction and electronic signature features.

With three decades of experience developing imaging and document management technology, Accusoft offers a variety of software integrations that can support digital collaboration efforts. From document assembly to secure spreadsheet support, our collection of SDKs and APIs can provide the features your InsurTech application needs to meet the evolving demands of the insurance industry. Check out our InsurTech fact sheet to learn how you can turn our capabilities into your capabilities.

 

FinTech adoption continues to accelerate. According to Wealth Professional, almost 40 percent of finance firms now prioritize the adoption of FinTech frameworks, even as new-to-market startups disrupt the status quo. 

However, spending alone isn’t enough to deliver streamlined and scalable FinTech processes. As noted by David Linthicum, Chief Cloud Strategy Officer at Deloitte in a recent protocol piece, firms now face the challenge of creating “high-quality, repeatable data processes with the profusion of systems involved in generating data” while simultaneously integrating unstructured and semi-structured data sources into existing processes.

At the front lines of this fundamental framework change is digital documents and business process workflows. Let’s dive in, and look at some of the biggest frustrations facing the finance industry, the solutions they need to streamline digital processes, and how Accusoft’s ImageGear can help redefine digital document delivery.


FinTech Framework Challenges

By leveraging data-driven techniques and digital-first processes, Forbes notes that it’s possible for even startup firms to differentiate their service delivery and compete with huge financial brands — but only when digital document processes align with on-demand performance expectations. 

Consider common use cases such as loan origination, credit applications, or mortgage approvals. Many FinTech firms now target client pre-approval within 24 hours rather than the days or weeks required by traditional finance corporations. The problem? As digital document processes naturally scale, so does complexity, creating a practical paradox around three key challenges:

  • Speed As noted above, many FinTech firms are looking to disrupt incumbent efforts by reducing approval times and increasing customer satisfaction. As the number and type of digital documents required for timely approval expands, disparate processes conspire to stifle speed. Consider a loan origination requiring identity verification, income confirmation, and current debt load documents for pre-approval, all of which are in different file formats, forcing firms to use multiple software solutions and slowing their progress.
  • SecurityCybersecurity and compliance are critical for FinTech firms to succeed, but both requirements come with rapid scaling complexity. For example, a recent FDIC document lists more than 200 types of Compliance Information and Document Request (CIDR) forms which must be customized for each financial use case. The result? Increased document processing volumes drives increased complexity and opens potential security gaps.
  • ConsistencyDigital data consistency is critical to ensure accurate approvals and assess potential risks, but contrasting document processes create the ideal environment for human error. Despite best efforts on the part of employees, the more manual processes introduced into FinTech functions, the greater the chance of misplaced assets or data conversion mistakes.

Streamlined Structure Solutions

To bridge the gap between FinTech potential and fast-track document processes, companies need solutions that deliver four broad benefits:

  • Document ConversionFinTech firms now face a diverse range of documents that often frustrate efforts to unify key data. Here, integrated conversion functionality is critical to ensure employees have the tools they need to quickly convert key documents without having to open multiple applications and manually move or manipulate data.
  • On-Demand AnnotationSpeaking of data, it’s also essential for staff to collaborate on key documents, especially as many FinTech firms embrace the remote work revolution. Advanced annotation tools that allow asynchronous collaboration are essential to ensure employees always have access to the most current document version and administrators can easily determine who edited documents, when, and why.
  • Digital CompressionAs digital documents become the de facto financial standard, storage space is at a premium. This is especially problematic for larger document types such as PDFs, which are often preferred by FinTech firms for the ability to easily control access, editing rights, and collaboration. Uncompressed, these PDFs can quickly overwhelm even enterprise storage systems, forcing companies to either spend more on cloud services or invest in bigger datacenters. Reducing PDF size both saves space and helps companies streamline document sharing.
  • PDF ManipulationWhile read-only access makes PDFs ideal for FinTech firms that need to share specific information without introducing security risk, adjusting and editing these documents in-house often requires multiple applications and increased employee effort. Even more worrisome? Staff encountering functional limits may opt for free, online applications that could compromise document confidentiality.

Practical Process Performance

ImageGear is designed to help FinTech firms both overcome current frustrations and help future-proof financial frameworks by combining disparate document functions into a single-source application and improve overall performance. Standout features include:

  • Complete PDF ControlImageGear provides a single-platform solution for PDF manipulation and control. Developers can easily integrate an SDK that enables application users to create, edit, view, and print PDFs from within the confines of existing applications, create searchable PDF documents, or flatten acroforms to remove file interactivity, all while automatically conforming to the PDF language standard.
  • Secure Signature VerificationSecure digital signatures now form a critical component of on-demand FinTech forms processing. If companies can’t accept and verify client signatures, they’re not able to deliver speedy approvals and meet evolving consumer expectations. ImageGear allows companies to ensure that electronic documents are authentic. It uses encryption to verify that the information  has not been altered and is coming from a trusted source.
  • Agile AnnotationsMaking changes to PDF files is easy with ImageGear. Staff can quickly add text, lines, hot spots, encryption, rich text, images, or even audio as needed to ensure documents are complete, accurate, and ready for approval.
  • Comprehensive Conversion OptionsTo deliver on the promise of FinTech performance, firms must be able to quickly and easily convert and combine multiple file types into a single PDF and convert PDFs as necessary into other file formats. ImageGear empowers developers to integrate a way for application users to quickly convert documents to PDF, create PDF/A files from raster images, and convert scanned pages into PDF searchable text using advanced optical character recognition (OCR). Annotations marks can also be converted as needed into XML files for enhanced auditability.
  • Substantial File Size ReductionImageGear enables file compression of up to 45 percent to save valuable storage space and utilizes automatic analysis to determine optimal compression operations for best-fit results.

Ready to embrace the future of FinTech and redefine digital document delivery at scale? Start your free trial of ImageGear today!

Question

Why am I unable to see the full menu bar with annotation and eSignature options?

Answer

These features are part of our Professional version. If you would like to evaluate the full feature set, please submit a request for a trial key here.

Question

Why am I unable to see the full menu bar with annotation and eSignature options?

Answer

These features are part of our Professional version. If you would like to evaluate the full feature set, please submit a request for a trial key here.

document redaction

Many professionals in highly regulated industries like legal, healthcare, and government handle a myriad of cases, contracts, and forms. However, collaborating on documents comes with a risk. Sharing personally identifiable information (PII) with the wrong person can cause chaos and even result in a lawsuit. That’s why redaction is so paramount to collaboration in so many industries. Where manual paper processes once required a permanent marker, digital solutions now offer redaction capabilities that work even better. 

Redaction removes key pieces of information — including sentences, images, and even entire pages — while leaving the bulk of the document’s text intact. Although many tools now empower organizations to “burn in” data redaction so it can’t be removed, they don’t allow users to indicate multiple reasons for redaction. 

Many solutions offer a coding system that enables users to tag a piece of redacted information with a single reason code that signifies why the data was hidden. However, they lack the ability to add those reasons while you are redacting, which could save time and effort. Just think of how large some of these files could be, and how manually adding comments throughout the document could take hours after you’ve already finished reviewing the content.

This creates additional pressure from viewers to understand the purpose of redaction, and potential reporting issues if the reason for redaction isn’t properly recorded. Solutions that permit the addition of redaction reasons can help defend key data and close this communications gap.


The Freedom of Information Act (FOIA) and Secure Data Sharing

As noted by CNN, government documents are often partially redacted to obscure personal data such as social security numbers or military information related to intelligence data gathering and applications. Consider a U.S. intelligence agency report made public by FOIA request. 

While the Freedom of Information Act forms a critical part of open, effective democracy, data in the report that suddenly becomes public domain — such as the names of confidential sources or the methods used to obtain information about foreign government actions — could jeopardize both the ability of the agency to do its job and put human lives at risk.

Most government redactions expire and are automatically declassified after 50 years, but agencies can also obtain permission for special exemptions which prevent the redaction from being removed. For example, redaction reason 3.3(h)(1)(a) is used to protect the identity of a classified human intelligence source and is exempt from automatic expiration.

There are currently nine FOIA exemptions that are withheld from public release and protected from disclosure. When a portion of a record is withheld from public release, an exemption code may be found listed in the margin. The Federal Bureau of Investigation’s list below showcases what exemption codes are subject to FOIA data withholding:

  • (b)(1) (A) Specifically authorized under criteria by an executive order to be kept secret in the interest of national defense or foreign policy and (B) are in fact properly classified to such Executive Order #12958 (3/25/03).
  • (b)(2) Related solely to the internal personnel rules and practices of an agency.
  • (b)(3) Specifically exempted from disclosure by statute (other than section 552b of this title), provided that such statute (A) requires that the matters be withheld from the public in such a manner as to leave no discretion on issue or (B) establishes particular criteria for withholding or refers to particular types of matters to be withheld.
  • (b)(4) Trade secrets and commercial or financial information obtained from a person and privileged or confidential.
  • (b)(5) Inter-agency or intra-agency memorandums or letters that would not be available by law to a party other than an agency in litigation with the agency.
  • (b)(6) Personnel and medical files and similar files, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.
  • (b)(7) Records or information compiled for law enforcement purposes, but only to the extent that the production of such law enforcement records or information:
  • A. Could reasonably be expected to interfere with enforcement proceedings;
  • B. Would deprive a person of a right to a fair trial or an impartial adjudication;
  • C. Could reasonably be expected to constitute an unwarranted invasion of personal privacy;
  • D. Could reasonably be expected to disclose the identity of confidential source, including a state, local, or foreign agency or authority or any private institution that furnished information on a confidential basis, and, in the case of a record or information compiled by a criminal law enforcement authority in the course of a criminal investigation or by an agency conducting a lawful national security intelligence investigation, information furnished by a confidential source;
  • E. Would disclose techniques and procedures for law enforcement investigations or prosecutions or would disclose guidelines for law enforcement investigations or prosecutions if such disclosure could reasonably be expected to risk circumvention of the law, or;
  • F. Could reasonably be expected to endanger the life or physical safety or any individual.
  • (b)(8) Contained in or related to examination, operating, or condition reports prepared by, on behalf of, or for the use of an agency responsible for the regulation or supervision of financial institutions.
  • (b)(9) Geological and geophysical information and data, including maps concerning wells.

Given these extensive reasons, we can start to understand how there might be reason to include multiple FOIA exemption codes for one piece of redacted information.


Regulatory Compliance & Document Security

For many organizations, adding redaction reasons to shared or publicly-available documents isn’t mandatory, but it can help reduce the risk of both legal and compliance challenges. 

Consider a redacted court document shared as part of an eDiscovery process. Without a custom redaction reason, other parties may challenge the necessity of your redaction, especially if no contextual evidence indicates its necessity. 

Compliance audits also pose a potential problem. If years or even decades-old documents don’t contain redaction reasons — and the originals aren’t easily located — your organization could face increased regulatory oversight.

Take for example the healthcare industry. There are several clinical studies that require peer review. To keep biases at bay and personal information secure, redaction is critical to the adjudication process. Think about a clinical trial that has specific events related to a test subject. That test subject has participated in a trial for an incentive. 

However, that person did not agree to share his or her personal information with a broad audience. Once the panel of experts reviews the results of a clinical trial, the research goes on public record. It’s crucial to protect the participants involved and their PII to ensure that no harm comes to them.

Many document viewing tools make it possible to add single redaction reasons to released documents, but what happens if your organization is dealing with multiple data types? Look for a solution that enables you to add multiple redaction reasons or codes to clarify your intent and keep data secure.