I am working at Landstuhl Regional Medical Center in Germany at the moment, and we have just brought up CHCS II at Landstuhl Regional Medical Center and most of our associated clinics and hospitals across Europe. CHCS II is now being run at DoD hospitals and clinics across Europe. By the end of the summer it is projected to be operational from Iceland to Turkey. Now granted CHCS II is running "alongside" CHCS I, provides relatively little functionality compared to the current CHCS I, and in no way "replaces" CHCS I, but it appears that there is some political/financial impetus behind CHCS II which indicates to me that the project is still "alive" and not a "failure". Your tax dollars and my tax dollars are being spent to deploy CHCS II around the world (DoD bases in Asia are next). Could Chris please elaborate on his statement that CHCS II is/has been "a failure"?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Richardson Sent: Sunday, June 12, 2005 10:11 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] == VistaWeb Missing Apps == David; The failure of CHCS II was not just one failure but a series of nearly 10 successive failures where the only criterion was that the solution could not be MUMPS. I lived it. I was there for the first three or four failures. The four month integration trials out at Tripler where the vendors where on site living DLL hell on a daily basis. In four months of integration testing (this was supposed to work the first time out of the bag when the vendors came to Hawaii). Their code was supposed to work and it didn't. In four months they could generate a patient list in twenty five minutes when they could go over to the CHCS I terminal and get that same atient list in 30 seconds. It was embarassing for these guys, but failure is not defeat, just justification to expend even more government money. After about two years this batch of vendors was kicked out and another set was brought in under a new management vendor. The result was equally disapointing and even more government money sunk down the hole. I was brought in to help the vendors figure out how to migrate away from MUMPS and VistA. I was happy to have some real world comparison of the capabilities of this "New" technology with the "Legacy Solution". I explained to them the reasons why their results were so bad. It isn't that the solution has to be all MUMPS, not at all. Let's think about using these tools for what they are good at. This was not the only task that the engineers helped make the interfaces work. There was a management interface where they wanted all of the data elements from the CHCS I system downloaded to their database (it happened to be a Relational Database). The process was tested out at Landstuhl, Germany, a CHCS site. They hooked their database engine up to the CHCS system and CHCS I downloaded to them for 6 and a half days until they ran out of disk space. CHCS I still had lots of data to send them. This was tried at Walter Reed as well and the add-on system was so slow that CHCS I was dumping the data to them faster than they could add it into their database and so it went to tape. Their system became an off-board tape-drive. Keep in mind that the winning of CHCS I by SAIC was part of a compute-off run by the military. The TRIMIS spec was the requirements, (20 years of specification without implementation). Four vendors, Baxter-Travenol, Technicon, Mc Donnel-Douglas, and SAIC doing the VA set-aside (suggested by Congressman Sonny Montgomery). Each participant was given $25 million dollars to provide a solution tot he compute-off. Baxter and Technicon spent their money and no-bid the contract. The contract was written so there would be a follow-on contractor as part of the process (an 85:15% split). OK, so Mac Donnel Douglas run their model and got a 67% functionality score and their bid was $2.6 Billion to do the military hospitals around the world. Not too bad. SAIC's entry into the compute-off was the CHCS model derived from the VA DHCP. Their entry scored 98% functionality and the bid was $1.01 Billion, 40% of the competing bid with more functionality. Mac Donnel Douglas could have had 15% of the contract by just standing there. They walked away. SAIC won 100% of the contract. These economies of scale are not unusual for MUMPS solutions. This was the 1986-7 time frame. CHCS I is still runnning the DoD hospitals. I don't mind having MUMPS replaced with something that works as well and as cheaply, but lets have a level playing field for once. Let MUMPS compete head to head with these other technologies and may the best system succeed. Of course, there are very few absolutes in life, but to throw away a big hunk of your tools just out of predjudice and politics is just wrong. One tool is not going to fit all applications, great. Lets find out what is going to be the easiest to support, to expand, and to adapt to the needs of the tasks ahead. #1 Projects fail for a lot of reasons, [politics and vendor pressure can be a couple of reasons. Non-technical management making technical decisions and predjudicing the outcome is another reason.] #2 An effective system is more than the benchmark. [Hey, true enough, but the proof is in the puting. Remember that Legacy also means that the current system does work and the new system should do at least what the current system does. Ain't seen it yet.] #3 Any project directly ported to another technology will not benefit from the advances in that new technology [Directly ported, I could agree with you. But that is one of the reasons that MUMPS has done so well. It is a thimble that looks like a 20 gallon sack to a lot of traditional applications. I am willing to bet that it would be easier to take an existing new technology data model and re-host it in MUMPS than the inverse. But again, if the application has a lot of glitz and sparkle but is not usable, then what have you got?] David, in #4 you stated that; "change platforms when your current platform restricts your architectuyre options." What do you mean by that? The MUMPS model is exceptionally flexible and strangely very platform independant. CHCS I was implemented on PDPs (running DSM-11), then Vaxes (VMS, then Open VMS), then Dell Servers (SCO Unix), and then the Alpha (also OpenVMS, and NT). CHCS I interfaced with every "other technology" I ever heard them ask for. Some of those interfaces were too slow to be fed by DSM. Some of the interfaces would generate a NAK for every other record to slow the CHCS I system down (CHCS was responsible for recording the communication errors, the other system was not). The CHCS I system was supporting a hospital and a number of these add-on dedicated interfaces (probably more than a dozen different interfaces) and CHCS I still had time to handle even more. The Open VistA model runs on PCs under the whole line of Microsoft OSs, haven't seen a Linux yet that won't work, now I believe that Apple has been added to the list. I have seen the VistA model run on IBM, Tandem, and a bunch of others. The MUMPS technology is breaking out of it's boundaries with more and more new interfaces, PHP, HTML, XML, Apachea and CGI, RPC, you name it. Somebody has found a way to get it to work. Once the technicals are worked out, these interfaces find their way into the applications. I have to close this off for now and get some sleep. Hey, proper tool for the proper job. Just let's have some level playing fields and open publication of benchmarks, compute-offs, and the like. ----- Original Message ----- From: "David Sommers" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Saturday, June 11, 2005 11:07 PM Subject: RE: [Hardhats-members] == VistaWeb Missing Apps == >> Comments about failed projects based on differing technologies. >> Comments on speed of that vs speed of this. >> Comments saying this thing bites and this other thing is... Whoa - slow down... I don't hold a PHD in database design but I do know: 1) A project fails for many more reasons than the database it was built upon. If CHCS II failed, VistA failed/fails, or "This new thang" fails - it has many factors involved. CHCS II could be "slow" because the developers queried the database wrong, designed the database wrong, forgot a crucial clustered index on 2 level join and returned unused columns thru an uncached web service. Whatever the reasoning - computers do what they are told and they're usually told wrong. 2) An effective system is more than the benchmark. If you have a bug turn-around time of 2 days instead of 2 weeks because the system is "better" but takes 20% longer to return your report - is it worth it? What if you could build a new feature in 1/4 the time because the system is modular, etc? What if your bug count was much lower because you utilized test-driven development, unit testing, etc? Where's the line between productivity and speed? I could write an ISAPI filter for IIS that'll return pages REALLY FAST because it was written in C but it won't be easily maintained or flexible. 3) Any project directly ported to another technology will not benefit from the advances in that new technology. If I had, say the Windows or Linux Kernel written in C. Porting it to some new technology like E (D actually exists) - will it simply work faster? Probably not. Not because E is a bad language, the kernels simply take advantage of C as it was implemented. The same thing applies to databases. My current SQL Server and OLAP (Analysis) Server are not the same. Two technologies used for different purposes. M is different, no doubt about that. But if you were to build a business application that once read lines out of a text file, would you have a relational database consisting of a single table and one column that holds each line of the text file? Nope. You'd probably normalize that thing out and make the most use of your technology. Maybe mapping VistA straight from M -> SQL isn't the best approach? If it is or isn't, I don't think one organization's implementation of an EMR sets the pace for comparison. Epic uses SQL - not all banks use M - many CRMs use relational system - etc. Going back to #1 - it's not just the database's fault. 4) Dropping VistA for the sake of changing technologies. I have a saying (well, I never actually say it out loud) - change platforms when your current platform restricts your architecture options. If SOA (web services) is something you want and you can't do it in ASM - then you should check your options. There are many languages out there and they're all good at something - but not everything. Could VistA be re-written in .NET, Java, or Python? Yes. Can it be just as successful as VistA-M? Possible. Depends on the interface between the chair and keyboard. And may I recommend this: http://www.amazon.com/exec/obidos/tg/detail/-/0596100124/ref=wl_it_dp/00 2-5699553-5527248 Database in Depth by C.J. Date Remember: You can't optimally use the targeted system until you know how it works under the hood. If you're using .NET or Java, question those easy-to-use syntax commands. So why is the StringBuilder better than looping thru a string? Why is a string immutable? Why does a patient's meds take longer to load on the new system than the old? Check those queries, your data model, your middle/business tier, etc. And if it's truly new technology - are you using fetch-ahead, background/multi-threading, caching, etc. Out. ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
