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 <[email protected]> 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 <[email protected]> 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<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 >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ 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]
