Semi-automating Document Import

For some time, I had been struggling to identify a workflow that could allow praxis assistants to scan documents on behalf of the doctors.

Until now, the only clearly-supported workflow was one in which the documents that pertain to an identified (and in focus) patient of interest are physically accessible to the doctor who would

(1) import them via scanner (or via file-picker selection of already-scanned files), and then

(2) as a pre-condition to being able to save, assigning an episode and a document type

************************************ Praxis assistants (manual method) ************************************

Praxis assistants can save the doctors time by pre-scanning paper to disk (detaching documents from email, downloading from a fax server) but it leaves the group praxis problem of how to cluster subsets of documents for different in-praxis primaries.

Doing it based on temporary file system subdirectories is one possibility, however this would need the praxis staff to

(i) in the case of paper originals, segregate the stacks by responsible doctor, and then change the default subdirectory based on the intended reviewer

(ii) in the case of documents that arrive digitally, open and inspect them to deduce the intended reviewer, then save accordingly

Even under such a system, the doctor must yet open the document to identify the patient (unless the staff did extra work to rename files by patient name). Then - activate the patient - go to Attach document plug in - apply file-picker selection (or, if supported by OS, drag-and-drop) - now actually read these documents, to identify the episode and type and a comment and any free-text - review and sign, plus minus "tag"

This is tedious for the doctor. The hooks framework could, when activating a patient, create the episode "unattributed incoming data" should it not exist, which praxis assistants could select from the phrasewheel.

I have come up with a plan (not the code for) a script-based alternative.

************************ Script-based alternative: ************************

1) establish file system subdirectories which begin with pk of praxis providers (as obvious from active person's window title in GNUmed client):

   .incoming/...(to be imported)
      8 McCoy L/docs 
      11 Bashir J/docs
      etc
   .incoming/processed/... (already_imported)
      8 McCoy L/docs… 
      11 Bashir J/docs…
      etc

2) praxis assistants deposit scans into doctors' respective
.incoming/unprocessed/...

3) Script polls (or is manually driven to process) above subdirectories and on exiting with success moves the original filesystem docs to ./processed/…

4) Where subdirectory does not begin with a number (say there are loose files in .incoming/)
--> script asks which (if any) one in-praxis reviewer to pre-assign
else
--> script understands to assign in-praxis reviewer based on leading number fragment of subdirectory name

5) each document is imported in its own row in

clin.incoming_data_unmatched.data (bytea)

6) script sets

--> .fk_provider_disambiguated = pk of intended reviewer (if fed or derived)
NOTE
we need a new v16 column for .fk_provider_disambiguated

--> .type = 'document' (unless value over-ridden via script launch dialog)

--> .other_info = filename in OS (in case already-named for patient)

Benefits:

1) staff can use the same (TBA) generic plugin as would be used to allow unmatched imported lab data to be matched
- the plugin should enable to view the doc that is in .data (the scanned PDF or TIFF or JPG) in a similar way to how the Attach document plugin works

2) once the staff would assign the patient identity
set clin.incoming_data_unmatched.fk_identity_disambiguated = dem.identity.pk

the script could assign the intended_reviewer
--> clin.incoming_data_unmatched.fk_provider_disambiguated = dem.identity.fk_primary_provider

3) the inboxes could recognize and report, on a provider-specific basis, the existence of _unmatched documents to attach

4) an _unmatched plugin button could transfer current _unmatched document into blobs

(a) for patient already-identified by fk
(b) failing value for fk, then for the patient who is currently in focus

5) manual step as in 4 would not be needed if patient was already designated by pk AND script could create/assign generic episode

"unattributed incoming data"

which the provider could revise as appropriate in the same step as they would be signing the document

-- Jim
Topic revision: 08 Jul 2011, JamesBusser
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark