dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi all

I am not sure if I can talk of best practice in the field of health
information, but considering information more generally - it is best
practice to treat the notions of naming and identification as
separate.  See ISO 11179 part 5 (Naming and identification principles)
for example.  This is true of Org units and I believe also of data
elements.

So it should be absolutely permissable for different OrgUnit to share
the same name.  Just as there is a use case for an orgUnit to have
more than one name.  This can be a multi-language thing, a political
reorganisation etc.  In short I agree with Knut that there need not
(and should not) be a uniqueness requirement on the name.

But there is a uniqueness requirement for an identifier.  An
identifier can be a composite of prefix+name.  Though more generally I
guess we have a hierarchy of prefixes to apply - so in a three level
hierarchy you might have an identifier of "SL::WA::Red Cross Clinic".
Or Johan's suggestion of the reverse:  "Red Cross Clinic::WA::SL"

So a particular clinic has a name, "Red Cross Clinic" and an
identifier "Red Cross Clinic::WA::SL".

<OrgUnit ID="SL">
  <Name>Sierra Leonne</Name>
  <OrgUnit ID="WA::SL">
      <Name>"WA"</Name>
      <OrgUnit ID="Red Cross Clinic::WA::SL" >
         <Name Preferred="True">Red Cross Clinic</Name>
         <Name>Formerly Red Rose Clinic</Name>
</OrgUnit>

etc etc

In terms of the pivot table, if duplicate names are a real and present
danger, then you should be using the identifiers rather than the
names.  Of course you can also use UUID's.  There is a weakness in
using prefix trees for determining identity.  The identifier gets
messed up when there is organisational change to the hierarchy.
identifiers should be long lived.  The problem with UUIDs is that they
are pretty meaningless to the human eye (visualize them in your pivot
table).

Perhaps the only effective measure of identity is a more probablistic
mix of GIS co-ordinates, name(s), assigned codes, postion in hierarchy
etc.  A fuzzy look at all of these might give you reasonable assurance
that two orgunit references are actually to the same orgunit.  You
guys who've been in the field longer will have a good intuitive feel
for how that mix is.  As for me I just want to caution folk to keep
separate the notion of name and identity.  Whereas it is frequently
convenient on the surface, there are dragons beneath ...

Cheers
Bob

2009/5/2 Johan Ivar Sæbø <johansa@xxxxxxxxxx>:
> While it might not be necessary to use a prefix, it is GOOD PRACTICE. For
> one not living in the databasee world, I usually encounter the OU names in
> reports, or pivot tables. In a pivot table, filtering a pivot field is
> hopeless with duplicates instead of prefixes...
>
> Suppose you want to list a few facilities, and that the district they are in
> contain other facilities you don't want to see. This is quite a common
> situation. Then you would have to filter the "facility" field, which will
> show ALL facilities, thus your list might look like this (also quite
> typical, in for instance Sierra Leone)
>
> ...
> Red Cross Clinic
> Red Cross Clinic
> Red Cross Clinic
> ...
>
> instead of
> ...
> BO Red Cross Clinic
> BM Red Cross Clinic
> WA Red Cross Clinic
> ...
>
> Just my five cents.. If you're making a H1N1 A (well, I will still call it
> swine flu) database covering the whole world, maybe a postfix would be
> better, if it turns out to be a long string...also easier for sorting
> Johan
>
>
> Jason Pickering wrote:
>
> Hi Ola,
>
> I am sitting here with Knut, and I am going to support him on this
> one. :) The actual "real" relationship should be as Knut states. There
> are many Pickens Counties in the USA, but only one in Georgia (my home
> town).
>
> The prefix method has been implemented in Zambia, but I would regard
> this as very messy as well, particularly since it does not actually
> reflect the actual name of the orgunit. I would really regard this
> more of a kludge than anything else. In the reports that I have
> created in Zambia, we have trimmed out the two characters, as they
> make the reports messy.
>
>
>
>
>
> Orgunit hierarchy is not referenced from the data values so the
> proposed change would easily cause problems when dealing with the data.
>
>
>
> What does this mean? Every value is referenced to an orgunitid ?
>
> In my opinion, we should try and model the actual physical world.
> Generally, there are never duplicates of an orgunit within a
> particular parent. There are Oslo's in both Norway and Peru, but they
> are unique within their own hierarchy. The constraint should be that
> for any given parentid, the names of orgunits should be unique. I am
> not sure why this will result in a messy database, but at the present,
> the database and its constraints simply do not reflect reality.
>
> Regards,
> Jason
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
> >From - Sat
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>