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<http://notes.openmrs.org/orders-service> and use cases<https://wiki.openmrs.org/display/RES/Order+Entry+Sprint+1+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<https://source.openmrs.org/cru/CR-TRUNK-634>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 _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
