I'm interested in what is mentioned below as OpenMRS remote entry - I take it that uses Xforms. Sounds like something we should look into for DHIS 2 also. Knut
---------- Forwarded message ---------- From: Jim Grace <[email protected]> Date: Thu, Oct 15, 2009 at 9:01 PM Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS To: [email protected] Thanks for all the responses so far. I'll check out DHIS. Free Download Manager says I should have it here in Kisumu in just another 39 hours... Oops, make that infinite. OK, now 215 hours. We'll see. :) I don't yet see anything yet about DHIS data entry being distributed the way OpenMRS remote form entry or synchronization are. This is something that would really help us with our remote districts. Otherwise it's sounding good so far. Reinventing the wheel is not my preferred mode. Running the new OpenMRS reporting over OpenMRS+DHIS sounds like a nice idea, Mike. Thanks for the tips everyone. Jim At 04:49 PM 15-10-09, Michael Seaton wrote: Hi Jim, As Justin mentioned, we have started down the road of implementing exactly what you describe in your option #2 below via the facilitydata module. We have been doing this for a few years now in our legacy system (combining hand-entered monthly aggregate indicators with calculated patient-data indicators) to produce our Pepfar reports, and the aim of the facilitydata module was to allow us to reproduce this process on OpenMRS. Robby worked hard to get this module off the ground this past summer, and if it is something that you are interested in I would be happy to discuss it with you and talk over what it would take to make it production-ready. You can download it directly from svn, and you can see some of the wiki documentation here: http://openmrs.org/wiki/Facility_Data_Module I have to say that, given discussions that happened at Cape Town this year with Bob Jolliffe and others, I'm leaning towards revisiting the above approach in favor of one that utilizes DHIS for the aggregate data collection piece, and integrates with the new reporting module to produce reports which combine indicators from both DHIS data and OpenMRS patient data. Regardless of the chosen approach, what you are describing is _exactly_ what we need to do when we roll OpenMRS out to our implementations in Haiti, and I would be very interested in working together to make it happen. Thanks, Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Justin Miranda Sent: Thursday, October 15, 2009 8:42 AM To: [email protected] Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS I'm pretty sure each of our implementations (at PIH) has a need for this type of data, but Mike (Seaton) has been advocating for collecting this type of data specifically for our Haiti sites. I see two approaches: (1) Something similar to the approach you suggested (from a form entry perspective). Robby (with Mike as mentor) started that process via the Google Summer of Code and built an initial version of a faciliydata module. You can download the latest code at: http://svn.openmrs.org/openmrs-modules/facilitydata/ (2) A reporting framework approach. I came to the conclusion at the conference that we need a file-based dataset definition that will allow users to upload spreadsheet data to be used within reports. That means you can take those spreadsheets, upload them to OpenMRS and use them within the reporting framework or third-party tools like Jasper or BIRT. Clearly this approach won't be useful until implementations start building their reports using the new reporting tools, but it's hopefully an approach that will be possible in the not-so-distant future. For the record, the file-based dataset definition does not exist yet. It has been identified as a requirement for the AMPATH sites, so it should be done eventually. However, without some development resources, it's probably not going to be completed any time soon. If there are developers that want to contribute to either of these projects, let me know. Justin Jim Grace wrote: > We're sitting here at FACES in Kenya crunching through our reporting-year-end data for PEPFAR (U.S. AIDS relief funding.) I'm writing software to pull data out of massive Excel spreadsheets where it's been aggregated, to put it into PEPFAR reports. There must be a better way. > > Basically, PEPFAR wants a whole bunch of monthly measures for each of our clinical sites, in such areas as prevention of HIV transmission (including mother-to-child transmission), HIV counseling and testing, antiretroviral treatment, etc. Some of these monthly numbers we can aggregate from our HIV patient support and treatment patient-level data in OpenMRS. Many others come from data not yet captured by us at the patient level in OpenMRS, and some from data we won't ever track at the patient level (e.g., "Number of individuals trained in the provision of laboratory-related activities", "Number of local organizations provided with technical assistance for HIV-related policy development", etc.) We need to report these monthly measures for 63 clinical sites, for 12 months. > > I'm thinking that the OpenMRS data collection tools would be ideal for us to input this data in the future. Define each measure as an OpenMRS concept. Design one or more OpenMRS forms to collect the monthly summary data for each site. Use the OpenMRS remote form entry infrastructure we've already deployed (and hoping to migrate to synchronization) to get all these numbers entered at the remote districts and brought back to our central server. Design an export process to pull out all this data (including aggregate summaries from patient-level data where applicable) for our PEPFAR reporting. > > Implementation possibilities include: > > 1. The most crude approach requires no software development. We could define a dummy patient (or one dummy per site or per district), a dummy provider, set up our concepts and forms, and enter one form per site per month (perhaps using the encounter date to represent the summary year/month.) > > 2. A much more ambitious plan is to design new tables that function similarly to encounter and obs, with respect to form entry. These tables could be used for monthly site summary data (or perhaps other kinds of data too?), and would not relate to patient or provider. > > 3. An in-between plan is to modify encounter and obs to make patient and provider references optional. > > Plans 2 and 3 would require a module with a UI so forms could be entered by site/month without first selecting a patient. > > Has anyone else considered or used OpenMRS data collection for this kind of monthly site summary data -- or for any other non-patient-related data? Do you have any experience and/or advice for us, as we consider these options? > > Thanks, > Jim > > P.S. For those who followed the OPENMRS-DEV "Location-based Privileges" thread, it is not lost, just dormant while we attend to other things. The need is still there, and the design is still percolating. :) > > _________________________________________ > > 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] _________________________________________ 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] -- Cheers, Knut Staring
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
