> > 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.
Actually, VistA isn't helpless in those situations. The VistA lab module doesn't depend on lab tests being done on the PATIENT File. I'm not sure why you thought it does. The LAB DATA file (#63) has a field named PARENT FILE (Field #.02) and a field named NAME (Field #.03). Any entry in any file in the system could in theory (though some concepts are crazy) be the "source" of a lab test. That is why the LRDFN (Field #.01) is just a number, and why the PATIENT file has an explicit pointer to the LRDFN rather than just being DINUMed to the PATIENT File. The Lab developers already thought of all those cases of needing to do lab tests, and designed the LAB DATA file to handle them. David > > 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. ------------------------------------------------------- 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
