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.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard G. DAVIS Sent: Tuesday, July 12, 2005 7:32 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Data dictionary question... I believe this is all fundamentally the result of constrained problem definition, more important, of constrained problem domain. The example I usually choose to illustrate the issue is the VistA PATIENT file. Consider the LABORATORY system, and what happens when the Infectious Disease personnel bring water samples to microbiology taken from the ice machines in the food service areas. When asked for the patient to be used for the transaction, what does VistA do with ice machine data. Or, consider the Research Service personnel who bring blood samples from dogs and cats. Again, VistA is helpless to deal with these instances of samples that lie OUTSIDE the domain of what is implemented in the semantics of the PATIENT file #2. The first order question preliminary to developing a "file", ala FileMan, should be answered, understood and answered, before any further work is done in creating that data structure. Specifically, "what" is this a file of? (poor english intended...) The fact is that the notion of a PATIENT file was so widespread and commonly held, that no effort was made to become obsessive about what it meant to say "the PATIENT" file. If you raised the issues of dogs, cats, ice machines and other such entities, the groans, eyes averted skyward, and outcries of pain quickly quenched any motivation to pursue the issue, and to surely avoid raising such domain of files issues in the future. For those familiar with DHCP history, consider the mess surrounding the PERSON/NEW PERSON/EMPLOYEE/PROVIDER/PHYSICIAN/.... files constellation. NEW PERSON file???? Doh! It is the acceptance of 'ad hoc' file definitions, and other associated semantics, and the willingness to ignore the importance of 'a priori' due diligence for database semantics that lurks in the background of all the examples you have presented Gregory. Even now, I suspect that this tendency is still very much present as the DVA tries to roll over its Healthcare IT system to the next generation. Regards, Richard. P. S. It is hard to refrain from observing that the MUMPS Development Committee of the 1979-1984 era was a group populated with some of the best minds I have ever known. The scope of thought presented by these people was a source of amazement to me, repeated minute to minute in those deliberations. Even so, the myopia of thought among these folks was still present. I watched and thought a lot about the hotly debated issues surrounding language extensions to manage the environment of the MUMPS process. We had the KILL command, but more was desired. Eventually the NEW command was passed into the language, along with several other related features. At one point, two days into the final debate in the Language subcommittee, a NEW command was formally under consideration. The Chairman of the Language subcommittee was visibly disturbed about the course of the debate and the content of the NEW proposal. He rose to address the committee, exercising the power of the chair, and carefully laid out a rationale that clearly showed how the NEW command could be derived from the KILL command. Therefore, he concluded, the NEW command was not really a language extension worth adding. On that occasion, one of the few times, I asked for the floor to challenge the group to think differently about the issue. The heavy lifters in that group could be merciless. I observed that the arguments presented by the chairman were well thought out and nicely developed. However, I suggested that the reasoning flowed in the wrong direction. In fact, the NEW command being considered was a more general, broader domain, concept for environment control. Moreover, the KILL command could be easily and simply derived from the more general case--the NEW command. In fact, I argued, the original framers of the MUMPS language had included the most simple case, the most degenerate form of the NEW command--the KILL command. To seal the counterargument, I suggested the absurd case that in the work before us, not only should be add the more general case--the NEW command to the language, but also, in the interest of parsimony, we should also at the same time remove the KILL command as a degenerate special case of the NEW command. The NEW command passed into the language that day, and the then chairman of the Language subcommittee left that meeting and was never seen in the MDC again to my knowledge. BUT. I believe that it is fundamentally an issue of the original MUMPS language framers not asserting due diligence to clarify the problem domain of the control of MUMPS process environments. We would have started out with some form of the NEW command, the pesky KILL command would have never troubled us. Why all those things happened? ...because human thought is often overwhelmed by local context. ...sigh R. D. > From: Gregory Woodhouse <[EMAIL PROTECTED]> > Reply-To: hardhats-members@lists.sourceforge.net > Date: Tue, 12 Jul 2005 10:54:55 -0700 > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] Data dictionary question... > > It is certainly true that the infrastructure packages (Kernel, > Fileman, etc.) do a good job of reducing the degree of coupling in > Vista (part of its genius, IMO) but pick your favorite application. > How easy it to rework it to use a different approach? How many Vista > applications still use HL7 1.5 (notably Lab) because it's not > practical to move over to 1.6? Why are people so interested in using > Imaging to store scanned documents (something having absolutely > nothing to do with medical imagining)? Why has it taken so much > effort to figure out how to add new patients to a Vista system when > it is not being used in a VA setting? Why is it so hard to adapt IB/ > AR to the needs of non-VA users of Vista? Why is re-indexing file 2 > such a case of "shoot self in foot"? Why did identifying and > resolving duplicates in this file require such a herculean effort? > > === > Gregory Woodhouse > [EMAIL PROTECTED] ------------------------------------------------------- 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 ------------------------------------------------------- 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
