On Mon, May 30, 2005 at 12:00:13AM +0100, Adrian Midgley wrote: > > prescription: > > > > - the database equivalent of the finished (paper) form a > > patient is given to carry to a pharmacy > in the UK, up to 3 items can go on one form. Same in Germany. What do you call that form ? We call it "Rezept".
> If a patient is given 4 items, has he had one prescription (on two paper > forms) or two prescriptions, one for 3 items and one for 1 item? True to my above definition (and to common use here) he would have had 2 prescriptions (2 Rezepte) with a total of 4 items (drugs) prescribed. Arching back to Jim's treatment plan comments there would be 1 treatment plan with 4 (drug) items prescribed producing 2 prescription forms. > I think there is a faultline in the definition, hence I talk about > items. I agree but we need a name for the grouping on the form, too. Let's call it "prescription form". > If a patient has 3 drugs (prescriptions/items, to me) for hypertension, > and because of a newly painful knee gets another item - Paracetamol - > for it, and all 4 are issued at the same time, does he have two > prescriptions, one for HT and one for knee pain, albeit they may be > arranged on the paper as 2 HT drugs and Paracetamol on page 1 and 2 HT > drugs on page 2? With my above definition he would in Germany and UK have 2 prescription forms no matter how the drugs are arranged. Either 2/2 or 3/1. Each item is tagged with the corresponding problem it was prescribed for anyways independant of how the prescription form was issued. Wait, I notice you are talking about pages. In Germany prescription forms only ever have one page (may have carbon copies, though). So in that case the patient would have 2 prescription forms for a total of 4 prescribed items. > > One reason for > > keeping the actual text with the form instance is that users > > may well edit the drug name right before printing > > Ouch. This would be specifically forbidden in the UK, under > requirements for accreditation (compliance testing). So the requirements pretty much dictate use of a database. Which is fine. I was also referring to free-text entries for items that happen to be missing in the database. One day we would write them in one way the next day we would use a different spelling/abbreviation. I have seen that in practice many times. Also, as Jim pointed out, legalese may require us to be able to say: This is what was printed on the form. > But if we can edit the items, I think we would like them to be presented > to us next time. There would be several sources of items going into the prescribed-today queue: - user submitted a free-text item - user selected a drug from a drug database - user selected an item from the current medication list - user selected a reprint of a previous form instance The last bullet may actually be a shortcut: The user wants to repeat an entire previous description and simply selects it for adjusted reprint. > > In summary, prescriptions would be form instances. Form > > instances are defined by a form template and associated form > > data. > > I have not seen it that way, I think - rather I see each preparation > prescribed as an entity, and putting them on a form just as something > one might do in order to output a list of entities. Sure, each prescribed item is an entity in itself. They will eventually be grouped into a prescription form instance. The form instance (eg template + data) is then kept (for mostly medico-legal reasons). > > 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. > > Definitely something to do before printing (or despatch electronically) > occurs, I'd think. SO per item rather than per form. Yes. Per item. > > ... Only at the end would I issue the "prescribe queued > > items" command > Print/send/despatch/release/authorise rather than prescribe, I think. You are right: "authorise queued items". Prescribing was done when queuing the item. 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
