Nested Order Groups

classic Classic list List threaded Threaded
6 messages Options
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Nested Order Groups

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

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Nested Order Groups

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 <[hidden email]> 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

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Nested Order Groups

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 <[hidden email]> 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 <[hidden email]> 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


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: Nested Order Groups

If you look under our Order API Design Page at the work from last year, 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: Nested Order Groups

In reply to this post by Michael Seaton

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Seaton
Sent: Friday, April 27, 2012 8:50 PM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]> 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


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list