dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

The following thread on the openmrs-devs thread is of interest.  Does anyone
know who is currently implementing Pepfar reports in DHIS2?

Regards
Bob

---------- Forwarded message ----------
From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
Date: 2009/10/15
Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS
To: dev@xxxxxxxxxxx


Hi

2009/10/15 Andrew Kanter <andy_kanter@xxxxxxxxx>

> 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: akanter@xxxxxxxxxxxxxxx
> Mobile: +1 (646) 469-2421
> Office: +1 (212) 305-4842
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
>
> ----- Original Message ----
> From: Justin Miranda <justin@xxxxxxxxxxx>
> To: openmrs-devel-l@xxxxxxxxxxxxxxxxxx
> 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
> LISTSERV@xxxxxxxxxxxxxxxxxx with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
> >
> > [mailto:LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l]
> >
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> LISTSERV@xxxxxxxxxxxxxxxxxx with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> LISTSERV@xxxxxxxxxxxxxxxxxx with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l]
>