I am going to put in my .02 cents as well – but these are Kenyan cents so possibly worth 1/84th of the 0.02 US cents added so far….I do agree with all of the points in the mail below which is very thorough. I just want to add the practical situations we faced in Kenya when we designed the MFL a few years ago.
The number one biggest hurdle was that EVERYONE except 2-3 enlightened individuals insisted that the facility ID be Province + District + Facility!
Everyone from the govt to the donors was sure that the facility id should have meaning… this is because of historical reasons, mainly:
But in the 2-3 years of the implementation of the MFL in Kenya the number of districts rose from 105 to over 285.
And now the 8 provinces have disappeared altogether and have been replaced by 47 counties.
There were lots of other subtle practical problems, all of which lead to the TOTAL unsuitability of using any administrative boundary IDs in the facility ID.
Instead, we used a sequential meaningless numeric integer – currently up to about 20000 – which worked since all IDs are assigned by a central database server when any district officer creates a new facility through the web application. (There is also a GUID, but that is for internal software applications only).
Apart from all the other excellent points in the email below, I completely recommend a facility ID with no meaning – but am sure that most users will be requesting this – so be prepared for this with lots of documented examples of why it is not suitable.
If the identifier is meaningless (and will not change), it is not necessary to have the ID to be timebound. But what is necessary to have the DISTRICT or other key administrative boundary to be timebound. So a subtable to show how facilities changed in districts over time. The checkdigit is also a good idea. Agree 5-6 digits plus checkdigit.
···
From: facility-registry@googlegroups.com [mailto:facility-registry@googlegroups.com] On Behalf Of Bob Jolliffe
Sent: 12 October 2013 17:26
To: facility-registry@googlegroups.com
Cc: Edward.Bunker@jhpiego.org; cleitner@capacityplus.org
Subject: Re: Facility ID’s in iHRIS…
I’ve a couple of thoughts. First, and partly in response to the original question, I guess there is a difference between identifiers which are currently in common use and what might be a more ideal or suggested best practice.
In my earlier answer to the first, I have found that the most common are either simple integers or some geographic or administrative concatenation of codes.
The merits and demerits of various types of identifier is really wholly dependent of what they are used to identify and how they will be used and who (or what) will use them. For example, with patient identifiers it is can be very important that they lend themselves to anonymous processes - in which case the inclusion of content with implicit meaning (birth date, sex, ethnicity or what have you) seems generally to be considered bad practice. Having said that the Norwegians make use of the their national id (which includes various meanings) in their health record which they seem to be happy enough with. I’m not sure I am would be but I’m not Norwegian.
I am less sure that context independence is necessarily the main thing to strive for when identifying health facilities. Though I take the point that there are hazards. If you identify a facility by the name (early dhis practice) then there are problems that (i) the name might change (ii) there can be different names for the same facility (eg language) and (iii) typically as the geographic scope widens, there can be many facilities with the same name. Identifiers which encode hierarchy, like the 18 digit one from Andra Pradesh, work well until the hierarchy changes.
But these are convenient and useful. As long as you can take into account the fact that their validity is time bound. eg. before the boundary changes the facility code was 67686896 but now it is 6545454. It can be as important to know how the facility was identified then as well as now.
UUIDS (or guids) don’t generally serve much useful purpose when identifying facilities. They simply work to reinforce what you already know. If you have a database full of unique facilities then you can meaningfully assign globally unique uuids to them. But if there are existing duplicates you just end up assigning each duplicate a uniquely different uuid. And if you have a candidate for a new facility to add to the list you need to use other more reliable forms of identification as it doesn’t come with a uuid baked in. I guess this is the difference with for example disk drives, where the uuid is assigned by the manufacturer. Or mac addresses on network adaptors. If the uuid were inscribed in the foundation stone of the clinic, it would be useful. But generally I find them an expensive distraction.
A more stable identification can be had with the geo-coordinates, though facilities can and do move. Mobile clinics being the extreme example.
Trying to fathom a list of useful guidelines from the complexity I would venture:
-
agree with Paul. Do use checkdigits. Particularly for identifiers that will be entered manually
-
cater for the fact that identifiers can be timebound
-
understand that multiple identifiers can be assigned by different authorities - some may be more ideal than others and often you have zero control over them. So rather than creating a structure which takes into account just the max length, rather take into account identifier context, validity and multiplicity. This is a pattern you find in hl7 and elsewhere (even to some extent in the FRED spec).
-
long random numbers don’t really help when trying to avoid duplicates in a collection. Rather focus on the name, location, type and other attributes as clues to whether you have potential duplicates.
-
something in the range of 5-6 digits plus a check digit is a reasonable length for a human-grokkable identifier, but these would necessarily be geographically scoped.
-
An identifier which is used for cross reference between or within interoperable computer systems need not be the same thing as a human grokkable identifier. But it might include it.
Also there is no technical substitute for local knowledge. The program may say there are 50 clinics in a district, all with unique codes, check digits and what have you, but trust the district manager who knows that there are only 49.
Thats at least 5 cents worth …
Bob
On 12 October 2013 15:41, Paul Biondich pbiondic@regenstrief.org wrote:
Seems like there’s a couple of comments / questions here:
-
What’s the most flexible datatype specification for a facility code that you’ve seen? I agree with Mike that it should probably allow for a GUID, which most easily would be stored as a string of 36 characters. They are a terror to use however, and I sure as heck hope they wouldn’t be used by individuals in real-world operational settings.
-
What are best practices around coming up with a facility code “scheme”? In my experience, it’s a grave mistake to advise anyone to build IDs that have implicit meaning in their structure. For all of the reasons that Bob describes below, as soon as you put meaning into a code, you run into a constraint within the scheme. I’ve seen it happen so many times now. 
The additional comment is that check digits (a mathematically imputed value usually appended to the end of a code) are really good practice. That way, you can better protect against human entry errors.
Just my $0.02.
-Paul
On Friday, October 11, 2013, Bob Jolliffe wrote:
Don’t get me started on guids …
In terms of curated codes they are typically quite short because people haven’t given them much thought and just assign integers. I have also seen cases where they are a concatenation of upper levels - statecode+districtcode+facilitycode in which case they can grow quite large. I believe facilities in India have identifiers like this though I haven’t looked for a while (I think about 16 chars).
Whatever you choose you will soon enough find something which breaks your hard limit so be prepared to change. But 25 sounds like a reasonable start.
Agree with Mike that UUIDs can be added in addition to, rather than as the MOH identifier. Not that I believe they serve much real purpose, but as I said, don’t get me started …
Bob
PS. John Lewis just sent me an example from Andra Pradesh just as I was about to hit the send button. 18 digits: 280728900111100030
On 11 October 2013 12:12, Gehron, Michael M GehronMM@state.gov wrote:
I believe the GUID standard is 35 alpha numeric (plus special characters, isn’t it?). Not that we would ever really attain an international master facility registry, or that we couldn’t just add a GUID if we ever found we needed one…just sayin’…for the sake of looking blackberry busy while eating alone at a crowded place 
Michael Gehron
202.203.7485 (O)
202.486.2563 ©
From: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Thursday, October 10, 2013 02:30 PM
To: Edward Bunker Edward.Bunker@jhpiego.org; facility-registry@googlegroups.com facility-registry@googlegroups.com
Cc: Carl Leitner cleitner@capacityplus.org
Subject: Re: Facility ID’s in iHRIS…
Hi All,
I am forwarding this question I received from Ed Bunker @ Jhpiego. I am sure he would appreciate your thoughts.
Cheers.
-carl
On Oct 10, 2013, at 1:05 PM, Edward Bunker Edward.Bunker@jhpiego.org wrote:
Carl,
Hello.
In your experience with iHRIS, what is the range of formats and lengths that you have found for Facility IDs… that come from MoH, etc.
Would an open text field of length 20 cover just about anything that we might encounter?
BTW… Thanks again for your reference to the various HR-related standards.
– Ed
Jhpiego-Innovating to Save Lives
Edward B. Bunker, MPH, MS
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
The additional comment is that check digits (a mathematically imputed value usually appended to the end of a code) are really good practice. That way, you can better protect against human entry errors.