dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Probably all good options, but likely we will need some flexibility to
match on different properties, and even combinations of properties.
For instance, there are two clinics in lusaka named "Pearl of Health".
Both in the same parent organisationunit, but with different physical
locations. So if you are faced with a situation like this, you might
need to match on parentid, name, and then lat/long, just as an
example.

Of course, having duplicate names is tricky within a district. It
would be easy for data entry personnel to make a mistake and enter
data for one clinic in another, especially if the data is being
entered from paper. I guess this is a separate process issue related
to a unique identifier, whatever that may be in the end. The approach
that we have taken with most surveys in the field is not a single
field, but a combination of fields that uniquely identify the
facility, such as Name, Address, and Lat/long. Perhaps a checksum of a
combination of fields might be a possibility to think about in terms
of assigning a computer-friendly ID.

Regards,
Jason


2010/8/27 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
> I have removed the uniqueness on organisation unit short names.
> We can think about removing uniqueness on name too after we have implemented
> the identifier blueprint.
> One challenge I came to think of is how we then match with "third party"
> data sources like gml, excel workbooks which will not have the DHIS specific
> identifier. Currently we match on name. Alternatives are to match on code
> (which is unique but not required in DHIS), or to add the DHIS identifier to
> the datasource.
>
>
>



-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+17069260025