Difference between revisions of "CHC Corner"

From VistApedia
Jump to: navigation, search
 
(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?
 

Latest revision as of 00:05, 7 July 2012

From: Matthew King <mking@clinicaadelante.com>

The Community Health Centers in AZ are forming the Arizona Integrated 
Network (AIN) to formally integrate information technology services, 
financial management, and clinical initiatives. We are have included 
VistA Office in our EHR evaluation.
From: John Leo Zimmer <jlzimmer@cbchc.com>

The Council Bluffs Community Health Center is assembling the hardware
and software to implement VistA Office or FOIA VistA in this one small
center. We hope to participate in an open development process that tailors
VistA to community health centers' special needs.

From Hardhats Listserve:

Here are some recurrent questions us nontechies have about VistA:

1) Is Mumps a serious limitation to complete EHR functionality, code maintainence, HL7, or PMS interfacing?

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?)

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?

4) What other concerns should we have regarding adopting VistA?

5) Are any Community Health Centers currently utilizing VistA?