CHC Corner: Difference between revisions
From VistApedia
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
From: | From: [[Matthew King]] <mking@clinicaadelante.com> | ||
The Community Health Centers in AZ are forming the Arizona Integrated | The Community Health Centers in AZ are forming the Arizona Integrated | ||
| Line 6: | Line 6: | ||
VistA Office in our EHR evaluation. | VistA Office in our EHR evaluation. | ||
From: | From: [[John Leo Zimmer]] <jlzimmer@cbchc.com> | ||
The Council Bluffs Community Health Center is assembling the hardware | The Council Bluffs Community Health Center is assembling the hardware | ||
| Line 23: | Line 23: | ||
environment. There are far more limitations (and serious ones at | environment. There are far more limitations (and serious ones at | ||
that) in most other languages and especially strict SQL | that) in most other languages and especially strict SQL | ||
Absolutely not. I will go one step further than Cameron. | Absolutely not. I will go one step further than Cameron. | ||
I have heard that M is the #1 language used for EHR's. | I have heard that M is the #1 language used for EHR's. | ||
| Line 42: | Line 42: | ||
(there are published reports) to SQL on the same hardware and | (there are published reports) to SQL on the same hardware and | ||
configuration.) | configuration.) | ||
Another difference is the way the data is stored. M data is stored | 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 | in b-trees, as compared to flat tables (I believe). This leads to | ||
faster data acess, and less CPU power needed. | faster data acess, and less CPU power needed. | ||
Also, the database in M is called by some a "sparce array." This | 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 | means that there are no "blank spaces" left for data to be later | ||
| Line 65: | Line 65: | ||
programmers and application consultants? So far I believe you'll | programmers and application consultants? So far I believe you'll | ||
currently pay more for a Java programmer. | currently pay more for a Java programmer. | ||
I am a physician and have taught myself M. It is a very simple | 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 | language. I consider it to be a scripting language. But it gets | ||
the job done, and has run hospitals safely for decades. | the job done, and has run hospitals safely for decades. | ||
There are many people on the list that would like work as | There are many people on the list that would like work as | ||
programmers, so I don't think there will be any limitation there. | programmers, so I don't think there will be any limitation there. | ||
| Line 78: | Line 78: | ||
Expect a long learning curve. Get help. | Expect a long learning curve. Get help. | ||
I think a factor here is how much you want to put into the system. | 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 | It is not turn key at this point, although there are installers | ||
| Line 86: | Line 86: | ||
for appointments. | for appointments. | ||
[[Matthew King]] adds: | |||
On the other hand, a lot of the bell and whistles that seem to | On the other hand, a lot of the bell and whistles that seem to | ||
exist in many commercial products are actually rudimentary or even | exist in many commercial products are actually rudimentary or even | ||
Revision as of 14:09, 20 September 2005
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?
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.
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.
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.