Burke --
Why not encounterless orders? Are HL7 orders required to
appear in a context which supports encounter creation? My recollection is no
(see the simple lab transaction from last summer's GSOC), but then again I
haven't been able to see things staring me in the face lately. Maybe as long
as we are going to redesign orders for 1.10, you could put up a wiki page for
that and describe your experience in implementing orders and the conclusions
you have drawn.
From: [email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin
Sent: Tuesday, January 24, 2012 7:39 PM
To: [email protected]
Subject: Re: [OPENMRS-DEV] Creating orders
FYI - regardless of the current data model design, it's very likely that we
will not allow encounterless orders in the future. Another good reason to
create encounters for orders.
-burke
On Tue, Jan 24, 2012 at 4:10 PM, Dave Thomas
<[email protected]<mailto:[email protected]>> wrote:
+1 for adding the orders to an encounter, and using a specific encounter_type
to represent exactly what those orders 'mean' (1 encounter type specifically
for lab orders, another for prescribing). These encounter types can then be
used to search for open orders or open prescriptions.
d
On Tue, Jan 24, 2012 at 9:42 AM, Ben Wolfe
<[email protected]<mailto:[email protected]>> wrote:
Roger, orders.patient_id and orders.orderer_id exist for encounterless orders.
For orders with encounters these are copies from encounter. (or I suppose the
orderer could be different from encounter.provider)
Ben
On Tue, Jan 24, 2012 at 11:12 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR)
<[email protected]<mailto:[email protected]>> wrote:
Rowan --
Creating an order without an encounter is not possible because
patient and provider come from the encounter.
If you are dealing with specimens collected at the facility,
e.g. by a phlebotomist, you will want to have that as an encounter and the
order can be attached to it; however, the provider is not really the
phlebotomist.
You could have "Order lab tests" and "Order drugs" checkboxes
on the form; the module could examine them and display the appropriate forms
with the encounter etc. information preloaded. This is extensible to other
types of orders -- referrals, non-lab tests (e.g. x-rays), physical therapy,
diet, etc. This might require an extension point in the encounter screen to
show what orders go with each encounter, and an "Add Order" button for each
encounter to add them directly there.
I would not recommend upgrading to 1.9 since we are going to be
working on orders for 1.10 and the data model is going to change.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rowan Seymour
Sent: Tuesday, January 24, 2012 5:55 AM
To:
[email protected]<mailto:[email protected]>
Subject: [OPENMRS-DEV] Creating orders
We have two modules under development here at the Rwandan MOH which relate to
orders - one for drug orders and one for lab test orders. The drug order module
currently has a dashboard tab portlet where new drug orders can be added to a
specific encounter. The lab test order module also has dashboard tab portlet
where new lab test orders are created - but these are added to a newly created
encounter.
Neither of these solutions seem ideal - the former requires the clinician to
search for an encounter which is awkward. The latter creates an extra
encounter. So I was wondering what the best practice here is. The options as I
see them are:
1. Create the orders without an encounter (I think this is possible...)
2. Add them to an existing encounter created (e.g. the encounter from the
consultation form like the drug orders)
3. Create a new encounter to hold the orders (like "lab test order"
encounter)
4. Add sections for lab tests and drug orders to the whatever consultation
form is being used (this isn't implemented in htmlformentry yet tho?) and this
would make sure all the orders end up in that one encounter.
5. Upgrade to 1.9 and group everything into a "visit"? (obviously not
happening anytime soon)
Advice appreciated
Rowan
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
