I'm importing this new discussion from Hardhats and converting it into an ongoing thread about namespaces and numberspaces. Here are the three messages so far:
===
from: Gregory Woodhouse subject: [Hardhats] What is the formula you use for local IENs? to: Hardhats date: 1/29/2011 11:29 AM
I realize it's been common practice for years to assign facility local IENs using the formula
L = facility * 10^k + n
for some value of k (what is it?) A related question is simply: where is this documented? I've been aware of this practice functioning as a kind of de facto standard for years, but the obvious sources, such as the old cookbook or M-11 are no longer used. Sent from my iPad
===
from: David Whitten subject: Re: [Hardhats] What is the formula you use for local IENs? to: Hardhats date: 1/30/2011 12:57 PM
In my experience in Class III development at a local hospital we used the value k=3 & k=6. i.e. if our facility number was 123 (which is NOT the facility number of any VA to my knowledge) then the facility variously might create files in the numbers 123000 to 123999 or might create files in the number range 123000000 to 123999999. The most common case has been k=3, but I have known some facility which used k=6.
David
===
from: Frederick D. S. Marshall subject: Re: [Hardhats] What is the formula you use for local IENs? to: Hardhats date: 1/31/2011 8:13 AM
Dear Greg,
David's essentially right. Here's the rest of the story.
The value of k should be set by the file designer, but since most primary developers haven't spent a lot of time thinking about this yet, you have to use your best judgment based on the number of entries that can exist in the file under normal conditions.
First, of course, is the question of whether the entries in the file belong to the primary developer or to the adopter (site). In most files (like Patient, New Person, Drug, etc.) they belong to the adopter, so there's no reason for facilities to worry about the specific IEN assigned.
Second, is the question of whether IENs are an exposed key (such as via DINUM) or not. If the IEN literally doesn't matter (as in the Option file), then adopters and secondary developers can add entries wherever they like (as long as they don't violate the file's keys, like creating a duplicate Option name).
If the IEN is significant, then entries must either all be namespaced (as in the File file, where the entries are shared among all developers and adopters) or secondary additions must be (as in the Race file, where the primary developers own the standard entries, so sites must add their secondary entries under numberspaced IENs.
Third, the normal numberspacing rule is k=3, for small files or for stable files with permanently fewer than 1,000 entries (safe in the case of State, for example, since no matter how many states the United States adds there will probably never be 1,000). For large, stable files in which the primary developers have not yet set a value for k, secondary developers need to guess as to what k should be, and then they should share their decision publicly with all adopters to ensure we all treat each file the same way. If the adopters or secondary developers choose well, then whenever primary developers get around to setting an official value they're likely to choose the same one.
Fourth, when primary developers set values for k for their own files, they can set higher values. For example, the File Manager team set k=4 for the Dialog file to create more room for dialog entries for each package. The value of k needs to be high enough that a site whose number is 1, multiplied by 10^k, would have all of its entries placed outside the range the file would ever grow to on its own.
Fifth, for files whose IENs are significant whose number of entries is not stable, files that grow rapidly or comparatively uncontrollable, there is at present no algorithm for numberspacing established. Strategies for such files should be developed on a case-by-case basis with the help of the primary developers, because otherwise it is very easy to paint yourself into a corner and create secondary entries that collide with future primary entries.
The guidelines for secondary development, especially the rules for forward compatibility (like proper numberspacing) have not yet been written down. I have outlined and am working in earnest on that very document now and hope to have it done in a couple weeks. Since there's interest in this area, which I'm glad to see, I'll start a thread on Mumpster (mumpster.org) to discuss namespacing and numberspacing, and I'll share each guideline as I document it.
Yours truly, Rick
_________________ Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net "The hidden harmony is best." - Heraclitus of Ephesus
|