Difference between revisions of "1) Is Mumps a serious limitation to complete EHR functionality, code maintainence, HL7, or PMS interfacing?"

From VistApedia
Jump to: navigation, search
 
Line 1: Line 1:
 
'''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,
 +
      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:
 +
 +
How many completely functional EHRs can you name that are not written in
 +
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
 +
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?

Revision as of 00:24, 21 September 2005

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, 
     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:

How many completely functional EHRs can you name that are not written in 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 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?

Retrieved from "https://vistapedia.com/index.php?title=1)_Is_Mumps_a_serious_limitation_to_complete_EHR_functionality,_code_maintainence,_HL7,_or_PMS_interfacing%3F&oldid=932"