Order Entry Design update

classic Classic list List threaded Threaded
3 messages Options
Wyclif Luyima-2 Wyclif Luyima-2
Reply | Threaded
Open this post in threaded view
|

Order Entry Design update

Hi everyone,

This week, i having been focusing on how we can redesign our new order entry API, Burke and i spent sometime a couple of times to discuss how we want to re-model it, you can see the notes on this etherpad and use cases for more details on what the views are. The key thing here is that we want to come up with a rather simpler design that will allow creating patient specific orders for the first pass but leaving us with leverage to iterate and incorporate new features after its initial release.

I spent some time today going through/reviewing the code in the order entry branch, i created this order entry branch review if you wish to have a look at it, below is the summary of the variations, the ones in red are additions that were made in the branch but we intend to discard according to what i have discussed with Burke and what was shared on this week's design call.

Additions:
  • New columns to orders table (6+)
  • Support for both structured and unstructured orders
  • New columns to drug_order table (3+)
  • TestOrder as subclass of Order
  • OrderGroup
  • OrderSet, PublishedOrderSet, OrderSetMember
  • Oderable
  • Generic Drug - this is a wrapper for a concept of class drug to represent an Orderable
  • OrderSaveHandler to assign new order numbers
  • Additions to OrderValidator in relation to added columns to the orders table
Removals:
  • OrderType and any web stuff related to handling them
  • Removed complex and complex_dosing columns from drug_order
I'm still indifferent between whether we should do this in a module or rework it in core and the main controversy is around the order type table and if we don't want to break existing code in module and legacy systems.

If we are to get rid of  order type as this is the case in the branch or rename it to something else like order category and don't mind breaking consuming code, i guess we can just remove the added unwanted additions and include any new stuff, merge it into trunk. I also hope consumers of the API don't get confused with the changes

On the other hand, if we don't want to force module developers and legacy systems to refactor their code when they upgrade and wish to see the module evolve more rapidly to support more features since a couple might not be available in the initial release, then we can implement this in a module. It is very likely that we will be copying over code from the branch the only pain being we have to incorporate back order types if we are to support them which i believe we are going to.

What next?
 - Can we decide on how we want to do categorization of orders and how to support more granular break down of these categories? Though i feel that supporting more granular categorization can be something we can do at a later stage. Or can't we leave this to be done from a separate module?
 - Can we decide on whether this should be done in core or a module? My vote is doing it in a module.

Responses to these will give me a better ground to come up with a more reasonable proposed design and figure what needs to be done in which sprint in case the work is projected to span over more than one development sprint.

Wyclif



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

Re: Order Entry Design update

Hi.  I want to re-iterate PIH Rwanda's main use case, that we've been desperate for for a good long while:  assuming there are standardRegimen templates (like the xml global property that currently exists), I use that template to create some DrugOrders.   There's currently no way to map back to the standardRegimen template after-the-fact, given a Set<DrugOrder> containing the current drugOrders for a patient.

I've worked around this a number of times doing matching against templates using a match-scoring system, but this is a pretty awful approach. 

Your email has OrderGroup in black and OrderSet in red, and I don't know what that means.  But if our use-case -- to have the capability to explicitly map a DrugOrder to a standardRegimen -- can make it into this push, that would be very very much appreciated.

d

On Thu, Apr 19, 2012 at 3:19 PM, Wyclif Luyima <[hidden email]> wrote:
Hi everyone,

This week, i having been focusing on how we can redesign our new order entry API, Burke and i spent sometime a couple of times to discuss how we want to re-model it, you can see the notes on this etherpad and use cases for more details on what the views are. The key thing here is that we want to come up with a rather simpler design that will allow creating patient specific orders for the first pass but leaving us with leverage to iterate and incorporate new features after its initial release.

I spent some time today going through/reviewing the code in the order entry branch, i created this order entry branch review if you wish to have a look at it, below is the summary of the variations, the ones in red are additions that were made in the branch but we intend to discard according to what i have discussed with Burke and what was shared on this week's design call.

Additions:
  • New columns to orders table (6+)
  • Support for both structured and unstructured orders
  • New columns to drug_order table (3+)
  • TestOrder as subclass of Order
  • OrderGroup
  • OrderSet, PublishedOrderSet, OrderSetMember
  • Oderable
  • Generic Drug - this is a wrapper for a concept of class drug to represent an Orderable
  • OrderSaveHandler to assign new order numbers
  • Additions to OrderValidator in relation to added columns to the orders table
Removals:
  • OrderType and any web stuff related to handling them
  • Removed complex and complex_dosing columns from drug_order
I'm still indifferent between whether we should do this in a module or rework it in core and the main controversy is around the order type table and if we don't want to break existing code in module and legacy systems.

If we are to get rid of  order type as this is the case in the branch or rename it to something else like order category and don't mind breaking consuming code, i guess we can just remove the added unwanted additions and include any new stuff, merge it into trunk. I also hope consumers of the API don't get confused with the changes

On the other hand, if we don't want to force module developers and legacy systems to refactor their code when they upgrade and wish to see the module evolve more rapidly to support more features since a couple might not be available in the initial release, then we can implement this in a module. It is very likely that we will be copying over code from the branch the only pain being we have to incorporate back order types if we are to support them which i believe we are going to.

What next?
 - Can we decide on how we want to do categorization of orders and how to support more granular break down of these categories? Though i feel that supporting more granular categorization can be something we can do at a later stage. Or can't we leave this to be done from a separate module?
 - Can we decide on whether this should be done in core or a module? My vote is doing it in a module.

Responses to these will give me a better ground to come up with a more reasonable proposed design and figure what needs to be done in which sprint in case the work is projected to span over more than one development sprint.

Wyclif



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Wyclif Luyima-2 Wyclif Luyima-2
Reply | Threaded
Open this post in threaded view
|

Re: Order Entry Design update

Just to clarify, OrderGroup was intended to be in red implying it isn't meant to be included in the new design1 for the first pass, it doesn't mean we won't include in the long run though.

Wyclif

On Thu, Apr 19, 2012 at 7:57 PM, Dave Thomas <[hidden email]> wrote:
Hi.  I want to re-iterate PIH Rwanda's main use case, that we've been desperate for for a good long while:  assuming there are standardRegimen templates (like the xml global property that currently exists), I use that template to create some DrugOrders.   There's currently no way to map back to the standardRegimen template after-the-fact, given a Set<DrugOrder> containing the current drugOrders for a patient.

I've worked around this a number of times doing matching against templates using a match-scoring system, but this is a pretty awful approach. 

Your email has OrderGroup in black and OrderSet in red, and I don't know what that means.  But if our use-case -- to have the capability to explicitly map a DrugOrder to a standardRegimen -- can make it into this push, that would be very very much appreciated.

d

On Thu, Apr 19, 2012 at 3:19 PM, Wyclif Luyima <[hidden email]> wrote:
Hi everyone,

This week, i having been focusing on how we can redesign our new order entry API, Burke and i spent sometime a couple of times to discuss how we want to re-model it, you can see the notes on this etherpad and use cases for more details on what the views are. The key thing here is that we want to come up with a rather simpler design that will allow creating patient specific orders for the first pass but leaving us with leverage to iterate and incorporate new features after its initial release.

I spent some time today going through/reviewing the code in the order entry branch, i created this order entry branch review if you wish to have a look at it, below is the summary of the variations, the ones in red are additions that were made in the branch but we intend to discard according to what i have discussed with Burke and what was shared on this week's design call.

Additions:
  • New columns to orders table (6+)
  • Support for both structured and unstructured orders
  • New columns to drug_order table (3+)
  • TestOrder as subclass of Order
  • OrderGroup
  • OrderSet, PublishedOrderSet, OrderSetMember
  • Oderable
  • Generic Drug - this is a wrapper for a concept of class drug to represent an Orderable
  • OrderSaveHandler to assign new order numbers
  • Additions to OrderValidator in relation to added columns to the orders table
Removals:
  • OrderType and any web stuff related to handling them
  • Removed complex and complex_dosing columns from drug_order
I'm still indifferent between whether we should do this in a module or rework it in core and the main controversy is around the order type table and if we don't want to break existing code in module and legacy systems.

If we are to get rid of  order type as this is the case in the branch or rename it to something else like order category and don't mind breaking consuming code, i guess we can just remove the added unwanted additions and include any new stuff, merge it into trunk. I also hope consumers of the API don't get confused with the changes

On the other hand, if we don't want to force module developers and legacy systems to refactor their code when they upgrade and wish to see the module evolve more rapidly to support more features since a couple might not be available in the initial release, then we can implement this in a module. It is very likely that we will be copying over code from the branch the only pain being we have to incorporate back order types if we are to support them which i believe we are going to.

What next?
 - Can we decide on how we want to do categorization of orders and how to support more granular break down of these categories? Though i feel that supporting more granular categorization can be something we can do at a later stage. Or can't we leave this to be done from a separate module?
 - Can we decide on whether this should be done in core or a module? My vote is doing it in a module.

Responses to these will give me a better ground to come up with a more reasonable proposed design and figure what needs to be done in which sprint in case the work is projected to span over more than one development sprint.

Wyclif



[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list