If you look under our Order API Design
Page<https://wiki.openmrs.org/x/yAgJAg>at the work
from last year <https://wiki.openmrs.org/x/PIPP>, you'll see that we
actually had an indication property for orders. We removed it as a
not-yet-needed feature when scaling back. If you need it, we can certainly
put it back in.
We hadn't put indication in order group, assuming that an optional
reference to the order set used to generate the order group would provide
enough information along with the capability of attributing an indication
to the individual orders. While we *could* add indication to order group
as well, I think I'd rather we implement order_group_attribute and let you
use that for now if that's okay, so we can see if your need for an order
group indication is an outlier or a common need. You'd still be able to
label orders with an indication. Would that suffice?
-Burke
On Fri, Apr 27, 2012 at 8:50 PM, Michael Seaton <msea...@pih.org> wrote:
> **
> Thanks Burke,
>
> My plan for this would be that this would be placed during a single order
> session - that this would be created as a result of choosing a complex,
> nested Order Set and that the order groups would reflect the complexity of
> that Order Set. I agree that using this to group together Orders across
> order sessions / encounters is an approach that could be problematic.
>
> On a related note, I do want to be able to indicate the reason why a
> particular Order or a group of Orders is placed, and to use this
> information for reporting and for organization within the UI. I'm not 100%
> sure how to do this with the current data model (which doesn't have
> anything like "indication" on the order table). I'm thinking about trying
> to support this by putting "indication" on Order Group, and then allowing
> for Orders to be organized by associating them with groups (even if they
> are just single-order groups), and then assigning an indication to the
> group. Other ideas for how to approach this?
>
> Mike
>
>
>
> On 04/27/2012 08:19 PM, Burke Mamlin wrote:
>
> Hmm. I could live with something like an order_group.parent_group to link
> groups into a simple hierarchy similar to obs groups; however, your example
> suggests links across encounters, which seems like you're starting to build
> episodes of care into the orders tables. Our vision for episodes of care
> was to link encounters that were part of a treatment program. If you're
> planning on placing all of these orders in a single order session (i.e.,
> one encounter defining the entire treatment plan going forward), then
> that's fine. But if you're picturing that these are multiple groups of
> orders over time (across separate encounters), then I'm not sold & we
> should discuss the potential ramifications.
>
> For example, we allow observations to be grouped logically within an
> encounter; however, creating a hierarchy of obs groups that spans multiple
> encounters would probably break assumptions made in the API & other
> applications. I think orders grouping would be in the same situation.
>
> -Burke
>
> On Fri, Apr 27, 2012 at 5:44 PM, Darius Jazayeri
> <djazayeri+...@gmail.com>wrote:
>
>> Hi Mike,
>>
>> As I mentioned to you on skype:
>> * at first though I figured we don't need nested order groups. (But what
>> do I know?)
>> * it won't hurt anything, so why not, I guess
>>
>> -Darius
>>
>>
>> On Fri, Apr 27, 2012 at 12:06 PM, Michael Seaton <msea...@pih.org> wrote:
>>
>>> Burke and all,
>>>
>>> As I was working through some of my Order Entry use cases today, my
>>> design for Order Groups ended up evolving such that they could be nested.
>>> So, just like you can have Obs that fall into nested Obs Groups, the same
>>> would be true for Orders. An example of this might be:
>>>
>>> OrderGroup: XYZ Oncology Treatment {
>>>
>>> OrderGroup: Pre-medication {
>>> 1-N DrugOrders...
>>> }
>>>
>>> OrderGroup: Chemotherapy {
>>>
>>> OrderGroup: Cycle 1 {
>>> 1-N DrugOrders...
>>> }
>>>
>>> OrderGroup: Cycle 2 {
>>> 1-N DrugOrders...
>>> }
>>>
>>> }
>>>
>>> Order Group: Post-medication {
>>> 1-N DrugOrders...
>>> }
>>>
>>> }
>>>
>>> Where I am going with this is that you would have an OrderSet whose
>>> members might be other OrderSets, and which would produce an OrderGroup for
>>> each OrderSet.
>>>
>>> Is there anything in your conception of Order Groups that would make
>>> this approach fundamentally wrong? Is your first reaction positive or
>>> negative to this approach?
>>>
>>> Thanks,
>>> Mike
>>>
>>> ------------------------------
> Click here to
> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
> ------------------------------
> Click here to
> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
