Urgent feedback required

Support - Assistance technique
1

Hi,

I need some urgent feedback on one very specific issue:

1.
We have a lot of monthly data that have been captured on a daily basis
(up to now in 1.4). The data is in reality monthly aggregated data
because it is the monthly totals that are used for indicators,
analysis, reports etc - but the data is captured daily into DHIS to
enable consistency/completeness tracking and to cut down on the
erroneous manual data compilation from paper forms at the end of every
month.

2.
Initially, the HISP team converted these daily captured values in 1.4
into datavalues in DHIS2 with dataperiodtype = daily. This approach
has various shortcomings, in particular when the use of daily
capturing is slowly being rolled out - meaning that while let us say
30% of all facilities captured data on a daily basis themselves, the
remaining 70% are still submitting monthly summary forms to the
sub-district office for capturing as monthly total data.

3.
I believe a more logical approach is to store the daily data (Day01,
Day02, ...., Day31) as categories - as mentioned, we are in general
NOT using those daily values for anything beyond the initial data
quality and completeness process.

QUESTION:
1. Are there any major drawbacks to storing these daily values as categories?

2. Are there any major limitations with regard to the design of data
entry forms that will make it difficult to have a "matrix" type data
entry form where
(a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)
(b) the year/month part of that date determines the dataperiodid
(c) the day portion of the date determines which category will be the
right-most column in the data entry matrix
(d) we can display let us say 7 preceding days in the matrix to assist
the data capturer with eyeballing data during capture (dynamic
selection & display of categories).

So the entry form would show up as
DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30
<data element1> 17 14 15 22 18
19 20 <entry>
<data element2> 13 11 19 8 15
12 10 <entry>

Any quick feedback would be appreciated

Regards
Calle

···

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

*******************************************

2

Hi Calle

I never thought of using categories like that, but it looks to me like it would work. Category=DayOfTheMonth, CategoryOptions=“Day1,Day2,…,Day31”. The sum of the categoryoptions add up to the total for the month which I think is consistent with rational category design.

···

Obviously you’ll need to make a heavily customized form, but I can’t see a reason why that shouldn’t be doable.

Bob

On 30 January 2015 at 13:11, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi,

I need some urgent feedback on one very specific issue:

We have a lot of monthly data that have been captured on a daily basis

(up to now in 1.4). The data is in reality monthly aggregated data

because it is the monthly totals that are used for indicators,

analysis, reports etc - but the data is captured daily into DHIS to

enable consistency/completeness tracking and to cut down on the

erroneous manual data compilation from paper forms at the end of every

month.

Initially, the HISP team converted these daily captured values in 1.4

into datavalues in DHIS2 with dataperiodtype = daily. This approach

has various shortcomings, in particular when the use of daily

capturing is slowly being rolled out - meaning that while let us say

30% of all facilities captured data on a daily basis themselves, the

remaining 70% are still submitting monthly summary forms to the

sub-district office for capturing as monthly total data.

I believe a more logical approach is to store the daily data (Day01,

Day02, …, Day31) as categories - as mentioned, we are in general

NOT using those daily values for anything beyond the initial data

quality and completeness process.

QUESTION:

  1. Are there any major drawbacks to storing these daily values as categories?

  2. Are there any major limitations with regard to the design of data

entry forms that will make it difficult to have a “matrix” type data

entry form where

(a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)

(b) the year/month part of that date determines the dataperiodid

(c) the day portion of the date determines which category will be the

right-most column in the data entry matrix

(d) we can display let us say 7 preceding days in the matrix to assist

the data capturer with eyeballing data during capture (dynamic

selection & display of categories).

So the entry form would show up as

DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30

17 14 15 22 18

19 20

13 11 19 8 15

12 10

Any quick feedback would be appreciated

Regards

Calle

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

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

3

Why not just make the dataset daily and transform all monthly data such that it occurs on the last day of the month?

···

On Fri, Jan 30, 2015 at 2:11 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi,

I need some urgent feedback on one very specific issue:

We have a lot of monthly data that have been captured on a daily basis

(up to now in 1.4). The data is in reality monthly aggregated data

because it is the monthly totals that are used for indicators,

analysis, reports etc - but the data is captured daily into DHIS to

enable consistency/completeness tracking and to cut down on the

erroneous manual data compilation from paper forms at the end of every

month.

Initially, the HISP team converted these daily captured values in 1.4

into datavalues in DHIS2 with dataperiodtype = daily. This approach

has various shortcomings, in particular when the use of daily

capturing is slowly being rolled out - meaning that while let us say

30% of all facilities captured data on a daily basis themselves, the

remaining 70% are still submitting monthly summary forms to the

sub-district office for capturing as monthly total data.

I believe a more logical approach is to store the daily data (Day01,

Day02, …, Day31) as categories - as mentioned, we are in general

NOT using those daily values for anything beyond the initial data

quality and completeness process.

QUESTION:

  1. Are there any major drawbacks to storing these daily values as categories?
  1. Are there any major limitations with regard to the design of data

entry forms that will make it difficult to have a “matrix” type data

entry form where

(a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)

(b) the year/month part of that date determines the dataperiodid

(c) the day portion of the date determines which category will be the

right-most column in the data entry matrix

(d) we can display let us say 7 preceding days in the matrix to assist

the data capturer with eyeballing data during capture (dynamic

selection & display of categories).

So the entry form would show up as

DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30

17 14 15 22 18

19 20

13 11 19 8 15

12 10

Any quick feedback would be appreciated

Regards

Calle

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

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

–

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+46764147049

4

we have a similar requirement in Mozambique and thought of using categories as well. unfortunately here the forms must show data for statistical months which start on the 27th day. makes it much harder to display a full month on one form leaving out 29/30/31st depending on month.

···

Obviously you’ll need to make a heavily customized form, but I can’t see a reason why that shouldn’t be doable.

Bob

On 30 January 2015 at 13:11, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi,

I need some urgent feedback on one very specific issue:

We have a lot of monthly data that have been captured on a daily basis

(up to now in 1.4). The data is in reality monthly aggregated data

because it is the monthly totals that are used for indicators,

analysis, reports etc - but the data is captured daily into DHIS to

enable consistency/completeness tracking and to cut down on the

erroneous manual data compilation from paper forms at the end of every

month.

Initially, the HISP team converted these daily captured values in 1.4

into datavalues in DHIS2 with dataperiodtype = daily. This approach

has various shortcomings, in particular when the use of daily

capturing is slowly being rolled out - meaning that while let us say

30% of all facilities captured data on a daily basis themselves, the

remaining 70% are still submitting monthly summary forms to the

sub-district office for capturing as monthly total data.

I believe a more logical approach is to store the daily data (Day01,

Day02, …, Day31) as categories - as mentioned, we are in general

NOT using those daily values for anything beyond the initial data

quality and completeness process.

QUESTION:

  1. Are there any major drawbacks to storing these daily values as categories?

  2. Are there any major limitations with regard to the design of data

entry forms that will make it difficult to have a “matrix” type data

entry form where

(a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)

(b) the year/month part of that date determines the dataperiodid

(c) the day portion of the date determines which category will be the

right-most column in the data entry matrix

(d) we can display let us say 7 preceding days in the matrix to assist

the data capturer with eyeballing data during capture (dynamic

selection & display of categories).

So the entry form would show up as

DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30

17 14 15 22 18

19 20

13 11 19 8 15

12 10

Any quick feedback would be appreciated

Regards

Calle

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

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

5

Hi Calle

I voted for Jason's suggestion. In Vietnam, in many cases we use this
approach.
Hacking dhis2 by using days as categories will be problematic in the long
run although such problems may not be visible now.

Once time in the past someone told us to use departments of hospitals as
categories (instead of orgunit). We followed this and this went bankcrupt
shortly.

Thanh

···

On Fri, Jan 30, 2015 at 9:52 PM, Jason Pickering < jason.p.pickering@gmail.com> wrote:

Why not just make the dataset daily and transform all monthly data such
that it occurs on the last day of the month?

On Fri, Jan 30, 2015 at 2:11 PM, Calle Hedberg <calle.hedberg@gmail.com> > wrote:
> Hi,
>
> I need some urgent feedback on one very specific issue:
>
> 1.
> We have a lot of monthly data that have been captured on a daily basis
> (up to now in 1.4). The data is in reality monthly aggregated data
> because it is the monthly totals that are used for indicators,
> analysis, reports etc - but the data is captured daily into DHIS to
> enable consistency/completeness tracking and to cut down on the
> erroneous manual data compilation from paper forms at the end of every
> month.
>
> 2.
> Initially, the HISP team converted these daily captured values in 1.4
> into datavalues in DHIS2 with dataperiodtype = daily. This approach
> has various shortcomings, in particular when the use of daily
> capturing is slowly being rolled out - meaning that while let us say
> 30% of all facilities captured data on a daily basis themselves, the
> remaining 70% are still submitting monthly summary forms to the
> sub-district office for capturing as monthly total data.
>
> 3.
> I believe a more logical approach is to store the daily data (Day01,
> Day02, ...., Day31) as categories - as mentioned, we are in general
> NOT using those daily values for anything beyond the initial data
> quality and completeness process.
>
> QUESTION:
> 1. Are there any major drawbacks to storing these daily values as
categories?
>
> 2. Are there any major limitations with regard to the design of data
> entry forms that will make it difficult to have a "matrix" type data
> entry form where
> (a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)
> (b) the year/month part of that date determines the dataperiodid
> (c) the day portion of the date determines which category will be the
> right-most column in the data entry matrix
> (d) we can display let us say 7 preceding days in the matrix to assist
> the data capturer with eyeballing data during capture (dynamic
> selection & display of categories).
>
> So the entry form would show up as
> DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30
> <data element1> 17 14 15 22 18
> 19 20 <entry>
> <data element2> 13 11 19 8 15
> 12 10 <entry>
>
> Any quick feedback would be appreciated
>
> Regards
> Calle
>
> *******************************************
>
> Calle Hedberg
>
> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>
> Tel/fax (home): +27-21-685-6472
>
> Cell: +27-82-853-5352
>
> Iridium SatPhone: +8816-315-19274
>
> Email: calle.hedberg@gmail.com
>
> Skype: calle_hedberg
>
> *******************************************
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

6

Than/Jason,

You cannot compare this with e.g. using departments of hospitals as
categories (to me an obviously BAD idea since you are trying to model
what is fundamentally an geographical/administrative dimension
phenomena as a fact dimension phenomena).

For me, using a daily data set with some data elements captured daily
and some data elements captured "monthly" is equally prone to become a
mess - you actually need very stringent controls ensuring that users
do not end up capturing both. In the type of changing environment we
have - where facilities are gradually shifting from using monthly
capturing at facility level to using daily capturing at
service/consulting-room/ward level - it will be very very difficult to
manage.

It is also important to understand that the use of daily capturing is
a data collection side phenomena/artefact - nobody is going to use the
daily values for anything beyond the initial data completeness &
quality assurance cycle. So after a year or two, we might simply do a
backup of those daily values and then remove them from the production
system, leaving only the monthly totals that are used for analysis and
reporting.

Otherwise, your point about the hosp dept highlights a fundamental
weakness with the current category/option design: technically the
design enables users to do almost anything - when you combine that
with limited or non-existing guidance (ref user manuals etc) on how to
define them in a systematic manner, you get a free-for-all landscape
where many database instance ends up having chaotic dataset by dataset
category/option setups that are difficult to maintain for the creators
and nearly impossible to understand for other people joining later.
(ref also a recent thread with posts by Bob, Jim, Jason, and the
OpenMRS crowd)

Regards
Calle

···

On 03/02/2015, Ngoc Thanh Nguyen <thanh.hispvietnam@gmail.com> wrote:

Hi Calle

I voted for Jason's suggestion. In Vietnam, in many cases we use this
approach.
Hacking dhis2 by using days as categories will be problematic in the long
run although such problems may not be visible now.

Once time in the past someone told us to use departments of hospitals as
categories (instead of orgunit). We followed this and this went bankcrupt
shortly.

Thanh

On Fri, Jan 30, 2015 at 9:52 PM, Jason Pickering < > jason.p.pickering@gmail.com> wrote:

Why not just make the dataset daily and transform all monthly data such
that it occurs on the last day of the month?

On Fri, Jan 30, 2015 at 2:11 PM, Calle Hedberg <calle.hedberg@gmail.com> >> wrote:
> Hi,
>
> I need some urgent feedback on one very specific issue:
>
> 1.
> We have a lot of monthly data that have been captured on a daily basis
> (up to now in 1.4). The data is in reality monthly aggregated data
> because it is the monthly totals that are used for indicators,
> analysis, reports etc - but the data is captured daily into DHIS to
> enable consistency/completeness tracking and to cut down on the
> erroneous manual data compilation from paper forms at the end of every
> month.
>
> 2.
> Initially, the HISP team converted these daily captured values in 1.4
> into datavalues in DHIS2 with dataperiodtype = daily. This approach
> has various shortcomings, in particular when the use of daily
> capturing is slowly being rolled out - meaning that while let us say
> 30% of all facilities captured data on a daily basis themselves, the
> remaining 70% are still submitting monthly summary forms to the
> sub-district office for capturing as monthly total data.
>
> 3.
> I believe a more logical approach is to store the daily data (Day01,
> Day02, ...., Day31) as categories - as mentioned, we are in general
> NOT using those daily values for anything beyond the initial data
> quality and completeness process.
>
> QUESTION:
> 1. Are there any major drawbacks to storing these daily values as
categories?
>
> 2. Are there any major limitations with regard to the design of data
> entry forms that will make it difficult to have a "matrix" type data
> entry form where
> (a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)
> (b) the year/month part of that date determines the dataperiodid
> (c) the day portion of the date determines which category will be the
> right-most column in the data entry matrix
> (d) we can display let us say 7 preceding days in the matrix to assist
> the data capturer with eyeballing data during capture (dynamic
> selection & display of categories).
>
> So the entry form would show up as
> DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30
> <data element1> 17 14 15 22 18
> 19 20 <entry>
> <data element2> 13 11 19 8 15
> 12 10 <entry>
>
> Any quick feedback would be appreciated
>
> Regards
> Calle
>
> *******************************************
>
> Calle Hedberg
>
> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>
> Tel/fax (home): +27-21-685-6472
>
> Cell: +27-82-853-5352
>
> Iridium SatPhone: +8816-315-19274
>
> Email: calle.hedberg@gmail.com
>
> Skype: calle_hedberg
>
> *******************************************
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

*******************************************

7

Hi Calle,

But I thought you said you were importing this data from 1.4? My point
was, if you are importing this from 1.4, you could simply transform
the data into something which appears to be daily. If people were to
enter both, well, of course that would be a problem, but if it is a
centralized data transformation from 1.4 and importing it into DHIS 2,
then it should not be an issue, as this situation could be easily
checked for.

You are certainly right about the catcombos being able to be used for
just about anything, but usually when it does not feel right, it
probably isn't. Representing days with categories would seem just as
risky and you would of course loose all of the ability to aggregate
things over time (days to months, months to quarters etc).

In regards to the documentation (or lack there of), it is really up to
the community to document what is good and bad practice. Contributions
are welcome and needed. (https://github.com/dhis2/dhis2docs\)

Regards,
Jason

···

On Tue, Feb 3, 2015 at 10:53 AM, Calle Hedberg <calle.hedberg@gmail.com> wrote:

Than/Jason,

You cannot compare this with e.g. using departments of hospitals as
categories (to me an obviously BAD idea since you are trying to model
what is fundamentally an geographical/administrative dimension
phenomena as a fact dimension phenomena).

For me, using a daily data set with some data elements captured daily
and some data elements captured "monthly" is equally prone to become a
mess - you actually need very stringent controls ensuring that users
do not end up capturing both. In the type of changing environment we
have - where facilities are gradually shifting from using monthly
capturing at facility level to using daily capturing at
service/consulting-room/ward level - it will be very very difficult to
manage.

It is also important to understand that the use of daily capturing is
a data collection side phenomena/artefact - nobody is going to use the
daily values for anything beyond the initial data completeness &
quality assurance cycle. So after a year or two, we might simply do a
backup of those daily values and then remove them from the production
system, leaving only the monthly totals that are used for analysis and
reporting.

Otherwise, your point about the hosp dept highlights a fundamental
weakness with the current category/option design: technically the
design enables users to do almost anything - when you combine that
with limited or non-existing guidance (ref user manuals etc) on how to
define them in a systematic manner, you get a free-for-all landscape
where many database instance ends up having chaotic dataset by dataset
category/option setups that are difficult to maintain for the creators
and nearly impossible to understand for other people joining later.
(ref also a recent thread with posts by Bob, Jim, Jason, and the
OpenMRS crowd)

Regards
Calle

On 03/02/2015, Ngoc Thanh Nguyen <thanh.hispvietnam@gmail.com> wrote:

Hi Calle

I voted for Jason's suggestion. In Vietnam, in many cases we use this
approach.
Hacking dhis2 by using days as categories will be problematic in the long
run although such problems may not be visible now.

Once time in the past someone told us to use departments of hospitals as
categories (instead of orgunit). We followed this and this went bankcrupt
shortly.

Thanh

On Fri, Jan 30, 2015 at 9:52 PM, Jason Pickering < >> jason.p.pickering@gmail.com> wrote:

Why not just make the dataset daily and transform all monthly data such
that it occurs on the last day of the month?

On Fri, Jan 30, 2015 at 2:11 PM, Calle Hedberg <calle.hedberg@gmail.com> >>> wrote:
> Hi,
>
> I need some urgent feedback on one very specific issue:
>
> 1.
> We have a lot of monthly data that have been captured on a daily basis
> (up to now in 1.4). The data is in reality monthly aggregated data
> because it is the monthly totals that are used for indicators,
> analysis, reports etc - but the data is captured daily into DHIS to
> enable consistency/completeness tracking and to cut down on the
> erroneous manual data compilation from paper forms at the end of every
> month.
>
> 2.
> Initially, the HISP team converted these daily captured values in 1.4
> into datavalues in DHIS2 with dataperiodtype = daily. This approach
> has various shortcomings, in particular when the use of daily
> capturing is slowly being rolled out - meaning that while let us say
> 30% of all facilities captured data on a daily basis themselves, the
> remaining 70% are still submitting monthly summary forms to the
> sub-district office for capturing as monthly total data.
>
> 3.
> I believe a more logical approach is to store the daily data (Day01,
> Day02, ...., Day31) as categories - as mentioned, we are in general
> NOT using those daily values for anything beyond the initial data
> quality and completeness process.
>
> QUESTION:
> 1. Are there any major drawbacks to storing these daily values as
categories?
>
> 2. Are there any major limitations with regard to the design of data
> entry forms that will make it difficult to have a "matrix" type data
> entry form where
> (a) the user select OrgUnit, DataSet, and the DATE (as in 2015-01-30)
> (b) the year/month part of that date determines the dataperiodid
> (c) the day portion of the date determines which category will be the
> right-most column in the data entry matrix
> (d) we can display let us say 7 preceding days in the matrix to assist
> the data capturer with eyeballing data during capture (dynamic
> selection & display of categories).
>
> So the entry form would show up as
> DataElement Day23 Day24 Day25 Day26 Day27 Day28 Day29 Day30
> <data element1> 17 14 15 22 18
> 19 20 <entry>
> <data element2> 13 11 19 8 15
> 12 10 <entry>
>
> Any quick feedback would be appreciated
>
> Regards
> Calle
>
> *******************************************
>
> Calle Hedberg
>
> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>
> Tel/fax (home): +27-21-685-6472
>
> Cell: +27-82-853-5352
>
> Iridium SatPhone: +8816-315-19274
>
> Email: calle.hedberg@gmail.com
>
> Skype: calle_hedberg
>
> *******************************************
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19274

Email: calle.hedberg@gmail.com

Skype: calle_hedberg

*******************************************

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049