|
|
| (10 intermediate revisions by 6 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: |
| | | | |
| − | '''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.
| |
| | | | |
| − | '''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?]] |
| | | | |
| − | While MUMPS has been characterized as "hierarchical", the
| + | [[4) What other concerns should we have regarding adopting VistA?]] |
| − | 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?'''
| + | [[5) Are any Community Health Centers currently utilizing VistA?]] |
| − | | |
| − | 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.
| |
| − | '''
| |
| − | 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.
| |
