Thanks Ben,
Agreed. I was suggesting the possible introduction of
"ordercompatibility" if we decided to go down the route of separate
orderentry tables, which is option that has been thrown about, either in
core or in a new module. I agree that if we evolve the existing tables
that this is not needed.
Mike
On 04/27/2012 08:45 AM, Ben Wolfe wrote:
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]
<mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>> wrote:
Sounds fine except for the hacky part.
On Wed, Apr 25, 2012 at 8:18 PM, Michael
Seaton <[email protected]
<mailto:[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]
<mailto:[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
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
