Validation: Module Checker

The validation phase consists in the subsequent checking of information acquired by the pen and consequent processing, making any necessary modification and “approving” the transaction. At this point the information flow is completed, eventually integrating data in specific databases or any other operation foreseen by the application. The linchpin of this process is the VF Module Checker, a Web component which enables the user to compare the image of the data written with the Anoto pen with information by the same obtained from the VF Engine; the validation phase takes place through a Web Application Custom that the designer has made available to this end. In the simplest case, one or more JSP pages will show the user the list of data to be validated. After validation the VF Engine, in collaboration with the servlet custom, verifies the modified data and carries out what foreseen by the specific logic.

Panoramica – Module Checker:

The operator, after having downloaded the data, will log in the application by a web browser. Access is allowed after giving personal credentials (username and password), according to a program prefixed by the Customer. The Customer will be able to grant different content rights to each profile, such as: only view of forms, view and modification of forms, right to modify and/or view only personal forms (thanks to a link between the profile and a single pen) or those of all operators, or only of some groups of operators.

We propose some screenshots in a Form Processing version:

1) The operator logs in with the univocal profile (username and password) assigned to him/her in the profiling phase  of the system:

2) The operator logs in and can carry out a research of transactions to be validated. Research standards are agreed upon together with the Customer in the deployment phase. In this case we can see the possibility of data search by type of form, identification of the pen that completed the form and the state of the form (validated or to be validated). 

3) By not imposing any parameter the complete list of transactions to be validated can be viewed, with some data highlighted which is considered specific to the transaction prefixed by the customer. In this case: name of form, number of call, date and time of transaction, pen identification, selector of image visualization or state of validation,  transaction deletion. All of these parameters will be configurable according to customer specifications: 

4) Clicking on the state icon it will be possible to access the heart of Form Processing, or the validation interface.

This interface puts the image of the completed form together with the interpretation carried out by the ICR  engine allowing, by automatic realigning and highlighting correspondence, (all in one click) the institutive and rapid comparison of effective text and interpretation of the same, as well as making any corrections in case of error by the same ICR.

It will also be possible (by clicking at the top of the page) to modify viewing at user discretion, save modifications for a subsequent validation completion, verify internal coherence of interpreted data according to parameters defined by the customer and finally to proceed to the effective “approval” of the form and consequent release of the .jpg and .xml file. In following screenshots there is an example of interface validation and facilitated error and incoherency management supplied by the Local Health Authority no 10 of Florence for an application concerning the acquisition of emergency/118 emergency forms.

Example of automatic incorrect value detection: 

 

 

Example of facilitated correction (based upon dictionaries supplied by the customer) of the wrong value: 

Example of automatic data incoherence indication:

Example of management with attached images (with D.A.R.K.):