I have to thank Steve Owen for pointing this out to me:
Gaining approval in the VA’s Technical Reference Model (TRM) effectively represents approval by the VA for a specific technology. I appreciate this very good news as it now appears that there is a growing understanding within the VA of the potential of EWD.js for rejuvenating and modernising VistA.
Unfortunately the TRM assessment is conditional and raises a number of concerns that I believe to be unfounded. It also reveals a number of misconceptions that need to be dispelled. For whatever reasons, the TRM assessment process appears to be carried out in isolation and anonymously. At no point was I approached by the people at the VA who were conducting the analysis of EWD. I wasn’t formally made aware that such a process had been started and wasn’t officially made aware when they formally approved EWD in the TRM (which appears to have been in September). I was not given any opportunity to provide answers to any questions or concerns they might have had (it sounds like they had a few!). I’ve no idea who actually conducted the analysis at the VA and I appear to have no means of contacting them to make any comments on their decision or set the record straight.
In the absence of an official channel, I’d like to use this article to pick up on the key areas of apparent concern:
“This is a very small company from the United Kingdom with limited resources. The VA must understand that support maybe extremely limited. It was very difficult to gather information about this product. Anyone wishing to use this product must understand the limitations for support.”
Had I been asked, I could have pointed the reviewer(s) at a wealth of information that I’ve published and made freely available, and I’d have furnished them with what ever additional information they’d required. At the very least, the many articles I’ve written in this blog should have provided all the necessary signposts to the information I’ve made available: indeed the entire history of and thinking behind EWD.js has been laid out in my previous postings.
Anyway, for the record, here are the key resources for EWD.js:
Secondly it’s not clear whether it’s the new EWD.js or the older “classic EWD” that has been approved. The forecast section suggests it’s EWD.js. This is certainly the version for which I’d want the VA’s approval, and it should be made clear in the TRM.
Thirdly, whilst M/Gateway Developments is a small, UK company, our support resources are not limited, and I have contingency measures in place to scale out our support services as and when it becomes necessary.
“There is an increased risk of vendor lock-in due to the technologies’ (sic) limited adaptability.”
I don’t understand what’s implied by “limited adaptability”. EWD.js is designed to create browser-based client/server applications and makes use of a Mumps database as a JSON storage engine. However it also provides built-in secure JSON-based web-service access to Mumps applications such as VistA (as I’ve described in detail in earlier postings). It will even run on a Raspberry Pi! The whole idea of EWD.js was its adaptability, so I’d really welcome some discussion on just what was felt to be the problem.
I’m not sure whether anyone from the VA who is involved in the TRM process will read this posting, or whether anyone from the VA who can contact them will read it. If you are such a person, perhaps I could be allowed some communication regarding the TRM for EWD and be allowed to set the record straight.
At the end of the day I (and I think many others) believe that EWD.js will be of great value at the VA and I’m therefore keen to help the VA’s understanding of EWD.js and move its TRM approval status from conditional to unconditional.