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 <[email protected]>: > > 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: [email protected] tel:+17069260025 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
