Dude.
I am known for throwing an occasional “Dude” into my jocular speech. Ok, maybe more than a couple when excited. OK, maybe more than a couple when I am not so excited as well. OK, maybe I use it indiscriminately at random times. But hey, I am just following Merriam-Webster definition of the appropriate usage of the term “practically anywhere” within a sentence.
But dude! Have you actually read the recent GAO reports regarding the status of the current VistA modernization project? I was literally shocked – let me save you the trauma by pulling in the highlights (where is WorldVistA, VistA Software Alliance, Roger Maduro, or any of the VistA luminaries in terms of reporting on this?)
- The VA is currently engaged in a MASSIVE rewrite of the entire VistA System
- They are planning on replacing 104 of the current applications that run in 128 different VA hospitals with a completely new suite of 67 applications, 10 common services, and 3 separate databases (this is based off the August 2006 HealthEVet Development Plan with assist from Carnegie Mellon)
- They have spent $600M dollars from 2001 to 2007 on this project and here is the status report of the 8 projects initiated so far
- Health Data repository – partially completed standardization project (see below for summary)
- Enrollment
- Scheduling – beta tested at first site in September 2008; general availability in 2011
- Laboratory
- Pharmacy
- VistA applications development project
- VistA foundations modernizations project
- Billing – is in early design planning (this after spending $150M on a failed system with Bearing Point).
- Original delivery date was estimated at 2012, which has subsequently been pushed back to 2018 (and counting)
- Furthermore the report found the following:
- VA Has Developed an Overall Strategy for HealtheVet, but It Lacks a Project Management Plan
- VA Has Not Fully Established an Oversight Structure for HealtheVet
- VHA Has Not Fully Implemented a HealtheVet Governance Structure
- Key Positions within the Office of Enterprise Development Are Vacant
- Which led to the following conclusion:
- “Although VA has made progress on its $11 billion HealtheVet initiative, it has also experienced significant delays, and NONE of the associated development projects have been completed. Moreover, VA is proceeding with this complex initiative without a project management plan and validated cost estimates to coordinate and guide the effort. At the same time, a governance structure for HealtheVet has not yet been established, and key leadership positions that are responsible for providing day-to-day oversight have not been permanently staffed. Further, several IT governance boards with oversight responsibility for HealtheVet have not yet performed essential reviews of HealtheVet projects to gauge progress and funding requirements and the department lacks a time frame for doing so. Until the department takes the necessary actions to fully address these matters, it will face the risk that HealtheVet may experience cost overruns and continued schedule slippages, and may not achieve the outcome it intends to achieve.”
Dude? What the heck – $11B project without any of this stuff in place, no clear plan, no direction, no people to do the work, and constant changes. Heck, I bet Epic would be happy to go into the VA and put that $11B dollars to work and having now experimented with Kaiser, I bet they could actually pull it off. Reading this makes one wonder what on earth the government is doing developing sofware.
However, the silver lining in my warped mind is that with this amount of money being thrown around, it is hard to think of a justification for the government not to take a portion of this money – say 10%, or 5%, or even a measley 1% of anticipated project costs ( >$100M dollars) – and engage the open source community on collaborative development. Better yet, why not use that money to develop an open source collaborative framework from which all the paid contractors, the open source fraternity, and a growing international community can contribute to the project.
Forward motion, forward movement, and forward thinking . . .Dude, where is the community leader to catalyze this opportunity?
HIGHLIGHTS from the 45 page report:
- Department officials acknowledge that VA has experienced significant delays in developing and implementing HealtheVet and attribute the delays to various factors, including loss of experienced contractor staff, changes in technical and deployment approaches, and lack of management continuity. Department officials stated that they are working to address the delays by using an incremental development life-cycle approach; establishing more realistic time frames; and establishing an integrated product team composed of information technology, program, and acquisition personnel to address contracting issues.
- The department does not yet have a comprehensive project management plan to guide the development and integration of the many HealtheVet projects. That is, it does not have a plan that describes, among other factors, the project’s scope, implementation strategy, and lines of responsibility, and includes an integrated schedule that considers all dependencies and defines subtasks to ensure that deadlines are realistic.
- In April 2008, VA provided an $11 billion cost estimate for completion of HealtheVet
- The business owners do not yet have a fully implemented governance structure for development projects that was endorsed by the department following a realignment of IT resources in which IT funding and personnel were placed under the control of the department’s Chief Information Officer (CIO).
- VistA now consists of 104 separate computer applications. These include 56 health provider applications; 19 management and financial applications; 13 crosscutting applications such as patient data exchange; 8 registration, enrollment, and eligibility applications; 5 health data applications; and 3 information and education applications
- Besides being numerous, these applications have been customized at all128 VA sites. According to VA, this customization increases the cost of maintaining the system, as it requires that maintenance also be customized. VA has reported expending significant resources (approximately $2.5 billion) to maintain the system between 2001 and 2007.
- VistA stores data in an organizational format based on the location where care is provided, rather than maintaining a global record for each individual patient, and it is programmed in a language for which there is a continually decreasing supply of qualified software developers.
- Finally, the Scheduling, Health Data Repository, Laboratory, Vista Application Development, and Vista Foundations Modernization projects were delayed by the loss of experienced contractor staff. These initiatives were supported by an overall contract for HealtheVet. When this contract expired in September 2006, it was renewed on a monthly basis to ensure continuity of work until a new contract was awarded. However, task orders from the new contract, which was signed in November 2006, were not issued until June, July, and September 2007. According to department officials, as a result of these delays, the experienced contractor staff who supported the initiatives had moved to other work, corporate knowledge for these initiatives was lost, and new contractor staff had to be hired and educated.
- Project Status
- The Scheduling application is planned for initial deployment at one site (aVA medical center in Muskogee, Oklahoma) in September 2008 (full deployment to all medical facilities is planned for 2011).
- For the Pharmacy project, final testing of one function (order checking) iss cheduled to begin in September 2008, and new drug file and pharmacydata management systems are scheduled to be implemented in January 2009. Remaining system functions to be developed include inventory, order entry and clinical monitoring, medication dispensing, and medication administration. Further development of the Pharmacy application depends on the results of an ongoing analysis and evaluation of the costs of building and deploying these functions. This analysis, for which a contract was issued in February 2008, is due July 2008.
- The new Laboratory system is scheduled for independent verification and validation in October 2008. National deployment is planned to begin in 2010, with a phased implementation across the department expected to take place over the next 5 years.
- The initial implementation of the Enrollment application is scheduled for August 2008. This project is to provide an enrollment workflow for use at VA’s Health Eligibility Center. An enhancement is scheduled for implementation by July 2009 for communicating to veterans and providing operational efficiencies for VA staff at the Health Eligibility Center and medical centers to coordinate changes in veterans’ eligibility. Finally, in December 2011, the department expects to complete a modernized registration capability.
- A fifth project (Billing) is for a new financial system, which is in the planning stage. The current Billing project is a second attempt to modernize the billing system. Under the first attempt, VA awarded a contract in July 2003 to implement a commercial product to provide an updated billing capability for the department (called at that time the Patient Financial Services System); however, after about $107 million was spent on this effort, the contract was terminated in September 2006 by mutual agreement between the department and the contractor. The department expects to complete national deployment of the current project (called the Revenue Improvements and System Enhancement project) at the end of fiscal year 2015. Finally, the program has two ongoing projects that are focused on activities to develop and implement required enhancements to existing VistA applications and lay the foundation for transitioning these applications to HealtheVet:
- The focus of the VistA application development project in the near term is to develop the critical enhancements and fixes to the VistA system that are necessary to ensure compliance with changes to patient enrollment and billing requirements and accomplish other critical data updates. In fiscal year 2010, the emphasis for this initiative will shift from fixes and enhancements to new development work aimed at the transition to HealtheVet. The initiative will then encompass building many of the replacement systems within HealtheVet.
- The VistA foundations modernization project includes work on architecture and testing services, including a comprehensive testing suite and strategy for all VistA and HealtheVet applications. In fiscal year 2009, several common services—the deployment toolkit, business rules engine, and workflow engine—are expected to be delivered, along with new testing services capabilities and updates to the overall architecture. This work is expected to be ongoing until the completion of the HealtheVet initiative.
- Project Concerns
- VA Lacks a Project Management Plan
- VA Has Not Fully Established an Oversight Structure for HealtheVet
- VHA Has Not Fully Implemented a HealtheVet Governance Structure
- Key Positions within the Office of Enterprise Development Are Vacant
- Conclusions
- Although VA has made progress on its $11 billion HealtheVet initiative, it has also experienced significant delays, and none of the associated development projects have been completed. Moreover, VA is proceeding with this complex initiative without a project management plan and validated cost estimates to coordinate and guide the effort.
- At the same time, a governance structure for HealtheVet has not yet been established, and key leadership positions that are responsible for providing day-to-day oversight have not been permanently staffed. Further, several IT governance boards with oversight responsibility for HealtheVet have not yet performed essential reviews of HealtheVet projects to gauge progress and funding requirements and the department lacks a time frame for doing so. Until the department takes the necessary actions to fully address these matters, it will face the risk that HealtheVet may experience cost overruns and continued schedule slippages, and may not achieve the outcome it intends to achieve.
Categories: Uncategorized
Hello, i think that i saw you visited my site thus i came to “return the favor”.I’m attempting to find things to improve my website!I suppose its ok to use a few of your ideas!!|
i want scheema of vista.does any body hase scheema daigram of vista.kindly help me in this matter.
thanx
Alan I’ve expanded some more of my thoughts here:
http://www.outoftheslipstream.com/node/125
Whilst I think you’re right that there is a growing consensus from the industry to move in a new direction, I also think it would be a real shame, and, as you’ll see in my article, I believe it is for some, if not all, of the wrong reasons.
Re: Michael Clayton and Rob Tweed ..Thank you for the information. I will take a long hard look.
I am aware of the new schema less approaches (i.e. Google Big Table) We are using MySQL with a similar design approach. Amazon Web Services is good stuff. These schema less technologies, however, should be handled with care and take some additional planning/understanding on the part of the application developer. They do provide highly scalable solutions.
I doubt we will be building any new applications based on MUMPS but we do intend to build some MUMPS interfaces (using REST).
I’m not the biggest fan of .NET either, but if customers we create a lot of code for customers in C#. Every technology has a place.
My thoughts on MUMPS are just an opinion, which is shared by many on the industry. I’d say there is a growing consensus from the industry to move in a new direction. My opinions on MUMPS are just that, an opinion. I hope it can be respected without resorting to personal name calling (Deaf, Dumb, and Stupid RE: Jim Bell)
MUMPS, like COBOL, will probably be around for a long time.
That URL got cut off. Here it is in full:
http://www.slideshare.net/george.james/mumps-the-internet-scale-database-
presentation/
Just to follow up on Mike’s comments, see
http://www.slideshare.net/george.james/mumps-the-internet-scale-database-presentation/
for more background on why, in fact, Mumps is the right technology for today’s requirements.
Personally I despair at what the VA is up to, but our Dept of Health here in the UK have been doing exactly the same thing with a similar degree of success….or lack of it.
To all the MUMPS detractors:
The very “latest thing” in the web development world is the schemaless hierarchical database. Just try Googling that. The relational databases the VA are trying to move to are the new legacy.
MUMPS is (as it always has been) incredibly powerful and ideally suited to the most modern development environments (or should I say the modern environments that actually get stuff done).
I was the recent Ajaxworld conference in NYC a few months back and M/Gateway were one of the most popular exhibitors with their excellent EWD (Enterprise Web Developer) product. They are due to give another exciting presentation at the upcoming San Jose event:
http://ajaxworld.com/
This just shows how well good old fashioned MUMPS (whether as the raw open source GT.M, or dressed up Cache) plays with the modern AJAX, DOM, JS and JSON world.
http://gradvs1.mgateway.com/main/
http://groups.google.co.uk/group/enterprise-web-developer-community/browse_thread/thread/e7fece2b31d18609?hl=en-GB
re: Mr. Alan Viars
Not being able to recognize the capabilities of the M environment is the same as being deaf, dumb, blind, and stupid, too.
Show me a functional COMPLEX design environ that WORKS (in more than one setting) and you might have an argument. So, far there isn’t a medical system that I’m aware of that has purchased private, commercial, proprietary software that isn’t suing their vendor. Java is still a piece of junk; you’d be better off in Assembler.
In regards to open source development in M there are pitfalls to be aware of. If one is in a small or solo practice, that advantage is huge. If one is in a complex medical setting structure that depends on real function in real time in a multidisciplinary environment, then that open source risk is high. It is most important to have your own on-site skill with open minds to glean the high value from independent development as well as having the skill to design and develop.
Okay okay…the “miniskirt” analogy was a little tongue-in-cheek, but please find a MUMPS/Cache developer under the age of 50 for me…or ask any developer if he or she thinks that MUMPS it is a good strategy for going forward.
Are there ANY colleges teaching courses in MUMPS? Have there been ANY books printed on MUMPS in recent years.
Answers to those questions speak volumes about the platform.
Its an antique, outdated, platform and should be rapidly phased out for the sake of the (failing) American health care system. (Sure there are other problems, but this is a real contributor to the expense of health IT.)
I understand there are many legacy systems out there using it, but let’s all agree that it is a very obscure technology and contributes to he overall complexity of programming health IT solutions, and therefore increases the overall expense of health care and wastes our tax dollars.
Alan Viars
Some basic information on MUMPS from Wikipedia below. Modern object-oriented languages such as Java and Python can be easily integrated with MUMPS in either the Caché or GT.M versions. The unusual design of MUMPS is in regard to its primary orientation as a database system with minmal programming features to conserve computer resources, as noted below. It is used in financial services because it is faster at processing transactions than the standard relational database systems.
The “miniskirt” analogy is nonsensical and irrelevant.
Large companies currently using MUMPS include AmeriPath (now part of Quest Diagnostics), Care Centric, Team Health, Epic Systems Corporation, EMIS, Partners HealthCare, Meditech, and GE Healthcare (formerly IDX Systems and Centricity). Many reference laboratories, such as Quest Diagnostics and Dynacare, use MUMPS software written or based on by Antrim Corporation code. Antrim, and its parent Sunquest, was acquired by Misys in 2001.
MUMPS is also widely used in financial applications. MUMPS gained an early following in the financial sector, and MUMPS applications are in use at many banks and credit unions. It is used by Ameritrade, the largest online trading service in the US with over 12 billion transactions per day, as well as by the Bank of England and Barclays Bank, among others.
As of 2005 most use of M is either in the form of GT.M or InterSystems Caché. The latter is being aggressively marketed by InterSystems and has had success in penetrating new markets, such as telecommunications, in addition to existing markets.
MUMPS is a language intended for and designed to build database applications. Secondary language features were included to help programmers make applications using minimal computing resources. The original implementations were interpreted, though modern implementations may be fully or partially compiled.
MUMPS must go!
You can put a miniskirt (Cache) on your grandma (MUMPS) but that doesn’t make her sexy….or even fertile for that matter.
Okay maybe that is too much of a visual…but DUDE..seroiusly!
If we are serious about saving tax dollars and serious about changing this borken healthcare systems, then we must move away from obscure tools such as MUMPS\Cache. How about a little Python, a little Java?..Heck even .NET…anything but MUMPS!
Security through obscurity in no security at all.
Alan Viars
MUMPS is to Cache’ as DOS is to Windows
In my experience doing enhancements to the back-end never works out on-paper to be the most cost effective approach.
It’s possible in real-life it is less costly, but with most project costing methodologies it doesn’t play out that way in the feasibility studies.
I’ve also seen enough projects with gold-plated Project Management Plans, and elaborate Oversight and Governance structures that never resulted in anything but project stamped coffee-mugs to know that those things may or may not make a difference.
It actually sounds to me in the project status part like they are creeping towards improvements. Things are going into testing and they’ve been smart enough to move to an incremental development life-cycle approach.
That means instead of sinking all your eggs into a grand plan that will get killed before anything is ever deployed you go into a mode where you circle around your target putting things up and working them out. It lacks the academic splendor of a huge master plan, but makes up for it with software that has been chugging away from an early stage.
Software development/enhancement on this scale is a dirty in-the-trenches business.
I could not agree more… having in-house developers enhance the existing backend and provide UI’s to the tradionally roll-and-scoll applications would satisfy the requirement at a far less cost to the taxpayers.
…but who am I to say…
Hap Moorii: “The recommendation of open source seems a bit out of place in this context. Open Source excels where the same people who use the software are also the same people who change, improve, or fix it.”
It is telling that this describes precisely the process within the VA that developed the “legacy” DHCP/VistA applications for which we will now pay billions to develop “Commercial Off the Shelf” replacements.
Note as well that the “legacy” VistA is itself in the public domain and is increasingly finding uses outside the VHA.
The open source model allows a return on the American people’s investment in VistA. That’s not something we will see from Cerner, Epic, SAIC, etc.
“…the developers need to have some knowledge of software requirements, workflow, day-to-day processes, etc. That’s a hard environment for open source to play in.”
I would argue that this is the most powerful reason to RETURN the VA’s software development efforts to an in-house, open-source model. (Don’t hold your breath.)
“MUMPS, an antique computer language somewhat akin to sanskrit”
True to the extent that the language is unique in many ways and that it predates C, not mention the many successors to C both direct and not direct (e.g. Java). Also true to the extent that Sanskrit – although no longer spoken, just as Latin, a related language, is no longer spoken – is an intricate and highly expressive language with superior features in terms of precision to its daughter languages. False to the extent that “antique” connotes no longer usable. See below.
“GT.M is the high-performance database engine offered by Fidelity National Information Services (FIS). Optimized for transaction processing, GT.M is also an application development platform and a compiler for the ANSI/ISO standard M language. The technology is used in several industries around the world, most notably financial services and healthcare.”
MUMPS or M is used in financial services because of its speed in handling huge volumes of data. The same value is true for healthcare applications which the application area that it was originally designed for.
I hate to sound cynical, but I wonder if GAO or somebody else will be issuing a similar report a few years from now about Kaiser Permanente’s much publicized and much praised clinical IT system? Let’s face it, transparency and the willingness to publicly acknowledge failures is not common among large organizations (even ones like the VA which did a highly commendable job in reforming itself a decade ago).
Skeptic
The recommendation of open source seems a bit out of place in this context. Open Source excels where the same people who use the software are also the same people who change, improve, or fix it. You also likely have an existing, complex legacy hardware environment that the government may plan to continue using. On top of that, the developers need to have some knowledge of software requirements, workflow, day-to-day processes, etc. That’s a hard environment for open source to play in.
Mr. Shreeve is exactly correct regarding this approach. The open source community world-wide is an incredible and incredibly innovative resource that should be tapped into on this or any other project. All one has to do is look at the fantastic software that continues to be generated by that community starting with the Apache web server and projects that are sponsored by the Apache Software Foundation and including huge software projects such as Java developed and overseen by Sun.
This is of course anathema to Microsoft, even though Microsoft itself has contributed to open-source projects, and its ilk that continue to proceed ever more unsuccessfully with proprietary software. IBM, Intel, HP and other large and smaller corporate software developers – not to mention Google, Yahoo and Amazon. The latter companies largely use and produce only open-source software, aside from whatever they may create for purely internal functions. The former have internal staffs dedicated to open source development and have contributed much software to the open-source community.
Mr. Shreeve, along with his brother, founded MedSphere a number of years ago, to exploit the VA’s VistA system as it existed then for commercial projects. I have not followed MedSphere’s recent history, but I believe neither is currently involved in the company. However each is certainly worth listening to, particularly on this topic.
The federal government continues to permit outside vendors – apparently Bearing Point as cited by Mr. Shreeve and a few years ago SAIC which provided worthless software to the FBI for a cost to the government of close to $200 million – to spend vast amounts of tax-payer money with no value whatsoever in exchange, yet to continue to win business from other agencies. If a project fails, the government must recover the tax-payer funds through other on-going projects, if not otherwise recoverable as well as follow Mr. Shreeve’s advice. All will benefit.
I would look at whose pockets this project is lining. Is it being done in-house or through an outside contractor?
VistA is correct casing, brother Paul. Don’t think it would be all that much cheaper if Epic did it. Look at the overruns out at Kaiser, which is much smaller than the VHA. And, like VistA, Epic is written in MUMPS, an antique computer language somewhat akin to sanskrit.
There are diseconomies of scale in complex systems like the VHA, and this is one of the direct costs. The VHA is the second largest organized health system in the world, after the British NHS, which completely blew an even bigger ($24 billion) IT project, Connecting for Health.
This is really, really hard- a colossal project management headache. Don’t think the Kumbaya approach is going to work, dude. . .