|
|
| (8 intermediate revisions by 5 users not shown) |
| Line 13: |
Line 13: |
| | VistA to community health centers' special needs. | | VistA to community health centers' special needs. |
| | | | |
| − | '''From: Hardhats Listserve:'''
| + | ==From Hardhats Listserve:== |
| | | | |
| | Here are some recurrent questions us nontechies have about VistA: | | Here are some recurrent questions us nontechies have about VistA: |
| Line 19: |
Line 19: |
| | [[1) Is Mumps a serious limitation to complete EHR functionality, code maintainence, HL7, or PMS interfacing?]] | | [[1) Is Mumps a serious limitation to complete EHR functionality, code maintainence, HL7, or PMS interfacing?]] |
| | | | |
| − | There are several major commercial EHRs that use MUMPS. In fact,
| + | [[2) What is the fundamental difference between a relational database and a hierarchical database and how does that effect the end-user? (Should we even care? If so why?)]] |
| − | the language was developed expressly FOR the health care
| |
| − | environment. There are far more limitations (and serious ones at
| |
| − | that) in most other languages and especially strict SQL
| |
| − |
| |
| − | Absolutely not. I will go one step further than Cameron.
| |
| − | I have heard that M is the #1 language used for EHR's.
| |
| − | Epicare, which just contracted for EHR for Kaiser, is based
| |
| − | on M, for example.
| |
| | | | |
| − | [Rick Marshall]] replies: | + | [[3) How hard is it for non-Mumps IT personnel to learn Mumps/VistA and are there enough experienced VistA programmers (or former VistA programmers) to consult or be hired to non-VA projects?]] |
| | | | |
| − | How many completely functional EHRs can you name that are not written in
| + | [[4) What other concerns should we have regarding adopting VistA?]] |
| − | MUMPS, whose functionality even comes close to VistA's? As far as I
| |
| − | know, MUMPS is the only programming system designed specifically for
| |
| − | medical systems development. Standard MUMPS cannot be used to generate
| |
| − | sophisticated graphical interfaces, but it can be used to communicate
| |
| − | with programming languages that do. No language does all things, nor
| |
| − | should, nor can. Programming requires mastery of multiple languages,
| |
| − | and the core language must be carefully chosen. The best reason for
| |
| − | using Standard MUMPS as VistA's core language is that it is decades too
| |
| − | late to do anything else. VistA is already written in Standard MUMPS,
| |
| − | and it took twenty-eight years to get this far. Replacing Standard
| |
| − | MUMPS at this point is an irresponsible waste of resources that could
| |
| − | instead be used to easily extend VistA to save lives. It is like
| |
| − | arguing that brick is passe, so we should shut down New York City for
| |
| − | fifty years so we can remove all the brick and replace it with something
| |
| − | more popular. Replacing Standard MUMPS to improve code maintenance (for
| |
| − | example) is like replacing my DNA so I can learn to play the
| |
| − | flute--unnecessary and irrelevant. Standard MUMPS is VistA's DNA.
| |
| | | | |
| − | Honestly, though, why does anyone who is not a programmer care what it
| + | [[5) Are any Community Health Centers currently utilizing VistA?]] |
| − | was written in? What is Mac OS X written in? How about Microsoft
| |
| − | Word? Google? Quicken? The Sims? Do you feel competent to evaluate
| |
| − | which programming language is ideal for a given problem domain? After
| |
| − | twenty-one years of programming practice and study, I do not know beyond
| |
| − | my chosen field of medical software. I certainly do not feel competent
| |
| − | to choose among surgical instruments. I could spend time trying to
| |
| − | teach nontechnical people how to evaluate programming systems enough to
| |
| − | understand why VistA had to be written in Standard MUMPS (something even
| |
| − | most programmers evidently do not understand), or they could spend a
| |
| − | fraction of that time teaching me what they need VistA to do for them.
| |
| − | If I can get VistA to do all those things for them, then in the end who
| |
| − | cares what language it is written in?
| |
| − | | |
| − | | |
| − | '''2) What is the fundamental difference between a relational database and a hierarchical database and how does that effect the end-user? (Should we even care? If so why?)'''
| |
| − | | |
| − | While MUMPS has been characterized as "hierarchical", the
| |
| − | DBMS that VistA uses, VA FileMan, provides what is more accurately
| |
| − | characterized as a polymorphic view of the database. One can
| |
| − | readily use relational projections (indeed there are commercial
| |
| − | add-ons that give a strict SQL view of the database). The more
| |
| − | advantageous view through VA FileMan is more like an object view
| |
| − | of the data with abstract data types being highly specialized for
| |
| − | optimal use and performance. End users usually need not care
| |
| − | (except that performance of VA FileMan is demonstrably superior
| |
| − | (there are published reports) to SQL on the same hardware and
| |
| − | configuration.)
| |
| − |
| |
| − | Another difference is the way the data is stored. M data is stored
| |
| − | in b-trees, as compared to flat tables (I believe). This leads to
| |
| − | faster data acess, and less CPU power needed.
| |
| − |
| |
| − | Also, the database in M is called by some a "sparce array." This
| |
| − | means that there are no "blank spaces" left for data to be later
| |
| − | filled into. So with M, if there is no data present, then no space
| |
| − | is wasted. I find this to lead to many many fields being defined
| |
| − | for a given file. With a traditional database, having all these
| |
| − | fields with empty/wasted space, would lead to huge database files.
| |
| − | But with M, one can can store years of patient information on a
| |
| − | relatively small disk.
| |
| − | | |
| − | '''3) How hard is it for non-Mumps IT personnel to learn Mumps/VistA and are there enough experienced VistA programmers (or former VistA programmers) to consult or be hired to non-VA projects?'''
| |
| − | | |
| − | Learning MUMPS is as simple as learning BASIC. Learning about all
| |
| − | the utilities and capabilities of the common services in VistA is
| |
| − | a years long process. And learning the functionality and setup
| |
| − | for the clinical and administrative functions in VistA would
| |
| − | probably take several life-times. Are there enough experienced
| |
| − | programmers and application consultants? So far I believe you'll
| |
| − | currently pay more for a Java programmer.
| |
| − |
| |
| − | I am a physician and have taught myself M. It is a very simple
| |
| − | language. I consider it to be a scripting language. But it gets
| |
| − | the job done, and has run hospitals safely for decades.
| |
| − |
| |
| − | There are many people on the list that would like work as
| |
| − | programmers, so I don't think there will be any limitation there.
| |
| − | And when CMS releases VistAOffice, there should be even more
| |
| − | interest and consultants available.
| |
| − | | |
| − | [[Rick Marshall]] replies: | |
| − | | |
| − | It is easy to learn Standard MUMPS, but impossible to master VistA.
| |
| − | Like the art of medicine itself, VistA is complex beyond human
| |
| − | comprehension--no, I am not kidding or exaggerating--and no one person
| |
| − | will ever know it all anymore. I have been programming with VistA for
| |
| − | twenty-one years; there are a couple areas of the code I know better
| |
| − | than anyone, several I know as well as the other experts, and a dozen or
| |
| − | so I know reasonably well--out of 80-120 software packages, depending on
| |
| − | where you draw the lines. Most of VistA I know by its patterns and
| |
| − | common structures, and maybe a few basic architectural features per
| |
| − | package, but for most of VistA I am the wrong person to go to. There
| |
| − | are whole packages I know only by name, whose purpose I can only guess
| |
| − | at. So it is with all the VistA gurus. None of us pretends to know it
| |
| − | all or even most of it. We work together as a community, sharing out
| |
| − | the vast scope of work that is VistA among ourselves.
| |
| − | | |
| − | To address your central concern, our tradition is to grow our own new
| |
| − | Standard MUMPS and VistA programmers from among its users, because we
| |
| − | have discovered it is far easier to teach a nurse to program than to
| |
| − | teach a programmer to practice medicine; the nurse has already mastered
| |
| − | the difficult part. It takes mere minutes to start writing Standard
| |
| − | MUMPS code, as with any programming system worth discussing, but a day
| |
| − | or two to introduce the basics, a week or two to introduce them fully,
| |
| − | and a month or two to become fully comfortable with the programming
| |
| − | system. It takes experienced programmers longer to learn Standard
| |
| − | MUMPS, because it is not like most other programming systems, and they
| |
| − | spend years whining about it instead of buckling down and coming to
| |
| − | grips with it on its own terms. Learning Standard MUMPS is like taking
| |
| − | small steps over very deep crevices; it is easy but unnerving for some.
| |
| − | | |
| − | Learning to program with VistA takes longer, and should happen in two
| |
| − | phases. First the programmer needs to learn our programming standards
| |
| − | and conventions and common calls. Then the programmer needs to pick a
| |
| − | package and focus on it for a long time, moving from simple assignments
| |
| − | to more complex ones. It is best if the student began as a user of that
| |
| − | package, then graduated to being an application coordinator (a kind of
| |
| − | super-user) for it, before learning to program with it. Becoming an
| |
| − | expert user of any reasonably sophisticated VistA package takes years.
| |
| − | Once an application coordinator starts training to become an information
| |
| − | manager, starts working on supporting and extending a package at a site,
| |
| − | every year they keep at it improves their skills with the package
| |
| − | measurably. Those who have worked with a package for ten years or more
| |
| − | are easy to tell apart from those who have only been doing it a few years.
| |
| − | | |
| − | There is a lot more I could tell you about the expertise lifecycle, how
| |
| − | it is structured, where to find VistA experts and how to grow your own,
| |
| − | but I am trying to keep this postscript "short."
| |
| − | | |
| − | '''4) What other concerns should we have regarding adopting VistA?'''
| |
| − | | |
| − | Expect a long learning curve. Get help.
| |
| − |
| |
| − | I think a factor here is how much you want to put into the system.
| |
| − | It is not turn key at this point, although there are installers
| |
| − | who can do the work for you. It is not going to have all the
| |
| − | bells and whistles that commercial EMR's want you to pay for.
| |
| − | It is not currently integrated with a billing system or a system
| |
| − | for appointments.
| |
| − |
| |
| − | [[Matthew King]] adds:
| |
| − | On the other hand, a lot of the bell and whistles that seem to
| |
| − | exist in many commercial products are actually rudimentary or even
| |
| − | vaporware. VistA isn't as pretty, but is very functional, with
| |
| − | easily modified clinical and preventive care reminders,support for
| |
| − | disease management, advanced drug interaction checks and lexion
| |
| − | support. The CPRS module supports drag and drop template building.
| |
| − | This makes custom templates a snap, something you pay dearly for
| |
| − | in many commerical products. The experts say 1/3 of medical errors
| |
| − | can be reduced by intelligent software design. Since the VA
| |
| − | product exists for patients, not profits, it is designed for
| |
| − | clinical functionality and patient safety, so that is where it
| |
| − | shines. Most commercial products have recently added EHRs as an
| |
| − | afterthought in an emerging market. The bells and whistles look
| |
| − | slick, but don't necessarily add to patient safety.
| |
| − | | |
| − | [[Rick Marshall]] replies:
| |
| − | Above all, it is a serious commitment. It is free as in freedom, not
| |
| − | free beer. It will save lives, not time. You cannot do this alone; you
| |
| − | may think you can, but sooner or later you will run aground without
| |
| − | help. To succeed with VistA you need the community in ways you cannot
| |
| − | imagine, but the good news is they will welcome and help you, and it
| |
| − | will not be long before you can return the favor. The big hurdle with
| |
| − | VistA is that anyone used to making medical informatics decisions has
| |
| − | learned how to prepare for defeat, to choose vendors on the basis of how
| |
| − | deep their pockets are (so you can sue them when the project collapses
| |
| − | in failure) instead of on the basis of their expertise and customer
| |
| − | service, to choose based on marketing flair and reputation. VistA is
| |
| − | the real deal, and for that very reason may be difficult to recognize as
| |
| − | such by customers who have learned only how to choose among flashy
| |
| − | failures. VistA requires the "customer" to become a partner, a
| |
| − | collaborator, words that have all but lost their meaning in the modern
| |
| − | marketplace; when you become fully engaged with the VistA lifecycle, you
| |
| − | will come to understand that if VistA is broken it is your fault as much
| |
| − | as ours, that it is your responsibility to hold the developers and the
| |
| − | software to a high enough standard to meet your needs. Unlike with most
| |
| − | commercial software products, you will rewarded instead of punished for
| |
| − | engaging in the critique, review, and even development of VistA.
| |
| − | | |
| − | There is an endless amount to learn about it, and it is under continuous
| |
| − | development, continuously patched, continuously changing, as it must
| |
| − | be. The static details of VistA are less important than the living
| |
| − | process by which its users drive development through their continuous
| |
| − | stream of suggestions and complaints. You will not and cannot
| |
| − | appreciate how true that is until after you have been involved with
| |
| − | VistA for years. The secret to its success is no secret, not specific
| |
| − | features, nor the technology used. It is the dynamic, hyperactive
| |
| − | software lifecycle that engages the creativity of tens of thousands of
| |
| − | users to mold the software over and over so that the longer you wait the
| |
| − | better it gets, as opposed to most software which is static by design,
| |
| − | updated at best occasionally, and obsolesces with time.
| |
| − | | |
| − | That inversion of the norm, emphasizing change instead of stasis, is a
| |
| − | repudiation of the core beliefs of the software industry and much of
| |
| − | academia, and as such you must expect to hear an endless stream of
| |
| − | irrelevant complaints lodged against VistA, usually by those who have
| |
| − | not used it. From those who do use VistA, you will generally find an
| |
| − | endless stream of relevant complaints together with strong loyalty.
| |
| − | Like any experienced VistA professional, I can and will criticize VistA
| |
| − | up one side and down the other for hours on end. We like it in part
| |
| − | because we know its faults, and so we try to prioritize the work most
| |
| − | important to us; when the lifecycle is healthy, if something is broken
| |
| − | it's because we think it's more important for the developers to work on
| |
| − | something else first. Those who fully engage in the VistA lifecycle
| |
| − | know VistA's flaws far more intimately than its critics, but they know
| |
| − | its strengths, too, and they can point to features in the software that
| |
| − | they personally first brought to the attention of the VistA development
| |
| − | community. In a way most software will never be, VistA really does
| |
| − | belong to its users, and they know it.
| |
| − | | |
| − | So when I echo other writers in saying VistA is free as in freedom, I
| |
| − | mean as in the responsibility that comes with true freedom, the
| |
| − | expectation to interact with it as an adult, taking responsibility for
| |
| − | what we need from it, and helping to chart our own future. To be blunt,
| |
| − | many people do not want that, prefer the simplicity of having limited
| |
| − | choices imposed upon them by someone more powerful, to recreate the
| |
| − | false security of childhood. Others do not mind the responsibility, but
| |
| − | cannot spare the time to learn a fully featured medical informatics
| |
| − | system, not even just the few parts of the few packages they would use
| |
| − | in their medical roles. In general, we find the truth about VistA
| |
| − | properly screens our potential clients; the right people respond well to
| |
| − | the challenge and possibilities of VistA, and enrich the community and
| |
| − | its software when they engage with us.
| |
| − | | |
| − | PPS: If I sound opinionated in the above, it is because experience has
| |
| − | made me so. For the first half of my career with VistA, I thought it
| |
| − | was probably nothing special, that every hospital system must have
| |
| − | something comparable. My disgust with the state of the art and
| |
| − | appreciation for VistA has accumulated over the years through a series
| |
| − | of disillusioning exposures to how most medical software works--or
| |
| − | doesn't. I do not know if there is even one feature in VistA that it
| |
| − | does better than any other system, but no other system seems to be able
| |
| − | to combine them all into such an integrated architecture driven by such
| |
| − | a potentially responsive software lifecycle. The experience of patients
| |
| − | in New Orleans in the wake of Hurricane Katrina would seem to be the
| |
| − | latest dramatic illustration. I have gradually arrived at the
| |
| − | surprising conclusion that my friends and I are working on something
| |
| − | unusually cool. Who knew?
| |
