On Thu, Oct 15, 2009 at 4:09 PM, Bob Jolliffe <[email protected]> wrote:
> The following thread on the openmrs-devs thread is of interest. Does > anyone know who is currently implementing Pepfar reports in DHIS2? > I doubt there is anyone doing that - but I would love to be proven wrong, and we should really try to get it done. Knut > Regards > Bob > > ---------- Forwarded message ---------- > From: Bob Jolliffe <[email protected]> > Date: 2009/10/15 > Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS > To: [email protected] > > > Hi > > 2009/10/15 Andrew Kanter <[email protected]> > >> Wouldn't the DHIS-integration approach also work? Are these just aggregate >> numbers which can be considered indicators? > > > I was just reading the top of this thread and that was also what I was > thinking. The monthly forms do have dataelements (note I'm not calling them > indicators :-) which would not be directly available from a patient based > system. In DHIS we can freely design the input dataset without regard for > the link to patient record. > > The new reporting framework of OpenMRS should be able to provide as many > datavalues as it can for dataelements which make sense for it. We can > import the openmrs report into what would be an incomplete dataset and fill > the rest manually or through some other import. Mostly what is required is > that we share uuids for dataelements. These can relatively easily be > exported as part of an sdmx metadata export. > > I think we can consume the datavalues from the reports in whatever xml > format is easiest to implement (so long as the uuids are intact). > > Regards > Bob > > >> I believe that the plan was to define a library of indicators which could >> be based on reference concepts (or mapped concepts), that could be shared >> between sites. Just wanted to be sure that we were not reinventing the >> wheel... There must be people who have already done this, no? >> >> -Andy >> -------------------- >> Andrew S. Kanter, MD MPH >> >> >> - Director of Health Information Systems/Medical Informatics >> Millennium Villages Project Earth Institute, Columbia University >> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology >> Columbia University >> >> >> Email: [email protected] >> Mobile: +1 (646) 469-2421 >> Office: +1 (212) 305-4842 >> Skype: akanter-ippnw >> Yahoo: andy_kanter >> >> >> >> ----- Original Message ---- >> From: Justin Miranda <[email protected]> >> To: [email protected] >> Sent: Thu, October 15, 2009 8:41:37 AM >> 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] >> > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > > -- 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
