Unless there will be actual interconnection with these systems, they could all be called the same. If a small range of institution numbers were set aside, it should cover anything short of a hospital chain.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Woodhouse Sent: Sunday, February 19, 2006 9:17 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] local file numbers On Feb 19, 2006, at 5:51 PM, Chris Richardson wrote: > Just as I thought. Thanks, Cameron. > > Are there other issues that anyone might see about this arrangement? > Perhaps Rick can comment. Although, ZZ* is set aside as a local namespace, so far as I know, there is no such thing as a local (meaning unregistered) number space. Existing facilities can, of course, use their facility number to derive a private (but not unregistered) number space. Unfortunately, that is of no use to anyone without an assigned institution number. Worse, some packages (such as IFCAP) require an assigned station number, and you often cannot even get into the menu system without one. But there is no infrastructure to support federated management of station numbers, and anything that might be developed would almost surely conflict with the INSTITUTION file as implemented in VHA (which cannot be modified locally). This is but one example of a file that may appear to be something that can be modified and administered locally: consider the use of the ICN to identify patients or standardization of files like the ITEM MASTER (#441). This seems to me to be a rather serious problem, in many ways analogous to address exhaustion in IPv4. In the case of IP, Classless Interdomain Routing (CIDR) provided a "quick fix" allowing the number of bits set aside for addresses (vs. network numbers) to vary (that's what the the slash in routing table entries is all about). Maybe a CIDR like solution is possible, but it would only be a temporary expedient. Expanding the station number to include more digits (or noncanonic numbers, as has been suggested) would require a LOT of work. It's easy to underestimate the number of utilities, options, input transforms, fixed width messages, etc. that would be affected. It's a big problem. === Gregory Woodhouse [EMAIL PROTECTED] "Good acts are like good poems. One may easily get their drift, but they are not rationally understood." --Albert Einstein ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
