On Sun, May 29, 2005 at 10:05:46PM +0100, Adrian Midgley wrote: > Prescriptions in history are not very bulky, basically a line in a table > for each one (in systems I've looked at, havn't dug that far into > GNUMed, yet). > So the overhead of storing on each occasion a prescription is issued, > not a pointer to a list of descriptions of items, but the actual text of > the item is small. > The design is surely simpler? > One specific benefit is that when the name of the drug changes - > Frusemide becomes Furosemide, or whatever, the record of what was > prescribed remains the record of what was described. You don't have to > add another line to teh dictionary to point to, and you don't have to go > back through the history changing it. Although you can.
Let's be very precise here and make sure we talk about the same things: prescription: - the database equivalent of the finished (paper) form a patient is given to carry to a pharmacy current medication: - an item in the list of medications a patient is taking regardless of whether the items in this list come from a <prescription> or not Now, I think our current objective was to generate prescriptions, right ? Let's assume paper forms for now. As far as those go one surely wants to keep around the actual text printed onto the form regardless of changes elsewhere. It could be argued that a "cache" table in the local clinical database may contain all versions of a drug name ever used and forms just link to it. However, this IMO goes against the notion of a form instance being a self-contained unit of template and data (deliberate denormalization). Which in turn means we would indeed want to store the actual text of a prescription right in the form instance regardless of a cache table. However, the form instance may still have a (then redundant) link to that cache table for more feature-rich coding. One reason for keeping the actual text with the form instance is that users may well edit the drug name right before printing and one would not want to keep all edited drug names a user comes up with in the cache table. In summary, prescriptions would be form instances. Form instances are defined by a form template and associated form data. The form data is denormalized actual text as it was when the form instance was considered finished by the user. It may, however, include pointers into a cache table of drugs (which may at some future point in time turn stale). Notice how we haven't taken into account any interaction with a current medication list at all yet. Which can be developed entirely separately and connected by a cleanly defined in/out API. So much for how to handle prescriptions. I just now realize that the pick - queue - group_as_prescription workflow is very amenable to supporting the problem-oriented documentation of GNUmed. Eg. from within one progress note editor I would queue one drug for prescription which thus is tagged with the appropriate problem. From within another progress note I might queue another drug tagged with that other problem. Only at the end would I issue the "prescribe queued items" command which would then group queued drugs into form instances and send those to the printer. The queued drugs would then be removed from the queue but the form instance(s) would be kept around. This is also one junction at which interaction with the current medication list would occur. BTW, the queue - group part is quite exactly the way Richard's prescribing mechanism works as I recall. Adrian, I very much enjoy this exchange of thoughts. Perhaps it may lead to a useful "generic" implementation of steps 2/3 of the prescription handling as I outlined earlier. 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
