This is exactly what the reportingobjectgroup module that i wrote was for -- the idea that you might want to use SQL to select groups of any OpenmrsObject, and still be able to intersect it with a base cohort.
I'd really like to talk strategy about how to roll this module into reporting core (or substitute a core solution for the things we already have built on it). d On Fri, Aug 19, 2011 at 5:30 PM, Darius Jazayeri <[email protected]> wrote: > We talked off-list, and it turns out that: > > Many/most of the indicators Bob wants to build are not really cohort > indicators, but rather counts of encounters, obs, log entries, etc. > They'd mostly be calculated via SQL. > They need to be able to export these via the sdmx-hd module, into DHIS. > > @Mike, @Ryan, > If we were to do a SqlIndicator implementation (which wouldn't be too much > work), would that easily fit into the current SDMX-HD export module? Or is > that hardcoded to cohort indicators? And how much work would it be to change > that? > -Darius > > On Fri, Aug 19, 2011 at 7:33 AM, Bob Jolliffe <[email protected]> wrote: >> >> On 19 August 2011 15:07, Darius Jazayeri <[email protected]> wrote: >> > You're not doing a count distinct, so if your opd_patient_queue_log can >> > have >> > the same patient_id more than once, that'd be why you get a difference. >> > -Darius >> >> Thanks Darius. You are absolutely right. I also just figured that >> out a few minutes ago. >> >> Though it has left me with a sinking feeling about how to use the >> reporting module. It makes sense now that the penny has slowly >> dropped, that a cohort query is in fact a query to select a distinct >> group, or cohort, of patients. Which you could then drill down into >> etc. >> >> But at the level of a typical service indicator, I am really not >> interested in who the individual patients are. I need to know how >> many patients had OPD encounters this month, for example. Using a >> cohort query for this seemed to make sense, but of course it doesn't >> as it filters the duplicate patients. So I should in fact be counting >> the encounters rather than the patients, but then its not a cohort >> query :-( >> >> > >> > On Fri, Aug 19, 2011 at 5:37 AM, Bob Jolliffe <[email protected]> >> > wrote: >> >> >> >> I am trying to compose an indicator which makes use of a join with a >> >> custom table. >> >> >> >> Does anyone have an idea why executing the query directly as: >> >> mysql -u ... -e 'Select count(patient.patient_id) from patient inner >> >> join opd_patient_queue_log on >> >> patient.patient_id=opd_patient_queue_log.patient_id' >> >> >> >> results in 16593, >> >> >> >> but when I create a sql cohort query as above (without the count), I >> >> get a result of 13592. >> >> >> >> How does openmrs count the size of the resultset? It seems its not a >> >> simple count ... >> >> >> >> Regards >> >> Bob >> >> >> >> _________________________________________ >> >> >> >> 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] >> > >> > ________________________________ >> > Click here to unsubscribe 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] > > ________________________________ > Click here to unsubscribe 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]
