[OPENMRS-DEV] Monthly site summary data in OpenMRS

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@gmail.com
Date: 2009/10/15
Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS

To: dev@openmrs.org

Hi

2009/10/15 Andrew Kanter andy_kanter@yahoo.com

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 :slight_smile: 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@ei.columbia.edu

Mobile: +1 (646) 469-2421

Office: +1 (212) 305-4842

Skype: akanter-ippnw

Yahoo: andy_kanter

----- Original Message ----

From: Justin Miranda justin@OPENMRS.ORG

To: openmrs-devel-l@LISTSERV.IUPUI.EDU

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.)
  1. 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.
  1. 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. :slight_smile:


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]

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

···

On Thu, Oct 15, 2009 at 4:09 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Regards
Bob

---------- Forwarded message ----------

From: Bob Jolliffe bobjolliffe@gmail.com
Date: 2009/10/15
Subject: Re: [OPENMRS-DEV] Monthly site summary data in OpenMRS

To: dev@openmrs.org

Hi

2009/10/15 Andrew Kanter andy_kanter@yahoo.com

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 :slight_smile: 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@ei.columbia.edu

Mobile: +1 (646) 469-2421

Office: +1 (212) 305-4842

Skype: akanter-ippnw

Yahoo: andy_kanter

----- Original Message ----

From: Justin Miranda justin@OPENMRS.ORG

To: openmrs-devel-l@LISTSERV.IUPUI.EDU

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.)
  1. 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.
  1. 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. :slight_smile:


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]


To unsubscribe from OpenMRS Developers’ mailing list, send an e-mail to LISTSERV@LISTSERV.IUPUI.EDU with “SIGNOFF openmrs-devel-l” in the body (not the subject) of your e-mail.

[mailto:LISTSERV@LISTSERV.IUPUI.EDU?body=SIGNOFF%20openmrs-devel-l]


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Cheers,
Knut Staring