> From: "Cameron Schlehuber" <[EMAIL PROTECTED]> > Reply-To: hardhats-members@lists.sourceforge.net > Date: Tue, 12 Jul 2005 22:21:13 -0600 > To: <hardhats-members@lists.sourceforge.net> > Subject: RE: [Hardhats-members] Data dictionary question... > > Indeed, the HealtheVet "Person Service" appears to me to be repeating some > of the same limited constraints as were imposed over two decades ago (e.g., > ONLY real humans are being given consideration ... no test entries, no > avatar IDs, etc.) There are two approaches I've recommended from the > beginning: One is to have instead of a "patient" file, to have a file of > "objects of interest". E.g. file 2 could contain any arbitrary object of > interest, differentiated by identifying traits and other attributes (human, > animal, vegetable, mineral, etc.) Note that DHCP/VistA used in veterinary > care has posed no problem with this approach. Or two, use a fully qualified > ID for each entity in the entity-role-act instances. The latter is similar > to what was developed with the so-called "Variable Pointer" ... which is how > VistA lab handles the unlimited categories of objects of interest that VistA > lab can deal with. But I'd like to hear your approach Richard. >
... .... ..... My approach is always the same--recognize the larger domain of which the initial set is actually a subset. That is what you propose for the PATIENT file where "objects of interest" may be the universe set that contains all PATIENTS and other subsets of interest as well. The key issue becomes one of 'art' not technology as the debate then shifts to determining the balance point at which the domain of the file membership is finally, formally decided. Note that as the domain is enlarged, one gathers up complexity and all the implications of that trend. On the one hand we have the restrictive PATIENT file domain as originally established, and on the other hand, a file of objects of interest in a universe domain so grand that the entire system of files is contained in the one single file! ...and, in between a system with some form of domain context switching. (See the variable pointer discussion below.) Notice that FileMan can be seen as a single file itself. FileMan could have been fully recursive and completely self referential. It could have been the case that operations on 'classical' FileMan files would work equally well on the FileMan itself. Programmer API's for FileMan could have worked just as well on the file that contains the data dictionary. Thus, the inquiry that started this thread would have not been needed. But, alas, the MUMPS language did not include a mechanism to support recursion in a practical way. George did write %RCR to serve essential internal functions within FileMan, but that was a stop-gap solution. The performance of %RCR was prohibitive and discouraged making FileMan fully self referential. When I wrote the code in the Food Nutrient Analysis package that reads the data dictionary as Kevin wants to do, my discussions with George Timson did include a call for extensions to cover this kind of functionality. George's interests were focused elsewhere and there has always been only one George Timson. :-( (...no sadder words of tongue nor pen than those--it might have been.) Your point #2 is I believe always needed as well. As long as a system design intends to limit attributes on file to those that represent properties of the entities being described in the file, then the future will always be at risk for cases where two or more real world instances can not be distinguished based on their native attributes. I would always include for every entry in a given file a SYSTEM ASSIGNED attribute, where the values of that attribute are everywhere unique. The FileMan Internal Entry Number (IEN) represents such a system assigned attribute. However, the implementation of IEN was for specific technical purposes that did not include the function I associate with point #2. So, I don't recognize FileMan IEN as a good example of a system assigned, uniquely valued attribute. As for the 'variable pointer', it has an ugliness that is exceeded only by that of the NEW PERSON mess. I see the requirement that the variable pointer was intended to serve as a "domain scope" switch. That is, a mechanism that supports the function of changing the domain in which you are operating. This allows a large set of software tools to be enabled over a wider range of contexts by context switching at runtime rather than at system design time which brings us back to the list of laments Gregory presented. Maybe then getting dog blood and ice machine water into the lab system becomes trivial. Regards, Richard. ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
