Re: [Gnumed-devel] Scanning and adding to the patients' document archive

[Karsten Hilbert]

An excellent assessment:

> When a patient record is not yet in focus:
> *******************************************
> The user possesses one or both of:
> 
> - a stack of paper (often on several patients) to be processed, and/or
> - as-yet unattached digital files (e.g. efax) whose contents may need to be 
> split
> 
> The user then, in order to keep paper patients distinct, must either

...

> --> if it is feasible for GNumed to operate this scanner, the task is then 
> best done from within the GNUmed plugin but if the logistics of leading the 
> scanner are a challenge, then it is best done using whatever nonGNU GUI is 
> best suited to the job including naming the document and saving the image to 
> a fileshare (if applicable) should be used.
> 
> ** or **

...

> --> This is perhaps best done *outside* the context of the GNUmed plug-in, 
> because user inattention or mis-clicks operating a plugin with a patient in 
> focus could cause:

The very complexity of the task you so succinctly describe
make me believe it should be handled by dedicated software
such as ...

> Actually, gscan2pdf comes close:

which means gscan2pdf (or whatever is identified to serve
best) should be lobbied / developed to be improved with
respect to

- feature(let)s the user is missing
- (pre)-configurability
- controllability

> In a perfect world, gscan2pdf might gain further configurability:
> - by default, retain the source file name and extension
> - be configurable (prefs) for target:
>       … Download directory (and drive)
>       … file format to save as: (original, other specified)
>       … name save as any combination of
>       - last-saved file name
>       - source file name
>       - creation datetime of source file
>       - current datetime
>       - auto-incrementing serial number
>       - optional auto-incrementing suffix (-0, -1, -2)
>       - OCR preference-saving
>               GOCR vs Tesseract
>               Tesseract language
> 
> - configurable post-processing
>       - chain to OCR? (yes, no)
>               save OCR text in a layer when the file format is PDF
>       - move imported file to another directory
>               e.g. …/processed

This is a very reasonable list of wishes. If I had the use
case I would identify the most crucial feature needs, and
those which have the most gain, and lobby for those.

Example: gscan2pdf doesn't necessarily need all the
nitty-gritty filename handling options if it can be told on
startup:

- where to save files to
- the file format
- a filename template within which to only substitute a
  counter or some user-generated part

and be configured to:

- invoke a shell script from a button press and import the
  result from a filename as a layer or comment

That would allow for all sorts of control of the filename
and all sorts of external post-processing (be it thumbnail
generation, OCR, signing, whatnot).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346