Alternative names

Support - Assistance technique
1

Hi all, we are currently investigating the core domain model in order to see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property of data element and indicator entities. It seems this property is a ad-hoc legacy internationalization effort and not really useful. Would it be okay to remove it?

regards, Lars

2

Thanks Lars, I do agree with you.

Regards

···

2011/4/27 Lars Helge Øverland larshelge@gmail.com

Hi all, we are currently investigating the core domain model in order to see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property of data element and indicator entities. It seems this property is a ad-hoc legacy internationalization effort and not really useful. Would it be okay to remove it?

regards, Lars

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

–
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338

Don’t Compromise The Quality! Don’t Risk It! apply Available Standards to Achieve Your/organizational Goal.

3

OK, we have two more use cases of calculated variables.

At present certain information is collected by diagnosis from the inpatient and outpatient clinics. The malaria information is copied to the malaria form, along with other information which does have to be entered. We want to enter this information only once, from the diagnosis records, but we want it to show up on the malaria form, we think it’s marginally acceptable to not show totals, but to not show the malaria people “their” data is bad customer relations.

The clinics keep daily logs of birth control products dispensed, for which the patients pay at a reduced rate. This form is turned in along with the cash receipts, serving as a financial control. It needs receipts by item (quantity x price) and total.

I think it would be good enough if the calculated variables were not stored or aggregated and only existed while the dataset form was being displayed, for input or as a report. It would also be reasonable to limit variables in the calculations to those in the dataset (so in the malaria case, the variable would be in the dataset, it would not appear on the form, only the calculated variable equal to its value).

Our users exist in a form-based world, where the form designers do not necessarily think systematically. Where we can make a closer correspondence between the form and data entry/printing, we add to their comfort with the system. While I may think the forms they are using are don’t make informatic sense, and that differences in rendering call for different strategies on screens than on paper, I can’t impose these changes on them. Cross-foot totals do contribute to accuracy in manual forms, they don’t in computer forms; double entry accounting contributes to accuracy in manual bookkeeping, it doesn’t in computer bookkeeping; but the habits of generations don’t change in a day.

4

Roger,

OK, we have two more use cases of calculated variables.

At present certain information is collected by diagnosis from the
inpatient and outpatient clinics. The malaria information is copied
to the malaria form, along with other information which does have to
be entered. We want to enter this information only once, from the
diagnosis records, but we want it to show up on the malaria form, we
think it's marginally acceptable to not show totals, but to not show
the malaria people "their" data is bad customer relations.

As I understand the case, this can be done by including the same data elements, like "Malaria xyz", in both data sets. This is what we did in Sierra Leone, where some forms had an data element overlap of 25%+. Data entered in for example "Malaria <1 male" in one form would then show up when you opened the data entry screen for the same month and clinic for the "twin-form". I believe the same can be done when you have calculated data elements. Making a calculated element visible in the data entry screen would be possible by assigning it to a cell in a custom form, while the sub-elements can be hidden by not assigning them. Using a standard form would all the elements visible.

The clinics keep daily logs of birth control products dispensed, for
which the patients pay at a reduced rate. This form is turned in
along with the cash receipts, serving as a financial control. It
needs receipts by item (quantity x price) and total.

I think it would be good enough if the calculated variables were not
stored or aggregated and only existed while the dataset form was being
displayed, for input or as a report. It would also be reasonable
to limit variables in the calculations to those in the dataset (so in
the malaria case, the variable would be in the dataset, it would not
appear on the form, only the calculated variable equal to its value).

Our users exist in a form-based world, where the form designers do not
necessarily think systematically.

This is very typical, and the change from paper-logic to computer-logic is a long process. Subtotals, double entry, and huge tables are typical for paper forms. Unfortunately, since paper come in fixed sizes, they are populated so that all free space is used. Automatically populating different forms by sharing the same data elements was used in Sierra Leone as a first step to highlight the possibilities of computer-based data entry and storage, and has since led to a certain degree of harmonization of the forms.

Regards,
Johan

  Where we can make a closer

···

On Wed, 27 Apr 2011 08:22:46 -0400, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rdf4@cdc.gov> wrote:

correspondence between the form and data entry/printing, we add to
their comfort with the system. While I may think the forms they are
using are don't make informatic sense, and that differences in
rendering call for different strategies on screens than on paper, I
can't impose these changes on them. Cross-foot totals do contribute
to accuracy in manual forms, they don't in computer forms; double
entry accounting contributes to accuracy in manual bookkeeping, it
doesn't in computer bookkeeping; but the habits of generations don't
change in a day.

5

Thanks Friedman,
Please share the copy of the tool with us to give some suggestions
regards

PEPELA WANJALAMINISTRY OF HEALTH HEADQUARTERSHEALTH INFORMATION SYSTEMAFYA HOUSE, HIS LG 37P.O BOX 30016, NAIROBI, KENYATEL: +254 (020) 2717077 EXT 45097CELL: +254 (0) 722375633 or 0202033363EMAIL: wanjala2p@yahoo.com hmis@health.go.ke

···

--- On Wed, 4/27/11, Friedman, Roger (CDC/CGH/DGHA) (CTR) <rdf4@cdc.gov> wrote:

6

Dear Lars
Thank you for your good efforts to improve the system. You have our support.

···

2011/4/27 Lars Helge Øverland larshelge@gmail.com

Hi all, we are currently investigating the core domain model in order to see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property of data element and indicator entities. It seems this property is a ad-hoc legacy internationalization effort and not really useful. Would it be okay to remove it?

regards, Lars

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

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

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

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

–
Dr. Ayub Manya
Medical Epidemiologist,
Division of Health Information,
Ministry of Health Headquarters, Nairobi.
0722221266

7

I would actually suggest that multiple alternative names to be added for a dataelement or indicator.

It would be similar to the representing synonyms for a data element or indicator.

···

Regards,

Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland larshelge@gmail.com

Hi all, we are currently investigating the core domain model in order to see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property of data element and indicator entities. It seems this property is a ad-hoc legacy internationalization effort and not really useful. Would it be okay to remove it?

regards, Lars

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

8

I would actually suggest that multiple alternative names to be added for a
dataelement or indicator.
It would be similar to the representing synonyms for a data element or
indicator.

Saptarshi I think I agree with you in principle. And probably the
best way to work towards this is to start by removing the hard coded
alternative name property. So +1 from me to the proposal.

···

2011/4/27 Saptarshi Purkayastha <sunbiz@gmail.com>:

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland <larshelge@gmail.com>

Hi all, we are currently investigating the core domain model in order to
see how we can make the entities have a consistent set of properties.
In that regard we are proposing to remove the alternative name property of
data element and indicator entities. It seems this property is a ad-hoc
legacy internationalization effort and not really useful. Would it be okay
to remove it?

regards, Lars

_______________________________________________
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

_______________________________________________
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

9

+1 from me as well, assuming that we can migrate the existing
alternative names to whatever object replaces it. Also, if you can
look into how we can match on these names during import, similar to
DHIS 1.4, this would be very useful in hetereogeneous, data
warehousing situations where multiple data bases feed DHIS2, but which
may have slightly different names of the same data element.

···

On 4/27/11, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

2011/4/27 Saptarshi Purkayastha <sunbiz@gmail.com>:

I would actually suggest that multiple alternative names to be added for a
dataelement or indicator.
It would be similar to the representing synonyms for a data element or
indicator.

Saptarshi I think I agree with you in principle. And probably the
best way to work towards this is to start by removing the hard coded
alternative name property. So +1 from me to the proposal.

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland <larshelge@gmail.com>

Hi all, we are currently investigating the core domain model in order to
see how we can make the entities have a consistent set of properties.
In that regard we are proposing to remove the alternative name property
of
data element and indicator entities. It seems this property is a ad-hoc
legacy internationalization effort and not really useful. Would it be
okay
to remove it?

regards, Lars

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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:+260974901293

10

+1 from me as well, assuming that we can migrate the existing
alternative names to whatever object replaces it.

To what extent to we have existing alternative names?

···

On 27 April 2011 15:24, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Also, if you can
look into how we can match on these names during import, similar to
DHIS 1.4, this would be very useful in hetereogeneous, data
warehousing situations where multiple data bases feed DHIS2, but which
may have slightly different names of the same data element.

On 4/27/11, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

2011/4/27 Saptarshi Purkayastha <sunbiz@gmail.com>:

I would actually suggest that multiple alternative names to be added for a
dataelement or indicator.
It would be similar to the representing synonyms for a data element or
indicator.

Saptarshi I think I agree with you in principle. And probably the
best way to work towards this is to start by removing the hard coded
alternative name property. So +1 from me to the proposal.

---
Regards,
Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland <larshelge@gmail.com>

Hi all, we are currently investigating the core domain model in order to
see how we can make the entities have a consistent set of properties.
In that regard we are proposing to remove the alternative name property
of
data element and indicator entities. It seems this property is a ad-hoc
legacy internationalization effort and not really useful. Would it be
okay
to remove it?

regards, Lars

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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:+260974901293

11

Not 100% sure, but I think Alternative Name is used to store the English translations of the Swahili data elements in the Tanzanian databases, as an ad-hoc i18n approach. This can of course be replaced by a using the i18n functionality (given that it works properly, and that it is also possible to show lists/reports etc. showing both languages).

Ola

···

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 27 April 2011 17:04, Bob Jolliffe bobjolliffe@gmail.com wrote:

On 27 April 2011 15:24, Jason Pickering jason.p.pickering@gmail.com wrote:

+1 from me as well, assuming that we can migrate the existing

alternative names to whatever object replaces it.

To what extent to we have existing alternative names?

Also, if you can

look into how we can match on these names during import, similar to

DHIS 1.4, this would be very useful in hetereogeneous, data

warehousing situations where multiple data bases feed DHIS2, but which

may have slightly different names of the same data element.

On 4/27/11, Bob Jolliffe bobjolliffe@gmail.com wrote:

2011/4/27 Saptarshi Purkayastha sunbiz@gmail.com:

I would actually suggest that multiple alternative names to be added for a

dataelement or indicator.

It would be similar to the representing synonyms for a data element or

indicator.

Saptarshi I think I agree with you in principle. And probably the

best way to work towards this is to start by removing the hard coded

alternative name property. So +1 from me to the proposal.

Regards,

Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland larshelge@gmail.com

Hi all, we are currently investigating the core domain model in order to

see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property

of

data element and indicator entities. It seems this property is a ad-hoc

legacy internationalization effort and not really useful. Would it be

okay

to remove it?

regards, Lars

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

–

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260974901293

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

12

Hi,

We have to be careful in misunderstanding of the meaning of alternative name. The I18n translation functionality which is only the support one for Multilingual. But in this case alternative name which could understand that a another name of a specified object. One data element, ie. it could be having many other alternative name. I’m not familiar with the health words.

But for example in Chemical field, if you say CH3-OH so everyone would know that is Methanol or Metilic alcohol.

Just a small comment.

···

On Thu, Apr 28, 2011 at 1:37 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:

Not 100% sure, but I think Alternative Name is used to store the English translations of the Swahili data elements in the Tanzanian databases, as an ad-hoc i18n approach. This can of course be replaced by a using the i18n functionality (given that it works properly, and that it is also possible to show lists/reports etc. showing both languages).

Ola

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 27 April 2011 17:04, Bob Jolliffe bobjolliffe@gmail.com wrote:

On 27 April 2011 15:24, Jason Pickering jason.p.pickering@gmail.com wrote:

+1 from me as well, assuming that we can migrate the existing

alternative names to whatever object replaces it.

To what extent to we have existing alternative names?

Also, if you can

look into how we can match on these names during import, similar to

DHIS 1.4, this would be very useful in hetereogeneous, data

warehousing situations where multiple data bases feed DHIS2, but which

may have slightly different names of the same data element.

On 4/27/11, Bob Jolliffe bobjolliffe@gmail.com wrote:

2011/4/27 Saptarshi Purkayastha sunbiz@gmail.com:

I would actually suggest that multiple alternative names to be added for a

dataelement or indicator.

It would be similar to the representing synonyms for a data element or

indicator.

Saptarshi I think I agree with you in principle. And probably the

best way to work towards this is to start by removing the hard coded

alternative name property. So +1 from me to the proposal.

Regards,

Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by CHANCE

2011/4/27 Lars Helge Øverland larshelge@gmail.com

Hi all, we are currently investigating the core domain model in order to

see how we can make the entities have a consistent set of properties.

In that regard we are proposing to remove the alternative name property

of

data element and indicator entities. It seems this property is a ad-hoc

legacy internationalization effort and not really useful. Would it be

okay

to remove it?

regards, Lars

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

–

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260974901293

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

–
Good health !

13

Hi,

We have to be careful in misunderstanding of the meaning of alternative
name. The I18n translation functionality which is only the support one for
Multilingual. But in this case alternative name which could understand that
a another name of a specified object. One data element, ie. it could be
having many other alternative name. I'm not familiar with the health words.

But for example in Chemical field, if you say CH3-OH so everyone would know
that is Methanol or Metilic alcohol.

Just a small comment.

Fair point. AlternativeName does invite the user to use it like this
in the absence of any other guideline.

In general many things do have many names (I am Bob, my passport says
Robert and the University of Oslo has me as Bo). What is important on
the output side is to know the context in which a particular name is
appropriate. In the I18n case, the context is determined by locale
which seems to me to be the right way of determining which alternative
name to use (assuming, as Ola says, that it works).

I am not sure if there is really a requirement for supporting other
sorts of naming contexts - I haven't seen one, but there might be.
For example different programs might have different names for the same
indicator. Facilities are perhaps an interesting case because they do
occasionally get renamed so you might have current name and old name.
Which is not a very serious problem when we don't use the name as the
primary identifier.

It would be easy enough to have a table for alternative names of any
and all identifiable objects. In fact it might even be a good idea.
What would be more complicated is to decide the context in which to
use which name. The simplest approach would be to not try and be too
artificailly intelligent about it and provide the report designer with
the set of alternative names to pick from if he/she so chose.

But without a clear requirement there's no need to make our lives
complicated. So to go back to my original question, do we have an
existing use case (outside of I18n) where people are using
alternativename differently? eg synonymns for methanol. My guess is
that this is more a requirement in clinical systems than in aggregate
reporting of datelements and indicators. Except perhaps facilities
...

Cheers
Bob

···

On 28 April 2011 10:09, Hieu Dang Duy <hieu.hispvietnam@gmail.com> wrote:

On Thu, Apr 28, 2011 at 1:37 PM, Ola Hodne Titlestad <olati@ifi.uio.no> > wrote:

Not 100% sure, but I think Alternative Name is used to store the English
translations of the Swahili data elements in the Tanzanian databases, as an
ad-hoc i18n approach. This can of course be replaced by a using the i18n
functionality (given that it works properly, and that it is also possible to
show lists/reports etc. showing both languages).

Ola
--------
----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 27 April 2011 17:04, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 27 April 2011 15:24, Jason Pickering <jason.p.pickering@gmail.com> >>> wrote:
> +1 from me as well, assuming that we can migrate the existing
> alternative names to whatever object replaces it.

To what extent to we have existing alternative names?

>Also, if you can
> look into how we can match on these names during import, similar to
> DHIS 1.4, this would be very useful in hetereogeneous, data
> warehousing situations where multiple data bases feed DHIS2, but which
> may have slightly different names of the same data element.
>
>
>
> On 4/27/11, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
>> 2011/4/27 Saptarshi Purkayastha <sunbiz@gmail.com>:
>>> I would actually suggest that multiple alternative names to be added
>>> for a
>>> dataelement or indicator.
>>> It would be similar to the representing synonyms for a data element
>>> or
>>> indicator.
>>
>> Saptarshi I think I agree with you in principle. And probably the
>> best way to work towards this is to start by removing the hard coded
>> alternative name property. So +1 from me to the proposal.
>>
>>>
>>> ---
>>> Regards,
>>> Saptarshi PURKAYASTHA
>>>
>>> My Tech Blog: http://sunnytalkstech.blogspot.com
>>> You Live by CHOICE, Not by CHANCE
>>>
>>>
>>> 2011/4/27 Lars Helge Øverland <larshelge@gmail.com>
>>>>
>>>> Hi all, we are currently investigating the core domain model in
>>>> order to
>>>> see how we can make the entities have a consistent set of
>>>> properties.
>>>> In that regard we are proposing to remove the alternative name
>>>> property
>>>> of
>>>> data element and indicator entities. It seems this property is a
>>>> ad-hoc
>>>> legacy internationalization effort and not really useful. Would it
>>>> be
>>>> okay
>>>> to remove it?
>>>>
>>>>
>>>> regards, Lars
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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:+260974901293
>

_______________________________________________
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

_______________________________________________
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

--
Good health !

14

Interesting...
My experience is that the same data element can be called different things by different installations e.g. in different states or projects - for example, "Malaria cases in children under five" and "Malaria - under five", etc. Sometimes the range of synonyms becomes so large between databases that importing for cross-database analysis becomes so difficult and a tiring process.
At other times there are just two synonyms. In this case having an "alternative name" or "old name" seems to be useful.

This "match-making" process during import is one requirement for an "alternative name" or "old name" or whatever it wants to be called...but perhaps there is a better way of solving this?

Ime

···

--- On Thu, 4/28/11, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

From: Bob Jolliffe <bobjolliffe@gmail.com>
Subject: Re: [Dhis2-devs] Alternative names
To: "Hieu Dang Duy" <hieu.hispvietnam@gmail.com>
Cc: "Ola Hodne Titlestad" <olati@ifi.uio.no>, "DHIS 2 developers" <dhis2-devs@lists.launchpad.net>
Date: Thursday, April 28, 2011, 12:18 PM
On 28 April 2011 10:09, Hieu Dang Duy > <hieu.hispvietnam@gmail.com> > wrote:
> Hi,
>
> We have to be careful in misunderstanding of the
meaning of alternative
> name. The I18n translation functionality which is only
the support one for
> Multilingual. But in this case alternative name which
could understand that
> a another name of a specified object. One data
element, ie. it could be
> having many other alternative name. I'm not familiar
with the health words.
>
> But for example in Chemical field, if you say CH3-OH
so everyone would know
> that is Methanol or Metilic alcohol.
>
> Just a small comment.

Fair point. AlternativeName does invite the user to
use it like this
in the absence of any other guideline.

In general many things do have many names (I am Bob, my
passport says
Robert and the University of Oslo has me as Bo). What
is important on
the output side is to know the context in which a
particular name is
appropriate. In the I18n case, the context is
determined by locale
which seems to me to be the right way of determining which
alternative
name to use (assuming, as Ola says, that it works).

I am not sure if there is really a requirement for
supporting other
sorts of naming contexts - I haven't seen one, but there
might be.
For example different programs might have different names
for the same
indicator. Facilities are perhaps an interesting case
because they do
occasionally get renamed so you might have current name and
old name.
Which is not a very serious problem when we don't use the
name as the
primary identifier.

It would be easy enough to have a table for alternative
names of any
and all identifiable objects. In fact it might even
be a good idea.
What would be more complicated is to decide the context in
which to
use which name. The simplest approach would be to not
try and be too
artificailly intelligent about it and provide the report
designer with
the set of alternative names to pick from if he/she so
chose.

But without a clear requirement there's no need to make our
lives
complicated. So to go back to my original question,
do we have an
existing use case (outside of I18n) where people are using
alternativename differently? eg synonymns for
methanol. My guess is
that this is more a requirement in clinical systems than in
aggregate
reporting of datelements and indicators. Except
perhaps facilities
...

Cheers
Bob

>
> On Thu, Apr 28, 2011 at 1:37 PM, Ola Hodne Titlestad > <olati@ifi.uio.no> > > wrote:
>>
>> Not 100% sure, but I think Alternative Name is
used to store the English
>> translations of the Swahili data elements in the
Tanzanian databases, as an
>> ad-hoc i18n approach. This can of course be
replaced by a using the i18n
>> functionality (given that it works properly, and
that it is also possible to
>> show lists/reports etc. showing both languages).
>>
>> Ola
>> --------
>> ----------------------------------
>> Ola Hodne Titlestad (Mr)
>> HISP
>> Department of Informatics
>> University of Oslo
>>
>> Mobile: +47 48069736
>> Home address: Vetlandsvn. 95B, 0685 Oslo, Norway.
Googlemaps link
>>
>>
>> On 27 April 2011 17:04, Bob Jolliffe <bobjolliffe@gmail.com> > wrote:
>>>
>>> On 27 April 2011 15:24, Jason Pickering <jason.p.pickering@gmail.com> > >>> wrote:
>>> > +1 from me as well, assuming that we can
migrate the existing
>>> > alternative names to whatever object
replaces it.
>>>
>>> To what extent to we have existing alternative
names?
>>>
>>> >Also, if you can
>>> > look into how we can match on these
names during import, similar to
>>> > DHIS 1.4, this would be very useful in
hetereogeneous, data
>>> > warehousing situations where multiple
data bases feed DHIS2, but which
>>> > may have slightly different names of the
same data element.
>>> >
>>> >
>>> >
>>> > On 4/27/11, Bob Jolliffe <bobjolliffe@gmail.com> > wrote:
>>> >> 2011/4/27 Saptarshi Purkayastha
<sunbiz@gmail.com>:
>>> >>> I would actually suggest that
multiple alternative names to be added
>>> >>> for a
>>> >>> dataelement or indicator.
>>> >>> It would be similar to the
representing synonyms for a data element
>>> >>> or
>>> >>> indicator.
>>> >>
>>> >> Saptarshi I think I agree with you in
principle. And probably the
>>> >> best way to work towards this is to
start by removing the hard coded
>>> >> alternative name property. So +1 from
me to the proposal.
>>> >>
>>> >>>
>>> >>> ---
>>> >>> Regards,
>>> >>> Saptarshi PURKAYASTHA
>>> >>>
>>> >>> My Tech Blog: http://sunnytalkstech.blogspot.com
>>> >>> You Live by CHOICE, Not by
CHANCE
>>> >>>
>>> >>>
>>> >>> 2011/4/27 Lars Helge Øverland
<larshelge@gmail.com>
>>> >>>>
>>> >>>> Hi all, we are currently
investigating the core domain model in
>>> >>>> order to
>>> >>>> see how we can make the
entities have a consistent set of
>>> >>>> properties.
>>> >>>> In that regard we are
proposing to remove the alternative name
>>> >>>> property
>>> >>>> of
>>> >>>> data element and indicator
entities. It seems this property is a
>>> >>>> ad-hoc
>>> >>>>
legacy internationalization effort and not really useful.
Would it
>>> >>>> be
>>> >>>> okay
>>> >>>> to remove it?
>>> >>>>
>>> >>>>
>>> >>>> regards, Lars
>>> >>>>
>>> >>>>
_______________________________________________
>>> >>>> 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
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
_______________________________________________
>>> >>> 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
>>> >>>
>>> >>>
>>> >>
>>> >>
_______________________________________________
>>> >> 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:+260974901293
>>> >
>>>
>>>
_______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Good health !
>
>

_______________________________________________
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

15

Hi Ime,

Yes, there is better way of doing this. Matching by name instead of id is unacceptable. We should give unique id across implementation despite naming conventions. Single data element can have more than one alias. We cannot live with just two names, there could be more. Moreover alternative name is not solution for i18n too. I call again for metadata refinement, which sovles most of issues brought to audience with “alternative name” removal. Also, though slitely out of this discussions, I see patterns of use, which are used in most of metadata objects are being repeated, we should avoid them.

regards,
murod

···

On Thu, Apr 28, 2011 at 1:22 PM, Ime Asangansi asangansi@yahoo.com wrote:

Interesting…

My experience is that the same data element can be called different things by different installations e.g. in different states or projects - for example, “Malaria cases in children under five” and “Malaria - under five”, etc. Sometimes the range of synonyms becomes so large between databases that importing for cross-database analysis becomes so difficult and a tiring process.

At other times there are just two synonyms. In this case having an “alternative name” or “old name” seems to be useful.

This “match-making” process during import is one requirement for an “alternative name” or “old name” or whatever it wants to be called…but perhaps there is a better way of solving this?

Ime

— On Thu, 4/28/11, Bob Jolliffe bobjolliffe@gmail.com wrote:

From: Bob Jolliffe bobjolliffe@gmail.com

Subject: Re: [Dhis2-devs] Alternative names

To: “Hieu Dang Duy” hieu.hispvietnam@gmail.com

Cc: “Ola Hodne Titlestad” olati@ifi.uio.no, “DHIS 2 developers” dhis2-devs@lists.launchpad.net

Date: Thursday, April 28, 2011, 12:18 PM

On 28 April 2011 10:09, Hieu Dang Duy > > > hieu.hispvietnam@gmail.com > > > wrote:

Hi,

We have to be careful in misunderstanding of the

meaning of alternative

name. The I18n translation functionality which is only

the support one for

Multilingual. But in this case alternative name which

could understand that

a another name of a specified object. One data

element, ie. it could be

having many other alternative name. I’m not familiar

with the health words.

But for example in Chemical field, if you say CH3-OH

so everyone would know

that is Methanol or Metilic alcohol.

Just a small comment.

Fair point. AlternativeName does invite the user to

use it like this

in the absence of any other guideline.

In general many things do have many names (I am Bob, my

passport says

Robert and the University of Oslo has me as Bo). What

is important on

the output side is to know the context in which a

particular name is

appropriate. In the I18n case, the context is

determined by locale

which seems to me to be the right way of determining which

alternative

name to use (assuming, as Ola says, that it works).

I am not sure if there is really a requirement for

supporting other

sorts of naming contexts - I haven’t seen one, but there

might be.

For example different programs might have different names

for the same

indicator. Facilities are perhaps an interesting case

because they do

occasionally get renamed so you might have current name and

old name.

Which is not a very serious problem when we don’t use the

name as the

primary identifier.

It would be easy enough to have a table for alternative

names of any

and all identifiable objects. In fact it might even

be a good idea.

What would be more complicated is to decide the context in

which to

use which name. The simplest approach would be to not

try and be too

artificailly intelligent about it and provide the report

designer with

the set of alternative names to pick from if he/she so

chose.

But without a clear requirement there’s no need to make our

lives

complicated. So to go back to my original question,

do we have an

existing use case (outside of I18n) where people are using

alternativename differently? eg synonymns for

methanol. My guess is

that this is more a requirement in clinical systems than in

aggregate

reporting of datelements and indicators. Except

perhaps facilities

…

Cheers

Bob

On Thu, Apr 28, 2011 at 1:37 PM, Ola Hodne Titlestad > > > olati@ifi.uio.no > > > > wrote:

Not 100% sure, but I think Alternative Name is

used to store the English

translations of the Swahili data elements in the

Tanzanian databases, as an

ad-hoc i18n approach. This can of course be

replaced by a using the i18n

functionality (given that it works properly, and

that it is also possible to

show lists/reports etc. showing both languages).

Ola

Ola Hodne Titlestad (Mr)

HISP

Department of Informatics

University of Oslo

Mobile: +47 48069736

Home address: Vetlandsvn. 95B, 0685 Oslo, Norway.

Googlemaps link

On 27 April 2011 17:04, Bob Jolliffe bobjolliffe@gmail.com > > > wrote:

On 27 April 2011 15:24, Jason Pickering jason.p.pickering@gmail.com > > > >>> wrote:

+1 from me as well, assuming that we can

migrate the existing

alternative names to whatever object

replaces it.

To what extent to we have existing alternative

names?

Also, if you can

look into how we can match on these

names during import, similar to

DHIS 1.4, this would be very useful in

hetereogeneous, data

warehousing situations where multiple

data bases feed DHIS2, but which

may have slightly different names of the

same data element.

On 4/27/11, Bob Jolliffe bobjolliffe@gmail.com > > > wrote:

2011/4/27 Saptarshi Purkayastha

sunbiz@gmail.com:

I would actually suggest that

multiple alternative names to be added

for a

dataelement or indicator.

It would be similar to the

representing synonyms for a data element

or

indicator.

Saptarshi I think I agree with you in

principle. And probably the

best way to work towards this is to

start by removing the hard coded

alternative name property. So +1 from

me to the proposal.

Regards,

Saptarshi PURKAYASTHA

My Tech Blog: http://sunnytalkstech.blogspot.com

You Live by CHOICE, Not by

CHANCE

2011/4/27 Lars Helge Øverland

larshelge@gmail.com

Hi all, we are currently

investigating the core domain model in

order to

see how we can make the

entities have a consistent set of

properties.

In that regard we are

proposing to remove the alternative name

property

of

data element and indicator

entities. It seems this property is a

ad-hoc

legacy internationalization effort and not really useful.

Would it

be

okay

to remove it?

regards, Lars

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

–

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260974901293

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

–

Good health !

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

16

I could understand that one dataelement may have many alias names for many report forms or data sets or programs. But that not mean we need to put more than 1 alternative name, or even we don’t need to put in the system alternative names. Because as real case, no one has time to do that. Instead of creating more names, we can make a document which will contain reference between dataelement names, dataelement id with the data unit name in the specified report. That’s what I usually do. May be put alternative name is good. but we also have the description area for the dataelement. We can put alias names there if we like.

···

–
Thuy

17

Hi Thuy

I could understand that one dataelement may have many alias names for many
report forms or data sets or programs. But that not mean we need to put more
than 1 alternative name, or even we don't need to put in the system
alternative names. Because as real case, no one has time to do that.

I am not sure if having time is the right argument. It is true that
often (always?) we construct the metadata for an implementation in a
hurry but it is also true that we must live in, among and with this
metadata for potentially many years. So there is a good case for not
making things like alternativename a necessity when putting together
an implementation. Which is also why I am happy to see it dropped as
a static field. But it is while we try to maintain this metadata over
time (and potentially importing definitions from elsewhere) that we
might find ourselves missing the ability to assign alternative names
for things.

···

On 28 April 2011 16:59, Thuy Nguyen <thuy.hispvietnam@gmail.com> wrote:

Instead
of creating more names, we can make a document which will contain reference
between dataelement names, dataelement id with the data unit name in the
specified report. That's what I usually do. May be put alternative name is
good. but we also have the description area for the dataelement. We can put
alias names there if we like.

--
Thuy

_______________________________________________
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

18

Bringing this old thread to life. Seems there is an agreement to remove the alternative name property. First there is no business logic attached to alternative name meaning it can and should be created as an attribute. Second the database internationalization has been fixed and now works well. Third it is making some currently planned changes in the web api harder. So we will remove it.

Lars

19

It seems we have discussed this at length actually. I had forgotten
about this thread.

Is there a consensus to get rid of this now?

If not, is there any harm in removing the database constraint which is
attached to this?

We are doing regular data imports from 1.4, and this constraint
complicates things. I cannot really see where it is used anywhere.

Best regards,
Jason

···

On Wed, May 2, 2012 at 5:07 PM, Lars Helge Øverland <larshelge@gmail.com> wrote:

Bringing this old thread to life. Seems there is an agreement to remove the
alternative name property. First there is no business logic attached to
alternative name meaning it can and should be created as an attribute.
Second the database internationalization has been fixed and now works well.
Third it is making some currently planned changes in the web api harder. So
we will remove it.

Lars

_______________________________________________
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

20

Hi Jason,

yes it will be removed for 2.9.

My only concern for removing the constraint is that it is still unique
in the database mapping/application. So when the system queries by
data element alternative name during the import process and finds
multiple objects with the same alt name then an exception will be
thrown. Maybe dropping the constraint then nulling all alternative
names after import would be a solution.

Lars

···

On Mon, Jun 18, 2012 at 11:21 AM, Jason Pickering <jason.p.pickering@gmail.com> wrote:

It seems we have discussed this at length actually. I had forgotten
about this thread.

Is there a consensus to get rid of this now?

If not, is there any harm in removing the database constraint which is
attached to this?

We are doing regular data imports from 1.4, and this constraint
complicates things. I cannot really see where it is used anywhere.

Best regards,
Jason

On Wed, May 2, 2012 at 5:07 PM, Lars Helge Øverland <larshelge@gmail.com> wrote:

Bringing this old thread to life. Seems there is an agreement to remove the
alternative name property. First there is no business logic attached to
alternative name meaning it can and should be created as an attribute.
Second the database internationalization has been fixed and now works well.
Third it is making some currently planned changes in the web api harder. So
we will remove it.

Lars

_______________________________________________
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