The Nebraska Department of Agriculture needed a way to offload some of the public records requests that were coming in regarding data that covered various agencies within the NDA. It seemed to us that we had come up with a valid use case to finally get our hands dirty using Hyland’s Public Access Viewer (PAV) in OnBase.

Each agency had different requirements that would affect their individual processes, but the end goal was the same; take these documents and make them available to the public. No fancy bells and whistles, no need for the user to create an account, no end-user agreement. Just give them information.

General Process

While the underlying process would be mirrored across the three separate PAVs we built, we needed to tailor-make each process to fit the needs and, more importantly, the legal requirements of the data in question.

In each process, we decided that we did not want to compromise the original documents. To handle this, as soon as a document enters the PAV routing life-cycle, we create a copy of it. We then use that copied document for public viewer routing/display, ensuring that the original maintains its historical integrity.

Process 1

With our first project, it was decided by the legal staff that nothing on the inspection forms we were displaying was inherently private, but they did want the option to redact sensitive information if necessary. It was also decided that, because this particular group of documents came into the system on a smaller scale (about 10-20 per month), the office staff wanted to have eyes on each document before it was sent to the public portal.

1. 1. Document enters the system
   2. Document is routed to PAV routing life-cycle
   3. Document is copied; original is removed from the life-cycle – any further processing is done on the copy
   4. Document awaits approval from office staff
   5. Document is either denied or approved

• Denied documents are removed from the life-cycle
• Approved documents are ‘sent out’ to the public portal
• Office staff has the option to redact information from the document at this point

Process 2

For our second project, the office staff did not want to have eyes on every document, as they are seeing upwards of 500+ documents coming into the system every month. The process we came up with for them was a much more automated, hands-off version of process 1.

We still wanted to give the office staff a chance to intercept any potentially sensitive or erroneous data, so we devised a timer system that will send the documents to the public portal on the 14^th of every month, but it will only process documents that were entered into the system before the first day of the month that the timer is running. For example, if 20 documents enter the system and are dated in March of 2019, those documents will be processed on April 14^th. Any documents that entered the system between April 1^st, 2019 and April 14^th, 2019 will not get processed until May 14^th, 2019, and so on.

This gives the office staff some time to react if they get word from an inspector that an inspection form may contain sensitive data, or maybe there was an error on a form.

1. 1. Document enters the system
   2. Document is routed to PAV routing life-cycle
   3. Document is copied; original is removed from the life-cycle – any further processing is done on the copy
   4. Document waits in a holding queue until the 14^th day of the next month
   5. Document is ‘sent out’ to the public portal
      • • Office staff still has the option to redact information or remove the form entirely before it is sent out; however, this must be done before the 14^th of the following month

Process 3

Our third project took the automated approach from process 2 and modified it to fit the agency’s need. In this process, the agency wanted an automated, hands-off approach – with a twist. There was sensitive data that existed on every single form that was going to be processed and sent to the public portal. For reasons I won’t get into here, we were unable to use OnBase’s automatic redaction feature so we came up with our own.

Process 3 is identical to process 2, with the addition of Document Composition. We shifted our thinking from ‘taking data off the page’ to ‘putting data on the page’. With doc comp, we were able to create a version of the form in question and only pull the non-sensitive data from it to display to the public. That doc comp document then becomes our public-facing document.

1. 1. Document enters the system
   2. Document Composition template is generated from data on the original form; original is removed from life-cycle
   3. Document waits in a holding queue until the 14^th day of the next month
   4. Document is sent out to the public portal
      • • Office staff still have the option to remove the document entirely before it is sent out, however, this must be done before the 14^th of the following month

Since we are using copies of the original forms, it is very easy to remove documents from the public access portals if necessary; we simply run the same custom query that the PAV uses to display the documents in Unity Client and delete the unwanted forms. On the flip side, if we need to add a document to the PAV after the fact, we can simply find the document(s) in question and send them through the PAV routing life-cycle and the rest of the work is done for us.

Because the use of the Public Access Viewer module doesn’t cost extra money, it doesn’t have maintenance fees associated with it, and it works out of the box – it was the perfect module for us to use to get this data to the public accurately and quickly. Setup can get tricky if you’re using load-balanced/multiple servers, but it is doable. Experience with custom queries and user groups is a plus.