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:[email protected]?body=SIGNOFF%20openmrs-devel-l]
