Re: [Gnumed-devel] Results tracking

[Karsten Hilbert]

> Scratchpad items (their can be more than one) are generated in the 
> consultation for future consultations (by oneself or one's cover) on the same 
> patient.
> They are just free strings in Richard's client (and IMHO should be too for 
> ours, in the first instance)
I like this approach :-)

> Richard has agreed that this should be integrated with recalls as 
> "time-delayed scratchpad items" (so that's a string + a date)
I can live with that. Eventually this may end up being folded
into a general request-result event framework where now-normal
scratchpad items are simply free text with
onset=next_encounter and expiry=manual.

> IMHO it should be a descendant of clin_root_item as a 'p' (soaP) type.
ACK !

> Drawing the bow a bit further, we can integrate (visually, not in the 
> backend) with overdue vaccinations,
> essentially "auto-generated" scratchpad items.
That is what I meant: A patient inbox *can* (and should) present
a unified view over "due things" no matter how they are stored
on the backend.

> Scratchpad items should be tracked (that is, we need to record by whom and 
> when they are ticked off as "done")
Could *that* be achieved (in version 1 at least) by adding a
clin_narrative row simply listing that information (eg.: "PAP
smear due, ordered today by ...") ?

> Yes, the scratchpad could be integrated with a "per-patient" Inbox showing 
> unreviewed new path results and documents
Same as above (vaccs).

> But not the "central" Inbox which shows the doctor's new results/documents 
> across all his/her patients.
Exactly ! However, I don't think that provider inbox should
list individual, say lab, items per patient - but that is a
matter of taste. It should IMO only contain a message "review
Mr Smith' lab" and a single-click way to get it done. And for
such things I believe standard email may work just fine.

> >Would the above importer adhere to what Ian had described at
> >http://salaam.homeunix.com/twiki/bin/view/Gnumed/DevelRefMisc#AnchorDataImportersAPI
Yes and no. What Ian describes is geared towards interactive
import. What we do is separation of interaction (scanning,
metadating) from unattended automatic import.

> Ideally yes. However faxes/scans need metadata to identify the patient, 
> which must be added manually.
> Karsten's description implies this is done at scan time but prior to 
> importing (and stored where?
The metadata that's added in the preparative steps is kept in
files. Per document (may contain several pages) a directory is
created. In it there are the data file(s) and a metadata file.

> One (presumed) problem with this approach is scanned files aren't available 
> until the next day (is this right?)
In our installation this is correct. However, it depends on
how often you care to call the importer. Could be cronned for
every hour. Could also be called manually via some button. We
just don't do it.

Eg. if you need scans *now* add an [import now] button to your UI.

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