Greg, Since I was a first hand participant in the earliest stirrings of what became DHCP, and as I engaged in work in this area continuously for 30 years, I think I have the cache' (sic... :-) ) to make some observations related to your views.
I recognize that the rise and fall of DHCP, its transformation into VistA, and the present path being cultivated by the DVA to move the patient care information management capability within VHA is gargantuan and complex. Countless factors have influenced the 'success' of VistA and its antecedent DHCP. While it is attractive to identify specific local features of the history of VistA/DHCP, especially where clear arguments can be made to satisfy the involved protagonists, most of these debates are, in my view, not strategically significant in understanding the success of VistA/DHCP. The contribution of FileMan to the success of Health Care IT in the VHA (DM&S) that was a critical success factor is in role it played in providing the basis for a coherent, mildly disciplined binding among a host of loosely affiliated units of business. Just like the VA medical centers were a very loosely affiliated group of health care delivery units in the 1907-1980 era, so also were the early, cornerstone components of DHCP--pharmacy, laboratory and patient registration/admission/discharge. What bound these packages, and the software engineers who developed them, together in a coordinated way in spite of the absence of a coherent and coordinated core management, was the Centralized Database Management System we refer to as the V A File Manager. The success achieved was not critically dependent on the MUMPS technology--any language/program system could have been pressed into service. (Yes, there were and still are technical arguments that show in a comparative way MUMPS is/was the superior choice.) The centralized, commonly shared, and uniformly enforced data dictionary technology delivered in the framework of V A File Manager is the muscle that gave DHCP the overwhelming power to provide rapid, durable and superior software solutions to the needs of V A Medical Center departments. This critical success factor could have been delivered by any number of alternative technologies then available. However, not if just the same few number of scattered software engineers had been used. At most, FileMan was never handled by more that 2 to 3 people. Likewise for the other major modules--pharmacy, lab, etc. So, the MUMPS technology did enable the high effic1ency delivery of software products. However, the essence of success in the scene is in the higher order level of discipline provided by FileMan. It is precisely this 'constraint' of discipline that is vexing to many today, not the nature of the underlying technology. And the critical importance of this 'heavy burden' of discipline is still just as critical. Regards, Richard. > > > From: Gregory Woodhouse <[EMAIL PROTECTED]> > Reply-To: [email protected] > Date: Sat, 12 Nov 2005 13:27:40 -0800 > To: [email protected] > Subject: [Hardhats-members] The essence of VistA and its success (was: Re: > VistA HL7 resources) > > > On Nov 11, 2005, at 5:22 PM, Gregory Woodhouse wrote: > >> Depending on your goals, this is certainly a reasonable approach. The most >> basic problems are that your library will, of necessity, be >> a message library, >> not an interface library. A second problem is that there needs to be some >> linkage between the message library and the VistA database. That is trickier >> than it sounds, because you normally expect business rules to govern the way >> data is retrieved or filed (this is where application servers and >> technologies >> like EJB or CORBA enter the picture). How to do this is a problem that has >> never been addressed in a systematic way in VistA, leading to a plethora of >> completely ad hoc (or, as people in the VA like to say, "one off") >> interfaces. >> > > Okay, I may be going against my better judgement here, but perhaps I should > try to explain my somewhat cryptic comments. In my opinion, the success of > VistA is due, in large measure, to the fact that it's developers were willing > to tackle larger problems than the immediate problem at hand. For example, > what advantage is there to using Fileman over raw MUMPS globals? The majority > of new VistA developers do not want to use Fileman at all, and some are > downright hostile to it. After all, doesn't it add a lot of complexity to what > is fundamentally a simple idea? I'm sympathetic to that point of view, but > doubt that VistA could ever have become what it is now if it didn't offer > generic and flexible tools hose usefulness go far beyond any one particular > application. Today, the tide seems to rather against this approach (and you've > probably heard me object to how "heavy" Fileman is, too), but I believe it > would be a serious strategic error to adopt a policy of doing "just enough" to > solve a particular problem. It is more important to understand the essence of > the problem and find a way to grapple with the underlying issues that lead to > your immediate difficulty. > > > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "Good acts are like good poems. One may easily get their drift, but they are > not rationally understood." > --Albert Einstein > > > > > ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
