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]> 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]> 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]> 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]] *On Behalf Of *Rowan >>> Seymour >>> *Sent:* Tuesday, January 24, 2012 5:55 AM >>> *To:* [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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> **** >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
