Vista Web GUI - Another Way, Perhaps ...

[Wally Cash]

Hi to all,



I have been a quiet member of this group for a number of years and
would like to contribute something (hopefully useful) back. I have
been experimenting with Jim Self's wonderful M2Web as a XML middleware
server mediating between VistA and the OpenLaszlo RIA platform
(openlaszlo.org). This approach utilizes M2Web's native capabilities
as well as a series of shims to facilitate calling RPC functions. The
shims are lightweight and thus far their number has been kept
relatively small by refactoring as patterns of call signatures and
return types emerge. I'm also working on a number of small non-RPC
related routines which expose other functionality such as validation,
help, and posting of data. I've posted some screenshots of the work to
the link below.



While this approach should support module level capabilities, I do not
know if it would scale to encompass something as large and complex as
CPRS. I'm somewhat time constrained this week but will try to get the
code posted this weekend (AGPL license, thoughts?). As an aside, I
also plan to explore using OpenLaszlo in concert with Rob Tweed's
MGateway tools. They should be a great fit.

Finally, I am grateful for the knowledge and wisdom that has been so
freely shared by the HardHats community. This has been and continues
to be very much a learning process for me. Thanks to all!

http://wallycash.com/screenshots.html



Regards -Wally

[K.S. Bhaskar]

Your screenshots look great, Wally.

I would encourage you to use the GNU Affero General Public License v3
(http://www.gnu.org/licenses/agpl-3.0.txt) to license your work.
Especially since your code would be serving content over the net,
anything else could permit your code to be incorporated in proprietary
software delivered by an ASP.

Regards
-- Bhaskar

[JohnLeo Zimmer]

Wally Cash wrote:
>
> I have been a quiet member of this group for a number of years

"quiet" indeed.

Judging from the screenshots, Wally,
you've been working in the shadows long enough.
Look forward to seeing the code.

thanks,
jlz

[rtweed]

Wally

I think you should add an appropriate comment to the thread at
http://blog.crossoverhealth.com/2009/01/12/the-problem-with-vista-its-the-platform-stupid/

Your examples would be a great addition there!

Rob

[Nancy Anthracite]

So how did you learn to do all of this? Do you have prior experience with
VistA?

Are you related to Wally Fort? Anyone who did all of this sure might be. ;-)

--
Nancy Anthracite

[Ben Mehling]

On Wed, Jan 14, 2009 at 3:36 AM, Wally Cash <wally...@gmail.com> wrote:

 

help, and posting of data. I've posted some screenshots of the work to
the link below.

Looks great -- I see some familiar patient faces there!  :-)   

I'm  somewhat time constrained this week but will try to get the
code posted this weekend (AGPL license, thoughts?). As an aside, I

Given the network-based nature of your work, the AGPLv3 makes good sense.  I would suggest you start there as you explore your licensing options.

Nice to see your work out in the open,

- Ben

[Peter Johanson]

On Wed, 2009-01-14 at 03:36 -0800, Wally Cash wrote:

> been experimenting with Jim Self's wonderful M2Web as a XML middleware
> server mediating between VistA and the OpenLaszlo RIA platform
> (openlaszlo.org). This approach utilizes M2Web's native capabilities
> as well as a series of shims to facilitate calling RPC functions. The
> shims are lightweight and thus far their number has been kept
> relatively small by refactoring as patterns of call signatures and
> return types emerge. I'm also working on a number of small non-RPC

Wally,

Very cool!

I'm curious to see how exactly you're doing the network calls. When you
say "XML middleware" is it SOAP? XML-RPC? Something else?

Looking forward to seeing the code, and watching your work progress,

-pete

The information contained in this email may be confidential and/or may be covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions.. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. To contact our email administrator directly, send to an email message to help...@medsphere.com. Thank you.

[Wally Cash]

Thanks for the feedback!

Bhaskar and Ben confirm my conclusion that AGPLv3 is the best way to
protect the code for the community - AGPLv3 it is. I will add the
appropriate licensing info and get it posted this weekend.

The comments and questions from Peter have made me realize that the
term "XML middleware server" was somewhat misleading. Perhaps "1/2 XML
middleware server" would be more accurate :-) What I have done is to
configure OpenLaszlo dataset sources as CGI requests to M2Web and am
utilizing M2Web and the shims to return an XML response which the
datasets then consume natively. Sorry for the confusion.

No, Nancy, I do not have previous VistA experience. Ironically, I
began looking at M/FileMan/VistA stack several years ago as a possible
platform upon which to solve an unrelated problem - but that's another
story. I have learned more from following and listening to Harhats
discussions over time than any other source. You will see that what I
have done is really not all that difficult to do. That's the point,
and what I wanted to share - that bolting an RIA interface onto M/
Fileman/VistA can be a relatively straightforward process if you
employ tools such as OpenLaszlo/M2Web or EWD to handle the plumbing.

Cheers --Wally

[hkw]

congrats on your work , Using M2WEB gives clean interfacing than any
other methodology .
looking forward to more info on developing other VistA modules.
how is interfacing done for images/media files and respective data
associated with it.

regards
hemanshu

[Jim Self]

Wally Cash wrote:

Hi to all,



I have been a quiet member of this group for a number of years and
would like to contribute something (hopefully useful) back. I have
been experimenting with Jim Self's wonderful M2Web as a XML middleware
server mediating between VistA and the OpenLaszlo RIA platform
(openlaszlo.org).

Very interesting. The screenshots are impressive. I am not familiar with OpenLaszlo, although I am sure I read something of it a couple of years ago. After your announcement I read that the OpenLaszlo server runs on Java and I found an announcement from 2006 that OpenLaszlo would be using some low-level features from Dojo for DHTML.

Can you tell us more of the development environment you are using and how you developed the code behind the screenshots?

 This approach utilizes M2Web's native capabilities
as well as a series of shims to facilitate calling RPC functions.

Which native capabilities?

What do you mean by shims and are you referring to the RPC functions defined in the VistA Remote Procedure file or some of the data query or FM-API features exposed in M2Web?

The
shims are lightweight and thus far their number has been kept
relatively small by refactoring as patterns of call signatures and
return types emerge.

I was thinking that it might be worthwhile and not too difficult to provide a generalized HTTP based alternative to the VistA RPC broker, although the existing RPC's defined there might not be a best match to the capabilities of browser based applications.

It sounds like your work might be a start in that direction. At the least, it would provide some illumination of the potential and some of the complications.

 I'm also working on a number of small non-RPC
related routines which expose other functionality such as validation,
help, and posting of data. I've posted some screenshots of the work to
the link below.
  

The last screenshot appears to be related to the Dojo based patient registration in M2Web, but without any of the data-type aware input widgets.

While this approach should support module level capabilities, I do not
know if it would scale to encompass something as large and complex as
CPRS. I'm  somewhat time constrained this week but will try to get the
code posted this weekend (AGPL license, thoughts?). As an aside, I
also plan to explore using OpenLaszlo in concert with Rob Tweed's
MGateway tools. They should be a great fit.

Finally, I am grateful for the knowledge and wisdom that has been so
freely shared by the HardHats community. This has been and continues
to be very much a learning process for me. Thanks to all!

http://wallycash.com/screenshots.html
  

I am looking forward to seeing your code and any ideas you can share for further development of M2Web and related projects.

-- 

---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Information Technology Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
---------------------------------------
M2Web Demonstration with VistA
(http://vista.vmth.ucdavis.edu/)
---------------------------------------

[Wally Cash]

On Jan 15, 1:02 pm, hkw <hkwath...@gmail.com> wrote:

> Using M2WEB gives clean interfacing than any
> other methodology .

I agree.

> looking forward to more info on developing other VistA modules.
> how is interfacing done for images/media files  and respective data
> associated with it.

Since I chose to use Medsphere's OpenVista implementation for this
exercise and thus used the model employed by the Medsphere OpenVista
CIS client. Namely, storing the images under the Apache document root
directory using the same conventions as Medsphere. The only difference
is that I am using plain old http vs. https simply to avoid the hassle
of setting up an ssl server locally. I wish that I understood VistA
imaging better.

[Wally Cash]

> Very interesting. The screenshots are impressive. I am not familiar with
> OpenLaszlo, although I am sure I read something of it a couple of years
> ago. After your announcement I read that the OpenLaszlo server runs on
> Java and I found an announcement from 2006 that OpenLaszlo would be
> using some low-level features from Dojo for DHTML.
>
> Can you tell us more of the development environment you are using and
> how you developed the code behind the screenshots?
>

First of all the code in question can now be downloaded at
http://wallycash.com/download.html. I would appreciate comments,
criticism, ideas, and priorities.

Being somewhat old school I use Vim as my code editor with syntax
extensions for lzx and M, the Firefox browser, and the built-in
OpenLaszlo debugger.

The methodology is something like:
1. Identify a feature to implement.
2. Identify the RPC associated with that feature by invoking said
feature on the the OpenVista CIS client and viewing the client server
conversation on the OVCIS bridge (which I instantiate in verbose
mode). This has been invaluable in understanding which RPC's are
called and why.
3. Cross reference the RPC identified using the bridge to the VistA
RPC file.
4. Study the source code for the RPC in question.
5. Use an existing shim to call and return XML from the RPC if
possible or create a function specific shim it not.
6. Test and debug.

> > This approach utilizes M2Web's native capabilities
> > as well as a series of shims to facilitate calling RPC functions.
>
> Which native capabilities?
>

Jim, here I'm referring to the substantial query capabilities built
into M2Web. For example, I am using the query mechanism that you have
provided with M2web to populate the patient listbox and to filter
based on provider, ward, and specialty. Querying for data of this type
seems to be simpler than obtaining it by invoking RPCs IMHO.I did some
minor tweaks to a couple of routines (listed in the M2Web changelog)
to make the output a bit more Laszlo friendly. While these tweaks
were not strictly necessary, learning how and where to make them
helped me to better understand the inner workings of M2Web.

> What do you mean by shims and are you referring to the RPC functions
> defined in the VistA Remote Procedure file or some of the data query or
> FM-API features exposed in M2Web?
>

The shims are contained in the lzRTN.m file and simply receive data
via CGI, parameterize and invoke RPCs, and parse the return values to
xml.

> > The
> > shims are lightweight and thus far their number has been kept
> > relatively small by refactoring as patterns of call signatures and
> > return types emerge.
>
> I was thinking that it might be worthwhile and not too difficult to
> provide a generalized HTTP based alternative to the VistA RPC broker,
> although the existing RPC's defined there might not be a best match to
> the capabilities of browser based applications.
>
> It sounds like your work might be a start in that direction. At the
> least, it would provide some illumination of the potential and some of
> the complications.
>

Yes. I have only been looking at the VistA code for slightly over two
years - I'm extremely green compared to most of the community. So I
simply decided to advance RPC by RPC. Initially, I had written
something like 30 function specific shims. As I began to recognize
patterns of call and return signatures I sorted them into cohorts and
refactored to more generalized shims. If memory serves I have replaced
some two dozen of the original shims with three of their generalized
brethren. Unfortunately, the consolidation comes at the price of
complexity. VistA appears to be a very heterogeneous environment. My
hope is that over time a more generalized mechanism will become
evident.

> > I'm also working on a number of small non-RPC
> > related routines which expose other functionality such as validation,
> > help, and posting of data. I've posted some screenshots of the work to
> > the link below.
>
> The last screenshot appears to be related to the Dojo based patient
> registration in M2Web, but without any of the data-type aware input widgets.
>

It is. I'm just playing with different things trying to figure out how
they work.

>
> I am looking forward to seeing your code and any ideas you can share for
> further development of M2Web and related projects.
>

Please, be careful what you wish for. Someone such as yourself will
likely find the code offensive!

Thanks --Wally