Ok, that makes life simpler. The work on the "orderentry" module should be stopped asap and the work moved to trunk (again). We must mark relevant order calls/methods as deprecated in 1.9.x before the release.
We don't want an "ordercompatiblity" module because we are modifying the core order tables. So using "ordercompatibilty" with 1.10+ would cause the exact same confusion as an "orderentry" module in 1.9 would! Ben On Thu, Apr 26, 2012 at 8:34 PM, Burke Mamlin <[email protected]> wrote: > Mike/Darius/Ben/Wyclif/Daniel/Roger, > > From our recent design calls, I agree with Wyclif/Darius/Mike, that we are > not being pressed for enhancements to order entry as much as the need for > improved order sets & grouping, which, via a module, could be adapted to > work with the existing order tables as well as the enhanced order tables in > a future version (e.g., 1.10). > > -Burke > > > On Thu, Apr 26, 2012 at 7:44 PM, Darius Jazayeri <[email protected]>wrote: > >> How about if we build and experiment with order groups and order sets in >> a module, and we refactor order in core in 1.10, pulling in the order group >> and set code from the module when it's ready. >> >> That lets us develop new end user functionality in a module usable with >> 1.9, while saving the under the hood refactoring for core. >> >> So #1, basically. >> >> -Darius (by phone) >> >> On Thu, Apr 26, 2012 at 2:38 PM, Michael Seaton <[email protected]> wrote: >> >>> ** >>> Option #1 is also conclusion I have arrived at. It likely means >>> introducing backwards-incompatibilities that module developers will need to >>> deal with (like we did with Provider in 1.9), which will be annoying, but >>> at least everything is predictable. It is far worse, IMHO, than having the >>> possibility that someone is unwittingly using a combination of modules that >>> are storing / retrieving Orders from 2 different places. That is a recipe >>> for disaster. >>> >>> A possible variation on this is to do something like we did with >>> reporting back in the day: move all current Order functionality out of >>> core and into an "ordercompatibility" module (not my proposed name). Then, >>> develop a new "orderentry" module which does things the right way and can >>> evolve at it's on pace. We would then add something to the module >>> framework to allow modules to indicate which other modules it does not play >>> nicely with, to ensure that no one ends up running both of these in >>> parallel. >>> >>> But I still think that this isn't better than #1, because a key >>> unwritten rule would be broken - that installing the module would change >>> your _core_ data in a non-reversible way. I guess we could treat this >>> module like sync - where once you install it, you are stuck with it unless >>> you jump through hoops to get it off of your system... >>> >>> Mike >>> >>> >>> >>> >>> >>> On 04/26/2012 04:42 PM, Wyclif Luyima wrote: >>> >>> Darius sent out an email yesterday, saying we should halt work on order >>> entry module and that i should look at the 3 options again, and after >>> carefully looking at all three today i have realized options 3 is most >>> likely going to keep us going in circles and is going to be a pain both to >>> us and the PIH guys. >>> >>> Wyclif >>> >>> On Thu, Apr 26, 2012 at 4:28 PM, Ben Wolfe <[email protected]> wrote: >>> >>>> I thought we already decided on option 3...multiple times. No? >>>> >>>> >>>> On Thu, Apr 26, 2012 at 4:26 PM, Wyclif Luyima <[email protected]>wrote: >>>> >>>>> Hi Guys, >>>>> >>>>> I have spent some time today analysing the 3 possible solutions as >>>>> to how we can rework order entry. >>>>> Here is an etherpad <http://notes.openmrs.org/new-order-entry> that >>>>> summarizes my views and my proposed solution. I have laid out what needs >>>>> to >>>>> be done, pros and cons of each solution and at the end proposed what i >>>>> think the most convenient solution from my perspective taking into >>>>> consideration what i think are the strong/key issues that Mike has been >>>>> pointing out. If you are eager to know what it is, i have proposed that we >>>>> just do this from core as part of 1.10 except for order groups/order sets. >>>>> Of course your views are welcome. >>>>> >>>>> Wyclif >>>>> >>>>> On Wed, Apr 25, 2012 at 10:22 PM, Ben Wolfe <[email protected]> wrote: >>>>> >>>>>> Sounds fine except for the hacky part. >>>>>> >>>>>> >>>>>> On Wed, Apr 25, 2012 at 8:18 PM, Michael Seaton <[email protected]>wrote: >>>>>> >>>>>>> This sounds fine to me >>>>>>> >>>>>>> >>>>>>> On 04/25/2012 07:00 PM, Darius Jazayeri wrote: >>>>>>> >>>>>>> I agree with that. >>>>>>> >>>>>>> I would further suggest that: >>>>>>> >>>>>>> * the API module (probably should be orderentryapi) should have >>>>>>> high-quality code, and be written to support general and complex use >>>>>>> cases >>>>>>> >>>>>>> * the UI module (probably orderentryui, or even >>>>>>> simpleorderentryui) is allowed (expected!) to have hacky code, and >>>>>>> should >>>>>>> target the simple, common use case of recording mostly-standard regimens >>>>>>> (e.g. for HIV and TB) in a low-resource setting, where it's equally >>>>>>> likely >>>>>>> to be the clinician entering the regimen order real-time, or a data >>>>>>> clerk >>>>>>> or secretary entering it later. >>>>>>> >>>>>>> -Darius >>>>>>> >>>>>>> On Wed, Apr 25, 2012 at 3:50 PM, Wyclif Luyima >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Hi Guys, >>>>>>>> >>>>>>>> Apparently, i forgot to bring up something that Burke commented >>>>>>>> on a ticket, he suggested that the order entry module that Daniel and >>>>>>>> I are >>>>>>>> working is purely an API with no web layer, and that we will have to >>>>>>>> author >>>>>>>> another module to provide the UI, does everyone agree to this? >>>>>>>> >>>>>>>> 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]
