> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
