The New WorldVistA VM - early version now available
825 views
Skip to first unread message
rtweed
Jan 17, 2012, 10:26:30 AM1/17/12
to Hardhats
Prior to a fuller, more formal announcement (not sure if one is
planned), this is more of a "heads up" for those interested in trying
out and evaluating the first incarnation of what is intended to be an
evolving resource.
As described in detail by George Lilly at the 24th VistA Community
Meeting (VCM) last Sunday, and announced and demonstrated at the very
end of the VCM:
- a fully installed and pre-configured virtual machine, complete with
GT.M and the latest EWD, running on Ubuntu Linux 10.10 + Apache +
m_apache
- the full version of Meaningful Use-certified WorldVistA
- configured as a fully-fledged hospital, with preconfigured wards,
beds, clinics etc
- configured for both Inpatients *and* Outpatients
- pre-installed with a large population of test patients with results,
histories etc etc
- CPRS
- a fully working version of VistACom, complete with full source code
(I'm sure George can further refine and detail what's in it).
For EWD development purposes, it is pre-installed with the Sencha
Touch Javascript framework (version 1.1). Others including YUI will
follow.
It's currently available as a VMWare VM, but the intention is that
there will be other incarnations for use with other Virtualised
environments such as VirtualBox etc.
In other words, this is everything anyone needs to get up and running
in just a few minutes with an entire VistA system, so it's going to be
ideal for, inter alia:
- evaluation, testing and demonstration of VistA
- learning / training in the use and configuration of VistA
- EWD training
- a platform for EWD-based VistA application development (for both
desktop & mobile [iPhone, iPad, Android] applications)
In yet other words, this is something we've all been waiting for and
an incredibly important step forwards for WorldVistA.
For those on the EWD Training Course, this is the VM we'll use for
Lessons 9 & 10.
So how do you get your hands on this amazing beast?
1) Download a copy from http://www.fourthwatchsoftware.com/dEWDrop.7z
(It's about 2.4Gb)
2) De-compress it using a 7-zip tool such as Stuffit Expander.
Anything capable of handling 7-zip format should be fine. It will
expand to about 9.5Gb, so it's pretty big (as you'd expect!)
3) Fire up a VMWare client (the free VMWare Player is fine, but VMWare
WorkStation, VMWare Server and VMWare Fusion will all work)
4) When you first start it, it will probably ask you if you moved it
or copied it - say you copied it.
5) The Linux server will boot. Its default networking configuration
is Bridged networking and DHCP is configured, so it will grab an IP
address automatically. (You can reconfigure it through VMWare to use
NAT if bridged won't work on your network)
6) Login to the server on the VMWare console window: Username:
vista / Password: ewd
7) Find out the IP address by typing: ifconfig You should see a
recognisable IP address near the top of the output
8) The VM is already SSH enabled, so do everything else from SSH
connections (eg Windows users can use WinSCP and puTTY)
9) EWD and Apache are already up and running, so you can point a
browser at the VM and try out the ewdMgr and VistACom applications:
Assuming the IP address is 192.168.1.130, you'd use the following
URLs (case sensitive!)
ewdMgr: http://192.168.1.130/vista/ewdMgr/index.ewd
VistACom: https://192.168.1.130/vista/VistACom/index.ewd
If you're using VistACom, you should use desktop Safari or Chrome
browsers, or of course you can use an iPad or Android tablet. It's
also possible to use an iPhone or iPod Touch or many Android phones,
but you'll find that in places the current version's UI isn't set up
to cope with the much smaller screen area available to a phone.
For VistACom use (or for accessing VistA generally), the following
Access Code and Verify Code is pre-configured:
A/C: worldvista
V/C: $#happy7
When you're asked to enter a patient name, just start typing, and it
will automatically find and filter matching names in a combo pop-up
That's it - start trying it out, but watch for future updates. On the
EWD side, we'll be adding Node.js to it pretty soon (I already have a
version working), so we'll be able to also then add some of the Web-
sockets "real time web" demo apps I showed at the VCM and get people
developing using this next-generation technology.
I'm hoping others who have been involved in the development of this VM
will follow up on this posting with further details and information
about what's inside this awesome package!
Make no mistake about it: this is huge!
Rob
planned), this is more of a "heads up" for those interested in trying
out and evaluating the first incarnation of what is intended to be an
evolving resource.
As described in detail by George Lilly at the 24th VistA Community
Meeting (VCM) last Sunday, and announced and demonstrated at the very
end of the VCM:
- a fully installed and pre-configured virtual machine, complete with
GT.M and the latest EWD, running on Ubuntu Linux 10.10 + Apache +
m_apache
- the full version of Meaningful Use-certified WorldVistA
- configured as a fully-fledged hospital, with preconfigured wards,
beds, clinics etc
- configured for both Inpatients *and* Outpatients
- pre-installed with a large population of test patients with results,
histories etc etc
- CPRS
- a fully working version of VistACom, complete with full source code
(I'm sure George can further refine and detail what's in it).
For EWD development purposes, it is pre-installed with the Sencha
Touch Javascript framework (version 1.1). Others including YUI will
follow.
It's currently available as a VMWare VM, but the intention is that
there will be other incarnations for use with other Virtualised
environments such as VirtualBox etc.
In other words, this is everything anyone needs to get up and running
in just a few minutes with an entire VistA system, so it's going to be
ideal for, inter alia:
- evaluation, testing and demonstration of VistA
- learning / training in the use and configuration of VistA
- EWD training
- a platform for EWD-based VistA application development (for both
desktop & mobile [iPhone, iPad, Android] applications)
In yet other words, this is something we've all been waiting for and
an incredibly important step forwards for WorldVistA.
For those on the EWD Training Course, this is the VM we'll use for
Lessons 9 & 10.
So how do you get your hands on this amazing beast?
1) Download a copy from http://www.fourthwatchsoftware.com/dEWDrop.7z
(It's about 2.4Gb)
2) De-compress it using a 7-zip tool such as Stuffit Expander.
Anything capable of handling 7-zip format should be fine. It will
expand to about 9.5Gb, so it's pretty big (as you'd expect!)
3) Fire up a VMWare client (the free VMWare Player is fine, but VMWare
WorkStation, VMWare Server and VMWare Fusion will all work)
4) When you first start it, it will probably ask you if you moved it
or copied it - say you copied it.
5) The Linux server will boot. Its default networking configuration
is Bridged networking and DHCP is configured, so it will grab an IP
address automatically. (You can reconfigure it through VMWare to use
NAT if bridged won't work on your network)
6) Login to the server on the VMWare console window: Username:
vista / Password: ewd
7) Find out the IP address by typing: ifconfig You should see a
recognisable IP address near the top of the output
8) The VM is already SSH enabled, so do everything else from SSH
connections (eg Windows users can use WinSCP and puTTY)
9) EWD and Apache are already up and running, so you can point a
browser at the VM and try out the ewdMgr and VistACom applications:
Assuming the IP address is 192.168.1.130, you'd use the following
URLs (case sensitive!)
ewdMgr: http://192.168.1.130/vista/ewdMgr/index.ewd
VistACom: https://192.168.1.130/vista/VistACom/index.ewd
If you're using VistACom, you should use desktop Safari or Chrome
browsers, or of course you can use an iPad or Android tablet. It's
also possible to use an iPhone or iPod Touch or many Android phones,
but you'll find that in places the current version's UI isn't set up
to cope with the much smaller screen area available to a phone.
For VistACom use (or for accessing VistA generally), the following
Access Code and Verify Code is pre-configured:
A/C: worldvista
V/C: $#happy7
When you're asked to enter a patient name, just start typing, and it
will automatically find and filter matching names in a combo pop-up
That's it - start trying it out, but watch for future updates. On the
EWD side, we'll be adding Node.js to it pretty soon (I already have a
version working), so we'll be able to also then add some of the Web-
sockets "real time web" demo apps I showed at the VCM and get people
developing using this next-generation technology.
I'm hoping others who have been involved in the development of this VM
will follow up on this posting with further details and information
about what's inside this awesome package!
Make no mistake about it: this is huge!
Rob
JohnLeo Zimmer
Jan 18, 2012, 10:12:20 AM1/18/12
to hard...@googlegroups.com
David Whitten
Jan 18, 2012, 3:59:48 PM1/18/12
to hard...@googlegroups.com
Long time Hardhats readers don't need this warning, but new people
may need us to be explicit. This is a BETA release.
It is suitable for Web-development practice, and NOT for installation
in a hospital, clinic, or medical doctor's office. It is known to be
incomplete for these purposes.
This is NOT a copy of the meaningful use VM. This is a BETA version
of the part of the meaningful use WorldVistA EHR that is useful for
development of EWD applications.
WorldVistA is actively packaging all of the Meaningful Use code and data
and anticipate release of the total package. This is a developer's release
to help people get ready for the WorldVistA 2.0 and is intended to help
those who have not had access to some of the work in progress.
Again, please do not plan to put this package anywhere other than in
the hands of a developer/programmer team, as it is guaranteed to not
be what you need for Meaningful Use.
David Whitten
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com
rtweed
Jan 18, 2012, 4:34:04 PM1/18/12
to Hardhats
OK I guess I should have said that - *don't* use it as the basis of a
production installation.
Personally I think its potential audience is a lot wider than just
programmers/developers, although that, of course, was its primary
target.
Rob
> > 1) Download a copy fromhttp://www.fourthwatchsoftware.com/dEWDrop.7z
production installation.
Personally I think its potential audience is a lot wider than just
programmers/developers, although that, of course, was its primary
target.
Rob
David Whitten
Jan 18, 2012, 4:51:17 PM1/18/12
to hard...@googlegroups.com
Rob,
I had no problem with your announcing the VM availability.
I just wanted to make sure that folks understand that this is
based on the WVEHR 3-09 release, (which is already out on sourceforge)
and that significant portions of the Meaningful Use work has been redacted.
As I understand for example, the excellent E-Prescribing work by George
Lilly is not in this release. Some of his quality measures work is there, but
other important components are not ready for release, and a decision was made
to not deliver an incomplete solution, but rather to make sure the complete
solution was prepared.
I had no problem with your announcing the VM availability.
I just wanted to make sure that folks understand that this is
based on the WVEHR 3-09 release, (which is already out on sourceforge)
and that significant portions of the Meaningful Use work has been redacted.
As I understand for example, the excellent E-Prescribing work by George
Lilly is not in this release. Some of his quality measures work is there, but
other important components are not ready for release, and a decision was made
to not deliver an incomplete solution, but rather to make sure the complete
solution was prepared.
Nancy Anthracite
Jan 18, 2012, 6:12:13 PM1/18/12
to hard...@googlegroups.com, David Whitten
Also, the redaction was not without its adverse consequences, all of which we
probably have not discovered yet, so bear with us as we get them fixed.
probably have not discovered yet, so bear with us as we get them fixed.
--
Nancy Anthracite
JohnLeo Zimmer
Jan 20, 2012, 1:03:08 PM1/20/12
to hard...@googlegroups.com
Well, Rob,
I have been able to download this monster. (Wifi at Patty's Coffee House on the square took an hour; my rusty old pipes at home would take more than a day and failed several times.)
I can report that dEWDrop.vmdk mounts up on Virtualbox just fine. ewdMgr and VistACom come up alright.
But so far the A/C: worldvista V/C: $#happy7 is rejected by VistACom.
I'll poke around more later today.
I'd like to split this mother into several partitions for easier dissemination, one for /home, perhaps one for /opt.
highest regards,
jlz
rtweed
Jan 20, 2012, 6:33:52 PM1/20/12
to Hardhats
Access Code is worldvista6
Rob
Rob
JohnLeo Zimmer
Jan 20, 2012, 7:39:16 PM1/20/12
to hard...@googlegroups.com
Yes, worldvista6 works.
Thanks, Rob
jl.z
(This looks like a good place for my substitute XUSHSH* with a null hash.)
jl.z
(This looks like a good place for my substitute XUSHSH* with a null hash.)
On Jan 20, 6:03 pm, JohnLeo Zimmer <johnleo...@gmail.com> wrote:
> Well, Rob,
>
>.....
> But so far the A/C: worldvista V/C: $#happy7 is rejected by VistACom.
Michael Reach
Jan 22, 2012, 7:09:27 PM1/22/12
to Hardhats
Rob, on the lesson today:
1) Concerning the Newing of all the Vista variables: I know it's
anathema for a programmer to let local variables run loose, but are
you sure that there will be problems in this case? I'm not familiar
with Vista, but just using Fileman and Kernel: There are always DI*
and IO* and %ZIS* variables and a few others running about when you're
done. We don't try to keep track of them, it's mostly impossible, we
just keep in mind that I shouldn't call anything DIC in the rest of my
code. I don't use local variables beginning with D. And I guess George
Timson takes care of the rest; as long as you K DO when he tells you
to, and make sure that DIC and DA are defined as he tells you to, all
those other local variables never seem to pose a problem; all the
Fileman stuff Just Works anyhow. Are you concerned that it will wreck
ewd-specific code (do you name something U?), or that someone might be
running a server that contains both Vista and non-Vista jobs? Anyhow,
I'm not sure what the problem would be - that would be any worse than
all of us Fileman users deal with every day when we use those
routines.
2) If it is a real problem, how about an exclusive "New (sessid) " at
the top of the prePageScript, to block everything else? You don't pass
in anything but sessid to your prePageScripts anyhow; all other local
variables have to be pulled from the session variable. [I suppose you
could even do that yourself, in the ewd-generated page code that calls
the prePageScript with sessid; just envelope the call in a New. After
all, I don't think one would ever want a prePageScript affecting local
variables.]
Michael
1) Concerning the Newing of all the Vista variables: I know it's
anathema for a programmer to let local variables run loose, but are
you sure that there will be problems in this case? I'm not familiar
with Vista, but just using Fileman and Kernel: There are always DI*
and IO* and %ZIS* variables and a few others running about when you're
done. We don't try to keep track of them, it's mostly impossible, we
just keep in mind that I shouldn't call anything DIC in the rest of my
code. I don't use local variables beginning with D. And I guess George
Timson takes care of the rest; as long as you K DO when he tells you
to, and make sure that DIC and DA are defined as he tells you to, all
those other local variables never seem to pose a problem; all the
Fileman stuff Just Works anyhow. Are you concerned that it will wreck
ewd-specific code (do you name something U?), or that someone might be
running a server that contains both Vista and non-Vista jobs? Anyhow,
I'm not sure what the problem would be - that would be any worse than
all of us Fileman users deal with every day when we use those
routines.
2) If it is a real problem, how about an exclusive "New (sessid) " at
the top of the prePageScript, to block everything else? You don't pass
in anything but sessid to your prePageScripts anyhow; all other local
variables have to be pulled from the session variable. [I suppose you
could even do that yourself, in the ewd-generated page code that calls
the prePageScript with sessid; just envelope the call in a New. After
all, I don't think one would ever want a prePageScript affecting local
variables.]
Michael
rtweed
Jan 23, 2012, 4:46:45 AM1/23/12
to Hardhats
Michael
Yes to all your above - EWD must be capable of running a mixture of
non-VistA and VistA applications. The back-end processes will be
swapping in and out whatever is being asked to run.
If the VistA environment is as horribly leaky as you suggest (and it
comes as no surprise to me), then I'll probably have no option but to
add an automatic exclusive New around the pre-page script call (as
you've suggested). I've avoided this in the past as it imposes a
substantial overhead, but if symbol table discipline isn't going to be
(or can't be) controlled by developers for whatever reason, I have no
real option.
The important thing is to understand the corollary of your arguments -
when you're using EWD and invoking a pre-page script, you MUST
understand that the symbol table, at that point, will be (or SHOULD
BE) effectively empty. In other words, the first task for a VistA
developer will be to fully and correctly/reliably reconstruct the
symbol table environment that his/her subsequent VistA logic will
require in order to run. You CANNOT and MUST NOT assume that stuff
will just be hanging around for you - it WON'T, and if it is, assume
it's not the right stuff. Remember that if you run and test EWD +
VistA as a single user, you'll get the impression that everything is
working fine. As soon as you move to a busy production environment
where multiple concurrent users are doing different things in VistA
and being swapped in and out of the available EWD/GT.M back-end
processes, users may get an unpleasant surprise if your logic is
assuming leaky local variables are just happening to be conveniently
hanging around for you - you'll end up with cross-polluted symbol
tables and unpredictable behaviour in your EWD/VistA applications as a
result.
IMO, all this argues strongly for a suite of properly thought-out API
wrappers for VistA functionality for use by EWD developers which can
manage and maintain the EWD Session and create/recreate the run-time
symbol table within pre-page scripts that use the APIs. Without good
symbol table discipline and proper control of local variable scoping
within your EWD pre-page scripts, I predict some people will manage to
create a horrible mess - please don't blame EWD if this occurs!
The more I think about it, the next version of is going to have to
include an exclusive New around any calls to users' scripts.
Rob
Yes to all your above - EWD must be capable of running a mixture of
non-VistA and VistA applications. The back-end processes will be
swapping in and out whatever is being asked to run.
If the VistA environment is as horribly leaky as you suggest (and it
comes as no surprise to me), then I'll probably have no option but to
add an automatic exclusive New around the pre-page script call (as
you've suggested). I've avoided this in the past as it imposes a
substantial overhead, but if symbol table discipline isn't going to be
(or can't be) controlled by developers for whatever reason, I have no
real option.
The important thing is to understand the corollary of your arguments -
when you're using EWD and invoking a pre-page script, you MUST
understand that the symbol table, at that point, will be (or SHOULD
BE) effectively empty. In other words, the first task for a VistA
developer will be to fully and correctly/reliably reconstruct the
symbol table environment that his/her subsequent VistA logic will
require in order to run. You CANNOT and MUST NOT assume that stuff
will just be hanging around for you - it WON'T, and if it is, assume
it's not the right stuff. Remember that if you run and test EWD +
VistA as a single user, you'll get the impression that everything is
working fine. As soon as you move to a busy production environment
where multiple concurrent users are doing different things in VistA
and being swapped in and out of the available EWD/GT.M back-end
processes, users may get an unpleasant surprise if your logic is
assuming leaky local variables are just happening to be conveniently
hanging around for you - you'll end up with cross-polluted symbol
tables and unpredictable behaviour in your EWD/VistA applications as a
result.
IMO, all this argues strongly for a suite of properly thought-out API
wrappers for VistA functionality for use by EWD developers which can
manage and maintain the EWD Session and create/recreate the run-time
symbol table within pre-page scripts that use the APIs. Without good
symbol table discipline and proper control of local variable scoping
within your EWD pre-page scripts, I predict some people will manage to
create a horrible mess - please don't blame EWD if this occurs!
The more I think about it, the next version of is going to have to
include an exclusive New around any calls to users' scripts.
Rob
Andy Bruce
Jan 27, 2012, 3:07:11 PM1/27/12
to hard...@googlegroups.com
Grettings All,
I've run into a problem loading the new virtual machine on to my Windows
7 laptop.
I successfully downloaded the "FourthWatchSoftware" file and unzipped it
(although the free Stuffit Expander did not recognize the file type)
with WinZip to a root subdirectory - dEWDROP.
I also downloaded the free VmWare player and configured/installed in the
same subdirectory using the client config wizard...disk space at 20gig,
memory at 2meg, and chose Uubuntu Linux as the OS.
When I attempt to "fire up" the client I get a message that I have
"insufficient permission" to open the dEWDROP.vmdk (virtual disk file).
This leads me to believe the client found the image file (as it is named
by complete path) but makes me question whether the authority lacking is
from the windows or Linux side of the machine. AFAIK I have all
permissions on my personal computer.
Has anyone else successfully loaded the VVM on Windows 7?
Suggestion appreciated...solutions adored.
Thanks
Andy
I've run into a problem loading the new virtual machine on to my Windows
7 laptop.
I successfully downloaded the "FourthWatchSoftware" file and unzipped it
(although the free Stuffit Expander did not recognize the file type)
with WinZip to a root subdirectory - dEWDROP.
I also downloaded the free VmWare player and configured/installed in the
same subdirectory using the client config wizard...disk space at 20gig,
memory at 2meg, and chose Uubuntu Linux as the OS.
When I attempt to "fire up" the client I get a message that I have
"insufficient permission" to open the dEWDROP.vmdk (virtual disk file).
This leads me to believe the client found the image file (as it is named
by complete path) but makes me question whether the authority lacking is
from the windows or Linux side of the machine. AFAIK I have all
permissions on my personal computer.
Has anyone else successfully loaded the VVM on Windows 7?
Suggestion appreciated...solutions adored.
Thanks
Andy
> desktop& mobile [iPhone, iPad, Android] applications)
>
> In yet other words, this is something we've all been waiting for and
> an incredibly important step forwards for WorldVistA.
>
> For those on the EWD Training Course, this is the VM we'll use for
> Lessons 9& 10.
glilly
Jan 27, 2012, 3:13:11 PM1/27/12
to Hardhats
Andy:
When you start up your VMWare player, there should be an option "Open
an existing Virtual Machine". This is the one you should choose. You
should not be having to select the OS or anything else, it should just
boot up.
gpl
> > 1) Download a copy fromhttp://www.fourthwatchsoftware.com/dEWDrop.7z
When you start up your VMWare player, there should be an option "Open
an existing Virtual Machine". This is the one you should choose. You
should not be having to select the OS or anything else, it should just
boot up.
gpl
Andy Bruce
Jan 27, 2012, 3:45:14 PM1/27/12
to hard...@googlegroups.com
Thanks George
Yes...when I double click the Icon ( in the sub-directory, the VM starts
up (shows dEWPROP as the only virtual machine in the list) and gives me
this error message:
> Error while powering on: Unable to open file "C:\VistA Virtual
> Machine\dEWDrop\dEWDrop.vmdk": Insufficient permission to access file.
if I click OK and highlight the list entry and choose "Open a Virtual
Machine" I get the same message again.
Potentially important consideration...This did not go as entirely smooth
as written...when I downloaded the VM I accepted the default placement
and set up dEWDROP in a root subdirectory. The VM couldn't find the
.vmdk file.
So I re-downloaded the VM into the dEWDROP directory
which......killed/removed the .vmdk file (from my file directory at
least)........ so
1) I renamed the the dEWDROP directory dEWDROPMe and
2) re-unzipped the files to a new dEWDROP DIRECTORY then
3) moved the .vmdk file into the dEWDROPMe directory and
4)killed the new dEWDROP directory and
5) renamed dEWDROPMe to dEWDROP.
THEN the error message started. Still seems close to kosher to me. I'm
double clicking on the dEWDROP.vmx file to start the application...which
is a config file...after it tells me I don't have permission it takes me
to a config wizard that doesn't look like the config I originally
selected and the config selections are greyed out.
Reckon I should I just remove, delete and reload?
I thought I would see if anyone else had a similar problem before I did
that.
Andy
David Whitten
Jan 27, 2012, 4:23:45 PM1/27/12
to hard...@googlegroups.com
Since your host operating system is Microsoft Windows, I think you should be aware that it sometimes marks
files as inaccessible if they came from the internet. If you right click on the files and choose properties, do you
get a message with the label
Security: This file came from another computer and might be blocked to help protect this computer
and a button with the label "Unblock" next to it?
If so, you might need to click that button to convince MS Windows to give you permission to access it.
David
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com
Andy Bruce
Jan 27, 2012, 4:34:22 PM1/27/12
to hard...@googlegroups.com
Thanks David...I'll look at that immediately...
AND the winner is...several of the files are read only.
This is a new one on me...I feel a little taller
Maybe this will do the trick
I'll post the results
Thanks Again David,
Andy
AND the winner is...several of the files are read only.
This is a new one on me...I feel a little taller
Maybe this will do the trick
I'll post the results
Thanks Again David,
Andy
David
--To unsubscribe, send email to Hardhats+u...@googlegroups.com
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com
Andy Bruce
Jan 27, 2012, 4:40:39 PM1/27/12
to hard...@googlegroups.com
Sorry to keep dunning the list but...
ITS UP AND RUNNING!
I appreciate the help
ITS UP AND RUNNING!
I appreciate the help
MikeParks
Feb 1, 2012, 3:34:41 PM2/1/12
to Hardhats
John did you find out why $#happy7 doesn't work? Thanks!
MikeParks
Feb 1, 2012, 3:42:55 PM2/1/12
to Hardhats
disregard...I see the next post saying worldvista6 is the correct
access code...thanks!
access code...thanks!
Luis Ibanez
Feb 3, 2012, 6:38:18 PM2/3/12
to hard...@googlegroups.com
-------------------------------------
It worked great for me.
I used yesterday's download of the dEWDrop
7z file, and everything went very smoothly.
Following the detailed instructions,
I was able to connect at the first try,
both from a browser in the laptop
hosting the VA, and from an iPad.
Congratulations, this is very impressive.
Luis
R Richards
Feb 4, 2012, 12:51:34 AM2/4/12
to Hardhats
Rob,
In order to make good use of this VM, I would like to leave it running
on my home computer continuously, and access it remotely.
As I am running a number of services (like WebDAV on port 80) on my
host, would it be possible in the next VM release:
(1) install and configure openssl
(2) provide configuration options so we can set default http port to
anything other than 80.
Alternately, would it be possible to make available the latest and
greatest dEWDrop as a machine on AWS? The would resolve the port
conflict and ssh issues.
Rafael
On Jan 17, 10:26 am, rtweed <rob.tw...@gmail.com> wrote:
> Prior to a fuller, more formal announcement (not sure if one is
> planned), this is more of a "heads up" for those interested in trying
> out and evaluating the first incarnation of what is intended to be an
> evolving resource.
>
> As described in detail by George Lilly at the 24th VistA Community
> Meeting (VCM) last Sunday, and announced and demonstrated at the very
> end of the VCM:
>
> - a fully installed and pre-configured virtual machine, complete with
> GT.M and the latestEWD, running on Ubuntu Linux 10.10 + Apache +
In order to make good use of this VM, I would like to leave it running
on my home computer continuously, and access it remotely.
As I am running a number of services (like WebDAV on port 80) on my
host, would it be possible in the next VM release:
(1) install and configure openssl
(2) provide configuration options so we can set default http port to
anything other than 80.
Alternately, would it be possible to make available the latest and
greatest dEWDrop as a machine on AWS? The would resolve the port
conflict and ssh issues.
Rafael
On Jan 17, 10:26 am, rtweed <rob.tw...@gmail.com> wrote:
> Prior to a fuller, more formal announcement (not sure if one is
> planned), this is more of a "heads up" for those interested in trying
> out and evaluating the first incarnation of what is intended to be an
> evolving resource.
>
> As described in detail by George Lilly at the 24th VistA Community
> Meeting (VCM) last Sunday, and announced and demonstrated at the very
> end of the VCM:
>
> - a fully installed and pre-configured virtual machine, complete with
> m_apache
> - the full version of Meaningful Use-certified WorldVistA
> - configured as a fully-fledged hospital, with preconfigured wards,
> beds, clinics etc
> - configured for both Inpatients *and* Outpatients
> - pre-installed with a large population of test patients with results,
> histories etc etc
> - CPRS
> - a fully working version of VistACom, complete with full source code
>
> (I'm sure George can further refine and detail what's in it).
>
> ForEWDdevelopment purposes, it is pre-installed with the Sencha
> - the full version of Meaningful Use-certified WorldVistA
> - configured as a fully-fledged hospital, with preconfigured wards,
> beds, clinics etc
> - configured for both Inpatients *and* Outpatients
> - pre-installed with a large population of test patients with results,
> histories etc etc
> - CPRS
> - a fully working version of VistACom, complete with full source code
>
> (I'm sure George can further refine and detail what's in it).
>
> Touch Javascript framework (version 1.1). Others including YUI will
> follow.
>
> It's currently available as a VMWare VM, but the intention is that
> there will be other incarnations for use with other Virtualised
> environments such as VirtualBox etc.
>
> In other words, this is everything anyone needs to get up and running
> in just a few minutes with an entire VistA system, so it's going to be
> ideal for, inter alia:
>
> - evaluation, testing and demonstration of VistA
> - learning / training in the use and configuration of VistA
> -EWDtraining
> - a platform forEWD-based VistA application development (for both
> follow.
>
> It's currently available as a VMWare VM, but the intention is that
> there will be other incarnations for use with other Virtualised
> environments such as VirtualBox etc.
>
> In other words, this is everything anyone needs to get up and running
> in just a few minutes with an entire VistA system, so it's going to be
> ideal for, inter alia:
>
> - evaluation, testing and demonstration of VistA
> - learning / training in the use and configuration of VistA
> -EWDtraining
> desktop & mobile [iPhone, iPad, Android] applications)
>
> In yet other words, this is something we've all been waiting for and
> an incredibly important step forwards for WorldVistA.
>
> For those on theEWDTraining Course, this is the VM we'll use for
>
> In yet other words, this is something we've all been waiting for and
> an incredibly important step forwards for WorldVistA.
>
> Lessons 9 & 10.
>
> So how do you get your hands on this amazing beast?
>
> 1) Download a copy fromhttp://www.fourthwatchsoftware.com/dEWDrop.7z
>
> So how do you get your hands on this amazing beast?
>
> (It's about 2.4Gb)
>
> 2) De-compress it using a 7-zip tool such as Stuffit Expander.
> Anything capable of handling 7-zip format should be fine. It will
> expand to about 9.5Gb, so it's pretty big (as you'd expect!)
>
> 3) Fire up a VMWare client (the free VMWare Player is fine, but VMWare
> WorkStation, VMWare Server and VMWare Fusion will all work)
>
> 4) When you first start it, it will probably ask you if you moved it
> or copied it - say you copied it.
>
> 5) The Linux server will boot. Its default networking configuration
> is Bridged networking and DHCP is configured, so it will grab an IP
> address automatically. (You can reconfigure it through VMWare to use
> NAT if bridged won't work on your network)
>
> 6) Login to the server on the VMWare console window: Username:
> vista / Password:ewd
>
> 7) Find out the IP address by typing: ifconfig You should see a
> recognisable IP address near the top of the output
>
> 8) The VM is already SSH enabled, so do everything else from SSH
> connections (eg Windows users can use WinSCP and puTTY)
>
> 9)EWDand Apache are already up and running, so you can point a
>
> 2) De-compress it using a 7-zip tool such as Stuffit Expander.
> Anything capable of handling 7-zip format should be fine. It will
> expand to about 9.5Gb, so it's pretty big (as you'd expect!)
>
> 3) Fire up a VMWare client (the free VMWare Player is fine, but VMWare
> WorkStation, VMWare Server and VMWare Fusion will all work)
>
> 4) When you first start it, it will probably ask you if you moved it
> or copied it - say you copied it.
>
> 5) The Linux server will boot. Its default networking configuration
> is Bridged networking and DHCP is configured, so it will grab an IP
> address automatically. (You can reconfigure it through VMWare to use
> NAT if bridged won't work on your network)
>
> 6) Login to the server on the VMWare console window: Username:
> vista / Password:ewd
>
> 7) Find out the IP address by typing: ifconfig You should see a
> recognisable IP address near the top of the output
>
> 8) The VM is already SSH enabled, so do everything else from SSH
> connections (eg Windows users can use WinSCP and puTTY)
>
> browser at the VM and try out the ewdMgr and VistACom applications:
>
> Assuming the IP address is 192.168.1.130, you'd use the following
> URLs (case sensitive!)
>
> ewdMgr:http://192.168.1.130/vista/ewdMgr/index.ewd
>
> VistACom:https://192.168.1.130/vista/VistACom/index.ewd
>
> If you're using VistACom, you should use desktop Safari or Chrome
> browsers, or of course you can use an iPad or Android tablet. It's
> also possible to use an iPhone or iPod Touch or many Android phones,
> but you'll find that in places the current version's UI isn't set up
> to cope with the much smaller screen area available to a phone.
>
> For VistACom use (or for accessing VistA generally), the following
> Access Code and Verify Code is pre-configured:
>
> A/C: worldvista
> V/C: $#happy7
>
> When you're asked to enter a patient name, just start typing, and it
> will automatically find and filter matching names in a combo pop-up
>
> That's it - start trying it out, but watch for future updates. On theEWDside, we'll be adding Node.js to it pretty soon (I already have a
>
> Assuming the IP address is 192.168.1.130, you'd use the following
> URLs (case sensitive!)
>
> ewdMgr:http://192.168.1.130/vista/ewdMgr/index.ewd
>
> VistACom:https://192.168.1.130/vista/VistACom/index.ewd
>
> If you're using VistACom, you should use desktop Safari or Chrome
> browsers, or of course you can use an iPad or Android tablet. It's
> also possible to use an iPhone or iPod Touch or many Android phones,
> but you'll find that in places the current version's UI isn't set up
> to cope with the much smaller screen area available to a phone.
>
> For VistACom use (or for accessing VistA generally), the following
> Access Code and Verify Code is pre-configured:
>
> A/C: worldvista
> V/C: $#happy7
>
> When you're asked to enter a patient name, just start typing, and it
> will automatically find and filter matching names in a combo pop-up
>
DL Wicksell
Feb 4, 2012, 3:02:39 PM2/4/12
to Hardhats
Rafael,
First off, you can set vmware player to use bridged networking,
although
that may give you problems on some networks, and that will give
dEWDrop
a different IP address on your network. OpenSSL is already installed
and
Apache is already configured to use it on dEWDrop release 1. I am
about
to announce the next release, release 2, later today.
Release 1 was really a beta, since I had to put it together very
quickly for
a conference. In release 2, for example, I have a local firewall
configured,
that closes port 80, as using a web application that is talking to a
VistA
system should NEVER use port 80 and be unencrypted. You should use
port 443/https or a port you configure to use SSL/TLS.
This virtual appliance is for testing WorldVistA EHR 2.0, and I
cannot and
will not configure it for eveyrone's personal use. If anyone wants
such service,
they may contact me, via email, privately, and we can talk about it.
So you are
on your own as far as configuring it to suit your own setups.
dEWDrop will constantly be improved and new releases will obsolete
old ones.
So you will have to make sure to save all your own work and add it to
the new
release of dEWDrop when it comes out and you upgrade to it.
I will be happy to answer questions, but don't expect me do configure
dEWDrop
for you, or to answer any question that a quick google search would
answer for you.
Keep in mind that dEWDrop is a testing release for WorldVistA EHR
2.0, that can
also be used as a development environment. As such it has EWD fully
configured and
working, even over https, and starting with release 2, later today,
will also have
Node.js installed, configured and working, though it doesn't yet parse
the complex
XSL transformations of the XML in the CCR/CCDs. That will probably be
fixed in
release 3. They work perfectly with Apache, however.
I hope this has answered your questions.
First off, you can set vmware player to use bridged networking,
although
that may give you problems on some networks, and that will give
dEWDrop
a different IP address on your network. OpenSSL is already installed
and
Apache is already configured to use it on dEWDrop release 1. I am
about
to announce the next release, release 2, later today.
Release 1 was really a beta, since I had to put it together very
quickly for
a conference. In release 2, for example, I have a local firewall
configured,
that closes port 80, as using a web application that is talking to a
VistA
system should NEVER use port 80 and be unencrypted. You should use
port 443/https or a port you configure to use SSL/TLS.
This virtual appliance is for testing WorldVistA EHR 2.0, and I
cannot and
will not configure it for eveyrone's personal use. If anyone wants
such service,
they may contact me, via email, privately, and we can talk about it.
So you are
on your own as far as configuring it to suit your own setups.
dEWDrop will constantly be improved and new releases will obsolete
old ones.
So you will have to make sure to save all your own work and add it to
the new
release of dEWDrop when it comes out and you upgrade to it.
I will be happy to answer questions, but don't expect me do configure
dEWDrop
for you, or to answer any question that a quick google search would
answer for you.
Keep in mind that dEWDrop is a testing release for WorldVistA EHR
2.0, that can
also be used as a development environment. As such it has EWD fully
configured and
working, even over https, and starting with release 2, later today,
will also have
Node.js installed, configured and working, though it doesn't yet parse
the complex
XSL transformations of the XML in the CCR/CCDs. That will probably be
fixed in
release 3. They work perfectly with Apache, however.
I hope this has answered your questions.
Nancy Anthracite
Feb 4, 2012, 3:11:02 PM2/4/12
to hard...@googlegroups.com, DL Wicksell
David, thank you VERY MUCH for all of the work you are doing on this. It is
real boon for the community in many ways. :-)
real boon for the community in many ways. :-)
--
Nancy Anthracite
Steve Owen
Feb 4, 2012, 4:57:15 PM2/4/12
to hard...@googlegroups.com
David, thanks for making this available. Very nice work.
Rafael,
--
DL Wicksell
Feb 4, 2012, 7:59:03 PM2/4/12
to Hardhats
Hello everyone,
First off, you are all welcome. I'm happy to be able to help the
community in this way.
I am formally announcing the latest dEWDrop, release 2. As before, it
is available as a 7zip
archive on my company's (Fourth Watch Software) website at:
http://www/fourthwatchsoftware.com
This release has fixed a bug, that was my fault, in VistACom. I have
cleaned up a bit of the
development configuration that Fourth Watch Software supplied. It
includes changes to the selection
of new persons/users supplied by Ignacio Valdes of Astronaut, LLC. It
has Node.js installed and
configured, out of the box to use port 8080. It is not yet configured
to use SSL, but should be for release 3.
Thanks to Rob Tweed of M/Gateway for helping me configure Node.js for
dEWDrop.
In order to use Node.js, you simply:
$ cd www/resources ; node ewd
and point your browser at port 8080. As before, dEWDrop contains the
EWD Manager application that
comes with EWD and the VistACom application that was developed by me,
supported by Oroville
Hospital, and which interfaces to the CCR/CCD package, developed by
George Lilly and packaged for
this version by OHUM. Rob Tweed, Chris Richardson, and Zach Gonzales
also provided some code that
is used by VistACom.
I have also configurd a local firewall, which will force you to use
port 443 to access the EWD applications
using Apache. You should ALWAYS encrypt medical data being accessed by
a web browser. When you log in,
you will see what release you are on, as well as the preconfigured
access/verify codes of a dummy user that
has test mail with CCR and CCD attachments, etc., so you can test
VistACom. Also, when logging in, you will
see your IP address (which can be seen again with the command $
ifconfig) and if you point a webkit based
browser at it, you can run the EWD applications, making sure to
substitute your own IP address.
E.g. https://192.168.1.112/vista/ewdMgr/index.ewd
for the EWD Manager using Apache
E.g. https://192.168.1.112:8080/vista/ewdMgr/index.ewd
for the EWD Manager using Node.js
(Make sure to have Node running already)
E.g. https://192.168.1.112/vista/VistACom/index.ewd
for VistACom using Apache
E.g. https://192.168.1.112:8080/vista/VistACom/index.ewd
for VistACom using Node.js
I have also included my M-tools package of M Developer tools for
users of the vim editor. If you use vi/vim as your
editor of choice, this package may help boost your productivity.
To wrap this up, I have also installed and configured the ExtJS
package of custom tags for use in EWD. I have tested
it and it works great. Also due to be completed for release 3 I will
configure the YUI widget library for use with EWD apps.
There may be more things that I can't remember, but I think this is
most of it.
Special thanks to everyone at WorldVistA who has put in countless
hours of work into the WorldVistA 3-09 release that
dEWDrop contains, especially George Lilly and Nancy Anthracite. Also
thanks to Rick Marshall of the VISTA Expertise
Network and Zach Gonzales of Oroville Hospital for helping configure
parts of the VistA system for dEWDrop. Thanks again
to Rob Tweed for helping me solve some of the thornier problems with
the rendering of XSLT transformed XML in VistACom,
and LD "Gus" Landis for helping me with some of the GT.M configuration
in dEWDrop. So thank you all for your help in
making dEWDrop a resounding success. :-)
One last thing, if anyone would like a dEWDrop image in a different
format, or archived and compressed in a different way,
just let me know.
> --http://groups.google.com/group/Hardhats
> smime.p7s
> 6KViewDownload
First off, you are all welcome. I'm happy to be able to help the
community in this way.
I am formally announcing the latest dEWDrop, release 2. As before, it
is available as a 7zip
archive on my company's (Fourth Watch Software) website at:
http://www/fourthwatchsoftware.com
This release has fixed a bug, that was my fault, in VistACom. I have
cleaned up a bit of the
development configuration that Fourth Watch Software supplied. It
includes changes to the selection
of new persons/users supplied by Ignacio Valdes of Astronaut, LLC. It
has Node.js installed and
configured, out of the box to use port 8080. It is not yet configured
to use SSL, but should be for release 3.
Thanks to Rob Tweed of M/Gateway for helping me configure Node.js for
dEWDrop.
In order to use Node.js, you simply:
$ cd www/resources ; node ewd
and point your browser at port 8080. As before, dEWDrop contains the
EWD Manager application that
comes with EWD and the VistACom application that was developed by me,
supported by Oroville
Hospital, and which interfaces to the CCR/CCD package, developed by
George Lilly and packaged for
this version by OHUM. Rob Tweed, Chris Richardson, and Zach Gonzales
also provided some code that
is used by VistACom.
I have also configurd a local firewall, which will force you to use
port 443 to access the EWD applications
using Apache. You should ALWAYS encrypt medical data being accessed by
a web browser. When you log in,
you will see what release you are on, as well as the preconfigured
access/verify codes of a dummy user that
has test mail with CCR and CCD attachments, etc., so you can test
VistACom. Also, when logging in, you will
see your IP address (which can be seen again with the command $
ifconfig) and if you point a webkit based
browser at it, you can run the EWD applications, making sure to
substitute your own IP address.
E.g. https://192.168.1.112/vista/ewdMgr/index.ewd
for the EWD Manager using Apache
E.g. https://192.168.1.112:8080/vista/ewdMgr/index.ewd
for the EWD Manager using Node.js
(Make sure to have Node running already)
E.g. https://192.168.1.112/vista/VistACom/index.ewd
for VistACom using Apache
E.g. https://192.168.1.112:8080/vista/VistACom/index.ewd
for VistACom using Node.js
I have also included my M-tools package of M Developer tools for
users of the vim editor. If you use vi/vim as your
editor of choice, this package may help boost your productivity.
To wrap this up, I have also installed and configured the ExtJS
package of custom tags for use in EWD. I have tested
it and it works great. Also due to be completed for release 3 I will
configure the YUI widget library for use with EWD apps.
There may be more things that I can't remember, but I think this is
most of it.
Special thanks to everyone at WorldVistA who has put in countless
hours of work into the WorldVistA 3-09 release that
dEWDrop contains, especially George Lilly and Nancy Anthracite. Also
thanks to Rick Marshall of the VISTA Expertise
Network and Zach Gonzales of Oroville Hospital for helping configure
parts of the VistA system for dEWDrop. Thanks again
to Rob Tweed for helping me solve some of the thornier problems with
the rendering of XSLT transformed XML in VistACom,
and LD "Gus" Landis for helping me with some of the GT.M configuration
in dEWDrop. So thank you all for your help in
making dEWDrop a resounding success. :-)
One last thing, if anyone would like a dEWDrop image in a different
format, or archived and compressed in a different way,
just let me know.
> smime.p7s
> 6KViewDownload
rtweed
Feb 5, 2012, 5:13:16 AM2/5/12
to Hardhats
Just to add an addendum to my original post: the direct URL for
downloading dEWDrop has now changed to:
http://www.fourthwatchsoftware.com/dEWDrop/dEWDrop.7z
Rob
downloading dEWDrop has now changed to:
http://www.fourthwatchsoftware.com/dEWDrop/dEWDrop.7z
Rob
rtweed
Feb 5, 2012, 5:28:11 AM2/5/12
to Hardhats
For anyone who is interested in using dEWDrop and wants to learn about
how EWD can be used to rapidly build new, modern web and mobile-web
UIs for VistA, a reminder that you can sign up to a 10 X 1hr course of
webinar-format lessons that have been recorded. The course covers
everything from the basics right through to its use with VistA and how
to customise it by building your own custom tags.
Sign up here:
http://www.regonline.com/Register/Checkin.aspx?EventID=1017708
Nancy will send you the links to the videos and slides.
Now we have the dEWDrop development platform that makes it so easy to
get up, running and started, we need lots of new developers!
Rob
how EWD can be used to rapidly build new, modern web and mobile-web
UIs for VistA, a reminder that you can sign up to a 10 X 1hr course of
webinar-format lessons that have been recorded. The course covers
everything from the basics right through to its use with VistA and how
to customise it by building your own custom tags.
Sign up here:
http://www.regonline.com/Register/Checkin.aspx?EventID=1017708
Nancy will send you the links to the videos and slides.
Now we have the dEWDrop development platform that makes it so easy to
get up, running and started, we need lots of new developers!
Rob
Michael Reach
May 31, 2012, 5:22:49 PM5/31/12
to hard...@googlegroups.com
So I tried the dEWDrop 2 Virtual Machine, and got most stuff working. Few things I'm perplexed by:
1) Seems to work fine with the Apache server [though of course I got really angry warnings from both Chrome and Firefox that my secure connection wasn't really].
But in node ewd:
In Chrome, for https://10.17.109.9:8080/vista/ewdMgr/index.ewd, I get
"SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error."
In Firefox, same url, got
"The connection was interrupted
The connection to 10.17.109.9:8080 was interrupted while the page was loading."
2) Another thing that perplexed me was that if I tried to get to gt.m from the command line, I got a lot of unhappy comments
"vista@dEWDrop:~$ gtm
Error opening file /home/vista/g/default.dat
: File exists
Error opening file /home/vista/g/tempgbl.dat
: File exists
%GTM-F-DBNOCRE, Not all specified database files, or their associated journal files were created
%GTM-W-JNLDISABLE, Specified journal option(s) cannot take effect as journaling is DISABLED on database file /home/vista/g/tempgbl.dat
%GTM-I-FILERENAME, File /home/vista/j/default.mjl is renamed to /home/vista/j/default.mjl_2012152145207
%GTM-I-JNLCREATE, Journal file /home/vista/j/default.mjl created for region DEFAULT with BEFORE_IMAGES
%GTM-I-JNLSTATE, Journaling state for region DEFAULT is now ON
%GTM-W-MUNOFINISH, MUPIP unable to finish all requested actions
MU-beta>"
Course, I wasn't sure I should use the prompt "gtm", so maybe there's a better way. After all that, I was in Mumps anyhow so I was happy. /gtm/gtm didn't work at all.
3) I wanted to try some ext-4 tags; I figured this was the newest version of ewd, and dEWDrop has Fileman already installed, so I could try some ext-4 on Fileman lookups, as Sam already discussed. So I downloaded ext-4 into /home/vista/www/ext-4/, created a new folder /home/vista/www/ewd/testing for a new application, added a file index.ewd straight out of page 2 of Rob's new ext-4 manual http://gradvs1.mgateway.com/download/EWD_EXTJS4_Reference.pdf
went into gtm and
"d compileAll^%zewdAPI("testing")
/home/vista/www/ewd/testing/ewdAjaxError.ewd
/home/vista/www/ewd/testing/ewdAjaxErrorRedirect.ewd
/home/vista/www/ewd/testing/ewdErrorRedirect.ewd
/home/vista/www/ewd/testing/index.ewd
%GTM-E-UNDEF, Undefined local variable: pageName
%GTM-I-RTSLOC, At M source location outputDOM+19^%zewdGTMRuntime"
Was I mistaken that dEWDrop had all the pieces I needed, or did I forget a step?
Thanks, Michael
Michael Reach
May 31, 2012, 7:31:43 PM5/31/12
to hard...@googlegroups.com, Michael Reach, nanth...@earthlink.net
It does, thanks. And some of it I would have seen if I read a little further in the ext-4 docs!
Michael
Michael Reach
May 31, 2012, 7:56:40 PM5/31/12
to hard...@googlegroups.com, Michael Reach, nanth...@earthlink.net
But I'm still getting the same compile error,
%GTM-E-UNDEF, Undefined local variable: pageName
%GTM-I-RTSLOC, At M source location outputDOM+19^%zewdGTMRuntime
even for the helloworld version 1 page.
Nancy Anthracite
May 31, 2012, 8:05:35 PM5/31/12
to hard...@googlegroups.com, Michael Reach
Look at this thread on December 19 to see if it helps
Problem: compileAll^%zewdAPI crashes when first "<" of ewd:config statement
does not exist.
--
Nancy Anthracite
On Thursday, May 31, 2012, Michael Reach wrote:
Problem: compileAll^%zewdAPI crashes when first "<" of ewd:config statement
does not exist.
--
Nancy Anthracite
On Thursday, May 31, 2012, Michael Reach wrote:
Michael Reach
May 31, 2012, 8:22:24 PM5/31/12
to hard...@googlegroups.com, Michael Reach, nanth...@earthlink.net
Hmm. But the new ext-4 setup doesn't use ewd:config any more.
But - I've just noticed that my dEWDrop machine (which was the latest version 2 that just came out) is using ewd build 894. The ext-4 docs say you need build 918 or later! So, you're right, the parser is probably looking for ewd:config or something and getting a headache!
So, how do I upgrade to the newest version of ewd on my dEWDrop?
Michael Reach
May 31, 2012, 10:45:45 PM5/31/12
to hard...@googlegroups.com, Michael Reach, nanth...@earthlink.net
I'd add that the usual way to install: Getting the latest version of ewd from github, unzipping it, and copying it over on top of the older version (which I guess is in /opt/lsb-mgateway/ewd/894 ?) isn't going to work as user "vista"; those files are owned by "root". Nor can I create a new direction /920 there. Unless we have the root password?
Nancy Anthracite
May 31, 2012, 10:53:48 PM5/31/12
to Michael Reach, hard...@googlegroups.com
I suspect (and maybe I should shut up since I have already messed up once
tonight) that this is ubuntu so you need to be the user, enter sudo su, and
then enter the password of the user to become root.
--
Nancy Anthracite
On Thursday, May 31, 2012, Michael Reach wrote:
tonight) that this is ubuntu so you need to be the user, enter sudo su, and
then enter the password of the user to become root.
--
Nancy Anthracite
On Thursday, May 31, 2012, Michael Reach wrote:
Kevin Toppenberg
Jun 1, 2012, 7:48:01 AM6/1/12
to hard...@googlegroups.com
Is this a demo system, i.e. filled with sample patients?
Does this include the pharmacy stuff needed for meaningful use?
Thanks
Kevin
On Tuesday, January 17, 2012 10:26:30 AM UTC-5, rtweed wrote:
Does this include the pharmacy stuff needed for meaningful use?
Thanks
Kevin
On Tuesday, January 17, 2012 10:26:30 AM UTC-5, rtweed wrote:
Prior to a fuller, more formal announcement (not sure if one is
planned), this is more of a "heads up" for those interested in trying
out and evaluating the first incarnation of what is intended to be an
evolving resource.
As described in detail by George Lilly at the 24th VistA Community
Meeting (VCM) last Sunday, and announced and demonstrated at the very
end of the VCM:
- a fully installed and pre-configured virtual machine, complete with
GT.M and the latest EWD, running on Ubuntu Linux 10.10 + Apache +
m_apache
- the full version of Meaningful Use-certified WorldVistA
- configured as a fully-fledged hospital, with preconfigured wards,
beds, clinics etc
- configured for both Inpatients *and* Outpatients
- pre-installed with a large population of test patients with results,
histories etc etc
- CPRS
- a fully working version of VistACom, complete with full source code
(I'm sure George can further refine and detail what's in it).
For EWD development purposes, it is pre-installed with the Sencha
Touch Javascript framework (version 1.1). Others including YUI will
follow.
It's currently available as a VMWare VM, but the intention is that
there will be other incarnations for use with other Virtualised
environments such as VirtualBox etc.
In other words, this is everything anyone needs to get up and running
in just a few minutes with an entire VistA system, so it's going to be
ideal for, inter alia:
- evaluation, testing and demonstration of VistA
- learning / training in the use and configuration of VistA
- EWD training
- a platform for EWD-based VistA application development (for both
desktop & mobile [iPhone, iPad, Android] applications)
In yet other words, this is something we've all been waiting for and
an incredibly important step forwards for WorldVistA.
For those on the EWD Training Course, this is the VM we'll use for
Lessons 9 & 10.
So how do you get your hands on this amazing beast?
1) Download a copy from http://www.fourthwatchsoftware.com/dEWDrop.7z
(It's about 2.4Gb)
2) De-compress it using a 7-zip tool such as Stuffit Expander.
Anything capable of handling 7-zip format should be fine. It will
expand to about 9.5Gb, so it's pretty big (as you'd expect!)
3) Fire up a VMWare client (the free VMWare Player is fine, but VMWare
WorkStation, VMWare Server and VMWare Fusion will all work)
4) When you first start it, it will probably ask you if you moved it
or copied it - say you copied it.
5) The Linux server will boot. Its default networking configuration
is Bridged networking and DHCP is configured, so it will grab an IP
address automatically. (You can reconfigure it through VMWare to use
NAT if bridged won't work on your network)
6) Login to the server on the VMWare console window: Username:
vista / Password: ewd
7) Find out the IP address by typing: ifconfig You should see a
recognisable IP address near the top of the output
8) The VM is already SSH enabled, so do everything else from SSH
connections (eg Windows users can use WinSCP and puTTY)
9) EWD and Apache are already up and running, so you can point a
browser at the VM and try out the ewdMgr and VistACom applications:
Assuming the IP address is 192.168.1.130, you'd use the following
URLs (case sensitive!)
ewdMgr: http://192.168.1.130/vista/ewdMgr/index.ewd
VistACom: https://192.168.1.130/vista/VistACom/index.ewd
If you're using VistACom, you should use desktop Safari or Chrome
browsers, or of course you can use an iPad or Android tablet. It's
also possible to use an iPhone or iPod Touch or many Android phones,
but you'll find that in places the current version's UI isn't set up
to cope with the much smaller screen area available to a phone.
For VistACom use (or for accessing VistA generally), the following
Access Code and Verify Code is pre-configured:
A/C: worldvista
V/C: $#happy7
When you're asked to enter a patient name, just start typing, and it
will automatically find and filter matching names in a combo pop-up
That's it - start trying it out, but watch for future updates. On the
EWD side, we'll be adding Node.js to it pretty soon (I already have a
rtweed
Jun 1, 2012, 8:19:45 AM6/1/12
to Hardhats
Just change directory/file permissions as appropriate using sudo chmod
Password is ewd
Rob
Password is ewd
Rob
Nancy Anthracite
Jun 1, 2012, 8:30:16 AM6/1/12
to hard...@googlegroups.com
Yes I believe it does, including some of the bad codes and discontinued or
non-existant meds required to pass the test, so don't use it in production.
--
Nancy Anthracite
non-existant meds required to pass the test, so don't use it in production.
--
Nancy Anthracite
Michael Reach
Jun 1, 2012, 11:41:19 AM6/1/12
to hard...@googlegroups.com
I added those new routines, and recompiled *.m, and am now also able to compile helloworld.ewd - but a lot of other stuff seems to have gotten messed up in the process. node ewd now gives an error:
-----------------
vista@dEWDrop:~$ node ewd
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: Cannot find module '/home/vista/ewd'
at Function._resolveFilename (module.js:334:11)
at Function._load (module.js:279:25)
at Array.0 (module.js:470:10)
at EventEmitter._tickCallback (node.js:192:40)
vista@dEWDrop:~$
----------------
And the Apache server no longer shows the ewd pages that were working before, such as
I get
----------------
This webpage is not available
Google Chrome could not load the webpage because 10.17.109.9 took too long to respond...
----------------
I know the server is still operating, because I can ping it. So I'm guessing the ewd gateway is erroring someplace.
Thanks, Michael
DL Wicksell
Jun 1, 2012, 2:30:20 PM6/1/12
to hard...@googlegroups.com
Hello Michael,
I am the creator and maintainer of dEWDrop. I have been a bit negligent, as I haven't written any documentation for it. I've just be slammed with work lately.
I will try to answer your questions real quick. First off, the 2nd release of dEWDrop is many months old, and has the then current version of EWD, and everything
else. It was released even before GT.M 5.5-000 was released, so that is even outdated. The good news is that I am currently working on the third release, and
hope to have it release very soon.
1) The really angry warnings are inevitable. dEWDrop does not have a TLS certificate signed by a Certificate Authority. If anyone wants to pay for one, I'd use it. ;-)
I made a mistake in release 2, and the self-signed certificate I made expires quickly. I have fixed that for release 3, which has a self-signed certificate that expires
in 10 years. What you should do, is look at the certificate in the browser and in my docs I will put the SHA1 fingerprint, so you can compare. But it should say dEWDrop
and my companies name, Fourth Watch Software, LC.
In release 2, Node.js doesn't work with TLS/SSL encryption, so you have to change the URL to use the http protocol, rather than the https protocol.
I think I will try to work up an encrypted solution with Node.js for the next release.
2) This is an issue that I didn't think of. When you invoked the command, gtm, you were executing a shell script written by Fidelity, which I haven't read in depth, that tries
to actually create a GT.M environment from scratch, I believe. Since one already exists in dEWDrop, that is why you were getting those errors. I never invoke GT.M with
a gtm command, because it isn't a part of the GT.M executable. On some systems it might be a shell script, on others, an alias, but you never know what it will do. In my
opinion, the correct way to invoke programmer mode in GT.M is to call it by the executable, mumps -direct, or to run a routine, mumps -run INETD^%ZMGWSIS or any other
routine calling point. That will work the exact same on EVERY GT.M system that does not have you locked into some sort of captive user or restricted menu or shell environment.
For release 3, since it is not needed for dEWDrop, I have turned off the execute bit for the gtm shell script, so typing gtm will just give you a permission denied error.
3) You already figured this one out, but the latest version of EWD at the time I created release 2 was 894, and was before Rob released the Ext JS 4 tags. The Ext JS 2 tags are
installed and work in release 2. Of course, release 3 will have the latest and greatest installed and working. And because of time, I didn't get the YUI tags working in release 2,
but they will work for release 3.
4) In another post you mention an issue starting Node up. That is an easy one, you have to be in the same directory as the JS code you are running with Node, and that is located
in www/resources, so you'd have to change directories there first, or invoke Node with the relative path, like this: node www/resources/ewd. Perhaps I will come up with an easier
way of running that. I know, without docs, this can be a pain in the rear. Rob Tweed has been getting on me for that, so I will try to have some documentation with release 3 of
dEWDrop, which I hope to be able to release very soon.
Thanks for your interest in dEWDrop. In the future, you may want to email me directly. I am pretty bad about reading through hard hats or the google groups, as I have no time for it.
I also get digest summary emails, but they get to may a day or two later than when people are asking questions, and I only skim them, so don't always see everything.
You can email me at dlwic...@fourthwatchsoftware.com and my name is David Wicksell. If you email me, I will get back to you, but I can't promise it will be immediately. :-) Thanks.
I am the creator and maintainer of dEWDrop. I have been a bit negligent, as I haven't written any documentation for it. I've just be slammed with work lately.
I will try to answer your questions real quick. First off, the 2nd release of dEWDrop is many months old, and has the then current version of EWD, and everything
else. It was released even before GT.M 5.5-000 was released, so that is even outdated. The good news is that I am currently working on the third release, and
hope to have it release very soon.
1) The really angry warnings are inevitable. dEWDrop does not have a TLS certificate signed by a Certificate Authority. If anyone wants to pay for one, I'd use it. ;-)
I made a mistake in release 2, and the self-signed certificate I made expires quickly. I have fixed that for release 3, which has a self-signed certificate that expires
in 10 years. What you should do, is look at the certificate in the browser and in my docs I will put the SHA1 fingerprint, so you can compare. But it should say dEWDrop
and my companies name, Fourth Watch Software, LC.
In release 2, Node.js doesn't work with TLS/SSL encryption, so you have to change the URL to use the http protocol, rather than the https protocol.
I think I will try to work up an encrypted solution with Node.js for the next release.
2) This is an issue that I didn't think of. When you invoked the command, gtm, you were executing a shell script written by Fidelity, which I haven't read in depth, that tries
to actually create a GT.M environment from scratch, I believe. Since one already exists in dEWDrop, that is why you were getting those errors. I never invoke GT.M with
a gtm command, because it isn't a part of the GT.M executable. On some systems it might be a shell script, on others, an alias, but you never know what it will do. In my
opinion, the correct way to invoke programmer mode in GT.M is to call it by the executable, mumps -direct, or to run a routine, mumps -run INETD^%ZMGWSIS or any other
routine calling point. That will work the exact same on EVERY GT.M system that does not have you locked into some sort of captive user or restricted menu or shell environment.
For release 3, since it is not needed for dEWDrop, I have turned off the execute bit for the gtm shell script, so typing gtm will just give you a permission denied error.
3) You already figured this one out, but the latest version of EWD at the time I created release 2 was 894, and was before Rob released the Ext JS 4 tags. The Ext JS 2 tags are
installed and work in release 2. Of course, release 3 will have the latest and greatest installed and working. And because of time, I didn't get the YUI tags working in release 2,
but they will work for release 3.
4) In another post you mention an issue starting Node up. That is an easy one, you have to be in the same directory as the JS code you are running with Node, and that is located
in www/resources, so you'd have to change directories there first, or invoke Node with the relative path, like this: node www/resources/ewd. Perhaps I will come up with an easier
way of running that. I know, without docs, this can be a pain in the rear. Rob Tweed has been getting on me for that, so I will try to have some documentation with release 3 of
dEWDrop, which I hope to be able to release very soon.
Thanks for your interest in dEWDrop. In the future, you may want to email me directly. I am pretty bad about reading through hard hats or the google groups, as I have no time for it.
I also get digest summary emails, but they get to may a day or two later than when people are asking questions, and I only skim them, so don't always see everything.
You can email me at dlwic...@fourthwatchsoftware.com and my name is David Wicksell. If you email me, I will get back to you, but I can't promise it will be immediately. :-) Thanks.
Michael Reach
Jun 1, 2012, 3:10:23 PM6/1/12
to hard...@googlegroups.com
Thanks!
Reply all
Reply to author
Forward
0 new messages