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 _________________________________________ 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]
