date:20090603

Hi Abyot

It is testing the functionality of the api classes rather than the
services.  And the api is critical and should be tested.  These tests
are very lightweight and easy to run (unlike the services which take a
long time and are not very suitable for regular testing).

I do see it is failing the test.  Sorry that's my mistake.  Thanks for
pointing it out.  Will fix it now.

Cheers
Bob

2009/6/2 Abyot Gizaw :
> Hi All,
>
> Any idea why we need this while we have another test in the services? And it
> is failling the test!!
>
> Thanks
> Abyot.
>
> ___
> 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
>
>

___
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

[Dhis2-devs] Fwd: Packaging Training Sessions: Make Your Package Upgrade Correctly

Some relevant training sessions coming up for anyone interested in
ubuntu packaging of dhis ...

-- Forwarded message --
From: Maciej Danielski 
Date: 2009/6/2
Subject: Packaging Training Sessions: Make Your Package Upgrade Correctly
To: Ubuntu Irish Team 

This is just a friendly reminder to all of the people out there wanting
to chip in Ubuntu Development Contributions. The upcoming packaging
training session gears up to be interesting ” Make Your Package
Upgrade Correctly “. This is one of a series of ongoing development
centered sessions focusing on showcasing the daily work of Ubuntu MOTU
contributors.

When: 4th June, 6:00 UTC

Where: #ubuntu-classroom @ irc.freenode.net

What: Package Session: Make Your Package Upgrade Correctly

How Long: One hour, Short demo of packaging technique and rest for Questions.

If you want to find out more about the upcoming Packaging Sessions
check https://wiki.ubuntu.com/Packaging/Training also make sure to
follow the RSS feed of Ubuntu Packaging at
http://ubuntupackaging.wordpress.com/

Kind regards,
Maciej Danielski aka Mean-Machine

--
Ubuntu-ie mailing list
ubuntu...@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-ie

___
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

[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 353: Fixed error in weeklyperiod test

2009-06-03 Thread noreply


revno: 353
committer: Bob Jolliffe  generatedPeriods = wpt.generatePeriods( p1 );
-assertTrue( "Period " + p1 + " in generated set", 
generatedPeriods.contains( p1 ) );
-}
-}
-}
-
-/**
- * Test method for
- * {...@link org.hisp.dhis.period.WeeklyPeriodType#createPeriod(Calendar)}.
- */
-@Test
-@SuppressWarnings( "deprecation" )
-public void testCreatePeriod()
-{
-Calendar testCal = Calendar.getInstance();
-Calendar startCal = Calendar.getInstance();
-Calendar endCal = Calendar.getInstance();
-
-// arbitrary instance - should increase coverage
-testCal.set( 2009, 4, 27 ); // Wednesday
-WeeklyPeriodType wpt = new WeeklyPeriodType();
-
-assertFalse( startCal.after( testCal ) );
-assertFalse( endCal.before( testCal ) );
-Period p = wpt.createPeriod( testCal.getTime() );
-startCal.set( Calendar.DAY_OF_MONTH, p.getStartDate().getDate() );
-assertTrue( startCal.get( Calendar.DAY_OF_WEEK ) == Calendar.MONDAY );
-endCal.set( Calendar.DAY_OF_MONTH, p.getEndDate().getDate() );
-assertTrue( endCal.get( Calendar.DAY_OF_WEEK ) == Calendar.SUNDAY );
-}
+public class WeeklyPeriodTypeTest {
+
+
+   /**
+* Test method for {...@link 
org.hisp.dhis.period.WeeklyPeriodType#generatePeriods(org.hisp.dhis.period.Period)}.
+*/
+   @Test
+   public void testGeneratePeriods() {
+   // get calendar of default locale
+   Calendar testCal = Calendar.getInstance();
+   WeeklyPeriodType wpt = new WeeklyPeriodType();
+   for (int year = 1990; year<2020; year++) {
+ for (int day=-7; day<7; day++)
+   {
+ testCal.set(year, 0, 1); // 1st day of year
+ testCal.add(Calendar.DATE, day);
+ // System.err.println("testing "+testCal.getTime());
+ Period p1 = wpt.createPeriod(testCal.getTime());
+ List generatedPeriods = wpt.generatePeriods(p1);
+ assertTrue("Period "+p1+" in generated 
set",generatedPeriods.contains(p1));
+   }
+   }   
+   
+   }
+   
+   /**
+* Test method for {...@link 
org.hisp.dhis.period.WeeklyPeriodType#createPeriod(Calendar)}.
+*/
+   @Test
+   public void testCreatePeriod() {
+   Calendar testCal = Calendar.getInstance();
+   Calendar startCal = Calendar.getInstance();
+   Calendar endCal = Calendar.getInstance();
+   
+   // arbitrary instance - should increase coverage
+   testCal.set(2009, 4, 27); // Wednesday
+   WeeklyPeriodType wpt = new WeeklyPeriodType();
+   
+   
+Period p = wpt.createPeriod(testCal.getTime());
+   startCal.setTime(p.getStartDate()); 
+   endCal.setTime(p.getEndDate()); 
+   
+assertFalse("start date after given 
date",startCal.after(testCal));
+   assertFalse("end date before given date", 
endCal.before(testCal));
+
+   assertTrue(startCal.get(Calendar.DAY_OF_WEEK)==Calendar.MONDAY);
+   assertTrue(endCal.get(Calendar.DAY_OF_WEEK)==Calendar.SUNDAY);
+   
+   
+   }
+
 }



--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.

___
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

[Dhis2-devs] patient_dataelement Vs routine_dataelement

Hi All,

Couldn't really convince myself as to the need to keep a separate track of
dataelements called patientdataelement. I just did an implementation for
patientdataelement ... but when giving it a thought about linking it with
some custom and predefiend values, then I see that one already in place by
Murod for the routine dataelements. And if we are going to have a case of
like recording multiple values for a single patient dataelement, then we
also will redo all the compex task of linking with options, categories and
their combinations, which is again in place for the routine dataelements.

If the need to separate the two - routine and patient is only for the
purpose of managment, then I think it will be better if we could introduce
an attribute called 'classification' for dataelements. With this attribue we
can classify our dataelements like - Routine, Patient, Header, Footer,...

Any input will be appreciated.

Thank you
Abyot.
___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

Hi Abyot,

If you read my summary e-mails just before the skype conference you will see
that my suggestion was NOT to have a different type of data element, and I
understood from the skype chat that we agreed on the same. What we talked
about was to possibly make a separation in the user interface to avoid
confusing the users, but in the background use the same DataElement object,
but I am not sure that will always be needed as there are lot of overlap
between routine and CHIS data elements.

As you say, if we want to easily reuse datasets and data entry forms
functionality we need to use the DataElement object also for client data
elements. And of course we want to reuse what Murid has implemented
regarding option lists for pre-defined values for data elements.

The separation comes in DataValue as the PatientDataValue will need other
properties than the (routine) DataValue.

And we also talked about the need to extend the DataSet object to include
more properties that makes datasets more flexible and dynamic as we need
them for CIS and also for survey data.

So here I guess we all agree, there is no need to come up with a separate
PatientDataElement.

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw  wrote:

> Hi All,
>
> Couldn't really convince myself as to the need to keep a separate track of
> dataelements called patientdataelement. I just did an implementation for
> patientdataelement ... but when giving it a thought about linking it with
> some custom and predefiend values, then I see that one already in place by
> Murod for the routine dataelements. And if we are going to have a case of
> like recording multiple values for a single patient dataelement, then we
> also will redo all the compex task of linking with options, categories and
> their combinations, which is again in place for the routine dataelements.
>
> If the need to separate the two - routine and patient is only for the
> purpose of managment, then I think it will be better if we could introduce
> an attribute called 'classification' for dataelements. With this attribue we
> can classify our dataelements like - Routine, Patient, Header, Footer,...
>
> Any input will be appreciated.
>
> Thank you
> Abyot.
>
> ___
> 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
>
>
___
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

[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 354: Mapping bug fixed.

2009-06-03 Thread noreply


revno: 354
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: trunk
timestamp: Wed 2009-06-03 11:59:40 +0200
message:
  Mapping bug fixed.
modified:
  gis/dhis-web-mapping/src/main/webapp/mfbase/mapfish/widgets/geostat/Mapping.js

=== modified file 
'gis/dhis-web-mapping/src/main/webapp/mfbase/mapfish/widgets/geostat/Mapping.js'
--- 
gis/dhis-web-mapping/src/main/webapp/mfbase/mapfish/widgets/geostat/Mapping.js  
2009-05-16 00:18:28 +
+++ 
gis/dhis-web-mapping/src/main/webapp/mfbase/mapfish/widgets/geostat/Mapping.js  
2009-06-03 09:59:40 +
@@ -377,9 +377,10 @@
 }
 
 if (this.newUrl) {
-url = this.newUrl;
+URL = this.newUrl;
 this.newUrl = false;
-this.setUrl('../../../geoserver/wfs?request=GetFeature&typename=' 
+ url + '&outputformat=json&version=1.0.0');
+this.setUrl('geojson/' + URL);
+
//this.setUrl('../../../geoserver/wfs?request=GetFeature&typename=' + URL + 
'&outputformat=json&version=1.0.0');
 }
 
 if (!Ext.getCmp('maps_cb').getValue()) {



--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.

___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

2009/6/3 Ola Hodne Titlestad :
> Hi Abyot,
>
> If you read my summary e-mails just before the skype conference you will see
> that my suggestion was NOT to have a different type of data element, and I
> understood from the skype chat that we agreed on the same. What we talked
> about was to possibly make a separation in the user interface to avoid
> confusing the users, but in the background use the same DataElement object,
> but I am not sure that will always be needed as there are lot of overlap
> between routine and CHIS data elements.
>
> As you say, if we want to easily reuse datasets and data entry forms
> functionality we need to use the DataElement object also for client data
> elements. And of course we want to reuse what Murid has implemented
> regarding option lists for pre-defined values for data elements.
>
> The separation comes in DataValue as the PatientDataValue will need other
> properties than the (routine) DataValue.

Agreed.  But what would these properties be exactly?  Two options
which have surfaced are:
1. an additional patientID attribute; or
2. no additional attribute - association of patient as a "source"

The first is most obvious and perhaps simplest.  And I suspect I am
the only one crazy enough to see any merit in exploring the second.
So I'm guessing Abyot will make a PatientDataElement with something
like a patientID.

What else?  Do we need a concept like an encounter (or visit) to which
a date would be tied?  Or can something be done with a PeriodType?

Regards
Bob

> And we also talked about the need to extend the DataSet object to include
> more properties that makes datasets more flexible and dynamic as we need
> them for CIS and also for survey data.
>
> So here I guess we all agree, there is no need to come up with a separate
> PatientDataElement.
>
>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw  wrote:
>>
>> Hi All,
>>
>> Couldn't really convince myself as to the need to keep a separate track of
>> dataelements called patientdataelement. I just did an implementation for
>> patientdataelement ... but when giving it a thought about linking it with
>> some custom and predefiend values, then I see that one already in place by
>> Murod for the routine dataelements. And if we are going to have a case of
>> like recording multiple values for a single patient dataelement, then we
>> also will redo all the compex task of linking with options, categories and
>> their combinations, which is again in place for the routine dataelements.
>>
>> If the need to separate the two - routine and patient is only for the
>> purpose of managment, then I think it will be better if we could introduce
>> an attribute called 'classification' for dataelements. With this attribue we
>> can classify our dataelements like - Routine, Patient, Header, Footer,...
>>
>> Any input will be appreciated.
>>
>> Thank you
>> Abyot.
>>
>> ___
>> 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
>>
>
>
> ___
> 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
>
>

___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

On Wed, Jun 3, 2009 at 11:45 AM, Ola Hodne Titlestad wrote:

> Hi Abyot,
>
> If you read my summary e-mails just before the skype conference you will
> see that my suggestion was NOT to have a different type of data element, and
> I understood from the skype chat that we agreed on the same.



Yes we agreed on the skype chat - but things do not fit smothly when it
comes to actual coding. Actually I was looking into the document prepared by
you. The number one task is "to represent patient data elements and add/edit
GUI"



> What we talked about was to possibly make a separation in the user
> interface to avoid confusing the users, but in the background use the same
> DataElement object, but I am not sure that will always be needed as there
> are lot of overlap between routine and CHIS data elements.
>
> As you say, if we want to easily reuse datasets and data entry forms
> functionality we need to use the DataElement object also for client data
> elements. And of course we want to reuse what Murid has implemented
> regarding option lists for pre-defined values for data elements.
>
> The separation comes in DataValue as the PatientDataValue will need other
> properties than the (routine) DataValue.


Yes I agree. But, I think, this will not require us to have a specific
dataelement different from what we have currently.


>
>
> And we also talked about the need to extend the DataSet object to include
> more properties that makes datasets more flexible and dynamic as we need
> them for CIS and also for survey data.


Yes we have talked about that. That is not my question, I am not yet into
this.


>
>
> So here I guess we all agree, there is no need to come up with a separate
> PatientDataElement.


That is also my bet!! And I am planning to reuse as many objects as possible
from the existing code.

But you didn't comment on my suggestion - differentiating the dataelements
using an attribute called "classification" and right now we have two
classification. Routine and Patient. What do you think?

Thank you
Abyot.


>
>
>
> best regards,
> Ola Hodne Titlestad
> HISP
> University of Oslo
>
>
> On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw  wrote:
>
>> Hi All,
>>
>> Couldn't really convince myself as to the need to keep a separate track of
>> dataelements called patientdataelement. I just did an implementation for
>> patientdataelement ... but when giving it a thought about linking it with
>> some custom and predefiend values, then I see that one already in place by
>> Murod for the routine dataelements. And if we are going to have a case of
>> like recording multiple values for a single patient dataelement, then we
>> also will redo all the compex task of linking with options, categories and
>> their combinations, which is again in place for the routine dataelements.
>>
>> If the need to separate the two - routine and patient is only for the
>> purpose of managment, then I think it will be better if we could introduce
>> an attribute called 'classification' for dataelements. With this attribue we
>> can classify our dataelements like - Routine, Patient, Header, Footer,...
>>
>> Any input will be appreciated.
>>
>> Thank you
>> Abyot.
>>
>> ___
>> 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
>>
>>
>
___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe  wrote:

> 2009/6/3 Ola Hodne Titlestad :
> > Hi Abyot,
> >
> > If you read my summary e-mails just before the skype conference you will
> see
> > that my suggestion was NOT to have a different type of data element, and
> I
> > understood from the skype chat that we agreed on the same. What we talked
> > about was to possibly make a separation in the user interface to avoid
> > confusing the users, but in the background use the same DataElement
> object,
> > but I am not sure that will always be needed as there are lot of overlap
> > between routine and CHIS data elements.
> >
> > As you say, if we want to easily reuse datasets and data entry forms
> > functionality we need to use the DataElement object also for client data
> > elements. And of course we want to reuse what Murid has implemented
> > regarding option lists for pre-defined values for data elements.
> >
> > The separation comes in DataValue as the PatientDataValue will need other
> > properties than the (routine) DataValue.
>
> Agreed.  But what would these properties be exactly?  Two options
> which have surfaced are:
> 1. an additional patientID attribute; or
> 2. no additional attribute - association of patient as a "source"
>
> The first is most obvious and perhaps simplest.  And I suspect I am
> the only one crazy enough to see any merit in exploring the second.
>

patientID yes, but probably also a DataSetID as we need to keep track (and
separation) of the encounters/visits (instances of a dataset, "a filled
form") in a more efficient way than we do in DataValue now.
At least this is how its done in 1.4 Patient module and also for Survey type
data.

> So I'm guessing Abyot will make a PatientDataElement with something
> like a patientID.
>
Data elements do not have any direct reference to its source, so this should
not be necessary. It is the datavalue that keeps this reference and which
again is controlled by the dataset.
We would in stead need a maintain Patients/Clients in a separate object, and
pherhaps in a hierarchy (family, village). Lars also liked the idea of
implementing the source object here, and I am open to that. After all that
is why we created the source, to have diffeent types of sources to register
data, not only orgunits.
The peirod handling might also be different here as we always work on dates
since these data are snapshots in time and not aggregtated over a certain
period.

Calle might have some useful input to how patient values are different from
routine, apart from the security aspect we already discussed some weeks
back.

>
> What else?  Do we need a concept like an encounter (or visit) to which
> a date would be tied?  Or can something be done with a PeriodType?
>

If we are going to reuse the DHIS concepts of data element, dataset, data
entry form and data value then the dataset is the key here.
In many ways routine datasets and "client" datasets are very similar, and "a
filled form", or what might be called an instance of a dataset, contains
values linked to data elements for a given period and a given source. Client
encounters, rows from a register book, are also like that; a client name,
multiple data elements (columns in the book) with values, and a date. After
all its the final row of the register book, the total row aggregating all
the encounters that gives the routine values for a monthly routine dataset.
This example also illustrates how data elements overlap between client data
and routine data, routine data are simply the total of "all clients" for the
month. (This is not the case in survey audit type of datasets e.g. with
maternal detah audits, but for standard CHIS it is mostly the case)

If we keep track of the DatasetID in a ClientDataValue object we can the
easily get an ecounter by querying for a client + a date + a dataset, or a
list of all encounters (within a certain programme (dataset)) by querying
for a client + a dataset. Of course it would be possible to get all data
elements belonging to a dataset without directly referencing datasetid in
datavalue, we do that today for dataset reports. Again, we need to check
this with Calle or others, but I think client data are different in the way
that a data element can exist in multiple datasets AND be registered for all
of them for the same client and date, because the same data elements in
different datasets might have different meanings and values. For routine
this is not the case, that is why we di not keep a reference to dataset in
datavalue, it is enough to use data element to describe the meaning of the
data.

So each encounter will be a data entry form, and its metadata will be
controlled through the dataset object, similar to how its done for routine
data. In the dataset object we need to specify what kind of data that is
going to be registered,e.g. aggregated, disaggregated, survey(or routine,
client, survey). Semi-permanent is then included in routine which is a bit
confusing, that is wh

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

On Wed, Jun 3, 2009 at 12:06 PM, Abyot Gizaw  wrote:

> On Wed, Jun 3, 2009 at 11:45 AM, Ola Hodne Titlestad wrote:
>
>> Hi Abyot,
>>
>> If you read my summary e-mails just before the skype conference you will
>> see that my suggestion was NOT to have a different type of data element, and
>> I understood from the skype chat that we agreed on the same.
>
>
>
> Yes we agreed on the skype chat - but things do not fit smothly when it
> comes to actual coding. Actually I was looking into the document prepared by
> you. The number one task is "to represent patient data elements and add/edit
> GUI"
>
>
>
>> What we talked about was to possibly make a separation in the user
>> interface to avoid confusing the users, but in the background use the same
>> DataElement object, but I am not sure that will always be needed as there
>> are lot of overlap between routine and CHIS data elements.
>>
>> As you say, if we want to easily reuse datasets and data entry forms
>> functionality we need to use the DataElement object also for client data
>> elements. And of course we want to reuse what Murid has implemented
>> regarding option lists for pre-defined values for data elements.
>>
>> The separation comes in DataValue as the PatientDataValue will need other
>> properties than the (routine) DataValue.
>
>
> Yes I agree. But, I think, this will not require us to have a specific
> dataelement different from what we have currently.
>
>
>>
>>
>> And we also talked about the need to extend the DataSet object to include
>> more properties that makes datasets more flexible and dynamic as we need
>> them for CIS and also for survey data.
>
>
> Yes we have talked about that. That is not my question, I am not yet into
> this.
>
>
>>
>>
>> So here I guess we all agree, there is no need to come up with a separate
>> PatientDataElement.
>
>
> That is also my bet!! And I am planning to reuse as many objects as
> possible from the existing code.
>
> But you didn't comment on my suggestion - differentiating the dataelements
> using an attribute called "classification" and right now we have two
> classification. Routine and Patient. What do you think?
>

I thin this separation should not be in the data element, which we should
keep as generic as possible, but in the dataset, where we say something
about HOW a data element will be used. In a typical CHIS scenario you would
use the same data element for both client and routine data, since client is
conceptually just an extension of the orgunit, and the data we register are
the same whether it is from a daily client register or the monthly
aggregated report. Exactly how we can support this duality of data elements
I am not sure... would it be enough to keep that separation in dataset (says
soemthing about who you register for and how often) and data value (says who
the data belongs to and for what period)? I hope so.


>
> Thank you
> Abyot.
>
>
>>
>>
>>
>> best regards,
>> Ola Hodne Titlestad
>> HISP
>> University of Oslo
>>
>>
>> On Wed, Jun 3, 2009 at 11:26 AM, Abyot Gizaw  wrote:
>>
>>> Hi All,
>>>
>>> Couldn't really convince myself as to the need to keep a separate track
>>> of dataelements called patientdataelement. I just did an implementation for
>>> patientdataelement ... but when giving it a thought about linking it with
>>> some custom and predefiend values, then I see that one already in place by
>>> Murod for the routine dataelements. And if we are going to have a case of
>>> like recording multiple values for a single patient dataelement, then we
>>> also will redo all the compex task of linking with options, categories and
>>> their combinations, which is again in place for the routine dataelements.
>>>
>>> If the need to separate the two - routine and patient is only for the
>>> purpose of managment, then I think it will be better if we could introduce
>>> an attribute called 'classification' for dataelements. With this attribue we
>>> can classify our dataelements like - Routine, Patient, Header, Footer,...
>>>
>>> Any input will be appreciated.
>>>
>>> Thank you
>>> Abyot.
>>>
>>> ___
>>> 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
>>>
>>>
>>
>
___
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

[Dhis2-devs] [Bug 383127] [NEW] DHIS 2 cannot import values greater than 2^31 from DHIS 1.4

2009-06-03 Thread jason.p.pickering

Public bug reported:

This may be related to #348703. Values greater that 2^31 cause the DHIS
1.4 file import to fail silently. This error is as follows, as occurs
with the ODBC connector driver, so it needs to be caught early.

* ERROR 12:57:12,283 The process threw exception (ProcessExecutor.java 
[Thread-17])
java.lang.RuntimeException: Query with RowHandler failed
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:141)
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:124)
at 
org.hisp.dhis.importexport.dhis14.file.importer.DefaultDhis14FileImportService.importRoutineDataValues(DefaultDhis14FileImportService.java:753)
at 
org.hisp.dhis.importexport.dhis14.file.importer.DefaultDhis14FileImportService.importData(DefaultDhis14FileImportService.java:281)
at 
org.hisp.dhis.importexport.ImportInternalProcess.executeStatements(ImportInternalProcess.java:84)
at 
org.hisp.dhis.system.process.AbstractStatementInternalProcess.execute(AbstractStatementInternalProcess.java:85)
at 
org.hisp.dhis.system.process.AbstractStatementInternalProcess.execute(AbstractStatementInternalProcess.java:37)
at 
org.amplecode.cave.process.ProcessExecutor.run(ProcessExecutor.java:126)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException:   
--- The error occurred in sqlmap/routineDataValue.sqlmap.xml.  
--- The error occurred while applying a result map.  
--- Check the routineDataValue.routineDataValueResultMap.  
--- Check the result mapping for the 'value' property.  
--- Cause: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
Caused by: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:185)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithRowHandler(GeneralStatement.java:133)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryWithRowHandler(SqlMapExecutorDelegate.java:644)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryWithRowHandler(SqlMapSessionImpl.java:121)
at 
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryWithRowHandler(SqlMapClientImpl.java:98)
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:135)
... 8 more
Caused by: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
at sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6957)
at sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7114)
at sun.jdbc.odbc.JdbcOdbc.SQLGetDataInteger(JdbcOdbc.java:3811)
at 
sun.jdbc.odbc.JdbcOdbcResultSet.getDataInteger(JdbcOdbcResultSet.java:5638)
at sun.jdbc.odbc.JdbcOdbcResultSet.getInt(JdbcOdbcResultSet.java:583)
at sun.jdbc.odbc.JdbcOdbcResultSet.getInt(JdbcOdbcResultSet.java:601)
at 
com.ibatis.sqlmap.engine.type.IntegerTypeHandler.getResult(IntegerTypeHandler.java:35)
at 
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getPrimitiveResultMappingValue(BasicResultMap.java:565)
at 
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getResults(BasicResultMap.java:319)
at 
com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor.java:394)
at 
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:185)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQuery(GeneralStatement.java:205)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
... 13 more


I would suggest that at least as a workaround the following procedure could 
possibly be tried?

1) Check to see if such problems exists. Lets get a list of ID´s to
exclude from the import process..

SELECT RoutineDataID FROM RoutineData WHERE EntryNumber > 2^31

2) Inform the user that there are some values that cannot be imported.

2) Then I guess the import process could start, excluding the list of
RoutineDataID´s from that list.

This is a big problem in places where figures like budget values reach
into the billions or trillions.

** Affects: dhis2
 Importance: Undecided
 Status: New

-- 
DHIS 2 cannot import values greater than 2^31 from DHIS 1.4
https://bugs.launchpad.net/bugs/383127
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.

Status in District Health Information Software 2: New

Bug description:
This may be related to

[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 355: Unique value enforced from getMapOrganisationUnitRelation.

2009-06-03 Thread noreply


revno: 355
committer: Jan Henrik Overland janhenrik.overl...@gmail.com
branch nick: trunk
timestamp: Wed 2009-06-03 13:54:07 +0200
message:
  Unique value enforced from getMapOrganisationUnitRelation.
removed:
  gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/pageload
added:
  gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/init
modified:
  
dhis-2/dhis-services/dhis-service-mapping/src/main/resources/org/hisp/dhis/mapping/hibernate/MapOrganisationUnitRelation.hbm.xml
  gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geostat.js

=== modified file 
'dhis-2/dhis-services/dhis-service-mapping/src/main/resources/org/hisp/dhis/mapping/hibernate/MapOrganisationUnitRelation.hbm.xml'
--- 
dhis-2/dhis-services/dhis-service-mapping/src/main/resources/org/hisp/dhis/mapping/hibernate/MapOrganisationUnitRelation.hbm.xml
2009-04-23 11:51:19 +
+++ 
dhis-2/dhis-services/dhis-service-mapping/src/main/resources/org/hisp/dhis/mapping/hibernate/MapOrganisationUnitRelation.hbm.xml
2009-06-03 11:54:07 +
@@ -11,10 +11,10 @@



-   
  
-   
  


=== added file 
'gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/init'
--- gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/init   
1970-01-01 00:00:00 +
+++ gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/init   
2009-06-03 11:54:07 +
@@ -0,0 +1,1 @@
+{"type":"FeatureCollection","features":[]}
\ No newline at end of file

=== removed file 
'gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/pageload'
--- gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/pageload   
2009-05-29 15:39:03 +
+++ gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geojson/pageload   
1970-01-01 00:00:00 +
@@ -1,18 +0,0 @@
-{
-"type":"FeatureCollection",
-"features":
-[
-{
-"type":"Feature",
-"id":"zn_roads.459",
-"geometry":{
-"type":"MultiLineString",
-
"coordinates":[[[39.739494,-4.94044],[39.738823,-4.935949],[39.727032,-4.91666],[39.724014,-4.907471]]]
-},
-"geometry_name":"the_geom",
-"properties":{"TRACK_ID":0,"ID":" ","RDLNTYPE":2}
-}
-],
-"crs":{"type":"EPSG","properties":{"code":"4326"}},
-"bbox":[38.960568,-7.753602,39.785995,-4.907471]
-}
\ No newline at end of file

=== modified file 
'gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geostat.js'
--- gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geostat.js 
2009-06-02 17:10:54 +
+++ gis/dhis-web-mapping/src/main/webapp/mapping/geostat/geostat.js 
2009-06-03 11:54:07 +
@@ -657,7 +657,7 @@
 //{ html: 'Organisation unit:' 
}, multi, { html: '' },
 { html: 'Organisation unit 
level:' }, organisationUnitLevelComboBox, { html: '' },
 { html: 'Map name:' }, 
newNameTextField, { html: '' },
-{ html: 'Geoserver map layer 
path:' }, mapLayerPathTextField, { html: '' },
+{ html: 'Map file name:' }, 
mapLayerPathTextField, { html: '' },
 { html: 'Unique column:' }, 
newUniqueColumnTextField, { html: '' },
 { html: 'Name column:' }, 
newNameColumnTextField, { html: '' },
 { html: 'Longitude:' }, 
newLongitudeTextField, { html: '' },
@@ -1377,7 +1377,7 @@
 title: 'Thematic map',
 nameAttribute: "NAME",
 indicators: [['value', 'Indicator']],
-url: 'geojson/pageload',
+url: 'geojson/init',
 featureSelection: false,
 loadMask: {msg: 'Loading shapefile...', msgCls: 'x-mask-loading'},
 legendDiv: 'choroplethLegend',
@@ -1402,7 +1402,7 @@
 title: 'Assign organisation units',
 nameAttribute: 'NAME',
 indicators: [['value', 'Indicator']],
-url: 'geojson/pageload',
+url: 'geojson/init',
 featureSelection: false,
 loadMask: {msg: 'Loading shapefile...', msgCls: 'x-mask-loading'},
 legendDiv: 'choroplethLegend',



--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.

___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

2009/6/3 Ola Hodne Titlestad :
> On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe  wrote:
>>
>> 2009/6/3 Ola Hodne Titlestad :
>> > Hi Abyot,
>> >
>> > If you read my summary e-mails just before the skype conference you will
>> > see
>> > that my suggestion was NOT to have a different type of data element, and
>> > I
>> > understood from the skype chat that we agreed on the same. What we
>> > talked
>> > about was to possibly make a separation in the user interface to avoid
>> > confusing the users, but in the background use the same DataElement
>> > object,
>> > but I am not sure that will always be needed as there are lot of overlap
>> > between routine and CHIS data elements.
>> >
>> > As you say, if we want to easily reuse datasets and data entry forms
>> > functionality we need to use the DataElement object also for client data
>> > elements. And of course we want to reuse what Murid has implemented
>> > regarding option lists for pre-defined values for data elements.
>> >
>> > The separation comes in DataValue as the PatientDataValue will need
>> > other
>> > properties than the (routine) DataValue.
>>
>> Agreed.  But what would these properties be exactly?  Two options
>> which have surfaced are:
>> 1. an additional patientID attribute; or
>> 2. no additional attribute - association of patient as a "source"
>>
>> The first is most obvious and perhaps simplest.  And I suspect I am
>> the only one crazy enough to see any merit in exploring the second.
>
> patientID yes, but probably also a DataSetID as we need to keep track (and
> separation) of the encounters/visits (instances of a dataset, "a filled
> form") in a more efficient way than we do in DataValue now.
> At least this is how its done in 1.4 Patient module and also for Survey type
> data.
>
>
>>
>> So I'm guessing Abyot will make a PatientDataElement with something
>> like a patientID.
>
> Data elements do not have any direct reference to its source, so this should
> not be necessary. It is the datavalue that keeps this reference and which
> again is controlled by the dataset.

Sorry typo - I meant PatientDataValue ..


> We would in stead need a maintain Patients/Clients in a separate object, and
> pherhaps in a hierarchy (family, village). Lars also liked the idea of
> implementing the source object here, and I am open to that. After all that
> is why we created the source, to have diffeent types of sources to register
> data, not only orgunits.
> The peirod handling might also be different here as we always work on dates
> since these data are snapshots in time and not aggregtated over a certain
> period.
>
> Calle might have some useful input to how patient values are different from
> routine, apart from the security aspect we already discussed some weeks
> back.
>
>>
>> What else?  Do we need a concept like an encounter (or visit) to which
>> a date would be tied?  Or can something be done with a PeriodType?
>
> If we are going to reuse the DHIS concepts of data element, dataset, data
> entry form and data value then the dataset is the key here.
> In many ways routine datasets and "client" datasets are very similar, and "a
> filled form", or what might be called an instance of a dataset, contains
> values linked to data elements for a given period and a given source. Client
> encounters, rows from a register book, are also like that; a client name,
> multiple data elements (columns in the book) with values, and a date. After
> all its the final row of the register book, the total row aggregating all
> the encounters that gives the routine values for a monthly routine dataset.
> This example also illustrates how data elements overlap between client data
> and routine data, routine data are simply the total of "all clients" for the
> month. (This is not the case in survey audit type of datasets e.g. with
> maternal detah audits, but for standard CHIS it is mostly the case)
>
> If we keep track of the DatasetID in a ClientDataValue object we can the
> easily get an ecounter by querying for a client + a date + a dataset, or a
> list of all encounters (within a certain programme (dataset)) by querying
> for a client + a dataset. Of course it would be possible to get all data
> elements belonging to a dataset without directly referencing datasetid in
> datavalue, we do that today for dataset reports. Again, we need to check
> this with Calle or others, but I think client data are different in the way
> that a data element can exist in multiple datasets AND be registered for all
> of them for the same client and date, because the same data elements in
> different datasets might have different meanings and values. For routine
> this is not the case, that is why we di not keep a reference to dataset in
> datavalue, it is enough to use data element to describe the meaning of the
> data.
>
> So each encounter will be a data entry form, and its metadata will be
> controlled through the dataset object, similar to how its done for routine
> data. In the

[Dhis2-devs] [Bug 383127] Re: DHIS 2 cannot import values greater than 2^31 from DHIS 1.4

** Also affects: dhis2/trunk
   Importance: Undecided
   Status: New

** Changed in: dhis2/trunk
   Importance: Undecided => Medium

** Changed in: dhis2/trunk
Milestone: None => 2.0.2

-- 
DHIS 2 cannot import values greater than 2^31 from DHIS 1.4
https://bugs.launchpad.net/bugs/383127
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.

Status in District Health Information Software 2: New
Status in DHIS Series: trunk: New

Bug description:
This may be related to #348703. Values greater that 2^31 cause the DHIS 1.4 
file import to fail silently. This error is as follows, as occurs with the ODBC 
connector driver, so it needs to be caught early. 

* ERROR 12:57:12,283 The process threw exception (ProcessExecutor.java 
[Thread-17])
java.lang.RuntimeException: Query with RowHandler failed
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:141)
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:124)
at 
org.hisp.dhis.importexport.dhis14.file.importer.DefaultDhis14FileImportService.importRoutineDataValues(DefaultDhis14FileImportService.java:753)
at 
org.hisp.dhis.importexport.dhis14.file.importer.DefaultDhis14FileImportService.importData(DefaultDhis14FileImportService.java:281)
at 
org.hisp.dhis.importexport.ImportInternalProcess.executeStatements(ImportInternalProcess.java:84)
at 
org.hisp.dhis.system.process.AbstractStatementInternalProcess.execute(AbstractStatementInternalProcess.java:85)
at 
org.hisp.dhis.system.process.AbstractStatementInternalProcess.execute(AbstractStatementInternalProcess.java:37)
at 
org.amplecode.cave.process.ProcessExecutor.run(ProcessExecutor.java:126)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException:   
--- The error occurred in sqlmap/routineDataValue.sqlmap.xml.  
--- The error occurred while applying a result map.  
--- Check the routineDataValue.routineDataValueResultMap.  
--- Check the result mapping for the 'value' property.  
--- Cause: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
Caused by: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:185)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithRowHandler(GeneralStatement.java:133)
at 
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryWithRowHandler(SqlMapExecutorDelegate.java:644)
at 
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryWithRowHandler(SqlMapSessionImpl.java:121)
at 
com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryWithRowHandler(SqlMapClientImpl.java:98)
at 
org.hisp.dhis.importexport.dhis14.file.query.IbatisQueryManager.queryWithRowhandler(IbatisQueryManager.java:135)
... 8 more
Caused by: java.sql.SQLException: [Microsoft][ODBC Microsoft Access 
Driver]Numeric value out of range on column number 7 (EntryNumber)
at sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6957)
at sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7114)
at sun.jdbc.odbc.JdbcOdbc.SQLGetDataInteger(JdbcOdbc.java:3811)
at 
sun.jdbc.odbc.JdbcOdbcResultSet.getDataInteger(JdbcOdbcResultSet.java:5638)
at sun.jdbc.odbc.JdbcOdbcResultSet.getInt(JdbcOdbcResultSet.java:583)
at sun.jdbc.odbc.JdbcOdbcResultSet.getInt(JdbcOdbcResultSet.java:601)
at 
com.ibatis.sqlmap.engine.type.IntegerTypeHandler.getResult(IntegerTypeHandler.java:35)
at 
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getPrimitiveResultMappingValue(BasicResultMap.java:565)
at 
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getResults(BasicResultMap.java:319)
at 
com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor.java:394)
at 
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:185)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQuery(GeneralStatement.java:205)
at 
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
... 13 more


I would suggest that at least as a workaround the following procedure could 
possibly be tried?

1) Check to see if such problems exists. Lets get a list of ID´s to exclude 
from the import process..

SELECT RoutineDataID FROM RoutineData WHERE EntryNumber > 2^31 

2) Inform the user that there are some values that cannot be imported. 

2) Then I guess the import process could start, excluding the list of 
RoutineDataID´

[Dhis2-devs] [Bug 383148] [NEW] Completeness button and validations

2009-06-03 Thread Johan Saebo

Public bug reported:

The following scenario would need some better pop-up messages:

Clicking the Complete button at the end of the data entry screen will
prompt the validation checks to be run. However, if there is a violation,
only the violation will appear as a pop-up, but there should also be some
text explaining that they would have to check up and change the values
that cause the violation before the completeness button will work. As it
is now, you can ignore the validation result, but the complete button will
not work.

** Affects: dhis2
 Importance: Undecided
 Status: New

-- 
Completeness button and validations
https://bugs.launchpad.net/bugs/383148
You received this bug notification because you are a member of DHIS 2
developers, which is subscribed to DHIS.

Status in District Health Information Software 2: New

Bug description:
The following scenario would need some better pop-up messages:

Clicking the Complete button at the end of the data entry screen will
prompt the validation checks to be run. However, if there is a violation,
only the violation will appear as a pop-up, but there should also be some
text explaining that they would have to check up and change the values
that cause the violation before the completeness button will work. As it
is now, you can ignore the validation result, but the complete button will
not work.

___
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

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

A bit tricky!

I think we need to maintain both Encounter and DataSet. I mean, a DataSet
evolving to an Encounter whenever a visit is made by either a patient or a
health-worker. This will help us to implement a dynamic DataSet
functionality.  And here the DataSet will be acting only as a template to
guide an Encounter.

· DataSet

o   Source

o   Period (for CHIS, daily periodType)

o   set



· ActivityPlan

o   Owner – person (Health Extension Worker)

o   Supervisor – person (Medical Officer)

o   Date – date

o   Activities – set



· Encounter  *implements* DataSet

o   Where – source (could be house or facility or anything else…)

o   When – date (time stamp)

o   ByWhom – person (the patient)

o   What – set (list of data to be collected)



· PatientDataValue

o   EncounterID

o   DataElementID

o   OptionComboID (just in case we are going to collecet multiple values for
a dataelement)

o   Value

Activity plan is linked to an Encounter because during a house-to-house
visit, health-workers are to follow a strict plan, signed by her/his
supervisor outlining whom to meet, where, when and what kind of service to
give (or what kind of data to collect).

The above approach will help us to do scheduling/tracking which I guess are
very much linked to Encounters. For example a Mother need to be scheduled
for a 2nd ANC Encounter following her 1st ANC Encounter, or similarly for
Child Immunization.

The dataelement classification is only to have a nice and tidy list of
dataelements on the GUI, for example not showing patient related
dataelements in indicator or datamart processing - which is a nice idea of
Ola. The classification will have no use for the functionality of CHIS.

Thanks
Abyot.

On Wed, Jun 3, 2009 at 2:04 PM, Bob Jolliffe  wrote:

> 2009/6/3 Ola Hodne Titlestad :
> > On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe 
> wrote:
> >>
> >> 2009/6/3 Ola Hodne Titlestad :
> >> > Hi Abyot,
> >> >
> >> > If you read my summary e-mails just before the skype conference you
> will
> >> > see
> >> > that my suggestion was NOT to have a different type of data element,
> and
> >> > I
> >> > understood from the skype chat that we agreed on the same. What we
> >> > talked
> >> > about was to possibly make a separation in the user interface to avoid
> >> > confusing the users, but in the background use the same DataElement
> >> > object,
> >> > but I am not sure that will always be needed as there are lot of
> overlap
> >> > between routine and CHIS data elements.
> >> >
> >> > As you say, if we want to easily reuse datasets and data entry forms
> >> > functionality we need to use the DataElement object also for client
> data
> >> > elements. And of course we want to reuse what Murid has implemented
> >> > regarding option lists for pre-defined values for data elements.
> >> >
> >> > The separation comes in DataValue as the PatientDataValue will need
> >> > other
> >> > properties than the (routine) DataValue.
> >>
> >> Agreed.  But what would these properties be exactly?  Two options
> >> which have surfaced are:
> >> 1. an additional patientID attribute; or
> >> 2. no additional attribute - association of patient as a "source"
> >>
> >> The first is most obvious and perhaps simplest.  And I suspect I am
> >> the only one crazy enough to see any merit in exploring the second.
> >
> > patientID yes, but probably also a DataSetID as we need to keep track
> (and
> > separation) of the encounters/visits (instances of a dataset, "a filled
> > form") in a more efficient way than we do in DataValue now.
> > At least this is how its done in 1.4 Patient module and also for Survey
> type
> > data.
> >
> >
> >>
> >> So I'm guessing Abyot will make a PatientDataElement with something
> >> like a patientID.
> >
> > Data elements do not have any direct reference to its source, so this
> should
> > not be necessary. It is the datavalue that keeps this reference and which
> > again is controlled by the dataset.
>
> Sorry typo - I meant PatientDataValue ..
>
>
> > We would in stead need a maintain Patients/Clients in a separate object,
> and
> > pherhaps in a hierarchy (family, village). Lars also liked the idea of
> > implementing the source object here, and I am open to that. After all
> that
> > is why we created the source, to have diffeent types of sources to
> register
> > data, not only orgunits.
> > The peirod handling might also be different here as we always work on
> dates
> > since these data are snapshots in time and not aggregtated over a certain
> > period.
> >
> > Calle might have some useful input to how patient values are different
> from
> > routine, apart from the security aspect we already discussed some weeks
> > back.
> >
> >>
> >> What else?  Do we need a concept like an encounter (or visit) to which
> >> a date would be tied?  Or can something be done with a PeriodType?
> >
> > If we are going to reuse the DHIS concepts of data element, dataset, data
> > entry form and dat

[Dhis2-devs] DHIS2-URL! The week in dhis2 development

Issue 3: Monday 25 May to Wedneday 3 June

Greetings

This week was yet another a busy one on and around
https://launchpad.net/dhis2 with the trunk revision number moving from
321 to 355 (see summary list of commits below).

Besides the usual run of bug reports and requests for assistance, the
major discussion of the past week on the mailing list has been around
the new community based system or module.

Abyot got the ball rolling with this [post
http://n2.nabble.com/Coding-layout---Community-Based-Health-Information-System-%28CBHIS%29-td2968595.html]
where he laid out a basic design plan. This developed into a long and
interesting thread including a summary from Ola of the functional
requirements coming out of Vietnam, India and Zanzibar.

Chau Thu Tran shared the work they have been doing in Vietnam,
including a fairly detailed requirements specification document here:
http://n2.nabble.com/Child-Health-Record---ideas-in-Viet-Nam-td2879276.html.
[probably this, and other documents shared by mail, should be put on
the wiki or somewhere for posterity]

The process lead up to an interactive skype chat conference on
Thursday whose text has been captured here
[https://lists.launchpad.net/dhis2-devs/msg01180.html]

Work has now started on the module with a new branch created here:
[https://code.launchpad.net/~dhis2-devs/dhis2/dhis2-chis]

I haven't picked up any blueprint changes this week. But a new one
has just been added:
[https://blueprints.launchpad.net/dhis2/+spec/data-export-information/]
by Johan Saebo.

Here's the summary of trunk commits:

355 Jan Henrik Overland 2009-06-03
Unique value enforced from getMapOrganisationUnitRelation.

354 Jan Henrik Overland 2009-06-03
Mapping bug fixed.

353 Bob Jolliffe 2009-06-03
Fixed error in weeklyperiod test

352 Jan Henrik Overland 2009-06-02
New method (fixed bounds) added. Set your own bounds, as many as you like.

351 Miri 2009-06-02
Added auto suggestion to Custom Value dataset option. While
typing more than 2 chars in new CustomValue field list of suggestions
will appear, user can select one from the list and press Add.

350 Jan Henrik Overland 2009-06-02
Period type name now used instead of internal period type id.

349 Jan Henrik Overland 2009-05-31
Removed unnecessary file.

348 Jan Henrik Overland 2009-05-31
SL facilities geojson added.

347 Jan Henrik Overland 2009-05-29
Loading local GeoJSON = Geoserver no longer needed.

Add views to DHIS 2 dashboard UI added.

Max 25 character check on map, legend set and view names.

346 Lars Helge Oeverland 2009-05-29
Minor fix

345 Lars Helge Oeverland 2009-05-29
Updated UserCredentialsDeletionHandler

344 Lars Helge Oeverland 2009-05-29
Work in progress on mapview in dashboard

343 Lars Helge Oeverland 2009-05-29
Work in progress on mapview in dashboard

342 Jan Henrik Overland 2009-05-29
Added action

341 Jan Henrik Overland 2009-05-29
addOrUpdateMapLegendSet added + maplegendset and mapview bugs fixed.

340 Tran Thanh Tri in the combo boxes as well.

328 Lars Helge Oeverland 2009-05-25
Cleaned up the web POMs

327 Jan Henrik Overland 2009-05-25
Test code removed.

326 Jan Henrik Overland 2009-05-25
Now add several indicators when creating a new legend set.

325 Jan Henrik Overland 2009-05-25
Index file path updated.

324 Jan Henrik Overland 2009-05-25
Folder 'demos' renamed to 'mapping'.

323 Jan Henrik Overland 2009-05-25
Database and shapefile orgunits counter added.

322 Lars Helge Oeverland 2009-05-25
- Slimmed down xwork.xml config files. - Made the ValidationRule
- Expression relation cascading with Hibernate.

321 Lars Helge Oeverland 2009-05-25
Slimming down xwork.xml

320 Lars Helge Oeverland 2009-05-23
Made the Period constructor protected and updated a few tests.

319 Lars Helge Oeverland 2009-05-23
Added test for datamart

318 Lars Helge Oeverland 2009-05-23
- Added some unit tests for the API. - Service implementation of
aggregation level boundaries in data mart.

317 Miri 2009-05-23
Some localization added to Audit functionality.

316 Miri 2009-05-23
Added Audit functionality for Data Values. Accessible from
DataValue History popup window. Audit will truck adding, updating and
deleting. All strings are localized.

315 Jan Henrik Overland 2009-05-22
Method and classes now part of MapLegendSet object + Background
wfs is now loading entirely on startup.

314 Miri 2009-05-20
Added new L&F to Customvalue edit Form.

313 Lars Helge Oeverland 2009-05-20
Added some missing transaction definitions

312 Lars Helge Oeverland 2009-05-20
Added URL GUI property for dat

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

2009/6/3 Abyot Gizaw 

> A bit tricky!
>
> I think we need to maintain both Encounter and DataSet. I mean, a DataSet
> evolving to an Encounter whenever a visit is made by either a patient or a
> health-worker. This will help us to implement a dynamic DataSet
> functionality.  And here the DataSet will be acting only as a template to
> guide an Encounter.
>
> · DataSet
>
> o   Source
>
> o   Period (for CHIS, daily periodType)
>
> o   set
>
>
>
> · ActivityPlan
>
> o   Owner – person (Health Extension Worker)
>
> o   Supervisor – person (Medical Officer)
>
> o   Date – date
>
> o   Activities – set
>
>
>
> · Encounter  *implements* DataSet
>
> o   Where – source (could be house or facility or anything else…)
>
> o   When – date (time stamp)
>
> o   ByWhom – person (the patient)
>
> o   What – set (list of data to be collected)
>
> Sorry for the above strange stuff. I think it is better like down below.


· Encounter

o   DataSet

o   ByWhom – person (the patient)

o   When – date (time stamp)


>
> · PatientDataValue
>
> o   EncounterID
>
> o   DataElementID
>
> o   OptionComboID (just in case we are going to collecet multiple values
> for a dataelement)
>
> o   Value
>
> Activity plan is linked to an Encounter because during a house-to-house
> visit, health-workers are to follow a strict plan, signed by her/his
> supervisor outlining whom to meet, where, when and what kind of service to
> give (or what kind of data to collect).
>
> The above approach will help us to do scheduling/tracking which I guess are
> very much linked to Encounters. For example a Mother need to be scheduled
> for a 2nd ANC Encounter following her 1st ANC Encounter, or similarly for
> Child Immunization.
>
> The dataelement classification is only to have a nice and tidy list of
> dataelements on the GUI, for example not showing patient related
> dataelements in indicator or datamart processing - which is a nice idea of
> Ola. The classification will have no use for the functionality of CHIS.
>
> Thanks
> Abyot.
>
> On Wed, Jun 3, 2009 at 2:04 PM, Bob Jolliffe wrote:
>
>> 2009/6/3 Ola Hodne Titlestad :
>> > On Wed, Jun 3, 2009 at 12:04 PM, Bob Jolliffe 
>> wrote:
>> >>
>> >> 2009/6/3 Ola Hodne Titlestad :
>> >> > Hi Abyot,
>> >> >
>> >> > If you read my summary e-mails just before the skype conference you
>> will
>> >> > see
>> >> > that my suggestion was NOT to have a different type of data element,
>> and
>> >> > I
>> >> > understood from the skype chat that we agreed on the same. What we
>> >> > talked
>> >> > about was to possibly make a separation in the user interface to
>> avoid
>> >> > confusing the users, but in the background use the same DataElement
>> >> > object,
>> >> > but I am not sure that will always be needed as there are lot of
>> overlap
>> >> > between routine and CHIS data elements.
>> >> >
>> >> > As you say, if we want to easily reuse datasets and data entry forms
>> >> > functionality we need to use the DataElement object also for client
>> data
>> >> > elements. And of course we want to reuse what Murid has implemented
>> >> > regarding option lists for pre-defined values for data elements.
>> >> >
>> >> > The separation comes in DataValue as the PatientDataValue will need
>> >> > other
>> >> > properties than the (routine) DataValue.
>> >>
>> >> Agreed.  But what would these properties be exactly?  Two options
>> >> which have surfaced are:
>> >> 1. an additional patientID attribute; or
>> >> 2. no additional attribute - association of patient as a "source"
>> >>
>> >> The first is most obvious and perhaps simplest.  And I suspect I am
>> >> the only one crazy enough to see any merit in exploring the second.
>> >
>> > patientID yes, but probably also a DataSetID as we need to keep track
>> (and
>> > separation) of the encounters/visits (instances of a dataset, "a filled
>> > form") in a more efficient way than we do in DataValue now.
>> > At least this is how its done in 1.4 Patient module and also for Survey
>> type
>> > data.
>> >
>> >
>> >>
>> >> So I'm guessing Abyot will make a PatientDataElement with something
>> >> like a patientID.
>> >
>> > Data elements do not have any direct reference to its source, so this
>> should
>> > not be necessary. It is the datavalue that keeps this reference and
>> which
>> > again is controlled by the dataset.
>>
>> Sorry typo - I meant PatientDataValue ..
>>
>>
>> > We would in stead need a maintain Patients/Clients in a separate object,
>> and
>> > pherhaps in a hierarchy (family, village). Lars also liked the idea of
>> > implementing the source object here, and I am open to that. After all
>> that
>> > is why we created the source, to have diffeent types of sources to
>> register
>> > data, not only orgunits.
>> > The peirod handling might also be different here as we always work on
>> dates
>> > since these data are snapshots in time and not aggregtated over a
>> certain
>> > period.
>> >
>> > Calle might have some useful i

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement

Hi,

Sorry, maybe I'm a bit slow, but I don't manage to follow this reasoning.

First of all I get a bit confused as to what is metadata and data in your
model Abyot. Now it seems you have split up data values for patient data
into two objects, Encounter and PatientDataValue, is that right? I can see
that PatientDataValue does no longer have a refenece to place or time, but
that this is taken care of through an Encounter.

If that is the case then we will not get the straight forward calculation of
aggregated data that we would have with Date (easily up to month) and
Orgunit (group data values by orgunit) in PatientDataValue, which I would
not recommend, especially for other use cases like birth/death audits or
disease surveillance.

(Guess I forgot to mention the orgunit reference from patient data value
earlier today,although it has been mentioned before. It has many advantages
when zooming in and out between aggregated and disaggregated data.)

But from your description of an Encounter as part of the tasks carry out in
the generated activity plan I got the feeling that Encounter is metdata
describing HOW to collect the datavalues as is the case with data sets.  "By
whom" and "when" in Encounter, seems to be information belonging to a data
value, and not metadata. If the references to Whom and When in Encounter are
"planned values" something you are supposed to do then I get it, but then I
guess we cannot use the same values as part of the data value, I mean the
world does not always go according to the plan. Maybe you just forgot to add
a reference to PatientID and Date (and Source maybe) in PatientDataValue, if
so then it would make sense to me.

I am not sure I like how you model mixes activities and plans with the
straightforward DHIS design of data elements, datasets, datavalues. Could
your planned activities be linked to dataset, patient, and source without
interfering with dataset and datavalue? That would keep the model simpler
and easier to use for other use cases where we ant to collect case-based or
client data.

An Encounter or a register, isn't that simply a view on top of patient data
values (filtered by dataset, date, patient), similar to a dataset report in
routine DHIS? I understand the importance of referencing the encounter from
the datavalue, but not sure I see the point of this dataset+encounter
design. Your Encounter object sounds more like an Activity object which is
stricty metadata (that says something of what you plan to do) and not a
regsiter/encounter (which says what have been done) that has values for a
patient, date and a set of data elements.

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

2009/6/3 Abyot Gizaw 

>
>
> 2009/6/3 Abyot Gizaw 
>
>> A bit tricky!
>>
>> I think we need to maintain both Encounter and DataSet. I mean, a DataSet
>> evolving to an Encounter whenever a visit is made by either a patient or a
>> health-worker. This will help us to implement a dynamic DataSet
>> functionality.  And here the DataSet will be acting only as a template to
>> guide an Encounter.
>>
>> · DataSet
>>
>> o   Source
>>
>> o   Period (for CHIS, daily periodType)
>>
>> o   set
>>
>>
>>
>> · ActivityPlan
>>
>> o   Owner – person (Health Extension Worker)
>>
>> o   Supervisor – person (Medical Officer)
>>
>> o   Date – date
>>
>> o   Activities – set
>>
>>
>>
>> · Encounter  *implements* DataSet
>>
>> o   Where – source (could be house or facility or anything else…)
>>
>> o   When – date (time stamp)
>>
>> o   ByWhom – person (the patient)
>>
>> o   What – set (list of data to be collected)
>>
>> Sorry for the above strange stuff. I think it is better like down below.
>
>
> · Encounter
>
> o   DataSet
>
> o   ByWhom – person (the patient)
>
> o   When – date (time stamp)
>
>
>>
>> · PatientDataValue
>>
>> o   EncounterID
>>
>> o   DataElementID
>>
>> o   OptionComboID (just in case we are going to collecet multiple values
>> for a dataelement)
>>
>> o   Value
>>
>> Activity plan is linked to an Encounter because during a house-to-house
>> visit, health-workers are to follow a strict plan, signed by her/his
>> supervisor outlining whom to meet, where, when and what kind of service to
>> give (or what kind of data to collect).
>>
>> The above approach will help us to do scheduling/tracking which I guess
>> are very much linked to Encounters. For example a Mother need to be
>> scheduled for a 2nd ANC Encounter following her 1st ANC Encounter, or
>> similarly for Child Immunization.
>>
>> The dataelement classification is only to have a nice and tidy list of
>> dataelements on the GUI, for example not showing patient related
>> dataelements in indicator or datamart processing - which is a nice idea of
>> Ola. The classification will have no use for the functionality of CHIS.
>>
>> Thanks
>> Abyot.
>>
>> On Wed, Jun 3, 2009 at 2:04 PM, Bob Jolliffe wrote:
>>
>>> 2009/6/3 Ola Hodne Titlestad :
>>> > On Wed, Jun 3, 2009 at 12:04 PM, Bob J

Re: [Dhis2-devs] patient_dataelement Vs routine_dataelement