Mark –
I would be concerned about putting too much use-case specific behavior
into the data model as opposed to the business logic. I also agree with Burke
that you are starting to get orders that extend beyond an encounter. I can’t
imagine that the default behavior is really to follow the program unless
cancelled rather than treat-evaluate-treat. I would look toward something like
tying order groups to program states where the program is a treatment program.
Saludos, Roger
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Seaton
Sent: Friday, April 27, 2012 8:50 PM
To: [email protected]
Subject: Re: [OPENMRS-DEV] Nested Order Groups
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
<[email protected]<mailto:djazayeri%[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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<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
