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
I am sure they might field questions from you on that same forum.
Interesting times :)
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?
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
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
Yeah, very cool stuff this web 2.0
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.
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,
● 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.
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.
-- --------------------------------------- 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/) ---------------------------------------
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.
Yeah, very cool stuff this web 2.0
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:
> 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?
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
----- Original Message -----
From: "Fred Trotter" <fred.t...@gmail.com>
Sent: Friday, May 23, 2008 1:45 PM
Subject: [Hardhats] Re: ClearHealth project compiles VistA to MUMPS-LESS web
Interesting times :)
Generally that makes it a non-starter.
Again, it is really an issue of what is doable and what I personally
have the bandwidth for.
This is, in my view, exactly what is needed for php <-> GTM
integration and could be a real game-changer. However there is a
licensing issue. I see no sourcecode download from your site, and I
see no mention of a specific license. I am also unsure of how you can
create a php module that links into GTM without complying with the GPL
license that GTM (linux version) comes with.
What is the license of your code. Would you consider releasing it under the GPL?
It seems like going open source is a pretty obvious choice for you.
The "GTM community" are attracted to GTM because of its license. Using
GTM, GNU/Linux and either WorldVistA or, now Medsphere OpenVistA, we
can have a complete FOSS stack. There is no way that we would consider
working with a project that messes that up. So if you are actually
interested in serious adoption by that part of the VistA commuity, it
will not happen without a license change.
This is true for many software companies, including Intersystems and
DSS. The difference is that I do not see how you are making any money
from your software. You are already doing a services model, so I do
not see how you would be impacted by this negatively at all.
If you release your code you stand to become a central component in
the "webifcation of VistA" effort. As the ClearHealth efforts
demonstrate, that is going to happen one way or another. The only
question is with what particular solution?
There is also no reason that you would need to open source everything.
You could keep your cache module proprietary. GTM actually does this
with its non-Linux binaries, (or it used to) and that is totally
I just did not understand what architecture they were
using. They are quite right to do it the way they are doing it, but
they really are leveraging the ASP loophole alot. They are actually
doing the integration with GTM, in a GPL script, that exposes a TCP/IP
interface to the same calls. In fact this design is the reason the
AGPL was created.
If Bhaskar decided to only allow GPL GTM downloads with "club
memberships" that cost $100 a year, I would still consider it a better
investment to spend two months learning MUMPS, and pay for GTM to get
That still seems like a better investment than spending 0 dollars and
10 minutes looking at a free download.
I write a website about just this issue GPLMedicine.org
In answer to your question: I always look at Trojan horses "in the
mouth" < because mixing metaphors is fun :)
Nope. I just disagree with you.
> it's hard to even give stuff away these days without people being
> suspicious. Timeo Daneos et donna ferentis.
I enjoy communities that regularly quote latin. :)
> We only make our money from support and consulting, not directly from
> our software. Although my time is not costless either, I've
> nevertheless invested a huge amount of it into creating sufficient
> documentation, examples, self-training information, pre-built virtual
> appliances etc into making it possible for someone who is willing to
> invest a small amount of their time to be able to use our products
> without any further direct assistance from us.
So far so good.
> Purchasing support or consulting from us is not a requirement of using
> our products - nowhere is that stated or implied on our web site.
> Purchasing support and consulting from us is simply an option.
I have no problem with you getting paid. So my concern is not, and
will never be, that you make money on the deal. Unless you making
money by trapping people with your software.
I have suggested to Bhaskar many times before that he should be more
aggressive about the "freeloader" problem. I am pleased to see the
32/64 bit divide, that is a great line in the sand for paid/unpaid
Someday I will write an article about this too, but people who
download and use software for free, without contributing anything
back, I feel are little more than leeches on the community.
> work on the basis that ultimately a proportion of our user base will
> eventually require the very high quality and responsive support and
> consulting advice for which we're renowned and upon which we've built
> our business and reputation.
Or they will require a change to your software. A change that only you
can make because only you have the sourcecode. This is the problem.
Your business model is support *but only you can provide it*. So this
is about control. You have it. Your users do not.
> Our business model works and we make
> what I believe to be an extremely honest living by supporting those
> who ask us to support them.
Alot of people take my criticism as an attack on them personally,
which is unfortunate. I am really trying to talk about the problems
with the model itself.
Consider a Casino. The manager is an honest hard working guy. He works
his shift and takes home the "bacon" to his wife and kids. I do not
have a problem with him.
The Casino itself is also "honest". They tell you what your odds are
upfront. So you know that if you put a dollar in you know that you are
going to get 60 cents (or whatever) back.
But just because everyone involved is honest, does not mean that the
fundamental business is morally OK. I am obviously not interested in
getting into a debate about casinos, or whether gambling is immoral,
but rather to note that there are other industries where "the morals
around the model" are the debate, rather than the morals of a
particular person in the model.
The moral issue in gambling is that our brains are poorly wired to do
the math that makes it apparent that gambling is typically a bad idea.
The moral issue here is that software, especially medical software,
always needs to be changed. Only a proprietary vendor can change the
software. Because you are an honest hardworking guy, there is no
change in your foreseeable future that would cause you fall down on
the job and not make a change that was required. But then, no one
really "forsees" their own death, or the bankruptcy/buyout of the
company that they worked to build. Further, these events WILL happen.
When they do, those relying on your software will not be able to make
the changes they require. In other industries, the resulting migration
is measures in dollars and cents. In medical software, the resulting
migration could be paid with human suffering.
> If someone uses our products and never
> contacts us, our attitude is good luck to you and we're glad if our
> software's made a difference.
You should add:
"But if you ever need changes, we are the only people who can do that for you."
> The only difference between our commercial model and open source is
> that we currently choose not to make our core source code available
> (though lots of peripheral stuff is), the reason being simply to
> protect our core intellectual property.
"intellectual property" is largely meaningless to those on this list
with my bent. Copyrights do not work like trademarks, trademarks do
not work like patents, and none of the tree work like "property" in
the real world. For instance, if I give you a shovel or a house, you,
and only you can "own" that house or shovel.
When you say intellectual property you are actually making an
implication that even though nothing "intellectual" works anything
like anything "property" you should be able to make arrangements to
control the scarcity of that resource, as though it were "property".
Of course after making this clever shift of focus, then you can easily
then argue that it needs "protecting", the same way that locks and
alarms protect our homes and cars. The problem is that this
"protection" means that your users lose software freedom.
> Anyway, tried and tested enterprise-grade GT.M integration with PHP,
> Java, ASP.Net, Python and Ruby is there if you want it for free.
free as in costless. Not as in freedom.
> No such thing as a free lunch, or willing to look a gift horse in the
> mouth? The choice, in the end, is yours to make.....but of course it
> won't cost anything to find out which it is :-)
I already know what it is and so does everyone else. What we disagree
about is the appropriateness of the deal.
Just as some people think Casinos are immoral, I think your whole
model is immoral. (Not you mind you, but your model)
Your software quality is probably good. You do sound like you know
what you are talking about.
However, you are offering a costless option that restricts users freedom.
Thankfully people like me have a much better option than giving up our
freedom. We can work or wait.
I am not going to work on this (I am working on other relevant stuff
however) but thankfully, someone else who agrees with me eventually
When they do, people will be able to choose between your solution,
(good software, costless use, proprietary license) and a
option (good software, costless use, FOSS license). Which one would you choose?
It does not really matter if you agree with me or not.
My way wins in the end because of economics anyway.
-skip Montani Semper Liberi
I will try to fix this soon however...
watch this space.