2023.1:Secondary Types (Property)

Secondary Types allow the application of multiple Content Types to a single Batch Folder.

About

One of the most important questions to ask about a document traveling through Grooper is "what kind of document is this?". Of course, answering this question is represented in Grooper through the Classify activity. Specifically, Classification in Grooper associates a Batch Folder (or document) with a Content Type. Once a Content Type is applied to the folder, Grooper knows which Content Model to leverage for the remaining logical operations concerning the Batch Folder like what to extract from it, among other things.
Historically only one Content Type could be assigned to a Batch Folder, limiting the logical operations that could be applied to it, but with Secondary Types this is no longer a limitation.

A Simple Example

Following we will see a simple example of the role Secondary Types can play.

In the "Multiple Types, Single Document" Project we have two distinct Document Types with their own models, but the accompanying Batch has three documents, and one happens to be a document that could reasonably be seen as either of the two Document Types.

How To

With a general understanding of what Secondary Types are let's now take a look at how to configure them using a couple of examples.

EOB Form with Check

Following is an example where a Batch contains EOB packets. In these packets you may or may not have a check that will come with it. In the cases where it does we want avoid a couple of old ways of doing things that would add complexity. In one case we could Separate the check into its own document. In another case we could have the Data Model contain extraction logic for checks and EOBs all the time. Both of these add unnecessary complexity. With Separation we're attempting to do one of the more challenging things in Grooper that require an extra level of logic and review. If we have the Data Model have extraction for checks and EOBs then often we will have blank Data Elements when there is not a check, and this can be confusing to people doing review and/or require a backend system to contain unnecessary extra fields that would remain blank or null.

Understanding the Setup

What we want to do is avoid this unnecessary complexity altogether, therefore, a packet with checks will not only be assigned an "EOB" Document Type, but also a "Check" Secondary Type when applicable.

Follow the instructions in the screenshots below.

Viewing Properties to See Secondary Type

Viewing Extraction Results for Document with Applied Secondary Type

Using Content Type Filter to Limit Data Shown in Review

Document Variability and Data Normalization

In the screenshot below you will see three different documents that essentially have the same type of information, but each is laid out differently. The end point for collected data ideally does not have variability and as a result seeks to normalize the variation. However, to ease the work and lessen opportunities for mistakes for those doing review of collected data you would allow them to review the data in as close to a 1to1 way as possible. The model the reviewer interacts with should look just like the document. To accomplish this we will take advantage of another benefit of Secondary Types and have two models. The first model will be as close to the documents as possible, while the second will be the normalized version. We will take advantage of the Convert Data activity which will associate a Secondary Type after the data is first reviewed, then via some expressions convert the information to its "final" form.