ClearHealth project compiles VistA to MUMPS-LESS web interface.

152 views
Skip to first unread message

Fred Trotter

unread,
May 21, 2008, 11:08:33 PM5/21/08
to Hardhats
Today at TEPR, ClearHealth announced that they have a web-based
version of VistA working without MUMPS.

Apparently the strategy is to compile the MUMPS code to C, run it
through some extensive processing, and then it becomes available in a
fashion that can be called from php.

They are currently in beta in one hospital with this technology.

I know very little about it so I cannot field questions. For those who
are very interested, take a look at this post on the ClearHealth
forums:

http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105

I am sure they might field questions from you on that same forum.

Interesting times :)

-FT
--
Fred Trotter
http://www.fredtrotter.com

Joseph Dal Molin

unread,
May 21, 2008, 11:33:06 PM5/21/08
to Hard...@googlegroups.com
....what some people will do to avoid learning a new programing language
is simply awe inspiring :-)


J

Joseph Dal Molin

unread,
May 21, 2008, 11:39:31 PM5/21/08
to Hard...@googlegroups.com
I posted a request for some screenshots on the Clearhealth forum...

J.

> .
>

Nancy Anthracite

unread,
May 21, 2008, 11:51:27 PM5/21/08
to Hard...@googlegroups.com
Patching it may be a very interesting exercise.

--
Nancy Anthracite

Chris Richardson

unread,
May 22, 2008, 6:05:53 AM5/22/08
to Hard...@googlegroups.com
And does the database scale when there are a bunch of users on?

Roger A. Maduro

unread,
May 22, 2008, 8:28:04 AM5/22/08
to Hard...@googlegroups.com
My understanding is that it is a replacement for CPRS, not VistA. It
should have the same functionality as CPRS but running on a browser. I
don't any of the MUMPS code is changed.

Roger

rtweed

unread,
May 22, 2008, 8:37:09 AM5/22/08
to Hardhats
Now if Mumps had someone fashionable like Google using it, everyone
would want to learn it instead of junking it. A lot of people will be
busy quite happily learning Python right now, simply because Google's
App Engine requires it. Turn a Google or Yahoo onto the wonders of
Mumps and globals and the tide would turn for sure. Will it happen?
Probably not.

In the meantime, all you can do is be safe in the knowledge that most
of these efforts have been ultimately doomed to failure for one reason
or another. The amazing thing is that nobody ever thinks to do any
research into the many high profile casualties there have been over
the years, or consider the untold millions (or is that billions?) that
have been poured down the "replace mumps at any cost" toilet. Why
should their efforts be successful in the light of such grim evidence?

Shrug your shoulders, smile sweetly and give a knowing sigh...

Chris Richardson

unread,
May 22, 2008, 10:37:39 AM5/22/08
to Hard...@googlegroups.com
Roger;

That is not what they said. They said " a web-based version of VistA
working without MUMPS" and "the strategy is to compile the MUMPS code to C,

run it through some extensive processing, and then it becomes available in a

fashion that can be called from php." I believe that both GTM and Cache can
work with PHP just fine without having to be converted to "C". I would love
to see their data model and watch their performance stats. I have a pretty
good idea what those will look like. If they wanted to say that they were
just replacing CPRS, then they should say so. If they didn't replace CPRS,
they could still claim that CPRS runs without MUMPS right now (as long as
you don't expect any data to come with it). If I am not mistaken, GT.M is
already written in "C" or some other compiler and pretty well optimized for
the data handling model. Re-inventing MUMPS in C would be a trick, getting
scalability and performance would be a miracle. Say you could (by some
miracle), what would you be loosing? Access to the source code (it is all a
black box and the end user is kept at arms length from verifying the
operation of the code). The user is at the mercy of the vendor once again.
Is this a good thing? I don't think so. Where is the good here?

Interesting, but is it really necessary? What is wrong with MUMPS? I
have heard of such efforts to replace MUMPS for over 20 years. If all of
this effort to replace MUMPS was so easy, it would have been done already.
It isn't a matter of money, the DoD and the VA have spent gobs of money to
replace it. What is keeping them?

Joseph Dal Molin

unread,
May 22, 2008, 11:35:14 AM5/22/08
to Hard...@googlegroups.com
It's billions. The health IT world needs to start practicing evidence
based medicine and realize that the opportunity cost of chasing the next
software fad in health systems is measured in lives.

Joseph

> .
>

Roger A. Maduro

unread,
May 22, 2008, 12:14:32 PM5/22/08
to Hard...@googlegroups.com
Chris,

As I said, I've head some extensive discussions with the Clear Health
guys on this. They took at look at CAV Systems' MJSP
<http://mjsp.sourceforge.net/>. This is an open source toolset that
can be used to create rich HTML clients that can run on top of Mumps
applications. MJSP has been used by CAV Systems to create some
beautiful browser-based web apps for Mumps applications. I have seen
these demoed and seen the CAV guys write HTML code for the base Mumps
app on the fly. It's impressive. CAV Systems' code however (for the
web piece) is J2EE. You can read the sourceforge documentation to get
the details.

ClearHealth has been doing all their browser work using PHP. Thus they
either used the MJSP code that connects to Mumps to connect to the RPC
broker or developed similar code using MJSP as the model (I am still
not clear). Then they used PHP to render the web front end. What the
Clear Health people told me is that they have not touched the Mumps
code, so I don't know where that part comes from.

The idea here is to replace the Delphi code behind CPRS with an
Ajax/Web 2.0 framework.

At this point, I would say that David Uhlman or some of the Clear
Health guys will hopefully provide some more details. I think this is
a very significant development and hope that they continue working on
it.

Roger

st...@stevenowen.com

unread,
May 22, 2008, 12:59:11 PM5/22/08
to Hard...@googlegroups.com
I think they are taking the right approach by developing a rich browser
client as the next generation CPRS. That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform. Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver. Plus, it has custom tags
to make use of javascript toolkits like extJS.

Yeah, very cool stuff this web 2.0

Chris Richardson

unread,
May 22, 2008, 1:46:42 PM5/22/08
to Hard...@googlegroups.com
Steve;

I'm not at odds at all with rehosting CPRS as a thin client. The
coordination of the clients with the server is a major headache in the
field. The webification of VistA is the logical extension of the
technology, but if you read the statements being made, that was not at all
clear from their words. MUMPS never was to run on the client, but it is
very difficult to run CPRS without VistA and the RPC interface (or weblink
or any of the other technologies being brought forward) on the server.

I can't tell you the number of times I have seen people say, "CPRS is
great, but now if we could just get rid of that darned VistA" without
knowning that the power of the rendition of CPRS or a web interface is still
the VistA-MUMPS back end service. BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.

Maury Pepper

unread,
May 22, 2008, 2:12:33 PM5/22/08
to Hard...@googlegroups.com
I'm not sure what others have seen. All I could find was this slide show at:
www.clear-health.com/download/tepr-2008.pdf

One slide contains this summary:

● Web Based CPRS
● Possible Web Based ViewCentric
● Proven System, Excellent Record
● Ease of Web Based Systems,
especially over M stack
● End-to-end system with
scheduling and billing
● Inpatient or ambulatory
Compatible with CH Advantage
● M/CACHE to PHP/MySQL & C,
Modern Technology
● Compatible with HealthCloud

I don't know how to interpret the next to last point which refers to M/CACHE.

Roger mentioned CAV Systems and their Java library. They also have a product (not open source) called JUMPS which will convert MUMPS to Java + SQL. Perhaps ClearHealth has used this or considered using it.

st...@stevenowen.com

unread,
May 22, 2008, 2:17:34 PM5/22/08
to Hard...@googlegroups.com
Ah, now I see that Fred mentioned something about re-compling mumps code to
C...that seems a bit odd if they can access the mumps backend via MJSP

david...@gmail.com

unread,
May 22, 2008, 3:27:24 PM5/22/08
to Hardhats
I wanted to weight in here so that there can be some on-record
discussion coming from us directly. I do not in any way want to offer
a general commentary on why some people want to use MUMPS or don't
want to, or X language is better than Y, I am not looking to instigate
a flame war or really say that what we are doing is a better or worse
approach from a technical standpoint than anything else. It is the
right approach for us. Additionally I need to make clear that this is
a preliminary announcement, we have moved beyond proof of concept but
there is still a lot to be done. We now have 2 beta sites we will be
rolling out over the course of the next 12-18 months while actively
seeking 1 or more additional sites.

What we are doing:
*Implementing a CPRS-like web based interface
*Breaking a live VistA server into static libraries and components
that can be utilized outside of a running GT.M instance or at-least a
continuously running instance
*Extracting datasets and so forth tied up in CACHE to be accessible in
other things including MySQL
*Integrating features that based on our market aren't present or are
underrepresented in a VistA/WorldVistA/etc installation with regard to
scheduling and X12 electronic billing.
*Enabling a lot of interfaces and integration points so that both data
and logic, that from our standpoint were difficult to work with in
VistA, are accessible using things like a PHP module and web services.
*The entirety of what we are going will be licensed under a feasible
combination of GPL and LGPL

What we aren't doing:
*Saying the M/Mumps/WorldVistA etc is good, bad or otherwise
*Saying we have a completed production ready system right now
*Saying it is trivial to get from where we are now to a completed
production system
*Building a web based front-end that uses RPC/etc to talk to a VistA
server

With respect to understanding the industry and the history of VistA we
aren't novices here, we are by most measure the largest open source
healthcare solution in patients, sites and dollars in the US. We
understand the engineering challenges. We understand that in the past
people have tried various other strategies and have failed. I am happy
to have fruitful discourse about what we are doing, I am not
interested in having a zealous back and forth about why we should or
shouldn't be doing this. If you disagree with our approach or think we
are crazy for x,y, or z that is absolutely your right and noted for
the record.

With regard to the "doomed to fail" comments, we are not naive and
have been doing complicated difficult things with Open Source with a
combined experience amongst are staff of more than 100 years. People
are welcome to their opinion but I think if you look at the life of
virtually any large open source project today it arose from a
situation where a lot of people said "doomed to fail". Linux, Apache,
MySQL, and PHP as well as many others have all, at times, had that
comment made about them and they now represent the most popular system
for each of their respective markets .

Our analysis of the market indicated that there were a lot of
institutions interested in VistA based solutions that for a variety of
practical reasons had difficulties integrating with the current
architecture, making customizations to the current architecture or
addressing needs in a different way than the current architecture can
reasonably provide for, that is our motivation for doing what we are
doing.

I expect that the first open source licensed code bundle we will be
releasing is still several weeks away. As the discussion indicated
there are a lot of technical challenges to what we are doing and we
want to first release to be reasonably accessible with regard to its
ease in compiling and getting running a basic version of the WebVistA
system. We do have some screenshots and such we will be releasing as
time permits.

I hope this clarify to some extent where we are and I am happy to
response to any inquiries beyond that. Thanks.

-David Uhlman
Customer Happiness Guru & CEO
ClearHealth Inc.

K.S. Bhaskar

unread,
May 22, 2008, 4:16:26 PM5/22/08
to Hardhats
Thanks, David. I am curious about your server side technology. Did
you use Kevin O'Kane's MUMPS to C translator to translate VistA to C?
Anything you can say to explain your server side technology would be
appreciated.

Regards
-- Bhaskar

On May 22, 3:27 pm, daviduhl...@gmail.com wrote:
> I wanted to weight in here so that there can be some on-record
> discussion coming from us directly. I do not in any way want to offer
> a general commentary on why some people want to use MUMPS or don't
> want to, or X language is better than Y, I am not looking to instigate
> a flame war or really say that what we are doing is a better or worse
> approach from a technical standpoint than anything else. It is the
> right approach for us. Additionally I need to make clear that this is
> a preliminary announcement, we have moved beyond proof of concept but
> there is still a lot to be done. We now have 2 beta sites we will be
> rolling out over the course of the next 12-18 months while actively
> seeking 1 or more additional sites.

[KSB] <...snip...>

Jim Self

unread,
May 22, 2008, 10:01:51 PM5/22/08
to Hard...@googlegroups.com
Chris Richardson wrote:
BTW, the idea of running VistA from the
web is not new, Jim Self and his folks at UC Davis have accomplished this
about 15 or more years ago.
  
Thanks for the mention, Chris.
  I think we clearly showed *how* it could be done about that long ago with a web interface to our own system (VMACS, for veterinary medicine) and some general tools and demo applications showing some of the possibilities for general M-to-Web applications, including high-level data to table generation in HTML, Javascript, and later XML.

More recent are some tools for generating and processing AJAX data entry forms tied to Fileman API's and data definitions. There is also an initial implementation of a functional menu interface for the VistA Options file.
-- 

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------

Jim Self

unread,
May 22, 2008, 10:44:10 PM5/22/08
to Hard...@googlegroups.com
st...@stevenowen.com wrote:
I think they are taking the right approach by developing a rich browser
client as the next generation CPRS.
I agree that development of a web based CPRS replacement would be a good project. I wish I had (more) time to work on it myself. I have a demo of most of the functionality required for building it. (See the links below)

That's why I'm putting together a
developer's virtual machine based on M/gateway's Enterprise Web Developer
platform.   Write your methods on the mumps side, compile the php pages on
the mumps side, and output them to your webserver.
I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't gone very far with that yet. When I last tried, there were some issues with getting the appliance to load in Parallels on my Mac.)

What advantages do you see in generating dynamic HTML, Javascript, etc for VistA from php instead of doing it from mumps?

Or might you be doing both? That might be relatively easy with EWD and/or M2Web?

Plus, it has custom tags
to make use of javascript toolkits like extJS.
  

Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few links from google comparing them but all from before Dojo 1.0.

I built some preliminary M2Web tools a while back for generating and processing Dojo based data entry forms for VistA from Fileman data definitions and API's. These can be used to make applications with very little source code.

Unfortunately the version I started with (Dojo 0.43) lacked some of the functionality I would like to see in a full scale data interface and upgrading to the current version (1.1) requires significant re-learning and re-programming. Their data API's and data enabled widgets have changed greatly between versions.

Yeah, very cool stuff this web 2.0

  
I agree. There seem to be many ways to go about developing it. So much to learn and so little spare time to do it in...

Still there must be some commonality in the different approaches...

If you keep a blog reporting your progress and problems along the way (and/or report it to hardhats) it might help to illuminate the way for you as well as others.

rtweed

unread,
May 23, 2008, 5:08:54 AM5/23/08
to Hardhats
Jim

> I agree that EWD seems worth investigating. (Sorry, Rob, but I haven't
> gone very far with that yet. When I last tried, there were some issues
> with getting the appliance to load in Parallels on my Mac.)

No problem. You might want to try the latest Virtual Appliance. The
network driver it uses seems much more reliable


> What advantages do you see in generating dynamic HTML, Javascript, etc
> for VistA from php instead of doing it from mumps?

The philosophy of EWD is that it doesn't and shouldn't matter where
the actual markup, Javascript etc is being served up from. It
abstracts that away from you so it's largely irrelevant.

The real advantage of EWD is that it makes the task manageable and
scalable. With increasingly complex UI functionality becoming
possible with the latest generations of Javascript-based widgets from
the likes of Yahoo, Dojo, ExtJS etc, the pages you have to serve up
become increasingly complex to write and (critically) to maintain.
That's where EWD's Ajax framework comes in - it simplifies how you
conceptually design your pages, and also where the custom tags come
in, because they can simplify the complex JSON-structured Javascript
coding required for these widgets down to a bunch of simple to use and
simple to understand XML tags. Witness the EWD/ExtJS desktop which
you can get working with just 2 custom tags: see
http://gradvs1.mgateway.com/download/extjs4.0.684.pdf, page 34.

A separate question is whether EWD could be made to work with GT.M
without the need for PHP. The model there would be akin to WebLink
and Cache. That's something I'm currently pondering. However, as
people who use EWD with Cache know, there would be no difference
within your EWD pages: whether and how an EWD application runs with
PHP, CSP, JSP or WebLink is handled by EWD's compiler and makes no
difference to the developer.

>
> Or might you be doing both? That might be relatively easy with EWD
> and/or M2Web?
>
> > Plus, it has custom tags
> > to make use of javascript toolkits like extJS.
>
> Please compare extJS with Dojo? (http://dojotoolkit.org) I found a few
> links from google comparing them but all from before Dojo 1.0.
>

Opinions may vary but my view is that ExtJS has become the leader and
everyone else is now playing catch-up with them. The latest ExtJS
widget library is nothing short of stunning and unbelievably
sophisticated. From what I've seen of the current CPRS interface,
there's not one bit of functionality that couldn't be done using ExtJS
widgets. The problem is that it would involve some very complex use
of the ExtJS widgets, but the good news is that EWD would make it do-
able and maintainable.

I'm afraid that the days of the hacked-together MUMPS routine to
generate web pages are out the window when you're into this level of
UI sophistication. You need a tailor-made toolset to make it
practical, manageable and maintainable and avoid going insane!


> I built some preliminary M2Web tools a while back for generating and
> processing Dojo based data entry forms for VistA from Fileman data
> definitions and API's. These can be used to make applications with very
> little source code.
>

One of the problems is not that any one bit of coding is particularly
complex, it's that if you attempt to emulate something like the CPRS
interface, you end up with so much stuff to write, manage and
maintain. You need automation tools like EWD to allow you to
conceptually simplify the process and allow you to crank out the
pages. And of course you need to maintain state and security, all
stuff done automatically for you by EWD so that burden is relieved
also.

> Unfortunately the version I started with (Dojo 0.43) lacked some of the
> functionality I would like to see in a full scale data interface and
> upgrading to the current version (1.1) requires significant re-learning
> and re-programming. Their data API's and data enabled widgets have
> changed greatly between versions.

I think it's safe to say that the Javascript widget world is advancing
at a blistering pace. One more reason for custom tags: to abstract
the physical implementation so the underlying code can be kept up to
date with the widget libraries whilst their use in your pages can
remain relatively constant.


> Yeah, very cool stuff this web 2.0
>
> I agree. There seem to be many ways to go about developing it. So much
> to learn and so little spare time to do it in...


...so anything that can make lighter work of it has got to be a good
idea, right?


>
> Still there must be some commonality in the different approaches...
>

> If you keep a blog reporting your progress and problems along the way
> (and/or report it to hardhats) it might help to illuminate the way for
> you as well as others.

I know that Steve is doing some great pioneering work with EWD, ExtJS
and Vista, so I too am looking forward to what he'll be able to
demonstrate in the hopefully not too distant future

Rob

Fred Trotter

unread,
May 23, 2008, 4:45:52 PM5/23/08
to Hard...@googlegroups.com
Chris,
Remember that this is completely second hand information.
I have neither seen the code, the process, nor the interface. I am
just parroting what was said in the talk at TEPR and I could easily be
wrong. I think it is pretty relevant that Roger has been talking to
the same people and has a very different technical summary. I would
assume that my 10000 foot summary turns out to be pretty off base. The
only reason I indicated that it was not just a CPRS replacement was
that I understand that David either has the pharmacy stuff working or
believes that he will be able to get it working.

As with anyone who has even a passing familiarlity with
MUMPS, I appropriately dubious. However I have seen David do some
amazing things with PHP, and I while he may sometimes be
overconfident, I have never known him to completely BS. So I am very
interested to see what they have. I just wanted you to know that I do
not actually know what they have... so make sure you do not rely on my
understanding too much.

On Thu, May 22, 2008 at 9:37 AM, Chris Richardson <r...@rcresearch.us> wrote:
>
> Roger;
>
> That is not what they said. They said " a web-based version of VistA
> working without MUMPS" and "the strategy is to compile the MUMPS code to C,
> run it through some extensive processing, and then it becomes available in a
> fashion that can be called from php." I believe that both GTM and Cache can
> work with PHP just fine without having to be converted to "C". I would love
> to see their data model and watch their performance stats. I have a pretty
> good idea what those will look like. If they wanted to say that they were
> just replacing CPRS, then they should say so. If they didn't replace CPRS,
> they could still claim that CPRS runs without MUMPS right now (as long as
> you don't expect any data to come with it). If I am not mistaken, GT.M is
> already written in "C" or some other compiler and pretty well optimized for
> the data handling model. Re-inventing MUMPS in C would be a trick, getting
> scalability and performance would be a miracle. Say you could (by some
> miracle), what would you be loosing? Access to the source code (it is all a
> black box and the end user is kept at arms length from verifying the
> operation of the code). The user is at the mercy of the vendor once again.
> Is this a good thing? I don't think so. Where is the good here?
>
> Interesting, but is it really necessary? What is wrong with MUMPS? I
> have heard of such efforts to replace MUMPS for over 20 years. If all of
> this effort to replace MUMPS was so easy, it would have been done already.
> It isn't a matter of money, the DoD and the VA have spent gobs of money to
> replace it. What is keeping them?
>
>

--
Fred Trotter
http://www.fredtrotter.com

George Timson

unread,
May 23, 2008, 5:16:00 PM5/23/08
to Hardhats
One of the challenges in replacing a MUMPS system is that MUMPS code
writes more MUMPS code and XECUTEs it on the fly. MUMPS really is the
"X language", to use Mr. Uhlman 's term. :-)

FileMan uses XECUTE all over the place. To be able to run a FileMan
report "outside a continuously running instance", how would the XECUTE
command be handled?

--George Timson

Chris Richardson

unread,
May 23, 2008, 11:23:35 PM5/23/08
to Hard...@googlegroups.com
Fred;

I am not trying to shoot the messenger, just find out where the reality
ends and the FUD begins. Yes, this is interesting work, and I have seen
many attempts at replacing MUMPS with compiled code on multiple occassions,
but why? Why is there all of this effort to replace one tool which was way
ahead of its time? Does VistA need to be re-writen, sure, but why not use
what we have and what works rather than build a compiled monstrosity that
you may or may not get the source code for. Where is the advantage? Lets
use what works, has worked, and has proven to be scalable beyond many of the
other environments that are being proped up to try to replace it, and only
coming in a poor second in nearly every case. I have seen no other system
out there that can hold and manage more than 30 years of patient history
like VistA can (the major exception is Octo Barnetts' model at Beth Israel
Hospital in Boston, but that is a MUMPS model as well. MUMPS must be doing
something right.


----- Original Message -----
From: "Fred Trotter" <fred.t...@gmail.com>
To: <Hard...@googlegroups.com>
Sent: Friday, May 23, 2008 1:45 PM
Subject: [Hardhats] Re: ClearHealth project compiles VistA to MUMPS-LESS web
interface.


>

Aylesworth, Marc CTR USAF AFMC AFRL/RISE

unread,
May 27, 2008, 9:20:21 AM5/27/08
to Hard...@googlegroups.com
Doesn't GTM compile Mumps down to .o files and then only check to make sure the source is older than the compiled code to make it faster.

Marc Aylesworth

RRC C3I Grooup
525 Brooks Road
Rome, NY 13440
PH: 315-330-2422

________________________________

http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105

Interesting times :)

-FT
--
Fred Trotter
http://www.fredtrotter.com <http://www.fredtrotter.com/>


winmail.dat

Maury Pepper

unread,
May 27, 2008, 10:33:20 AM5/27/08
to Hard...@googlegroups.com
Yes, but it dynamically invokes the compiler for any indirection or Xecute. It is not "MUMPS-LESS". (BTW, Cache, DSM and MSM all compile the source into p-code and the resulting execution is not much different than GT.M's threaded code.)

kdt...@gmail.com

unread,
May 27, 2008, 12:46:37 PM5/27/08
to Hardhats
Seems like there is already program that takes M code and converts it
to standard object files, and is callable by php.

It's called GTM.

Kevin

Fred Trotter

unread,
May 27, 2008, 2:13:39 PM5/27/08
to Hard...@googlegroups.com
I looked into that code briefly, but it does not work with php 5

Generally that makes it a non-starter.

kdt...@gmail.com

unread,
May 27, 2008, 6:07:57 PM5/27/08
to Hardhats
I guess I should let Bhaskar comment, but GTM has an interface for
call in from other languages. For example, someone has written an
interface form perl to GTM. So if php 5 is not able to connect to
another program written in c that has predefined channels for such a
connection (such as GTM), then I would see that as a limitation of
php.

I suspect that it is doable, but there just hasn't been a need for it,
so the channel has not yet been created.

Kevin

kdt...@gmail.com

unread,
May 27, 2008, 6:12:09 PM5/27/08
to Hardhats

kdt...@gmail.com

unread,
May 27, 2008, 6:24:49 PM5/27/08
to Hardhats
This has perked my interest (read: more fun to research this than to
finish office charts...)

According to this link:
http://www.php.net/manual/en/intro.pdo.php
There would need to be a database driver written for GT.M

This is a list of databases already having a driver established.

The following drivers currently implement the PDO interface:
Driver name Supported databases
PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase
PDO_FIREBIRD Firebird/Interbase 6
PDO_IBM IBM DB2
PDO_INFORMIX IBM Informix Dynamic Server
PDO_MYSQL MySQL 3.x/4.x/5.x
PDO_OCI Oracle Call Interface
PDO_ODBC ODBC v3 (IBM DB2, unixODBC and win32 ODBC)
PDO_PGSQL PostgreSQL
PDO_SQLITE SQLite 3 and SQLite 2

So a connection is theoretically possible, but not currently ready to
go. I would guess that the interface would need to talk SQL, so one
would have to include a GT.M SQL engine as well....

Sigh, it's hard when it seems that 98% of the rest of the world talks
a different language...

Kevin




On May 27, 6:07 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:

rtweed

unread,
May 27, 2008, 6:42:32 PM5/27/08
to Hardhats
Our MGWSI gateway (http://gradvs1.mgateway.com/main/index.html?
path=mgwsiMenu) provides a connection between GT.M and:

- PHP (all versions)
- Java Server Pages
- ASP.Net

Our latest version, due for release soon, adds Python and Ruby to the
list.

In all cases MGWSI allows you to access a GT.M system from within any
of these environments, to access and manipulate globals and/or to
invoke routines/functions and send/receive data.

It's free too!

Rob

kdt...@gmail.com

unread,
May 27, 2008, 7:23:06 PM5/27/08
to Hardhats
Wow! That's great!

Does it doe the interface via one of the PDO type drivers mentioned in
my prior post? Can you elaborate a bit on the technology? How is it
set up? I don't operate much in PHP etc, so don't know the details.

I guess with this the LAMP stack could be:
L - Linux
A - Apache
M - MUMPS :-)
P - PHP

Kevin

edsalvador

unread,
May 27, 2008, 9:11:05 PM5/27/08
to Hardhats
I do not think this is a matter of learning a new programming
language.
I think it is a matter of Vista gaining traction in the physician
practice community. You can knock the current commercial EMR
applications all you want, however, they have anywhere from hundreds
to thousands of users.
How many does Vista have? What is being done by WorldVista to gain
market share?
When you can solve this issue, the point will be moot.

Ed

On May 21, 10:33 pm, Joseph Dal Molin <dalmo...@e-cology.ca> wrote:
> ....what some people will do to avoid learning a new programing language
> is simply awe inspiring :-)
>
> J
>
>
>
> Fred Trotter wrote:
> > Today at TEPR, ClearHealth announced that they have a web-based
> > version of VistA working without MUMPS.
>
> > Apparently the strategy is to compile the MUMPS code to C, run it
> > through some extensive processing, and then it becomes available in a
> > fashion that can be called from php.
>
> > They are currently in beta in one hospital with this technology.
>
> > I know very little about it so I cannot field questions. For those who
> > are very interested, take a look at this post on the ClearHealth
> > forums:
>
> >http://www.clear-health.com/forum/index.php?t=rview&goto=3105#msg_3105
>
> > I am sure they might field questions from you on that same forum.
>
> > Interesting times :)
>
> > -FT- Hide quoted text -
>
> - Show quoted text -

K.S. Bhaskar

unread,
May 27, 2008, 9:44:35 PM5/27/08
to Hardhats
If you really want a PHP 5 interface to GT.M, Fred, I'm curious why
porting a few older PHP modules to PHP 5 is a show-stopping obstacle?
I know people who saw how small http://downloads.sourceforge.net/fis-gtm/phpgtcm.tar.gz
is, read it and then wrote their own Java interface to GT.M.

In any case, you can also use PIP (http://www.fis-pip.com &
http://sourceforge.net/projects/pip) to get FOSS JDBC/SQL access to an
M/Fileman database, but that may be more work.

Also, as Rob points out, the M Gateway code (which is really cool)
provides another great free (don't know if it is Free) way to access M/
Fileman data.

I fully understand if you are stymied by lack of interest - let's not
forget that MUMPS is infectious! 8-)- - lack of funding, lack of
enthusiasm, etc., but you shouldn't be stymied by a lack of
technology.

Regards
-- Bhaskar

K.S. Bhaskar

unread,
May 27, 2008, 9:56:24 PM5/27/08
to Hardhats
Good point, Ed.

For the last three months WorldVistA EHR has been downloaded from
Source Forge at the rate of around 1400 downloads/month and last week
was at 98.38 percentile of all projects by activity at Source Forge.
The WorldVistA project (mostly FOIA VistA flavors) was at 96.83
percentile last week and has been averaging around 700 downloads/month
for the last three months.

GT.M (independent of activity and downloads bundled with VistA) was at
98.73 percentile last week, and has been averaging 600 downloads/month
over the last three months.

So, you're probably right - it's a dying application on a technology
that's about to go belly up. Time to move on to something else...
any decade now.

-- Bhaskar

Fred Trotter

unread,
May 27, 2008, 9:56:49 PM5/27/08
to Hard...@googlegroups.com
If I had the bandwidth to work on something here, it would be a python
to GTM bridge. From what I can tell python has many of the same
web-enabled benefits of php, with stricter OOP.

Again, it is really an issue of what is doable and what I personally
have the bandwidth for.

edsalvador

unread,
May 27, 2008, 11:32:35 PM5/27/08
to Hardhats
Bhaskar,
Download stats are meaningless unless physicians actually use the
application.
Where are the real-world stats?

Ed

I agree that the applications has potential.
However, like someone told me:
Sh*t in one hand and wish in the other. See which one gets filled-up
faster.
> > Ed- Hide quoted text -

rtweed

unread,
May 28, 2008, 2:49:25 AM5/28/08