Mike when I first started reading your email I was afraid of where you were going. But actually I agree 100 percent with your proposed solution. I also wanted to call it PatientCalculation in the first place for this very reason.
this will have very little impact on the existing code written by Wyclif but keep us future proof for something we know we want to eventually support. -Darius (by phone) On Mar 6, 2012 4:07 PM, "Wyclif Luyima" <[email protected]> wrote: > Mike, you have just mentioned something that also bothered me all the time > i worked on the module, i kept on wondering if we are really never going to > change out minds about some assumptions that were made in the original > design. > > Since we made it clear that this was initially going to be used to perform > patient based calculations, i'm fine with having a > PatientCalculationService and CalculationService remains as an empty > interface. > > I had written a BaseCalculation abstract class that would also give us > leverage when we change our minds, say in case we wish to add another > common method among calculations but i ended up dropping it. > > Wyclif > > On Tue, Mar 6, 2012 at 5:20 PM, Michael Seaton <[email protected]> wrote: > >> Hey Darius / Wyclif / Burke, >> >> As a quick Calculation question to try to get out there tonight so I >> don't get bogged down with it when I look over the code later and/or >> tomorrow (because this issue is bothering me): >> >> To what degree do we want to leave open the possibility of having >> Calculations that may be performed on Objects other than Patient / Cohort? >> >> My gut feeling is that we want to leave this possibility open, even if we >> have no interest in supporting it now, and so we should take care to _not_ >> have a single CalculationService that makes this assumption. >> >> Right now we have: >> >> Calculation { >> ParameterDefinitionSet getParameterDefinitions(); >> } >> >> this is good. It does not make any such assumption. >> >> But we also have: >> >> CalculationService { >> Result evaluate(Integer patientId, Calculation, CalculationContext); >> CohortResult evaluate(Cohort, Calculation, CalculationContext); >> } >> >> this is less good. It makes the assumption that all Calculations are >> evaluated for a single patient or a cohort of patients. >> >> So, I want to open this up for debate and am proposing that we change >> things such that we have: >> >> TokenRegistrationService: handles all crud operations for token >> registration >> >> PatientCalculationService { >> Result evaluate(Integer patientId, PatientCalculation, >> PatientCalculationContext); >> CohortResult evaluate(Cohort, PatientCalculation, >> PatientCalculationContext); >> } >> >> in some, possibly non-existent (possibly near) future: >> >> EncounterCalculationService { >> Result evaluate(Integer patientId, EncounterCalculation, >> EncounterCalculationContext); >> EncounterSetResult(**EncounterSet, EncounterCalculation, >> EncounterCalculationContext); >> } >> >> The EncounterCalculationService would be able to calculate things like: >> number of Obs in a particular encounter; provider for a particular >> encounter, etc. And you could see a world in which aggregation tools allow >> you to use this data to produce calculations like "Provider associated with >> the most Encounters", "Average number of Obs entered on Intake Forms", >> "Percentage of Encounters entered between 10am-11am on Wednesdays", etc, >> which our users are already asking for from the reporting module, and I >> view as an inevitable next step... >> >> Thoughts? >> Mike >> >> ______________________________**___________ >> >> 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:LISTSERV@LISTSERV.**IUPUI.EDU <[email protected]> >> ?body=SIGNOFF%**20openmrs-devel-l] >> > > ------------------------------ > 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]
