I too am a fan of the architecture that Rich describes. There are certain elements of it that were used (through a very different set of circumstances) in the FHIE project (and now with several projects that have derived from that framework.) The simplicity of the structure coupled with the complexity permitted in the associations using a powerful reference terminology make it one of the most appealing architectures.
Until about a dozen years ago, every major package in VistA was "re-engineered" every 6 to 18 months when major package "versions" were released. It was a sad day when major versions were no longer to be permitted except in the rarest of circumstances. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 03, 2005 7:31 AM To: [email protected] Subject: RE: [Hardhats-members] RE: A parallel strategy for evolving VistA - Re: [Hardhats-member s] MDC Revival Jim, the stovepipes are the underlying clinical (and some clinical/administrative) packages, such as Lab, Pharmacy, V-files, PCE, TIU, Bed Control, PTF, Radiology, etc. Many of these packages were developed years ago (I believe initially at different medical centers, and then at different Field Offices). I also believe that originally some of these packages had their own patient files ! All of these packages store what could be classified as results, reports, etc in what really amount to seperate databases within the M/Fileman, environment. "Stovepipes" in a sense. Navigating these files/databases to do clinically relevant queries using Fileman can be daunting at times. Think of trying to identify a simple cohort of patients who meet the following criteria: "All female patients taking Digoxin, with a potassium level less than a certain threshhold value". One must jump from patient file, to some very complicated lab files, to the prescription file. It's probably simpler to just write a custom program to do this, than to try to frame the query in Fileman. Nowadays, some of these queries can be done with CPRS. But we're talking years after it could have been available. Also I think CPRS would have difficulty with more complex queries than my example. For many years, here at Indianapolis, we used a system called RMRS. It was a clinical repository, written in M, that was loosely based on the Regenstrief Medical Record system, which was originally created at the Regenstrief Institute. At the heart of this system is a single M-based file, that stores 27 different types of clinical data in a standardized way. It is fed its data by HL7 messages, from Vista, or, any commercial package that sends the data in the proper HL7 format. The file is easily queryable on a patient by patient basis, or across the entire file, to identify cohorts of patients, as described above. The system could even be programmed to page physicians, when laboratory results on their patients were outside reference values. The system was abandoned, mainly because the lead developer left the VA, and because Vista did not contain the necessary mapping tools to map non-standard terms to standard ones in an efficient manner. Mapping them manually, was not impossible, but it was resource intensive. These same issues have resurfaced 10 years later with the HDR, but this time a properly resourced team of Data Standardization people has been assembled to revisit the issue. And so we are "back to the future" in a sense. My point is, that Vista could be much simplified, with an architecture like this, if it were redesigned with "lessons learned" taken into consideration. It could be done in M, because after all, it has already been done once in M. Finally, I will tell you that I am not the person best qualified to proselytize on this system. Nor am I sure the original developer has any further interst in the system. I am simply saying that I am a fan of the architecture. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Self Sent: Wednesday, March 02, 2005 5:24 PM To: [email protected] Subject: Re: [Hardhats-members] RE: A parallel strategy for evolving VistA - Re: [Hardhats-member s] MDC Revival Richard, You make some excellent points. Any long-lived system needs to be re-engineered periodically (continually, if possible) in order to adapt to changing technology and the changing expectations of its users. I would think that much of the re-engineering that you speak of is a necessary part of any manageable comprehensive transition to a newer platform whether it be Java or M2Web or something else. What are the 30 year old stovepipes? As I understand it, the DHCP kernel was formed only about 20 years ago. What would your standardized, easily query able format look like? What would make it easy? Richard.Sowinski wrote: >A rational "plan A" might have been to re-engineer Vista such that the >clinical packages were lighter, more like front-ends to an underlying >clinical repository, which stored all the results and data for lab tests, >procedures, prescriptions, problem lists, diagnoses, etc. in a standardized, >easily query able format. Instead of in multiple stovepipes, built 30 years >ago. > >The feeding of the CR could have been message-based, making it possible to >substitute >best of breed commercial systems for some of the less popular Vista >packages, if that's >what individual sites wanted to do. > >The new Vista, would also have been much less tightly integrated so that >you don't need the xxx package installed, in order to run Lab, or the >yyy package installed in order to run Scheduling. > >All of this could have been done in M, by re-engineering what is there. > >Don't get me wrong, Vista is a good system, that has been built by many >talented individuals, over many years, and it has served the VA well. > >But, I think it could have been so much better, had sound software >engineering >principles been applied, rather than blaming M for any shortcomings that may >exist. --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
