You are viewing limited content. For full access, please sign in.

Question

Question

QuickFields - Improving performance while scanning form with more than 190+ Zone OCR fields which corresponds to 190+ metadata fields

asked on August 17, 2015

Hi,

We do receive paper claims in CMS 1500 format with more than 190 fields. We are trying to migrate to QuickFields from existing legacy application. While doing so we ended up creating 190+ Zone OCR fields and each of them is associated with 190+ metadata fields. Also, there are few fields that require additional custom validations which we plan to implement using VB/C# script.

We believe creation of 190+ metadata fields might impact scanning performance. If yes, then how can we improve performance keeping all the metadata fields?

 

[We need all the fields from the Claims form and unable to skip any. Hence we ended up with 190+ fields]

Please advise!

0 0

Replies

replied on August 17, 2015

Would you really use any of the 190+ fields that you mention to perform a search within Laserfiche? That's seems very excessive. Usually you will only have metadata fields for data that you will perform a search on.

0 0
replied on August 18, 2015

Hi,

We may not use all the 190+ fields to search. We just use 10 to 15 metadata fields to search.

However, the Claims form contains 190+ metadata fields and all these fields need to be stored in the repository once the page is processed.

Please advise!

0 0
replied on August 18, 2015

Where is the Claims form coming from? What format are you receiving it as?

0 0
replied on August 19, 2015

The Claim form is coming from various doctors across the country and it is in CMS 1500 format.

We need to store all the information in our database as per the contract requirements.

However, only a handful of fields will be used as metadata fields to perform search.

Can a field be stored into repository without being part of metadata fields. If so, kindly advise. Thanks in advance!

 

 

0 0
replied on August 19, 2015

You can OCR the entire document and it will still be searchable through full text search. But as Blake mentioned, the fields are meant as an easy way to find documents based on the most commonly used properties. If you're not searching on all of them, it's not really worth the effort to separate that data out.

Unless when you say "We need to store all the information in our database" you mean a different database than the Laserfiche repository?

0 0
replied on August 19, 2015

Hi, Thanks for your response.

"We need to store all the information in our database" you mean a different database than the Laserfiche repository?

Yes, we need to store the values from at least 130+ fields to our core application database. The core application relies on these information extracted from Claim form to process and pay them accordingly.

Thank you!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.