[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Scanning and adding to the patients' document archive
From: |
Jim Busser |
Subject: |
[Gnumed-devel] Scanning and adding to the patients' document archive |
Date: |
Wed, 06 Jan 2010 02:00:20 -0800 |
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
(i) perform discontinuous loadings of the scanner… more "jobs" but this would
lower the chance of downstream human error splitting the file on a PC
--> I think this is the way to go when there exists no cover page having to be
shared by multiple patients.
--> Within the bundle of a single patient, to subdivide pages into multiple
discrete jobs all on the same patient seems to just make more work, however it
*may* make sense is to re-sequence the pages so that despite having arrived in
some arbitrary order even as two back-to-back faxes, the desk staff might
*physically sort* the pages into a sequence that would better assist
segmentation into multiple distinct kinds of GNUmed documents
--> 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 **
(ii) load multiple patients' papers into the scanner i.e. as a bundle –
repeating as needed – to produce (one or, over time, multiple) multi-page
digital files.
Each multi-page file will contain multiple patients' data. Therefore, in a
separate step, these file contents need to have their contents "split" into
respective patients. At this point, the workflow may be the same as if the file
(e.g. an efax) had been received electronically.
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:
1) an unrelated patients' data to be saved into the file of the active patient,
and
2) (equally concerning) will risk some other patient's data getting
functionally "lost", and unactioned
I was thinking it might be helpful to have an app whose left panel depicts
individual page views (zoomable, double-clickable) and a right pane into which
one or more pages could be dragged, in which the selected pages would be merged
to create a new file. Actually, gscan2pdf comes close:
- click Import icon (or Ctrl I)
- Import parses (e.g.) TIFF or PDF, other file formats too
- confirmatory dialog: extract images / pages [1] through [n]
- appends to any images remaining from the prior import
- left pane: thumbnails
shift for continuous selection
alt-ctrl for discontinuous selection
up / down cursor keys determine the thumbnail in focus
- right pane: viewing of the thumbnail that is in focus
crop; negate (black < > white); threshold; unsharp; call GIMP
zoom; rotate
- Renumber (Ctrl R) pages: (all, selection) (start #, increment)
- Save (Ctrl S): supports continuous / discontinuous selections
- Cut (Ctrl X): selection of images/pages from left pane
- Clear all pages from left pane
One further variable (use case) exists where "meta" data from the cover page is
important on account of when it's *missing* from per-page fax headers. Data
like the point of origin, the sending party, even the date sent.
This turns out to be well-manageable in gscan2pdf, because the cover page can
be part of a continuous selection which is then Ctrl + S saved after which the
cover is dropped from the selection (Ctrl Alt clicked), and the
already-saved-still-selected images cut (Ctrl X), then down-cursoring to
identify the maximum extent of the next patient, then extending the selection
up to the cover, and so on. Edit menu "Undo" support.
Possibly these files would be saved with characters from the patient surname,
plus comma, plus space, plus firstname characters.
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