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