Hello,
I am a newbie to VistA but am trying to figure out if this is
usefull for a menthal healthcare organisation in the Netherlands.
I succesfully installed the latest OpenVistASemiVivAFOIAGold20050825.tgz
but seem to be stuck now on the GTM command prompt.
It would be very nice if somebody
2. The source code is already on your machine for VistA itself in the r
directory for OpenVistA . The source code for the client side software can
be found on the ftp.va.gov/vista under (roughly) Software, Packages, Order
Entry - Results Reporting - OR, Programs
Hello,
I found the information below very usefull. Thank you.
Now one question remains:
1-do I need the CPRS program or is there a way to start some sort
of menu system on a Linux system? As mentioned before I have a GMT prompt.
kind regards,
On Tue, August 30, 2005 3:41 pm, Nancy Anthracite
You may be able to find out some information about how to use the text based
CPRS here:
http://www.va.gov/vdl/Clinical.asp?appID=61
Try the list manager version as I think that is probably it.
On Tuesday 30 August 2005 10:17 am, Jeroen Baten wrote:
Hello,
I found the information below very
Did you also check Finland?
http://www.hardhats.org/cs/broker/finn1.htm
http://www.uku.fi/tike/fixit/mta99-plenary.pdf
Perhaps worth a look if you haven't seen it.
Thanks,
thurman
-Original Message-
From: [EMAIL PROTECTED] [mailto:hardhats-
[EMAIL PROTECTED] On Behalf Of Jeroen
I use the text based CPRS application periodically.
1. ncurses is not needed (VistA has its own equivalent)
2. the text based version doesn't have all the features of the gui
windows CPRS. But if all you want to do it to enter progress notes,
it is workable.
3. It is available through the menu
Hi all,
I've installed OpenVistA on Linux/GT.M and have
noticed that the performance of the CPRS GUI is much
slower than what I've experienced with Windows/Cache.
Is anybody else experiencing similar slow down?
I have tried running through xinetd and through
the RPC broker directly in
Under Windows, are you running CPRS locally or on a separate box? With
GT.M what kind of network are you using?
--- Orion Richardson [EMAIL PROTECTED] wrote:
Hi all,
I've installed OpenVistA on Linux/GT.M and have
noticed that the performance of the CPRS GUI is much
slower than what
I'm with Greg. I bet its a network issue instead of a GT.M speed issue.
Kevin
On 8/30/05, Greg Woodhouse [EMAIL PROTECTED] wrote:
Under Windows, are you running CPRS locally or on a separate box? With
GT.M what kind of network are you using?
--- Orion Richardson [EMAIL PROTECTED] wrote:
I think Kevin Greg are right on the right track that the differences
are caused by network configurations, but it would help to narrow things
down. Especially on an unloaded server, which is what I suspect Orion
is running, I would expect no perceptible difference between different
MUMPS
Thanks all for such quick responses. You are correct
in assuming that the network setup woudl be different,
but the speed was so noticably different and I'd used
the VistA demo from the VA with better performance
than my linux machine with the same CPRS location.
That seemed weird.
Here's how I
You could verify the GTM daemon by trying to access Apache or something
similar on your linux box to verify it on the network. If Apache (or
FTP) is slow, then concentrate your efforts on the box. If Apache (or
FTP) is fast, then concentrate on GTM.
And what are the licensing options for Cache
You can access the free Caché version from an other computer in your
network, exactly as you do with GT.M
I have both installations Caché and GT.M on similar servers and can acess
them with CPRS in an other computer yin the network and there is no
noticeable difference in speed.
Alberto Odor, MD
Orion --
As Alberto's experience suggests, the issue is highly unlikely to be
with GT.M. You would be wasting your time looking trying to run GT.M in
raw partitions (I no of no one who uses raw partitions).
As an engineer by training, I am not a betting man, but if I were, I
would bet on
David --
GT.M is unusual among database engines in that it does not have a
database daemon. This avoids a potential single point bottleneck and/or
source of failure. Also, compared to database engines where a daemon
runs as root, system security is a little better since processes that
must
OK, OK, I know this is a M list. But hear me out.
The December our Mysis contract will expire, which is our old EMR.
The company says that it will be $5,000+ to get the old progress notes
exported. Recently our group voted not to do that, and to just go
forward with our paper printouts of that
I'm not sure about MicroFocus Cobol (which is a PC Cobol, as I recall)
but I recall that on the mainframes (IBM 360/370 range)
Cobol did NOT provide its own database layer.
It is probably something like VSAM or ISAM, or possibly SQL.
A web search yielded:
I'd like to hear everyone's thoughts about
http://www.computerworld.com/newsletter/0,4902,104195,0.html?nlid=AM
Network Effect
Opinion by Frank Hayes
AUGUST 29, 2005 (COMPUTERWORLD) - I work for a hospital management company
in the Midwest that works with 30 very small rural community
Hello to everybody in the list;
I have a little problem here, I need to start the TASKMAN and a
routine to listen the port 9260/TCP in a not interactive way. When I
make it in an interactive way, I do:
# mumps -direct
GTM D P^DI ENTER
VA FileMan 22.0
Select OPTION: 1 ENTER
ENTER OR EDIT FILE
Most of that is one time setup. The settings are saved in Fileman, so
the next time around, you only need to start Taskman (your D ^ZTMB,
though you can also do it through a menu option, if you wish). Other
options, such as starting the Broker can be designated to start
automatically, if you wish.
Thanks a lot for your help, Greg; now I can start the Taskman in a non
interactive way, now, I need to open the 9260/TCP port, so I do:
GTM D STRT^XWBTCP(9260) ENTER
Start TCP Listener...
Checking if TCP Listener has started...
TCP Listener started successfully.
GTM
and to stop it; I just type:
Can Expect handle something like this?
On Tuesday 30 August 2005 08:28 pm, César Yáñez Fernández wrote:
Thanks a lot for your help, Greg; now I can start the Taskman in a non
interactive way, now, I need to open the 9260/TCP port, so I do:
GTM D STRT^XWBTCP(9260) ENTER
Start TCP Listener...
Why are you wanting to start and stop your system all the time? If
you are planning a stable system, then you will turn it on and leave
it on (i.e. on a server.)
Kevin
On 8/30/05, Nancy Anthracite [EMAIL PROTECTED] wrote:
Can Expect handle something like this?
On Tuesday 30 August 2005
Please provide some guidance about future releases of OpenVistA VivA.
I have thus far used Knoppix (http://knopper.net/knoppix/index-en.html)
as the basis for OpenVistA VivA FOIA Gold releases, and Morphix
(http://morphix.org) as the basis for OpenVistA VivA releases. The
former releases are
César --
Use Linux's shell scripting capabilities. Something like (don't take
this literally, but use it as the basis for what you should do):
To start:
export gtm_dist=/usr/local/gtm
export gtmgbldir= ...pointer to global directory...
export gtmroutines= ...routine search path...
I generalized non-interactive process to daemon. I haven't used GTM
nearly as much as I would like but I understand your POV.
David Sommers, Architect | Dialog Medical
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of K.S.
Bhaskar
Sent: Tuesday,
K.S. Bhaskar wrote:
Please provide some guidance about future releases of OpenVistA VivA.
At the other extreme, is Damn Small Linux (http://damnsmalllinux.org).
Sans VistA, this distribution is small enough to fit onto a business
card sized CD. With VistA, the download would be around 220MB.
I would be very open to investigating running under Windows while we
still have this dependency on CPRS. Having a single system demo is very
very useful.
Plus I'm all for dogfooding a puppy as well.
David Sommers, Architect | Dialog Medical
-Original Message-
From: [EMAIL
Much thanks goes to you Bhaskar for all of your support in maintaining
these releases.
Would it be possible to create .deb packages of GT.M/OpenVistA? It would
be so nice to automate and manage updates and installations on a running
Debian server with dpkg or apt-get. Perhaps something such
Very perceptive, in my opinion.
I suspect that everyone here is so focused on getting a product out
that questions of interoperability are not given much consideration.
But it's surely true that people will shy away from using VistA if
they feel that they are locked in to a particular
I assume your basic goal is to come up with something like a turn key
solution. Is that a fair assumption? Going back to the network effect
message, I don't know that marrying your solution to Debian, Knoppix,
Red Hat, or what have you is the right way to go. It will be easier
to get user
I believe we need to drive for the requirements first. What is the
intent or the target audience of VivA? Is it as a method for easy
installation that leads to production use, or easy instance that leads
to demonstration?
With the former, building a RPM or installable package is a favorable
Kevin;
There are ways of capturing the data. Obviously, if you can generate the
information electronically, that would make the effort easier. There are
probably pointer relationships which need to be preserved to make sense out
of the information. Also if you have access to the data
33 matches
Mail list logo
