Moving CPRS and other VistA functionality into the browser

[John Willis]

I've been reading another thread on this forum, in which it was asserted that a web-enabled CPRS replacement would likely result in a drop in quality and functionality. This got me thinking about the topic of web-enabling VistA in general, debatable questions of native-vs.-browser aside. I think that the first run at the fence for any application replacement--regardless of source and target platforms--will probably be slightly less mature and functional than its predecessor, but can be refined over time to meet or exceed its predecessor in every possible way.

It seems like several things are at work here:

• Modern IT operations tend to favor web applications, especially if their design adapts to both the desktop browser, the tablet, and the smartphone.
• Any major enterprise application suite (like VistA) will raise eyebrows if this functionality is not provided, especially if the alternative is a glass teletype or a ScreenMan-style full screen TUI.
• Many purchasing decisions that are deferred to C-level executives will hinge on UX and visual appeal.
• There are a number of people working on and deploying web applications in the VistA ecosystem. I applaud all of these innovators heartily.
• These apps tend to be implemented in some flavor of EWD (original EWD, EWD Classic, EWD Lite, EWD.js). These tools--especially EWD.js--provide a tremendous amount of power and flexibility.
• There is little consistency among the applications' choice of client-side framework (jQuery/Bootstrap, ExtJS, Sencha Touch, etc.). This greatly affects the cohesion of VistA as a whole, and makes training more expensive and difficult, as no two applications look the same or function the same way.
• Power and quick learning will always be somewhat at odds, IMO. This is why a Bootstrap-style UI is probably more suited to PHRs/patient portals, while a more desktop-app-like framework such as ExtJS could be harnessed to great effect for internal apps (like a CPRS replacement).
• Each application exists in something of a stovepipe, either launching from a custom menu item in CPRS, or navigated to within the browser using a different URL for each.

I am wondering what it would take to get the community onto a set of UX and UI design guidelines to improve the overall UX of VistA, and what the benefits and drawbacks would be.

I've thought for a couple of years about the idea of creating some kind of framework for building VistA web applications (for providers, not for patients). This is the overall idea:

• Provide a sign-on for checking access/verify codes, without relying on CPRS.
• Provide an extensible UI, wherein individual applications/screens could function as plugins, taking authentication and authorization info as necessary. Individual apps within this wrapper could follow the tab-oriented design of CPRS for their main views, and still be able to open dialog boxes, etc. as provided by the client-side framework in use.
• Provide, as part of this extensible UI, standard dialog boxes for selecting patients, selecting providers, selecting encounters, etc. of which these "plugin" applications could make use, reducing duplicated code and encouraging consistency. Basically, any sort of browse/select operation that is shared by many VistA applications would be standardized, with a robust, simple, and well-documented client-side Javascript API.
• Use this extensible authentication and UI framework as a vehicle for providing CPRS functions in the browser in a piecemeal fashion, while lowering the overall barrier of entry and boilerplate code that developers would have to implement. I realize that a great deal of business rules and logic are currently embedded in CPRS, so this would not be a small undertaking, by any means.
• Applications coming from multiple developers/vendors could be integrated into one view.

Regardless of the outcome of this thread, this is something I may take a crack at. But I am curious to hear what--if anything--others in this community have pondered on these topics.

[Ben Irwin]

John,

I am hoping that this turns out to be a real interesting thread.  There are many ideas and directions of how to accomplish the task you are considering.  I will share a few thoughts of my own.

My main position is to develop every thing possible in MUMPS.  The reason for this in the VISTA environment is so that the code can be distributed through the patch distribution system (KIDS).  Another part of staying with MUMPS is that it is compatible with the open source community.

In the past I have worked and shared something that I called a simple web application.  The framework includes a single CGI script on the Linux side and a single CSP page or class on the Cache side.  These two different entry points for each of the different technologies is mostly the only difference.  The single entry point is designed so that depending on the context a different MUMPS routine is called to serve up the web page to display information of collect user input.

The routines were sectioned out with subroutines that would provide the JavaScript for the header section and footer section.  It also contained a call to a common CSS function to provide the style information.  Serving the JS and CSS within the page makes for a slightly faster page load.

The advantage of dynamically serving the JS is this can provide the nice menu structure individualized for the users security level.

In a web page design, I would recommend retiring the RPC broker and creating web functions to match the functionality.

This probably uses MUMPS more then you had in mind, but it is my opinion.  I look forward to hearing about your adventure.

Thanks,

Ben Irwin

[rtweed]

Please note, before any FUD increases:

> These apps tend to be implemented in some flavor of EWD (original EWD, EWD Classic, EWD Lite, EWD.js). 

"original EWD" and "EWD Classic" are one and the same thing, just a different way of referring to the same product

"EWD Lite" and "EWD.js" are also one and the same thing.  EWD Lite was the original working name for what I then re-branded EWD.js

So there are just 2 products in the EWD stable and not 4 as John implies:  

- The original EWD is a "server page" technology, which generates all the HTML, JavaScript etc from Mumps routines which, in turn, are generated by a compiler from files of XML & HTML

- The newer and more modern 100% JavaScript-based EWD.js which uses Mumps as a database (and a database that is abstracted to appear to be a JSON persistence engine), but which also allows legacy Mumps code to be executed from within JavaScript.

Regarding Ben's posting, essentially the original EWD was designed to do was to make his kind of approach more scalable, sustainable and maintainable.  Let me give some historical and technical background and perspective:

The original use of the web with Mumps started in about 1995 and quickly centred around a Mumps gateway product called WebLink (developed by my company M/Gateway but sold to InterSystems) - such early development used Ben's approach of writing Mumps routines that generated the HTML, JavaScript etc.  

For anyone developing large applications, it soon became clear that this approach was unsustainable and pretty much unmaintainable as you had a horrible mix of massive amounts of inter-twined Mumps code, HTML, JavaScript etc.  Additionally, every developer had to figure out a way of maintaining state and controlling security - it turned out that in general either they didn't (leaving horribly insecure applications), or did it badly and/or inconsistently, leaving gaping security holes in places.  For this reason, a number of frameworks developed whereby the developer created what appeared to be pages of HTML and these were converted into Mumps code by a compiler - those generated routines consisted largely of Mumps write commands that spat back the originally-specified HTML (very like the hand-crafted examples that Ben has shown elsewhere).  The other key feature of such frameworks was an automated and consistently-applied solution for security and session management, meaning less code and logic for the developer to worry about.  Such frameworks reduce the actual Mumps coding that a developer has to physically write to the bits that really matter - getting, validating and saving data and performing the "business logic" of the application.  All other Mumps code was either generated or run by the framework itself.

The earliest serious example of these frameworks was WebLink Developer (I was its author back in 1995/96, again it was sold to InterSystems).  InterSystems attempted to replace WebLink Developer with their Cache Server Pages (CSP) technology.  For a number of reasons I won't bore you with, I never liked their CSP concept, but one key feature was its dependence on Cache Objects and therefore its complete proprietary lock-in (actually, to this day the largest internet-facing web applications based on Cache still use WebLink Developer, not CSP - a little-known fact!).  

EWD was eventually my response, taking what I felt were the best aspects of WebLink Developer, but resolving a number of deficiencies that I'd become aware of over the years and adopting new, modern techniques.  EWD was originally written when I was consulting for a UK company called Mtivity, and provided a means of migrating them from an unmaintainable mess of hundreds of hand-crafted CSP pages to a sustainable, easily maintainable set of HTML pages from which CSP pages could be generated.  It turned out that hand-crafted CSP was little better than hand-crafted Mumps code in terms of maintainability - CSP does nothing to discourage an inevitable descent into an inter-twined spaghetti of Cache ObjectScript/Mumps, JavaScript, HTML and CSS.  So EWD was originally a framework for generating CSP pages from a higher-level abstraction that enforced separation of front-end and back-end code.

EWD evolved to work with any Mumps technology including GT.M - for this it makes use of an Open Source Apache gateway product called m_apache.  EWD (the original one) is now a mature and thoroughly tried and tested and secure product - it's what runs Quest Diagnostics' EzOrder interface to their Internet-facing Care360 application, for example. 

If, like Ben, you prefer to do your work in Mumps code, I'd strongly recommend using the original EWD - there's absolutely nothing to be gained by writing all that Mumps code yourself, other than gaining an understanding of just what frameworks such as EWD do for you in terms of saving you a ton of work, creating a maintainable code-base and looking after security and session management in a consistent way. Don't underestimate the importance and complexity of security in web applications - trust me, it's not something you want to roll yourself.  If you use EWD you get the benefit of a security solution that has been tested and audited thoroughly by the likes of Quest Diagnostics.

EWD.js moves the state of the art a long way forward, dropping the now old-fashioned "server pages" concept (as is happening elsewhere in the industry) and moving to a 100% JavaScript approach and using static HTML and JavaScript pages for the application front-end.  You can, in fact, still write your back-end business logic in Mumps code if you wish, and wrap it so that it can be invoked as a JavaScript function.  EWD.js retains much of the security and state management techniques and concepts of the original EWD, and once again looks after all of it automatically.

However, the key concept behind EWD.js is to provide a strategic future for legacy Mumps applications against a backdrop of what everyone in this community needs to understand (whether they like it or not) is a dwindling population of developers who know or want to learn the Mumps language.  EWD.js provides a realistic way of allowing the huge and growing population of JavaScript developers to be harnessed and provide a new generation of developers who can be the torch-bearers for VistA (and other such legacy Mumps applications).  EWD.js means that VistA's Mumps code doesn't have to be thrown away or rewritten before it can be used and developed upon by the new generation of developers - but it makes that Mumps code accessible by JavaScript developers in their terms, not those of a Mumps developer.  It sets the scene for a controlled and measured migration away from the Mumps language to JavaScript without throwing out the huge benefits of the massively and still relevant Mumps database.  EWD.js harnesses that NoSQL database capability by projecting the database as a JSON persistence engine - once again allowing the JavaScript developer to use the Mumps database in their terms, not those of a Mumps guy, whilst allowing the Mumps development community to continue working as normal - the best of both worlds.

I therefore see no benefits or strategic future whatsoever in raw Mumps development for web-enablement of VistA.  Neither do I see the original EWD as providing a long-term solution.  The strategic future is EWD.js: it has been designed on the belief that VistA is a product and heritage worth preserving and passing on to the next generation, and is based on coming to terms with the fact that it's not going to be possible to build and retain the numbers of Mumps developers needed to sustain VistA into the future.  Making it possible for the new generation of JavaScript developers to become VistA's future custodians, however, is, in my opinion, the sensible, right and proper thing to be doing. 

Rob

[rtweed]

On Monday, June 30, 2014 8:07:43 AM UTC+1, John Willis wrote:

I've thought for a couple of years about the idea of creating some kind of framework for building VistA web applications (for providers, not for patients). This is the overall idea:

• Provide a sign-on for checking access/verify codes, without relying on CPRS.
• Provide an extensible UI, wherein individual applications/screens could function as plugins, taking authentication and authorization info as necessary. Individual apps within this wrapper could follow the tab-oriented design of CPRS for their main views, and still be able to open dialog boxes, etc. as provided by the client-side framework in use.
• Provide, as part of this extensible UI, standard dialog boxes for selecting patients, selecting providers, selecting encounters, etc. of which these "plugin" applications could make use, reducing duplicated code and encouraging consistency. Basically, any sort of browse/select operation that is shared by many VistA applications would be standardized, with a robust, simple, and well-documented client-side Javascript API.
• Use this extensible authentication and UI framework as a vehicle for providing CPRS functions in the browser in a piecemeal fashion, while lowering the overall barrier of entry and boilerplate code that developers would have to implement. I realize that a great deal of business rules and logic are currently embedded in CPRS, so this would not be a small undertaking, by any means.
• Applications coming from multiple developers/vendors could be integrated into one view.

Regardless of the outcome of this thread, this is something I may take a crack at. But I am curious to hear what--if anything--others in this community have pondered on these topics.

I think you'll find that Chris Casey has done quite a bit of work in this area - see for example:

https://github.com/borochris/RCPClinicalHeadings

This demonstrator already includes VistA access code/verify code sign-on

Also see the stripped-down version that is included when you run Chris Edwards' OSEHRA VistA installer - this provides a set of examples showing how a single set of VistA back-end logic can be wrapped such that it is exposed for use within EWD.js for both browser-based applications and REST services.  It's all described in detail here:

http://robtweed.wordpress.com/2014/03/02/ewd-js-vista-a-technical-deep-dive-into-the-vista-demo-application/

Your suggested work would get my support, but please avoid re-inventing wheels and build on the work that Chris and I have already done.  You should also ensure that you build upon and retain compliance with the work of Sid Torason at Astute Semantics, eg:

http://astutesemantics.com/fileman-gui/

 

Rob

[Ben Irwin]

Yes, it's true, I am a little old and old fashion.  My first position as a college lab assistant was teaching machine code on the Intel 8080 chip.  Boy were we excited when the new and greatly improved 8086 came out.  So many more manual possibilities.

[Doug Martin]

I'd encourage folks to take a look at http://www.carewebframework.org, which provides a standardized, open-source platform and the extensibility you want.  There is a VistA (and RPMS) port with some plugins already built.  We have a complete EMR/CPOE system built on this framework (not on top of VistA) and up and running in a large county hospital.

[Steven Li]

Don't know about programming language and backend, but the VA has used three different applications based on browsers:

 

-VistAWeb

-JointLegacyViewer JLV (previously known as Janus)

-HealthManagementPlatform  HMP (previously known as AViVa).

 

My understanding is that they are leveraging JLV for current deliverables nearterm 2014 and then HMP for MU2 deliverables 2017. 

 

Perhaps that's a place to start to factor in where VA programming is going and adjust to refocus? Just thinking that may get better traction instead of another rail.

 

On Tue, Jul 1, 2014 at 11:49 AM, Doug Martin <mart...@email.com> wrote:

I'd encourage folks to take a look at http://www.carewebframework.org, which provides a standardized, open-source platform and the extensibility you want.  There is a VistA (and RPMS) port with some plugins already built.  We have a complete EMR/CPOE system built on this framework (not on top of VistA) and up and running in a large county hospital.

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Habiel]

I had to jump on today rather than respond on the weekend.

Dr. Douglas Martin's note is maddeningly modest.

John W, Dr. Martin has created three generations of a componentized
user interfaces with full capabilities to support an EMR, including
support for CCOW-like context changing. If you were at the Vista
Community Meeting, you would have met him and see how we requested an
encore presentation after his initial presentation.

Let me put this in simpler stark terms: What he has as the CareWeb
framework is the closest thing I have seen to a functional web
replacement for CPRS, without CPRS's shitty design decisions (which
admittedly was great in 1995!)

I would love to have something equivalent for EWD.js. It's the right
future facing technology that will last a long time to come. CareWeb
is in Java, and it doesn't have the advantages of Node.js. Let's
enumerate them:

- Bidirectional communication (i.e. TCP duplex communication)
- Same language on both server and client; easier for developers.
- Very rich open source ecosystem
- Far better web nativeness than Java.

John W, if I were you, I would get the CareWeb framework and starting
designing something like it. I don't think we will ever get something
that is better designed any time soon. By the third time doing this, I
am pretty sure Dr. Martin figured out a lot of things.

Just to give him more street cred, he wrote the VISTA XML Parser, the
PCL barcoding routines, base64 encoding routines; a good portion of
the RPMS GUI RPCs; a good portion of CIRN... I can say that he knows
what he is doing.

Sam

[Astute Semantics]

Don't worry, Sam - Astute Semantics is all over this.

You'll notice that Template GUI took one of the hardest parts of CPRS and translated it into the browser, the template editor.  The rest is surely to follow.

There will be another closely related release coming out by the middle of this month in addition to a Fileman GUI update.

My goal is to have a CPRS patient select and cover sheet completed by the first week of August since the short term is tied up with Fileman GUI enhancements.

- Sidney

[Doug Martin]

Thanks for the kudos, Sam.  Regarding the advantages of Node.js over Java, let me counter these with the following:

- Bidirectional TCP - I presume you are talking about WebSockets here.  This is certainly not unique to the Node.js world and could be implemented in our environment as well.  I think you will see more and more Ajax frameworks adopting this technology.  ZK, upon which CareWeb Framework is built, uses Comet push technology for bidirectional communication.

- Same language on client and server - ZK unifies client and server programming by providing a rendering engine that takes the UI component model constructed in Java on the server and renders it (using standard JavaScript and HTML) on the browser.  This means the Java is the programming language for our environment (though we do do some custom JavaScript programming to enhance ZK's capabilities).

- Very rich open source ecosystem - You can't get much richer than the ecosystem around Java.  We build on existing open source technologies (Spring, ZK, JQuery, JQuery UI, Apache Commons, ActiveMQ, Maven, FHIR, etc.).

- Far better web nativeness than Java - Again, ultimately things get rendered in JavaScript and HTML.  Not sure how you get more native than that.  The component model employed by ZK will be very natural to folks used to programming in Delphi, VB or C# in the thick client world.

-doug

[John Willis]

Not to put too fine a point on it, but Java would be my last choice
for this project, and I'm not interested in what the VA is doing or
wants to do. In my opinion, they're the reason VistA has been
directionless for decades.

[Kevin Toppenberg]

Hasn't the VA already made its decision (i.e. HMP).  And as good at Doug Martin's stuff is, hasn't it become irrelevant?

Kevin

On Tuesday, July 1, 2014 8:02:44 PM UTC-4, Sam Habiel wrote:

[John Willis]

John W, if I were you, I would get the CareWeb framework and starting
designing something like it. I don't think we will ever get something
that is better designed any time soon. By the third time doing this, I
am pretty sure Dr. Martin figured out a lot of things.

Just to give him more street cred, he wrote the VISTA XML Parser, the
PCL barcoding routines, base64 encoding routines; a good portion of
the RPMS GUI RPCs; a good portion of CIRN... I can say that he knows
what he is doing.

Sam

Thanks Sam,

Where can one find this CareWeb framework? is it FOSS, or at least does it have a demo? 

[JohnLeo Zimmer]

http://www.carewebframework.org/

https://github.com/carewebframework/carewebframework.github.io/wiki

[Sidney Seo]

In my humble opinion, EWD.js could migrate CPRS functionality into the browser with far more elegance and grace.

Why use Java which then renders to JavaScript when you can just start with JavaScript in the first place?

Here is the rationale for PayPal (among many other high volume outfits) to abandon Java and go with Node.js: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

Development:

• ​​
  Built almost
  ​​
  twice as fast with
  ​​
  fewer people
  
  
• Written in
  ​​
  33% fewer lines of code
  
  
• Constructed with
  ​​
  40% fewer files

​​Performance:

• Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
  
  
• 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.
  

[Doug Martin]

I guess we must agree to disagree on the topic of language selection and suitability (and yes, to Kevin's point, as to relevance as well).  I will say that belabored debate on language choice is rarely productive, mostly distracting, and never achieves consensus.  I am simply offering up one solution to the problem at hand.  I would again encourage those with an interest in this topic to look at the capabilities provided by the CareWeb Framework that are specifically designed to create an environment for collaborative development, something that is sorely lacking in the VistA world.

-doug

[Sidney Seo]

Doug, your work is amazing from what I've heard - please recognize that suggesting an alternative is not a personal attack on your merit.  You absolutely have my respect.

There is no pleasure gained from being right or proving the other person wrong here... the pleasure will be getting the Veterans a system that is up to standard with what is out there today in arguably less important sectors than healthcare.

The fact is that Netflix, eBay, Groupon, Walmart... even Microsoft Azure... are all running on Node.js.  

If it is trending with the giants of tech, shouldn't we at least consider it?

There seem to be many documented Java to Node.js implementations but very rarely is there one the other way around.

Even though healthy debate is difficult and distracting... what other way is there for the best solution to filter to the top for the greater benefit of our community?

I would gladly mark the EWD.js approach as flawed/inferior to Java if there is solid evidence to support the notion.

It is my hope that such evidence (or lack thereof) becomes available for the community at which point we all can benefit at the cost of participation in this admittedly cumbersome public discussion.

Thank you for your input, Doug.  I would love to build a relationship with you offline.

[Darren Coolidge]

Node.js is on the decline. This often happens to frameworks that try
to be everything to everyone. They cease to be useful and have too
big of footprint for the little things that people need from it. To
call it trending is the wrong word. Trended maybe I don't know. Just
putting in my 2 cents. (or what ever it costs to send an email now ;)

>>> - ​​
>>> Built almost
>>> * ​​twice as fast *with
>>> * ​​fewer people*
>>>
>>> - Written in
>>> * ​​33% fewer lines of code*
>>>
>>> - Constructed with
>>> * ​​40% fewer files*
>>>
>>>
>>> ​​Performance:
>>>
>>> - *Double the requests per second vs. the Java application*. This is

>>> even more interesting because our initial performance results were

>>> using a *single
>>> core for the node.js application compared to five cores in Java*. We

>>> expect to increase this divide further.
>>>

>>> - *35% decrease in the average response time* for the same page. This
>>> resulted in the pages being served *200ms faster*— something users

[rtweed]

On Friday, July 4, 2014 9:51:26 PM UTC+1, dcoo...@gmail.com wrote:

Node.js is on the decline. 

The evidence I read daily suggests otherwise, eg just a few examples:

http://strongloop.com/developers/node-js-infographic/

http://jxcore.com/business-case-for-javascript-and-node-js-jxcore/

http://viewfromtheedge.progress.com/2014/06/node-js-stay-npm-takes-top-billing-repositories/

http://thenewstack.io/node-js-an-enterprise-situation-report/

However, if you have contradictory evidence, do tell.

 

[Kevin Toppenberg]

My concern about node.js, and EWD that builds on them, is practical rather than technical.  From what I can see, when one connects node.js to mumps, it has "root" access to the database.  And while careful software engineering can make that safe, I would be surprised if VA IT administrators didn't suffer heartburn when considering letting it be attached to their system.  Yes, EWD has been added to the list of approved technology that can be used in the VA, but that doesn't mean that an administrator is going to let it happen.  VistALink, on the other hand, has an established track record, and a well define security model (the RPC environment).  Unfortunately, VistALink means java.

We are part of a project right now that is creating web-based resources to the provider.  But we are having to pretend to be CPRS, and use only CPRS-provided RPC's.  From the IT administrator's perspective, this is safe.  They would not be agreeable to even allowing new custom RPC's.  There is no way, in my opinion, that they would let EWD connect to their database.

So what I see as a next needed step, is a good, solid, safe way for node.js and EWD to connect in a manner that makes everyone happy.  Perhaps a EWD --> node.js --> VistALink --> mumps chain??  This would have the java layer just be a passthrough and hopefully wouldn't cause too much of a performance hit.

Kevin

[Kevin Toppenberg]

On Friday, July 4, 2014 4:51:26 PM UTC-4, dcoo...@gmail.com wrote:

Node.js is on the decline.  This often happens to frameworks that try
to be everything to everyone.  They cease to be useful and have too
big of footprint for the little things that people need from it.  To
call it trending is the wrong word.  Trended maybe I don't know.  Just
putting in my 2 cents. (or what ever it costs to send an email now ;)

I agree with Doug's point that arguing about which language / platform is best is rarely fruitful.  Let's say that you are correct that Node.js is less popular today vs 1 yr ago.  (I tend to agree with Rob that it is NOT declining, but that is beside the point. )  Does that really matter?  Pascal/Delphi has been on the decline for some time now, but it is still in the top 20 languages or so (http://langpop.com), and still gets the job done.  Which is the best brand of hammer? (http://gearpatrol.com/2013/07/03/nailed-it-5-best-hammers/)  I think it is the one you have in your toolbox.

Kevin

[Sam Habiel]

On Node and direct access to Globals. That is Mump's problem not node.js. Any RPC you call can do whatever the hell it wants anywhere in the database. Messages are almost identical in concept to RPCs... So I fail to see any difference in the security implications. 

But in any case, let's be clear about this: Dr Martin's solution has a very strong track record of it working and being in production. Depending on the community and funding, EWD.js may suffer what happened to EWD. One off applications that are not integrated in a Clinician's workflow. I don't think that's going to happen; but a lot depends on the right funders, clinicians and programmers involved. And that is rather unlikely to happen in the VA. 

Sam

--

[rtweed]

On Saturday, July 5, 2014 2:58:30 PM UTC+1, Kevin Toppenberg wrote:

From what I can see, when one connects node.js to mumps, it has "root" access to the database.  And while careful software engineering can make that safe, I would be surprised if VA IT administrators didn't suffer heartburn when considering letting it be attached to their system.

The Node.js connector to Cache uses exactly the same callin interface that is used for Java, .Net etc so is no less secure that using any other language or connector.  The level of database access is controlled at several levels - the Node.js process has to define the username and namespace to which it connects.  That restricts the Globals potentially accessible by your EWD.js applications.  Then, just as in *any* application, the user's access to the database is controlled by the application logic.  In the case of a properly-written VistA application using *any* technology, the correct approach is to use the correct kernel APIs that ensure access is determined by the user's DUZ.

If you're using the NodeM connector to GT.M, then access is controlled and limited via the standard use of environment variables - so no different from any form of application development in any other language or grafted on technology.

By the way, it's quite possible to invoke RPCs directly from within EWD.js applications if that's what you need to do.

Any suggestion that the Node.js-based access used by EWD.js is somehow inherently insecure or somehow less secure than any other form of access to VistA is, quite frankly, uninformed nonsense and/or mischievous FUD.  Indeed, there's also a whole raft of additional security layers built-in to EWD.js - please read:

http://robtweed.wordpress.com/2014/03/10/ewd-js-application-web-service-and-rest-security/

if someone thinks they have some hard evidence to the contrary, then I'd like it demonstrated please.

[rtweed]

On Saturday, July 5, 2014 2:58:30 PM UTC+1, Kevin Toppenberg wrote:

Perhaps a EWD --> node.js --> VistALink --> mumps chain??  This would have the java layer just be a passthrough and hopefully wouldn't cause too much of a performance hit.

I think I've lost the will to live

[John Willis]

>> Perhaps a EWD --> node.js --> VistALink --> mumps chain?? This would have
>> the java layer just be a passthrough and hopefully wouldn't cause too much
>> of a performance hit.
>
>
> I think I've lost the will to live
>

I think that several innocent kittens just died.

[Kevin Toppenberg]

On Saturday, July 5, 2014 11:52:57 AM UTC-4, rtweed wrote:

The Node.js connector to Cache uses exactly the same callin interface that is used for Java, .Net etc so is no less secure that using any other language or connector.  

I don't think VistALink uses Java, so this still doesn't address my security point.

>>On Node and direct access to Globals. That is Mump's problem not node.js. Any RPC you call can do whatever the hell it wants anywhere in the database

This is true, and is why the administrators don't want any new RPC's on their system (to say nothing about new root access to the database).  I made a prior post about creating a safe subset of Mumps.  Kind of like Douglas Crockford's "Javascrit: The Good Parts", we could have "Mumps: the Safe Parts".   There would be a code validator, and if the code passed, it would be allowed to run, otherwise not.  No one offered a reason that it wouldn't work.  I think it is very achievable and was disappointed by the lack of interest.

Kevin 

[Kevin Toppenberg]

I don't think VistALink uses Java, ...

I mean on the server side.  Obviously it does on the Java client side.  Just like the regular RPC Broker is Delphi/Pascal on the client, and mumps on the server.

Kevin 

[rtweed]

On Saturday, July 5, 2014 10:16:11 PM UTC+1, Kevin Toppenberg wrote:

This is true, and is why the administrators don't want any new RPC's on their system

I repeat:

I's quite possible to invoke any existing RPCs from within EWD.js applications.... or JS-interface underlying code within existing RPCs (which would remove a lot of unnecessary overhead of the current RPCs without incurring any difference in functionality or security).

[Kevin Toppenberg]

I repeat:

EWD can not execute RPC's on a mumps system without being given root access to the database.

Kevin

[rtweed]

On Saturday, July 5, 2014 10:48:02 PM UTC+1, Kevin Toppenberg wrote:

I repeat:

EWD can not execute RPC's on a mumps system without being given root access to the database.

I really must be missing something, Kevin - I have no idea what you're talking about

[Nancy Anthracite]

Kevin, could you explain what you mean by root access? Is it Programmer
access, i.e., $P(^VA(200,DUZ,0),"^",4)="@" ?

--
Nancy Anthracite

[Kevin Toppenberg]

It means the ability to execute this line of mumps code:

KILL ^DPT

That Programmer Access you are talking about only protects the system when one is running inside Menu Man etc.    So anyone that has access to a mumps prompt has root access.  And custom RPC's that are written have this ability because the RPC listener turns over execution to the mumps code in the RPC.  And EWD has this ability too because control is given to mumps code.

I don't want to come across as hating on EWD.  I think it is good technology and I think that it is much simpler to use than $@#$ VistALink.  And for my own system, I welcome having such "root" abilities.  I just get frustrated with the layers of security that are wrapped around existing systems at time.  I suspect that such caution comes from good reasons, but it can make getting anything done problematic.  I am just pointing out building a solution for the VA on EWD will need to get security approval at the same level as installing a KIDS patch with mumps code.

Kevin

[rtweed]

On Sunday, July 6, 2014 12:15:38 AM UTC+1, Kevin Toppenberg wrote:

It means the ability to execute this line of mumps code:

KILL ^DPT

That Programmer Access you are talking about only protects the system when one is running inside Menu Man etc.    So anyone that has access to a mumps prompt has root access.  And custom RPC's that are written have this ability because the RPC listener turns over execution to the mumps code in the RPC.  And EWD has this ability too because control is given to mumps code.

I don't want to come across as hating on EWD.  I think it is good technology and I think that it is much simpler to use than $@#$ VistALink.  And for my own system, I welcome having such "root" abilities.  I just get frustrated with the layers of security that are wrapped around existing systems at time.  I suspect that such caution comes from good reasons, but it can make getting anything done problematic.  I am just pointing out building a solution for the VA on EWD will need to get security approval at the same level as installing a KIDS patch with mumps code.

Of course - this issue is true for Mumps generally.  So the solution is pretty straightforward and I've talked about it before on numerous occasions: identify the complete range of authorised functions/methods that are allowed for a VistA system, encapsulate and wrap them in a standard way and make them available as a set of approved APIs.

I've already described how that wrappering can be done at the Mumps level in a way that exposes them to Node.js as JSON-interfaced functions:

http://robtweed.wordpress.com/2013/11/19/json-interfacing-vista-and-other-legacy-mumps-systems/

The next sensible step for the VA is to ban all direct access to the VistA kernel and instead make all access only possible via REST services that invoke that set of approved functions/methods.  EWD provides a Node.js-based solution  - the EWD REST Server.  This builds on the step above and, in addition along the way as a bonus, provides solutions for security, scalability, redundancy and federation.  It also provides the basis for mapping those approved wrapped APIs to FHIR resources, as I demonstrated with the VistA Novo reverse-engineer exercise at the January VCM.

For interactive, browser-based applications, this means you can (and should) still use EWD.js, but instead of making direct invocation of Mumps code on a VistA system, the application EWD.js system has no direct access to VistA - it can (and probably should) be a physically separate system, and instead it can access one or more VistA systems via the REST (and/or FHIR) services they expose.

Here's a summary of how it can work - once again I provide the recipe book for making it work:

http://gradvs1.mgateway.com/download/VistAREST.pdf

The initiate and authenticate methods have actually already been written and are included in the VistADemo application that gets installed and you can try out for yourself when you use Chris Edwards' VistA installer.  See:

http://robtweed.wordpress.com/2014/03/02/ewd-js-and-vista-rest-interface/

So everything is there for anyone to pick up and use to make this all possible.

Of course this architecture means a chain of layers across 2 EWD.js systems and an EWD REST Server.  However the sheer speed of each EWD.js system and the EWD REST server means that it's still going to be orders of magnitude faster than anything like VistALink (and even faster than also wading through the further added overheads of an ESB!), and what small sacrifice is made in terms of sheer performance is made up in bucket-loads in terms of scalability, federation and reliability/resilience.

It also provides an assured level of protection for the VA VistA administrator - only the authorised APIs to VistA are available to the EWD.js browser application developer.  So this should make him happy and confident in the way you are concerned about.

So I've provided all the building blocks you need.  I've addressed every one of the issues that are pertinent to the challenge of modernising VistA and getting it into a state that can be passed to the next generation of developers and in a way that can be migrated, in a measured, low-risk way, from the Mumps language to something more modern and with a popularity that will last.  I've addressed security. I've provided the basis for FHIR integration.  I've provided a technical architecture that is lighting fast and will provide all the performance and scalability needed by an organisation the size of the VA without layers and layers of stuff that ends up slowing things down to a snail's pace and then needs other nonsense such as database caches to try to bring it back to some semblance of performance.  

The one thing I'm sorry I don't provide (which is where the last resistance will come from, I can be sure of it) is a career path and resume builder for Java developers - well I suppose they had their chance and blew it between 2001 and 2008 during their glorious HealtheVet initiative days, the inevitable, miserable and eye-wateringly expensive failure of which resulted in Roger Baker's decision to Open Source VistA and led us to where we are today.  Let's not encourage anything that returns us by stealth back down that discredited Java/J2EE route.

I've created the technical platform to do it properly this time.  Sidney has unequivocally demonstrated what's possible:

http://astutesemantics.com/fileman-gui/

So can we now just get on with it, please?

 

[K.S. Bhaskar]

Without getting into religious aspects of the discussion of programming languages and technologies in this thread, I'd like to note that the technique of having an agent act on behalf of a client is a common & well accepted design pattern, one that is not per se a security problem.  For example, a common type of database engine design (GT.M doesn't do it this way, but most databases do) uses a daemon that actually performs database updates.  A daemon has the power to cause mayhem, but typically doesn't - a correctly designed and implemented daemon authenticates clients, ensures that the communication channel is secured, and validates that each client is authorized to perform the accesses and updates it requests the daemon to make on its behalf.  Extending this to client server architectures changes the technologies required, but remains a fundamentally valid design pattern.  The devil, of course, is always in the details.

Regards
-- Bhaskar

[Sidney Seo]

Thank you to all that have provided input.  

The "root" level access being identified as a MUMPS issue by someone as stunningly intelligent as Sam Habiel was quite clarifying for me as well as others who question the security of EWD.js.  Right before I think my work is done for a particular session.. I hear Sam's voice explaining reminder dialogs and it keeps me pushing that extra mile.

Doug, thank you for initially taking on the burden of throwing in your opinion.  It seems to have at least added value for Kevin and myself.

"​Node.js is on the decline.  This often happens to frameworks that try 

to be everything to everyone."

Is there any evidence or supporting facts for this statement at all, Darren (dcoo...@gmail.com)?

You've rarely participated on hardhats in the past and a google of your e-mail address clearly reveals your technology stack preferences, but please let us know what has led you to believe Node.js is on the way out.

--

[Sidney Seo]

The video for CPRS Evolution is 9 days away.

Key features:

- world's first VistA RPC Broker for websockets (http://i.imgur.com/iCDulA8.png)

- multiple patient charts at once (http://i.imgur.com/u1e1grM.png)

CPRS Evolution additional progress pics: 

http://i.imgur.com/CbCqF3R.png

http://i.imgur.com/byHbSK5.png

An abstract including ​CPRS Evolution will also be featured ​at the OSEHRA summit. 

[Kekoa]

rofl - poor kittens; i missed this thread and only caught up because of the recent post.

really folks? i can see it now - up and coming programmers reading this post thinking "what the heck? VistA uses an old language called Mumps and they're debating the use of node.js vs java. weird group."

here are my 2 cents being thrown in the wishing well - websockets are a standardized protocol. When designing your web front end that leverages websockets nothing prevents you from building a well defined websocket interface that all websocket servers abide by. in other words - write your web app using the websocket standard and implement your needed interfaces. if needed swap out the websocket server with your implementation and there you go - that's the point of having the standard. your awesome new web front end doesn't and shouldn't care what websocket server its talking to. similarly your web browser doesn't care if its talking to an apache or nginx web server.

of course standards go out the window once your technical design depends on tight coupling usually imposed by a vendor. *cough* example - cache objects vs m 

[Sidney Seo]

Just wanted to add a link to the CPRS Evoluton demo video on this thread:

https://www.youtube.com/watch?v=0YJxZxSKDg8

--

[Astute Semantics]

An EWD.js VA <-> DoD interoperability prototype demo by Astute Semantics, dubbed JLV Evolution, was released earlier today: 

https://www.youtube.com/watch?v=FlbIXk78v8A

​

On Tue, Sep 23, 2014 at 9:07 PM, Astute Semantics <seos...@gmail.com> wrote:

An EWD.js VA <-> DoD interoperability prototype demo by Astute Semantics, dubbed JLV Evolution, was released earlier today: 

https://www.youtube.com/watch?v=FlbIXk78v8A