There is a fine line to be walked between satisfying the "Release Early, Release Often" mantra of the open source free software movement on the one hand, and on the other, having enough functionality for the software to be worth trying. The volunteers porting FOIA VistA to GT.M (http://www.sanchez-gtm.com ) feel that they are now ready for friendly users to try the software. If you are an M programmer experienced with VistA applications, or with Kernel and Fileman, this may be your chance to help the team.
The significance of VistA on GT.M on x86 GNU/Linux is that it represents a complete and proven stack of open source free software for healthcare that can scale from the needs of a small clinic to those of a large teaching hospital.
FOIA VistA for GT.M is available at Source Forge (http://sourceforge.net/projects/hardhats) as is the open source free software GT.M for x86 GNU/Linux (http://sourceforge.net/projects/sanchez-gtm ). Please use the appropriate support forums at Source Forge to request assistance and report anomalous behavior. In particular, Network Mail and HL7 Messaging are not yet functional. There is information at Source Forge under both the CVS link and in the Docs section on getting the source code from CVS. This VistA code should work with GT.M on any platform, not just GT.M on x86 GNU/Linux. You should use GT.M V4.3-FT06, the field test version of the forthcoming production version V4.3-001.
An extract from an initialized VistA database will hopefully be posted shortly in the VistA area of Source Forge. If you have an existing VistA database under Cache, Maury Pepper has posted in the Patches section a Cache program to export a database in GT.M's ZWR format. His program should be straightforward to convert to other dialects of M.
If you are able to render assistance to others who request it, please do so; the team of volunteers thanks you. For now, Ed de Moel (demoel @ users.sourceforge.net) is acting as the ibrarian. So, if you have a fix, even if you have write access to the CVS repository at Source Forge, please do not commit your changes. Instead, please submit them in the Patches section, and send an e-mail to Ed telling him to look for them.
Kudos to the entire team, and especially to Rick Marshall, Dave Whitten and Chris Richardson, for making this happen. It is their hard work and dedication that makes this possible.
I want to thank you for your help earlier with what was a simple Linux permissions problem. Since then we have successfully installed GT.M and VistA to the point where TaskMan was running.
I am currently involved in a project to implement BCMA at a small non-VA hospital with a goal date of Aug 1 this summer. We have been running VistA inpatient pharmacy for the last 4+ years using NT and Cache, our plan was to use 2000 and Cache. BUT, GT.M gives us a serious option to that implementation plan. The questions are:
- What are the current issues related to GT.M
and VistA in a production setting? We would
like to help if at all possible.
- If we decided to put our time and energy into
an implementation using GT.M would this delay
us by a significant period?
I realize that these are questions not easily answered and my feeling is that we would like to go with GT.M, but there are concerns about being first on the block.
Any and all comments appreciated.
Pages 147-182 in the GT.M-x86-UNIX-AdminOpsGuide seem to be missing. Is this just an error in the rewriting and numbering or can I find a newer updated Guide.
Thank you for the update on your experience with GT.M.
> I want to thank you for your help earlier with what was a simple Linux
> permissions problem. Since then we have successfully installed GT.M and
> VistA to the point where TaskMan was running.
> I am currently involved in a project to implement BCMA at a small
> non-VA hospital with a goal date of Aug 1 this summer. We have been
> running VistA inpatient pharmacy for the last 4+ years using NT and
> Cache, our plan was to use 2000 and Cache. BUT, GT.M gives us a serious
> option to that implementation plan. The questions are:
> - What are the current issues related to GT.M
> and VistA in a production setting? We would
> like to help if at all possible.
[KSB] As far as I know, VistA on GT.M is more or less "code complete"
in that the porting team believes that everything should now work,
including network mail and HL-7 messaging. The last set of code
changes has not been made available yet at Source Forge
(http://sourceforge.net/hardhats) but I expect it to be there shortly.
What remains is testing. If you are able to help test the port,
especially for the functionality you want to put into production, it
would be very helpful.
> - If we decided to put our time and energy into
> an implementation using GT.M would this delay
> us by a significant period?
[KSB] I don't think so. You have VistA and Taskman running. Between
everyone who is evaluating VistA on GT.M, significant pieces of VistA
are already running on GT.M, even if they are not yet in production.
> I realize that these are questions not easily answered and my feeling
> is that we would like to go with GT.M, but there are concerns about
> being first on the block.
[KSB] There is little need to be concerned about GT.M itself. It is
licensed to process the core systems at over 1,000 financial
institutions worldwide, from small community banks to global
institutions. Your personal bank balance may already be entrusted to a
GT.M database. GT.M on Linux (counting all software and documentation)
has been downloaded over 10,000 times from Source Forge, and I would
guess that there are probably in the small thousands of real users
today. I know that at least some have put it into production, but it
is hard for me to know how many. VistA on GT.M on Linux is new, but
you're looking at mature application code on a mature database on a
mature operating system (and certainly one that is more stable than
Windows -- I speak from personal experience). So, I think you are on
(A word from our sponsors: when you put VistA on GT.M on Linux into
production, please do consider purchasing GT.M support from Sanchez.)
The URL you quoted for hardhats on sourceforge is incorrect. It is actually:
Well, here goes--this is probably the wrong forum for my question, but I am friendly-testing Vista on GT.M.. Tonight zlink appeared to stop working. No matter what I did the source code wouldn't zlink. So I rebooted Linux (crazy, extreme, I know..) After rebooting, zlink worked like it usually does. I think the thing that broke it in the first place might have been a <(ZLINKFILE)> error that occurred when trying to zlink a % routine. I don't know what was wrong with that either--maybe permissions--but the main question is how to get it to work again after one of these errors, without rebooting.
Lloyd Milligan (Lloyd@SeaIslandSystems.com)
This is as good a forum as any! We'll get to the bottom of this.
When ZLINK failed for you, what was the message. Also, how did you know that it failed?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.