dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

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 <openmrs@xxxxxxxxxxxxxx>
Date: Thu, Oct 15, 2009 at 9:01 PM
Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS
To: openmrs-devel-l@xxxxxxxxxxxxxxxxxx


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: dev@xxxxxxxxxxx [mailto:dev@xxxxxxxxxxx] On Behalf Of Justin
Miranda
Sent: Thursday, October 15, 2009 8:42 AM
To: openmrs-devel-l@xxxxxxxxxxxxxxxxxx
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]

_________________________________________

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]



-- 
Cheers,
Knut Staring