dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

Hi Andrew,

It is me who is working from the DHIS2 side. I was kind of pulling part of
OpenMRS model into DHIS2 and start storing individual data into DHIS2.
Though my approach is kind of short sighted .....

I did this because DHIS2 is strong in reporting based on frequency/period
and routine data registration. On top of that for the place the house-hold
system is required we have a huge install-base of DHIS2. So introducing a
new system could really be a problem.......

But after discussing with Paul (we meet in GOA for an integrated e-health
architecture workshop hosted by HISP-India) and after looking a
demonstration of a system (by a HISP-India team) I thought making the GUI in
DHIS2 but maintaing 2 databases (OpenMRS for individuals, DHIS2 for the
rest) in the backend could be a possible approach. But for this to happen
... there needs to be some addition from OpenMRS side so that we can keep
all the data in OpenMRS ... but the aggregate figures into DHIS2.


Abyot.


On Mon, Aug 3, 2009 at 2:25 PM, Andrew Kanter <andy_kanter@xxxxxxxxx> wrote:

> Abyot,
> We in MVP need to be doing something very similar, but I think have
> approached it differently. We use OpenMRS to capture individual data
> elements and then use CommCare or other tools by Community Health Workers to
> followup data entry at the home. Right now, this data is still attached to
> individual patients (although you can attach household observations to the
> head of household record). We definitely require the need to attach meta
> data to a household which then has a relationship to the people who live in
> it. There has been work done by DHIS2 to add this meta data there, and there
> has been work to have DHIS2 and OpenMRS to work together. In Geneva last
> month, we discussed having a concerted effort to get this combined system
> running (OpenMRS + HH data + DHIS2). In addition, there was also discussion
> about adding HR via iHRIS.
>
> I have not heard a status report on this collaboration. Jorn, can you
> update us?
>
> As for creating a grouper for encounters to establish an episode of
> care.... I like this a lot. I don't think it is critical functionality for
> what we are doing now, but would be for latter EHR development.
>
> 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
>
> ------------------------------
> *From:* Abyot Gizaw <abyota@xxxxxxxxx>
> *To:* openmrs-devel-l@xxxxxxxxxxxxxxxxxx
> *Sent:* Monday, August 3, 2009 6:04:47 AM
> *Subject:* Re: [OPENMRS-DEV] Routine checkups
>
> Hi Burke,
>
> Yes what I need is a reporting one generated from clinical observations.
> And as you rightly pointed out it is more of a program-workflow. Depending
> on the program type we may need to record/observe the same data every month
> (for example in the case of Family Planning we may need to count the number
> of condoms or contraceptive pills given for individuals) or measure
> different data every month or program milestone (for example for
> immunization a child may be given Vaccine Type 1 for the first cycle and
> then get into schedule followed by treatment and observation for Vaccine
> Type 2 ... it goes on for subsequent cycles)
>
> My understanding from OpenMRS is that Encounters are specific incidences
> observed for a set of concepts (Encounter --> Observation --> Concept -->
> value). And I am quite sure that this will not serve my need. What I want is
> to put a set of Encounters in a form and then ask my healthworkers to go and
> visit individuals in their house and bring me their observations. In most
> developing countries because there is shortage of skilled manpower, clinic
> or generally infrastructure a district medical officer might ask his
> assistants to vist a house-hold once every month and bring specific
> observations. For a situation like this we need to think beyond a clinic
> because patients might not be able to come to a clinic either because there
> is a no clinic in the vicinity or something else ......
>
> DHIS2 is quite strong for reporting, the encounters and the forms are
> loosely coupled, and I started to implement a house-hold visit module into
> it. I know that it is bit of a push for DHIS2 to make it regsiter individual
> data - OpenMRS is strong for dealing with individuals. After discussing with
> Paul and Saptarshi I am kind of thinking if it is possible to jump into
> OpenMRS and have a house-hold visit management system. The way I see it
> ..... there needs to be changes into your datamodel!
>
> Abyot.
>
>
> On Mon, Aug 3, 2009 at 7:15 AM, Burke Mamlin <bmamlin@xxxxxxxxxxxxxxx>wrote:
>
>> Abyot,
>> It sounds like your looking more for a reporting tool than a clinical one
>> -- i.e., you're talking about a process that would occur periodically to
>> organize/relate existing data rather than periodic visits from a patient,
>> right?  Usually, observations are made when the patient is present -- i.e., during an encounter.
>>
>> Creating new encounter types seems fairly clean; however, if you are not collecting new observation and, rather, organizing existing observations, then these new encounter types would end up duplicating observations and could confuse any other attempts to understand the data (e.g., a patient's weight might appear in the original encounter, again in the auto-generated weekly encounter, and then again for the
>> auto-generated monthly encounter).  Trying to sort out actual observations
>> vs. copies would be messy.
>>
>> It sounds like you want something slightly above encounters -- i.e., an
>> episode of care -- that could span multiple encounters (e.g., TB treatments
>> that takes months and multiple encounters).   The program-workflow "state"
>> machine has some of this capability; however, I'm not sure it fits perfectly
>> with your needs.  We've been considering the "episode of care" idea as well
>> as loosening the coupling between encounter & form (allowing many-to-many
>> relationships between forms & encounters).  But these are not small changes.
>>
>> How about an episode-of-care module that adds it's own table to link m
>> ultiple observations and/or encounters into episodes of care?  This might
>> be a way to experiment with candidate changes to the core data model. :-)
>> -Burke
>>
>> On Aug 3, 2009, at 12:59 AM, Abyot Gizaw wrote:
>>
>>
>>
>> On Mon, Aug 3, 2009 at 12:09 AM, Ben Wolfe <bwolfe@xxxxxxxxxxxxxxx>wrote:
>>
>>> Can you have a new Encounter Type for the different period types?
>>
>>
>> Yes that could be possible.
>>
>>
>>>
>>>
>>> Or the slightly hackier solution would be to have a "Period Type"
>>> Concept with answers of Daily, Monthly, etc, that is stored in an Obs
>>> for that encounter.
>>
>>
>> Emm that would really be a "hackier", I mean the item we are collecting
>> and its frequency/time_axis should be kept separate.
>>
>>
>>>
>>>
>>> If we had encounter_attribute + encounter_attribute_type, the solution
>>> would be obvious.
>>
>>
>> Ya, that will make much more sense. Or else making encounter, period,
>> period_type,... attributes of a new object for example form or registry or
>> something like that.
>>
>>
>>>
>>>
>>> Ben
>>>
>>> On Sun, 2009-08-02 at 09:33 +0200, Abyot Gizaw wrote:
>>> >
>>> >
>>> > On Sun, Aug 2, 2009 at 7:42 AM, Saptarshi Purkayastha
>>> > <sunbiz@xxxxxxxxx> wrote:
>>> >         Checkups as such are Encounters in OpenMRS and these checkups
>>> >         can have one or more observations (Obs in OpenMRS)
>>> >
>>> > Yes that was the closest I could come from OpenMRS. The timing with
>>> > Encounters (in OpenMRS) is more of an instance - recording the
>>> > datetime where the Encounter has happened. And this is ok as far as an
>>> > "ecnounter" is concerned. But what I want is more of a routine
>>> > periodic observations. It is like pulling out a medical record form
>>> > every month/week/...and then recording specific
>>> > observations/encounters together with their time of incidence
>>> > (datetime in openmrs). The medical record forms can uniquely be
>>> > identified by the registering clinic/facility (I think Location in
>>> > OpenMRS) and the reporting period.
>>> >
>>> >
>>> >
>>> >
>>> >         But when you talk about a plan or something that will happen
>>> >         in the future, it is considered Orders. Providers orders
>>> >         (medications, plan, etc.) and this can later result in an
>>> >         Encounter
>>> >
>>> >         Hope that answers your question.
>>> >
>>> > not sure .... may be something like a "Recoding Form" object having
>>> > Encounter and Period as its attributes among other things is what I
>>> > want. Period also needs to have period types (like  daily, monthly,
>>> > quarterly, yearly,...). You can say I can run cohort and bound
>>> > Encounters within a specific time frame and relate it with my period.
>>> > But reporting in HMIS, of course together with local use of
>>> > information, are critical and need proper modeling or something like
>>> > that.
>>> >
>>> > Thank you
>>> > Abyot.
>>> >
>>> >
>>> >
>>> >
>>> >         ---
>>> >         Regards,
>>> >         Saptarshi PURKAYASTHA
>>> >         Director R & D, HISP India
>>> >         Health Information Systems Programme
>>> >
>>> >         My Tech Blog:  http://sunnytalkstech.blogspot.com
>>> >         You Live by CHOICE, Not by CHANCE
>>> >
>>> >
>>> >         2009/8/2 Abyot Gizaw <abyota@xxxxxxxxx>
>>> >
>>> >                 Hi All,
>>> >
>>> >                 Can any one explain me how routine checkups are
>>> >                 treated in OpenMRS? Say for example if a patient is
>>> >                 going to have a weekly/monthly/.../periodic checkups
>>> >                 is there any object in openmrs to handle this?
>>> >
>>> >                 Thank you
>>> >                 Abyot.
>>> >
>>>
>> ------------------------------
>> Click here to unsubscribe<LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l>from OpenMRS Developers' mailing list
>>
>
> ------------------------------
> Click here to unsubscribe<LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l>from OpenMRS Developers' mailing list
> ------------------------------
> Click here to unsubscribe<LISTSERV@xxxxxxxxxxxxxxxxxx?body=SIGNOFF%20openmrs-devel-l>from OpenMRS Developers' mailing list
>