gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Results tracking


From: Ian Haywood
Subject: Re: [Gnumed-devel] Results tracking
Date: Sun, 06 Mar 2005 13:11:45 +1100
User-agent: Mozilla Thunderbird 0.8 (X11/20041012)

J Busser wrote:

also, presuming we want only *one* scratchpad item per patient, then in whatever table the scratchpad resides (if the table is designed to also hold non-scratchpad items) we would have a field like is_scratchpad, and the combination of is_scratchpad and <patient identifier> would be unique.
My understanding of Richard's concepts is that the 2 are separate.
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)
Richard has agreed that this should be integrated with recalls as "time-delayed 
scratchpad items"
Classic example is Pap smear: you don't want it to appear in your scratchpad 
now, but in two years
time (so that's a string + a date)
IMHO it should be a descendant of clin_root_item as a 'p' (soaP) type.

Drawing the bow a bit further, we can integrate (visually, not in the backend) 
with overdue vaccinations,
essentially "auto-generated" scratchpad items.
Scratchpad items should be tracked (that is, we need to record by whom and when they are 
ticked off as "done")

Yes, the scratchpad could be integrated with a "per-patient" Inbox showing 
unreviewed new path results and documents

But not the "central" Inbox which shows the doctor's new results/documents 
across all his/her patients.

Would the above importer adhere to what Ian had described at
http://salaam.homeunix.com/twiki/bin/view/Gnumed/DevelRefMisc#AnchorDataImportersAPI

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?
Karsten, could you elaborate on this)
in which case this would work.
One (presumed) problem with this approach is scanned files aren't available 
until the next day
(is this right?)
If not, no, a separate importer which is manually operated (to match files to 
patients) is required.

Ian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]