Vista (VA EMR) Is Not Meant for Solo Docs and Small Group Practices

The VA announced about 4-5 years ago that they would be releasing their Vista EMR as an open source package. Of course, the headline read “Government Gives Away Free EMR.” In essence, this was true. The government was making their Vista EMR available for free. In fact, I remember one of the people in HIM had an article on this subject and brought it to me when I first started working with EMR software.

I think this was a really smart move by the VA and the government and I think we’re just now starting to see some of the fruits of it being open source come to fruition. Check out this recent post about Vista on EMR and EHR. I have no doubt that the VA’s Vista EMR (err…the open source version of it) will be a player in the hospital EMR space.

The problem I have with it (and feel free to correct me if I’m wrong on this) is that Vista EMR isn’t meant for small practices like solo docs and small group practices in an ambulatory care setting. I’m not saying that it couldn’t be used that way, but it seems to me like taking a sledge hammer to a 1 penny nail. It’s overkill and is likely to cause more problems than good.

Here’s one example of a “feature” I’ve learned about the Vista EMR (and really the MUMPS database that powers it): “VistA is a multi-user system that actually can get faster with more people in the machine.”

I haven’t personally tested the statement, but it makes since why it could be the case. In fact, it’s a really cool feature for a large hospital with a large number of users accessing the same patients over and over again. Now let’s apply this to a small ambulatory practice. You only have a few people accessing a patient. Does this mean that Vista would actually be slower than other databases when you only have a small user base (ie. a small clinical practice)?

I’m not an expert on Vista (and probably never will be), but it seems to me that the marketing message for Vista should have read, “Government Gives Away Free Hospital EMR.”

About the author

John Lynn

John Lynn is the Founder of HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

15 Comments

  • I would say that a MUMPS based system would perform better compared to SQL given the same amount of users for the same query. For example, 50 people accessing John Smith’s lab report will see faster response from a MUMPS DB as compared to a SQL DB, given all other parameters are the same (efficiency of the query, size of DB etc.)

    However, 1 user accessing a MUMPS based (or SQL, or DB2 or Oracle based) system would get faster response as compared to a 1000 users no matter what you do. Think of it like this: you have to go through a door, will you get through quicker if it was just you or if there were another 99 people trying to get through too?

    Sure, you can make a system that will pretty much perform optimally for 10,000 concurrent users, but the 10,001th user will cause the system to slow down. After all you have limited resources to distribute between all your users.

  • I agree with your article. MUMPS is hard to use and is considered an arcane medieval beast by many a modern software engineer. Its from the 1960s, and codding MUMPS is akin to hieroglyphics.

    While VistA is technically free and open source, the total cost of ownership can be very high, because you are going to have to bring in a value added vendor or a consultancy group to get it to work.

    There’s really no “Do it yourself /How-to Setup VistA” guide. Such “How-to” guides exist with many open source projects, but in the case of VistA you’re going to have to bring in specialists…and not just any computer science guy will do. They don’t teach MUMPS in college..at least not in the past 20 years. Worse yet, the last book I saw published on MUMPS was from the 1980s. Epic and other large EMRs also run on MUMPS. It is my opinion that MUMPS, serving as an underlying technology, contributes to the high cost of health IT.

    Finding MUMPS developers can be hard and expensive. Although I’m sure a few exist, I’ve never met a MUMPS developer under age 50. Don’t expect to setup VistA/MUMPS without spending at least a few million dollars.

    MUMPS is fast, but so are a host of other technologies. MUMPS is also schema-less, which means it lacks referential integrity present in relational databases such as Oracle and MySQL. This isn’t necessarily a bad thing. Schemaless databases are by their nature fast and useful in some circumstances. CouchDB, BigTable(Google), and SimpleDB(Amazon) are a few modern examples of schemaless (i.e. object) databases.

    A Linux/Apache/MySQL/PHP (i.e. LAMP) is much easier to maintain and support. If LAMP is good enough for Google, Yahoo, FaceBook, Government, and millions of other apps, then it will work in healthcare. Even better, almost all college grads understand the LAMP paradigm. Many of the new free EMRs, now emerging are LAMP or LAMP-ish (something close to it that is mainstream).

    The ‘MUMPsters’ and VistA advocates will certainly attack my point of view, but its a view is shared by many in the Health2.0 community. I’d also point out that often times, people advocating VistA are actually value added vendors selling add-ons or in some way profiting from organizations using MUMPS/VistA.

    There are quite a few small simple alternatives to VistA, that can be setup quite easily and are more appropriate for small practices.
    Although I don’t have too much experience with these small practices/hospitals seeking an open source solution might want to explore:

    IndivoHealth: http://wiki.indivohealth.org/
    (The schema are open too so that’s good thing.)
    OpenMRS: http://openmrs.org/wiki/OpenMRS

    -Alan

  • Dear Friend of VistA,

    We are inviting you to visit the beta version and be among the first visitors to http://www.vxVistA.org. This new Collaboration Environment has been created to foster and support the use of VistA and is intended to be the focal point around which a new open source community will form. On the site, you will find forums where a broad range of VistA related questions and issues, both technical and functional can be discussed. You will also be able to download vxVistA, the new standard in open source EHR’s.

    Open Health Tools and DSS, Inc. are sponsoring this website because we strongly believe that it takes a committed and involved community for open source software to be a success. We hope that you will take us up on our invitation, visit the website, provide feedback on what you like and don’t like and ultimately become part of the vxVistA.org community.

  • Fabian,
    How does vxVistA fit with OpenVista, WorldVista, etc and the likes of Medsphere. I’d be really interested in learning more about the various VistA movements that are happening in the open source world.

  • John,
    vxVistA is FOIA VistA that has been modified and enhanced by DSS, Inc. to work in non-VA health care delivery settings. For example, modifications include removing many of the references to “veterans” and allowing the use of medical record numbers rather than the social security number which the VA uses for patient identification. Other enhancements include adding functionality for pediatrics and obstetrics.
    vxVistA is released under the Eclipse Public License (EPL). By using the EPL, all members of the VistA community, including competitors, will be able to use vxVistA as the core framework for their products and innovations. We included a section called Resource Pool in vxvista.org where companies and professionals can promote their services and products.
    Companies will be able to collaborate to build products by programming and packaging plug-ins, modules and extensions to vxVistA’s core framework.
    I think that vxVistA.org is a complement to the other collaboration environment that are supporting VistA efforts. Our main focus is to address the needs of people (patients, nurses, physicians, developers) who may have less experience with the system by promoting the interaction with highly skilled users and developers.

  • Hello John,

    I attended a symposium last weekend and an inquiry was made to me by an attendee as to the best EMR for a solo-doc practice. I advised that a hosted solution would be recommended. Your input and guidance is greatly appreciated.

    Thanks in advance,
    Justin

  • Justin,
    There’s no good answer to that question. I’ve implemented an in house EMR for a solo practice and it’s worked fantastic and they don’t have to rely on their internet connection.

    There’s no way that you can answer that question for a specific practice without knowing how that practice operates, what specialty they represent, what labs they want to interface with, other integrations, how do they handle billing, how do they want to input data, etc etc etc.

    Sorry, not much of an answer. I guess the point is that solo practices don’t have many shortcuts. The process is similar. I’ll be coming out with an e-Book on EMR selection before the HIMSS conference at the end of the month. Hopefully that will help them too.

  • John – just as a follow-up, in this case, the specialty is GI. I don’t know if that narrows the selection down at all. To offer a bit more information – the office is COMPLETELY paper-based. Thus I should better articulate in that they will need to integrate a PM as well. So perhaps a hosted hybrid PM/EMR would be desirable. I will be sure to point the gentleman to your article on first IT steps pre-EMR: https://www.healthcareittoday.com/2009/11/30/hit-projects-you-can-implement-today/

    Thanks in advnace,
    Justin

  • In reply to Alan Viars, there are a few inaccuracies in his comments on MUMPS. Firstly it is not hard to use – on the contrary it must be one of the easiest and the most powerful of all programming languages. Then the last “book” I saw on MUMPS (by the way, it’s now called Caché Object Script) was updated one day last week (available free on the Intersystems’ web-site). As for young developers, ours is 28. Most of the ones I met in India are 20-something. Ours developed quite a passable EMR system in 6 months, then polished it over the next 2 years. Total cost 30,000 USD. At Sri Lankan salary levels, of course.
    But it is true that mainstream computer programmers look down on it. I never really found out why. Perhaps it was that crazy name! But there are some fantastic systems running in various places round the world written in MUMPS. And by the way, hieroglyphics are quite easy to write – once you learn them!

  • Most people I talk to that use MUMPS would prefer to use something else. I’m just saying it isn’t mainstream and therefore increases complexity and cost. I’m not trying to be a negative Nancy, and I’m trying to understand the virtues of this approach. So far, the best virtue is the fact that MUMPS has a large existing install base in large organizations.

    I’d be more warm to the idea if a larger richer open source community existed around MUMPS and VistA.

    I agree that VistA EMR is not suitable for small practices, because it prohibitively complex and costly.

    For small offices, something very very lightweight is needed. The fully web based solutions (some of them even free) are probably the most ideal solution for small outfits.

    To me the lack of openness and transparency around informatics standards is a much bigger problem than what EMR you use (whether open, proprietary, or somewhere in the middle).

    Things like HL7 and CPT codes should be in the public domain but are not.

    If the EMR is like the baby grand (big/expensive) or Casio keyboard (lightweight), then the standards represent the way music is written. The patient data is the specific composition of those “rules”. Right now the ability to “read the music” is left only to the EMR vendors, keeping the general populous in the dark. I’m not saying my mother is going to study up on health informatics, but I’d argue that the current state is contributing to the overall lack of data liquidity and is hampering innovation in the health care space. Good for established EMR vendors, bad for EMR customers, the government, and the general public.

  • I’d have to add that if VistA services were simply provided as a managed service via the Web, then maybe it can be a lightweight solution. It would need to be as simple as just logging in. My point is small practices cannot expect to download the “free” VistA code base and be up and running in a couple of days.

    Still new code and code written in a more commonly understood language, can have huge benefits in terms of maintainability, reduced complexity, and flexibility.

  • mumps infected me last month and this is a very painful disease, my jawline were all swollen

  • @Massage Cushion – You are right, mumps is a nasty disease especially if it hits you lower down than the jawline. But MUMPS was not so nasty. It was easy to learn – one of the early ANSI standards had 16 commands and 25 functions. No declarations, no files, no modes. It was so easy you could learn it on the plane from Zurich to San Diego to attend a VISTA course.
    Alas, MUMPS is almost dead. But it still lives on as GT.M (public domain) and its ghost is embedded as the native command language in Intersystem’s Caché database (proprietary). And MUMPS code is still running many hospitals, hotels, harbors, law courts, warehouses, libraries – you name it.
    So be careful, it might infect you yet.

Click here to post a comment
   

Categories