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 <mailto:djazayeri%2b...@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
<mailto: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
<mailto: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]
