How can I allow an Enterprise Scan user to select where to archive if the location has 1000+ childr

Jaco Conradie

Hi, We have a scanning requirement to index documents into folders. The folders are part of a structure similar to the following:

1st level : Hospital Name (one of many)

2nd level : → Employee Name (one of at least 100 to 2000 at some hospitals and growing over time)

3rd level : → one of 14 static folders

So the idea is to allow a scan operator to do ad-hoc indexing into any 3rd level folder of any employee at any hospital.

We tried the following:

1. Scan and index from the folder side. This seems to be the fastest solution albeit still slow, as the Indexer cannot split a singular PDF document into several 3rd level folders
2. Allow the Indexer to navigate to the appropriate Employee at archiving time. This also limits the operator to only one folder, but it has the additional issue that ES takes an enormous amount of time to display the folder (second level with all the employees) with lots (e.g. 1000+ folders in it) for the operator to browse
3. We tried to create dropdown fields that allow the operator to select the hospital, then populate and allow the operator to select employees belonging to the selected hospital and then selecting a 3rd level folder from a static list. This approach would allow the operator to select different 3rd level folders for different documents and then the operator can archive all in one go. The idea is sound, however, populating the dropdowns with actual information from CS proves to be taking just as long and therefore rendering the advantage of this approach as unusable.

Code to populate the hospitals:

import Ixos.Scan.Extension.Livelink;

import Ixos.Scan.Indexing;

import System.Windows.Forms;

Fields["Facility"].Choices.Clear();

try {
var session: ILapiSession = SessionManager.Session;

var documents: ILapiObjectInfo[];

documents = session.ListObjects(-2000, 12416962); //Id for parent folder of hospitals

if (documents.length > 0)

{
for (var x = 0; x < documents.length;
x++)
{
Fields["Facility"].Choices.Add(new IndexingPair(documents[x].nodeId, documents[x].name));

    }
  }

  

//If there is only one value in the dropdown, display/select that value by default.

if (Fields["Facility"].Choices.Count == 1) {
Fields["Facility"].Value = documents[0].nodeId;

  } 
}
catch (Exception) 
{
}

Fields[":Document Details (International):13271324:Division"].Value = "MCUAE";

Context[":Document Details (International):13271324:Division"] = Fields[":Document Details (International):13271324:Division"].Value;

So my questions :

1. Am I correct in saying that scripting is the way to go to find a solution here?
2. Or should we pursue a compiled DLL, called from the profile, to facilitate the lookups?
3. Are there anything that indicates that the above type of scripting might soon be outdated? e.g. LAPI vs Webservices.
4. Did we miss something from an Content Server config or Enterprise Scan config side that would facilitate pagination of browse results?
5. Any other comments would be more than welcome!

Thx

Jaco

appuq

Here's another idea we did a very similar implementation of a HIPAA-compliant solution. The trick was to separate the workstreams into scanning and the second stream would be filing.HR system that was responsible for our company would create an Informatica feed so an example would be NurseX who could be accessing PatientY's records on a particular ACL on the object(for ease the employee folder) and would most likely be invalidated the next time. When I developed this with a team we created two tables one that would represent an existing table full of Nurse/Doctor entries and then a second table that would represent the future so if you subtracted(actual sql cmd I found was MINUS) .BTW I am getting carried away by that but what I wanted to say was our scanning people with their powerful Bell& Howell's had one job scan and put the correct SSN which served as employee# and Kofax script put them in a huge folder like a dropfolder. We wrote then a scheduled agent that monitored the drop if it had a match on SSN to find the folder if not create a folder, and apply the ACL based on the above algorithm. Like you said the Folder itself was not browsable but we provided tools based on category information.

This can almost easily fit the new extended ecm paradigm when we were doing this it had not been invented.

The idea we found was indexing people were not readily able to be trained nor did they need to so long as they were able to put the required attributes for a process to make use of it.