dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Thu, Oct 15, 2009 at 4:09 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> 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 <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]
>>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cheers,
Knut Staring