[Top][All Lists]

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

Re: [Gnumed-devel] address@hidden: Archetypes: Medication order, risks a

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] address@hidden: Archetypes: Medication order, risks and goals]
Date: Wed, 1 Jun 2005 13:37:50 +0200
User-agent: Mutt/

On Wed, Jun 01, 2005 at 08:28:22PM +1000, E Dodd wrote:
> On Wed, 1 Jun 2005 18:26, Karsten Hilbert wrote:
> > > It is not complete and needs more work, but has many of the features of
> > > a medication order that are required in the health system. This is not a
> > > prescription (which is a set of medication orders) - all this
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> the prescription refers to a single medication order
> i think that he is quite confused between the *prescription form* and the 
> data, because as we discussed a form can contain up to three items in most 
> jurisdictions.
I am pretty sure most people actually mean "prescription form"
as an entity composed of medication orders (items, that is)
when they sloppily say "prescription".

Note the "form" is misleading, too, as there may not be any
real form yet or anymore. With "prescription form" I am
referring to the aggregation of one or many medication orders
complete with dosage, instructions etc that is intended to be
used on, say, a paper form. IOW the abstract concept of what a
paper form represents.

Anyways, back on target:

1) select items (medication orders)
   - add dosage/instructions/...
   - add to queue

2) assemble prescription aggregate instance
   - authorise/kick-off
   - subject to locale rules, eg target channel, no of items
   - queue up for outbound processing

3) process outbound queues
   - get from queue
   - process
   - send to target (print/mail/fax it)

It may be easiest to start off with 3). Adrian, what do you
think ?

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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