I am moving into logic. I am using it to determine the reference ranges for certain lab tests, which are based primarily on age and sex but can also be based on various demographic (e.g. ethnicity) or health status (e.g. pregnancy) variables. I will be running multiple rules against a single patient, but not many at a time. My main concern is that existing high level features (logic expression definition, persistence and evaluation) remain available. This is a very small piece of a very large app and it is unlikely that people experienced with this aspect of OpenMRS will be available.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Thomas Sent: Monday, November 14, 2011 4:14 PM To: [email protected] Subject: Re: [OPENMRS-DEV] The future of Logic Hi. My biggest push into using logic was during an early draft of the mdrtb module version 2.0, in which I used it in a controller to create a custom patient summary. The complaints about logic listed by Mike basically reflect the experience. However, I've been thinking about how to create robust but generic templates for patient summaries, for ANY clinical area quickly. And i think one very powerful answer is htmlforms, restricted to 'view' mode, with logic tokens being referenced through the htmlformentry tags. If this was fast and robust, this would be EXTREMELY useful if I felt like it wasn't going to be like going down the rabbit hole... Is my impression about the state of things incorrect? d On 11/14/11, Michael Seaton <[email protected]> wrote: > Hi all, > > Not much of a resounding response to this :), but I would like to move > it forward. Can we discuss it during the Design Forum this week? > > Thanks, > Mike > > > On 11/09/2011 10:23 PM, Michael Seaton wrote: >> Hi all, >> >> I wanted to pick up a thread on the future of Logic that we spent >> some time discussing during the Developers Forum on October 27 >> <https://wiki.openmrs.org/x/5oamAQ>. >> >> The overall consensus on the call was that /"Logic is too complicated. >> We wish there were a simpler implementation, that were easier to >> adapt to individual needs. We wish it were more rigorously tested, >> including performance testing"/. >> >> *Anyone that cares about preserving Logic as it currently exists, or >> wants to see it change in a specific way, please read further* >> >> Specific users of Logic have communicated the following needs: >> >> * Tammy and her team require more control over the current Logic >> implementation, and better testing around it, so that future >> upgrades do not cause serious bugs and performance degradation >> * Win and Tammy need implementations of Logic that are optimized >> for running lots of rules for individual patients at a time >> * Mike needs an implementation of Logic that is optimized for >> running a single rule for lots of patients at a time as well >> * Mike wants to be able to choose to not use the existing Logic >> implementation in favor of an implementation provided by the >> Reporting module >> >> To accomplish this, the following high-level refactoring steps are >> being considered: >> >> * Reduce and simplify the number of interfaces and interface >> methods that Logic exposes in OpenMRS core >> * De-couple the existing Logic Module in such a way that it is one >> of many possible "Rule Providers" that can plug into this >> lighter-weight core framework >> * Remove, if possible and practical, the need to have a "required" >> Logic module installed >> >> Specifically, we are considering an approach that would reduce the >> core Logic interfaces to something like: >> >> interface LogicContext; >> >> interface Result; (classes DateResult, NumberResult, >> ListResult...) >> >> interface Rule { >> Set<RuleParameterInfo> getParameterInfo(); >> Class<? extends Result> getReturnType(); >> Result evaluate(Integer patientId, Map<String, Object> >> parameters, LogicContext context); >> } >> >> interface LogicService { >> public Result evaluate(Rule rule, Patient patient, Map<String, >> Object> parameters, LogicContext context); >> public Map<Integer, Result> evaluate(Rule rule, Cohort cohort, >> Map<String, Object> parameters, LogicContext context); >> } >> >> I would like for this to spur the following potential activities: >> >> * Give anyone who has not yet been aware of these discussions, or >> who does not agree with this approach, an opportunity to weigh >> in and get involved in the process >> * Make a plan to put this topic onto one or more future Design >> Forum calls, in order to agree upon the revised design, make >> tickets, and establish an owner for moving it forward. >> * Publicize when this Design Forum will occur so that interested >> parties can be involved as desired >> >> Thanks! >> Mike >> >> >> >> --------------------------------------------------------------------- >> --- >> 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] > _________________________________________ 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] _________________________________________ 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]
