Astronaut WorldVistA Installers for Linux Beta 0.7 (Falling with
Style!) (see WorldVistA license below)
Description: Installs WorldVistA EHR/VOE 1.0 via rpm (Fedora/RedHat)
or dpkg (.deb file Ubuntu/Debian)
Downloads: http://sourceforge.net/projects/worldvistaautoi/files/
Changes: GUI-Scheduling client probably will work in this release by
changing XUS1.m and adding IPv6 processing to BMXMON and XWBTCPM.
Monster release with fixes for TMG-GUI-Config that allows User
access/verify code management, pre-loads bmx and all the pieces needed
to run GUI-Scheduling.
Other changes: Latest Fidelity Information Services gtm V53004A "Rock
Solid, lightning fast.", gtm is now symlinked to /opt/lsb-gtm/gtm so
that it can be easily upgraded. All client installers upgraded with
the latest TMG-CPRS, TMG-GUI-Config and GUI-Scheduling. The p(atch)
subdirectory will now work correctly (which is in the eye of the
beholder) and is now populated with the results of many patches. mupip
man page is now installed.
Default ID's and passwords: System Linux id for an instance now follow
the VistA Standard Base spec of <branding>vista<instance> to avoid
conflict and allow multiple instances to run side by side. For example
worldvistaEHR is the default Linux id for rpm install with password
vista!123. The default VistA id is sys.admin vista!123.
Author: Ignacio Valdes <iva...@hal-pc.org>
Contributors of code, modules or other in Alphabetic order (Ommitted?
Don't want to appear? Let me know.)
Individuals:
Anthracite, Nancy -- Original install document, general knowledge.
Bodtke, Peter -- Testing, documentation.
Bhaskar, KS -- GT.M, Acculturation documentation, architecture, shell scripts.
Dorsey, Jon -- VistA Standard Base co-proposer.
Hagood, Eddie -- TMG-GUI-Config and fixes.
Habiel, Sam -- BMX functionality, GUI-Scheduling.
Landis, "Gus" -- VistA Standard Base co-proposer.
Noorden, Lars -- Mupip man page.
Meiling, Ben -- VistA Standard Base co-proposer.
Papillion, Anthony -- VistA Standard Base co-proposer.
Pardue, Andy -- OVID.
Self, Jim -- m2web
Tai, Jonathan -- GT.M knowledge, VistA Standard Base, rpm wizardry.
Timson, George -- Pointed out IHS fix for SSN problem.
Toppenberg, Kevin -- TMG-CPRS, TMG-GUI-Config, TMGIDE, general knowledge.
Trotter, Fred -- VistA Standard Base co-proposer.
Watson, Steve -- Testing, documentation, VistA Standard Base co-proposer.
Whitby, Bruce -- Testing, , VistA Standard Base co-proposer, Misc.
Whitten, David -- Global expertise, debugging, architecture.
Corporations:
Fidelity Information Services -- GT.M
Medsphere Systems Corp -- OVID, Other.
M/Gateway Developments Ltd -- EWD
WorldVistA -- Processed FOIA VistA/VOE.
Government:
Indian Health Service -- BMX, scheduling GUI.
Veterans Affairs -- FOIA VistA.
Problems, comments, bugs: Post problems or issues to the Hardhats
group: http://groups.google.com/group/Hardhats or to
<iva...@hal-pc.org>
License: Installer: Affero GNU GPL version 3. No warranties expressed
or implied, use at your own risk. (see WorldVistA license below)
This installer has been tested on Fedora 10 and Ubuntu 9.
To install on rpm based systems, log in as root:
# yum install -y --nogpg astronaut-<version info>.rpm
Will install all depencencies and then the rpm or somewhat independently:
# rpm -i astronaut-wv-server-installer-XXX-0.X-X.i386.rpm
IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.
To uninstall:
# rpm -e astronaut-wv-server-installer-XXXX-0.X-X
(NOTE: the absence of .i386.rpm for uninstalling)
To install on .deb, dpkg apt-get based systems, use sudo or sudo su to
log in as root:
# dpkg -i astronaut-wv-server-installer-XXXX_0.X-0.X.deb
IT IS NORMAL TO SEE A BUNCH OF ERROR MESSAGES DURING COMPILATION.
To uninstall:
# dpkg -r astronaut-wv-server-installer-XXXX_0.X-0.X.deb
You can change the default installation parameters: location, port,
etc by creating a file called wv-rpm-defaults in /, (rpm apparently
can only find it in /):
vista_path="/opt/worldvista/EHR" # Full path with the last node being
the instance name.
vista_instance="EHR" # Same as the last node above in
/opt/worldvista/EHR
VISTAUSER=worldvista$vista_instance
VISTAGROUP=worldvista$vista_instance
port=9260 # Listening port. By convention 9260
Production, 9261 Training, 9262 Development
vista_port_old_rpc=9210 # Listening port for old rpc broker.
Defaults to 9210
vista_port_vistalink=8002
Alter the above parameters as desired before running the rpm and it
will override the above defaults.
Follow the next steps after the rpm install has run. This gets you to
the point of being able to login as a text or CPRS client. BOX:VOLUME
PAIR GETS AUTOMATICALLY SET! The pre-set Access Code is: sys.admin
with Verify Code: vista!123. You will have to re-set the verify code
upon first login. Download the Windows client installers which should
all work out of the box with this server. The pre-set Linux id is
vista.world password is vista!123 which you will also have to re-set
on first login to the Linux vista.world id. To start m2web simply
start or restart apache then go to step 10 here:
http://vista.vmth.ucdavis.edu/notebook/index/48.html
Features:
1) Conforms to VistA Standard Base 0.9 RC 10.
2) Quick install.
3) Automatically sets BOX:VOLUME pair!
4) Creates a text<instance> id, automatically edits, compiles and
installs Bhaskar's runzu so that text<instance> runs with no shell and
no home directory.
5) Relatively smaller download size 155Mb complete package containing all files.
6) Controller software such as vistactl.sh start | stop | restart,
xinetd listener automatically configured and installed.
7) Automatic vista startup with journaling on server start and
graceful shutdown. Bhaskar's code.
8) Automatically opens CPRS port.
9) Has a backup solution (some assembly required).
10) Latest WorldVistA and gtm V53004A
11) Installs /opt/worldvista/EHR
12) Creates default vista id automatically.
13) Management commands: copy_this_vista_to.sh and
change_client_port.sh and uninstall_this_vista.sh
14) Requires two-factor deletion to really delete an instance. rpm -e
only removes symlinks to log files, text-client id and auto-start
routines. Requires explicit rm -Rf to really delete it all. rpm -i
--force will NOT over-write an existing instance.
15) Checks for file wv-rpm-defaults and overrides default install
parameters for different locations for the install.
16) Port handling files correspond to worldvista name spaces.
17) Pre-installs m2web. Start or restart apache then go to step 10
here: http://vista.vmth.ucdavis.edu/notebook/index/48.html Turn off
and on SELinux between boots by: echo 0 >/selinux/enforce or echo 1
>/selinux/enforce
18) Refreshed: Pre-installs Kevin Toppenberg's debugger, see
http://vistapedia.net for activation.
19) Pre-installs EWD (currently broken).
20) Pre-installs OVID.
21) Pre-installs Victory Programming Environment, see
http://vistapedia.net for activation.
# 22) MSC Fileman 1034 Had to be removed as it was causing a problem.
Stay tuned!
23) TMG-CPRS support with all associated bug fixes.
24) TMG-GUI-Config now supports user management.
25) BMX RPC broker and necessary parts pre-loaded.
26) GUI-Scheduling components pre-loaded.
27) Man page for mupip command.
Caveats:
1) Beta installer.
WorldVistA EHR /VOE 1.0 Release 6-2008
IMPORTANT FOR ALL PROVIDERS:
All drugs that the provider may need must be entered into the database
BEFORE THE PROVIDER PRESCIBES THEM from WorldVistA EHR.THE DRUG FILE
INCLUDED HAS NOT BEEN PREVIOUSLY RELEASED. IT IS ALWAYS IMPERATIVE THAT
ANY AND ALL DRUG ORDERS AND PRESCRIPTIONS BE CAREFULLY REVIEWED BY THE
PRESCRIBING PHYSICIAN AND DISPENSING PHARMACIST TO INSURE ACCURACY. IF
PROBLEMS ARE FOUND, PLEASE REPORT THEM HERE
IN...@WORLDVISTA.ORG
OR
http://trac.opensourcevista.net/worldvistaehr
Please see this link for information about entering new drugs and drug
doseages:
<http://worldvista.org/World_VistA_EHR/license-and-readme/ReadMe%20-%20Wor
ldVistA%20Pharmacy%20Drug%20File%202008-01-31.pdf>
Please look for additional information and updates about this release
here:
<http://worldvista.org/World_VistA_EHR/license-and-readme>
All portions of this release that are modified from the original Freedom
of Informtion Act release provided by the Department of Veterans Affairs
carry the GPL license and are Copyright WorldVistA. See this URL for the
full text of the license:
http://worldvista.org/World_VistA_EHR/license-and-readme/WorldVistA%20EHR%
20GPL%20License.txt
YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING
THIS PRODUCT. DOWNLOADING OR USING ANY PART OF THE SOFTWARE AND
DOCUMENTATION INDICATES THAT YOU ACCEPT THESE TERMS AND CONDITIONS. IF
YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT
PROCEED.
A. General Disclaimer. THE WORLDVISTA-EHR (WV-EHR) SOFTWARE IS
PROVIDED TO RECIPIENT HEREUNDER "AS IS" AND ANY USE OF WV-EHR SOFTWARE BY
REQUESTOR SHALL BE AT ITS OWN RISK. TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, WORLDVISTA AND ITS CONTRACTORS, EMPLOYEES AND AGENTS
DISCLAIM ALL WARRANTIES WITH RESPECT TO WV-EHR SOFTWARE, EXPRESS, IMPLIED
AND STATUTORY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY,
COMPLETENESS, TIMELINESS, NON INFRINGEMENT OF THIRD-PARTY RIGHTS, NON
INTERFERENCE, AND ERROR FREE SERVICE. WORLDVISTA TAKES NO RESPONSIBILITY
FOR MONITORING OR REGULATING THE USE OR ACCURACY OF WV-EHR SOFTWARE.
RECIPIENT ACKNOWLEDGES AND AGREES THAT WORLDVISTA IS UNDER NO OBLIGATION
TO VERIFY THE ACCURACY OF OR OTHERWISE UPDATE WV-EHR SOFTWARE OR ANY
CONTENT CONTAINED THEREIN OR TO NOTIFY RECIPIENT OF ANY INACCURACIES
THEREIN OR UPDATES THERETO THAT MAY COME TO THE ATTENTION OF OR BE
DEVELOPED BY WORLDVISTA. WV-EHR MAY BE UPDATED PERIODICALLY, AND IT IS
THE RESPONSIBILITY OF THE RECIPIENT TO OBTAIN UPDATED VERSIONS OF THE
WV-EHR RELEASE AS REQUIRED. WORLDVISTA BEARS NO RESPONSIBILITY FOR
PROVIDING UPDATES TO RECIPIENTS. PASSWORD IS asdTYU
B. LIMITATION OF LIABILITY. TO THE MAXIMUM EXTENT PERMITTED BY
APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF ITS EMPLOYEES, AGENTS OR
CONTRACTORS SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING WITHOUT LIMITATION DAMAGES
FOR LOST PROFITS OR REVENUES, GOODWILL, WORK STOPPAGE, SECURITY BREACHES,
VIRUSES, COMPUTER FAILURE OR MALFUNCTION, USE, DATA OR OTHER INTANGIBLE
LOSSES OR COMMERCIAL DAMAGES, EVEN IF ANY OF SUCH PARTIES IS ADVISED OF
THE POSSIBILITY OF SUCH LOSSES, ARISING UNDER OR IN CONNECTION WITH THIS
AGREEMENT, COMPLIANCE EFFECTIVENESS STUDY TOOLS, THE USE OF OR INABILITY
TO USE THE SAME, OR ANY OTHER SUBJECT MATTER HEREOF. IN ADDITION, TO THE
MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, NEITHER WORLDVISTA NOR ANY OF
ITS EMPLOYEES, AGENTS OR CONTRACTORS SHALL BE LIABLE FOR ANY LOSS OR
DAMAGE SUFFERED BY RECIPIENT WHICH ARISES OUT OF OR IN CONNECTION WITH
ANY INFORMATION OBTAINED BY RECIPIENT VIA OR IN CONNECTION WITH WV-EHR
SOFTWARE.
Okay, I just uploaded and updated Astronaut WorldVistA 0.7.3 rpm/deb/windows appliance.
17) Pre-installs m2web. Start or restart apache then go to step 10 here: http://vista.vmth.ucdavis.edu/notebook/index/48.html Turn off and on SELinux between boots by: echo 0 >/selinux/enforce or echo 1 /selinux/enforce
19) Pre-installs EWD (currently broken).
Having the KIDS builds themselves available is a good first step. For
OpenVista Server, we've begun to distribute KIDS builds separately[1]
from full-database releases to accommodate users who are upgrading. The
installation sequence can be found in the commit messages[2] of our open
repository.
> 2. ?
For #2, I would suggest that separating out the Linux components from
VistA itself, as we've done this with our OpenVista/GT.M Integration
Project[3], is vital. If the VistA management tools are separated from
VistA, you can attack making the tools upgradeable and making VistA
upgradable separately.
Making the tools upgradeable is relatively easy, since the tools don't
involve any configuration or patient data that must be preserved. Our
management tools from the OV/GT.M integration project have been
upgradeable from release to release since the first 0.8.0 release back
in May. In fact, you can upgrade from any older release to any newer
release (e,g. 0.8.0 => 0.8.2, 0.8.1 => 0.8.5), just like packages from
upstream Linux distributions.
VistA is already upgradeable via KIDS, and a (relatively) small amount
of work could allow a series of KIDS builds to be installed quickly,
provided that your upstream is pushing out a reliable sequence of builds
(see #1, above).
> 3. ... Well, I don't know <everything>. :)
I don't know everything either, but for #3, I'd suggest that the
next-generation revision control tools I've ranted about[4] at length on
this list could be used to distribute upgrades. Having the revision
control tools in place would allow a site to consume more than one patch
stream at once (although care should be taken that the two streams do
not conflict with one another). In practice, production sites with no
developers on staff will probably want to consume just a single
"aggregate" stream (possibly provided by a VistA integrator), and the
development work required to ensure no conflicts, QA, etc. will be done
in the integrator's branch.
- Jon
[1] http://tinyurl.com/mkyt4f
http://sourceforge.net/projects/openvista/files/OpenVista%20Server/1.5SP2/openvistaserver-1.5.sp2-kids.zip/download
[2] http://tinyurl.com/netwru
http://bazaar.launchpad.net/~ov+server/openvista-server/mainline/revision/37
[3] http://medsphere.org/community/project/gtm
[4] http://tinyurl.com/m2yoja
http://medsphere.org/people/jon.tai/blog/2009/07/01/the-case-for-distributed-revision-control-in-the-vista-community
[jl.z] Begging David's pardon for ignoring the meat of his post,
Besides, I see that Jon has more substantial contributions to make
(and is typing faster than I)
1. KIDS (just one, essential tool)
> What are the details of that part ?
We must have a better way of maintaining a repository of KIDS distributions.
And there should be an automated or semi-automated method of
distributing them to "subscribers".
I do not believe that this needs to be a central repository. But there
needs to be a complete listing of KIDS files however widely they may
be distributed physically. So, yes, a virtual central repository.
> Why is it worth doing ?
The VA FOIA site remains an important resource and its patch stream is
unlikely to replace KIDS with something more "modern". So VistA users
will continue to need access to these patches. Those of us living
outside the firewall should be able to evolve reliable mechanisms for
using KIDS, to include notification of new entries
In addition there are other potentially valuable inputs to the patch
stream outside the VA firewall.
** on the Trac server one can find the work of the CCR/CCD group:
https://trac.opensourcevista.net/browser/ccr/trunk/archive/C0C_1_0_10_T1_GTM.KID
It also holds kdtop's work on TMG-CPRS:
https://trac.opensourcevista.net/browser/cprs/branches/tmg-cprs/Server_KIDS/TMG1-1.0-3.KIDS
** Medsphere is contributing work on several fronts, for example on
GTM integration:
http://code.launchpad.net/openvista-gtm-integration/mainline/0.8.5/+download/MSC_GTM_INTEG_8.KID
** There are things hanging out on Nancy's server:
http://opensourcevista.net:8888/NancysVistAServer/Scheduling/VWSD_1_0.KID
(just an example)
** I'd like to find somewhere (and perhaps a namespace) for my pipe
print device.
> Do we have what we need to do it ?
Initially one individual could build a virtual repository, not of
files but of pointers to files.
> Who has permission to do it ?
It's a free country. I would expect some vendor or the other to have
a hidden repository for its own purposes. But I could start from FOIA
and the other freely available sources listed here.
> What will people get from it ?
Ask Kevin about the need for maintaining a patch stream up to date.
Until we start to maintain public lists of patches, we will miss
things.
> Who can we depend on to maintain it ?
We'd better depend on ourselves.
Other relevant issues:
Synchronization within an organization's VistA servers
MailMan distribution
Versions for Cache vs GT.M,
The limitations of KIDS distributions.
jl.z
-- --------------------------------------- Jim Self (http://www.vmth.ucdavis.edu/us/jaself) M2Web (http://vista.vmth.ucdavis.edu/notebook) ---------------------------------------
> > Who has permission to do it ?
>
> It's a free country. I would expect some vendor or the other to have
> a hidden repository for its own purposes. But I could start from FOIA
> and the other freely available sources listed here.
Wearing my "some vendor" hat for a moment:
1) The OpenVista repo is not hidden [1]
2) KIDS builds are available in a tarball [2] and an open, source code
management, repository [3]
3) Patch sequence is available in release documentation (ChangeLog)
- Ben
[1] http://bazaar.launchpad.net/~ov+server/openvista-server/mainline/files
[2] https://sourceforge.net/projects/openvista/files/OpenVista%20Server/1.5SP2/
(openvistaserver-1.5.sp2-kids.zip)
[3] http://bazaar.launchpad.net/~ov%2Bserver/openvista-server/mainline/files/head%3A/kids/
I was <not> referring to Medsphere, currently the most open vendor we have. :-)
I even used http://code.launchpad.net/openvista-gtm-integration/mainline/0.8.5/+download/MSC_GTM_INTEG_8.KID
as an example of a KIDS distribution that should be included.
"I would expect some <other> vendor(s) to maintain their own repository."
Highest regards,
jl.z -- Rock solid (not counting the right knee).
Lightning fast (except for that prostate thingy).
Phew! Thank goodness! Removing that hat then -- besides, it doesn't
fit very well. ;-) -Ben
Nothing stops you from just using 32KB block sizes for everything and
not having to care. If you care about performance, GT.M let's you tune
for performance. We cater to all needs! (Since the computer systems at
some of our high end users are in the million dollar range and up,
saving a few percentage points in performance is pretty real money.)
Nomex not needed here!
Regards
-- Bhaskar
GT.M - Rock solid. Lightning fast.
_____________
Jim You have to understand that (like most software that I anticipate ending up in GT.M over coming years) EWD was originally developed on Cache where 32k strings are the norm. Much of EWD's compiler functionality has been designed and relies on the fact that 32k strings are available in global storage. I dare say I could mess about and re-code stuff to make do with a lot less, but a) I don't have the time (or rather can't justify it), b) I don't want to risk de-stabilising EWD unecessarily and
c) 32k string handling seems entirely reasonable in this day
Speed is VERY important to caregivers.
On 09/09/2009 09:35 PM, Butch wrote:
[KSB] <...snip...>
> I do agree though that the extra bits for adapting to the underlying
> filesystem is not a good way to have to do things. For the sake of
> curiosity, is this a limitation of other non-cache based M?
[KSB] This is an interesting use of the English language. GT.M lets you
use 32KB block sizes for all your global variables. It also lets you -
optionally - use different block sizes for different global variables.
And this is termed a "limitation"?
Regards
-- Bhaskar
On 09/09/2009 04:50 AM, rtweed wrote:
[KSB] <...snip...>
> Let's be clear: getting EWD to work with GT.M and VistA is not
> difficult or rocket science - either configure a 32k database for its
> specific use, or configure the entire environment to work with 32k
> strings. I'm not sure I understand the resistance to doing this or
> the apparent inability being demonstrated to make this happen.
>
> Can I ask the question: 9 months after having one out of my way to
> make it available as Free Open Source to try to provide this community
> with a state of the art tool for Ajax development, is *anyone*
> actually using EWD with VistA yet? I have to be honest and say that I
> do wonder sometimes why I bothered. All I seem to hear is reasons why
> people haven't used it or don't use it.
[KSB] Rob, I think you underestimate the difficulty of recreating a new
graphical user interface for VistA. I suspect that simply mapping the
breadth of functionality that must be exposed may be a daunting task,
and if you consider CPRS reverse engineering the functionality therein
is a major project. I doubt that even with a corporation behind it,
Medsphere's portable dotNet client took a substantial chunk of work.
It has been said that it takes three times as long to create an
application as it does to create a prototype, and three times as much
yet again to create that application as an integrated part of a complete
system.
Remember that what EWD does is make Javascript toolkits easier to
integrate with MUMPS - it is infrastructure, rather than a design studio
for creating graphical user interface applications.
Incidentally, since there are a number of MUMPS programmers who also
know Python, I wonder if Pyjamas (see http://lwn.net/Articles/348341/0
and http://pyjs.org/) might make it easier for MUMPSters to develop GUIs
and hook them up to MUMPS applications with EWD.