I’ve been helping customers implement high-end, highly-scalable web application architectures since the mid-1990s. If there’s one thing I’ve learned, it’s that the key to a successful, cost-effective and maintainable architecture is to keep it simple and keep the number of moving parts to a minimum. Oddly, that seems to not be a lesson learnt by much of the rest of the IT industry, who, in my opinion, appear to go out of their way to make web architectures as complex as possible and with a bewildering accumulation of layers and technologies. Thankfully, many of these architectures fail to make it beyond the Powerpoint stage, but just dreaming up those Powerpoint slides seems to be good business for many.
People who know me know that I prefer to get on with stuff and do it, rather than just pontificating and talking about it, and that’s very much been my motivation for coming up with my EWD.js technology. EWD.js, by the way, is the new, official name for what I’d previously called EWD Lite in earlier postings.
What I’d like to do in this posting is to outline the architecture that can be created at the US Department of Veterans Affairs (VA) by using EWD.js. This is an architecture that can be literally created today, not in several years time, with almost no effort, Rather than costing eye-watering sums of money, it can be created at almost no cost using existing Open Source products. The architecture is simple, with almost no moving parts, yet that simplicity belies leading-edge capabilities, taking the VA into the 21st century and allowing the creation of their vision of mobile and web-based access and SOA-based services, whilst still supporting, maintaining compatibility with and making use of their existing VistA system. The architecture will be fast, scalable, secure and extensible and will allow secure inter-operation across all 130 VA sites, “straight out of the box”.
Those of you who attended the recent VistA Expo in Seattle and stayed until the end will have seen this architecture and technology being demonstrated and put through its paces by me and Zach Gonzales from Oroville Hospital. What I’m going to describe isn’t some theoretical grand-plan: this exists today, and is already in production use at Oroville where they use VistA as their Electronic Health Record (EHR).
Let’s start with the key piece of technology that makes it possible: the Node.js interface that InterSystems added to their Caché database technology. Caché, of course, is the back-end database technology that supports and runs the Mumps-based VistA application at the VA. The Node.js interface is an officially-supported, built-in part of Caché and has been available since version 2012.2. In fact, the interface file (cache.node) can be transferred to any earlier version of Caché and will just work. The interface is rather unusual for a Node.js database interface in that it provides an in-process interface: ie both Node.js and Caché run in the same physical process. It is also unusual in that it provides synchronous APIs which turn out to run significantly faster than their asynchronous, non-blocking counterparts.
The key thing is that this interface is sitting waiting to be used in all the Caché systems used by the VA at no additional cost.
Key to the success and viability of this architecture in the post-OSEHRA world is the fact that an API-compatible, Open Source alternative to the InterSystems Node.js interface has been developed for GT.M. This ensures that architectures built using EWD.js are compatible and applications written using EWD.js can run identically at both the VA and at sites using the Open Source version of VistA outside the VA,. Critically, it allows two-way collaboration between the two communities: in other words this architecture will support and embody the spirit of OSEHRA, and supports the needs of the Open Source VistA community. None of the other proposed architectures for the VA that I’ve seen appear to allow this.
The diagram below summarises how these two interfaces connect Node.js to Caché and GT.M. The key thing is that to Node.js, the two database technologies appear to be identical.
JSON interfacing of VistA
The combination of EWD.js, Node.js and these interfaces to Caché and GT.M allows something very powerful to be created: a completely JSON-based interface to VistA. This can be done simultaneously at two levels:
- Caché and GT.M appear to be JSON persistence engines, in effect turning them into a class of NoSQL database known as a Document Database, providing behaviour similar to databases such as MongoDB. Both new and existing data, physically stored in these databases as what are known as Globals, are automatically mapped to and from an equivalent JSON representation within Node.js.
Client/Server in the Browser
This changes everything: we can now build and run client/server applications in the browser and we are no longer limited by the HTTP protocol. The browser no longer needs to poll to check for changes at the back-end: when things change at the back-end, it can send a message to all relevant browsers, and receipt of that message can trigger an appropriate change in the browser’s User Interface (UI).
This is what EWD.js is all about: creating this 100% JSON environment.
Creating an EWD.js environment on top of VistA
Perhaps the most surprising thing is how quickly and simply this can be enabled on a VistA system running at a VA center.
- The Node.js interface is already in place if the VistA system is running on Caché 2012.2 or later. If not, it can be enabled simply by copying the interface file from a more recent Caché build and putting into the right directory on the older Caché build.
- Node.js needs installing on the server(s) that are running Caché. This is a quick and simple process. Note that Node.js was recently approved for use by the VA.
- EWD.js is enabled by installing an Apache 2-licensed Node.js module called ewdgateway2.
In the near future, I’m hoping that a growing library of JSON interfaces to VistA will become available as a Node.js module. Zach Gonzales is already building out an initial set of such interfaces at Oroville Hospital that could potentially form the basis of a community-wide module.
That’s all there is to it!
Now I’d like to explore the architecture that EWD.js creates and how it can be used to support the VA’s operations.
The diagram below summarises the architecture created by EWD.js
At the core is a single Node.js process that provides the main web server and WebSocket interface with which browsers communicate. Incoming JSON-based WebSocket messages from browsers are placed onto a queue which is then immediately processed by a dispatcher. When the EWD.js module is started, a pool of persistent Node.js child processes is also started: each of these child processes binds to an instance of Caché (or GT.M) via the in-process Node.js interface. The dispatcher passes a message from the queue to a child process in the pool, and as soon as this happens, the child process is removed from the free pool. Child processes therefore only handle a single JSON message at a time. Handling of the message is carried out by a Node.js module written by the application’s developer. Typically this handler will access the Caché (or GT.M) database, perhaps saving the JSON message, running a JSON-interfaced VistA function, and/or getting data in JSON format from the VistA system. Typically the handler will return a JSON message back to the master Node.js process which forwards it to the browser that originally sent in its message. Having completed its processing of the incoming message, the child process then returns itself to the free pool, ready to handle another message.
There’s a key reason for this queue/child process architecture: by ensuring that a child process handles just one incoming request at a time, the programmer can make use of those high-performance synchronous APIs that are provided by the Node.js interface to Cache and GT.M. By using the synchronous interfaces, there’s a further and very significant benefit: the application developer doesn’t have to tie himself or herself in knots writing the almost unmaintainable asynchronous logic that is otherwise required when handling databases in Node.js (trust me, I’ve been there, done it and it’s not pretty or straightforward to write anything other than trivially simple logic using asynchronous logic, and none of the pseudo-synchronous syntax alternatives – eg Promises – make life as simple and intuitive as synchronous logic).
The system administrator can configure EWD.js to determine the number of child processes to spawn at startup. Child processes can be dynamically added or removed if necessary without having to stop and restart EWD.js.
Anatomy of an EWD.js Application
As illustrated below, a developer of an EWD.js application creates 3 things:
An EWD.js-based VistA application is largely defined as two sets of Event Handlers:
- one set that responds to in-browser events, creates a JSON payload and sends it to the back-end
All interaction between the browser and back-end is via WebSockets, and all messages are JSON-based.
Integrating VA systems via EWD.js
In addition to supporting browser-based applications, EWD.js has another trick up its sleeve. Any back-end module can be automatically exposed as a JSON-based web service (the request is a simple HTTPS request, the response is an application/json mime type). The WebServer functionality within the master Node.js process provides the HTTPS server interface for incoming Web Service requests. Furthermore, in order to prevent unauthorised access to an EWD.js system, all Web Service requests must be digitally signed. EWD.js automatically uses the same HMAC-SHA256-based security that is used by Amazon Web Services for its HTTPS-based services (eg S3, SimpleDB).
Just as in Amazon Web Services, a user of an EWD.js web service must be registered within the EWD.js system with a unique Id and Secret Key. The Secret Key is known to both the client user (or system) and the EWD.js server but nobody else. In order to invoke a Web Service, the client user must digitally sign the HTTP request using their Secret Key. On receipt of a Web Service request, the EWD.js system automatically looks up the user’s Id that is in the incoming request and tries signing the incoming request using the user’s Secret Key. Only if the incoming siganture matches the calculated one will the request be accepted.
EWD.js as a Web Service Client
An EWD.js back-end module that executes in an EWD.js child process can act as a Web Service client, making calls out to any externally-available Web Service. Node.js provides a built-in HTTP(S) client for this purpose.
Of course, the Web Services accessed by and EWD.js child process can be provided by another EWD.js system. Simply by installing a pre-built EWD.js/Node.js Web Service Client module, your EWD.js applications on one VistA system can be accessing services on another VistA system: all the digital signature mechanics required by the client application are automatically handled by the Web Service Client Module. All that is needed for one VistA system to securely communicate with another VistA system in this way is for each VistA system to know the Id and corresponding Secret Key of the other VistA system. This is summarised diagrammatically below:
Remember that this inter-linking of VistA systems uses the same security architecture as used by Amazon Web Services, who run their services over the open Internet and have done so for several years without any apparent problem. I see no reason why all 130 VA systems couldn’t be interconnected using this extremely lightweight but secure Web Service architecture.
As an aside, we used this same secure Web Service mechanism in the Oroville Hospital Scheduler in order to demonstrate scheduling between VA centres.
External Message Generators
EWD.js has one further trick up its sleeve. The master Node.js process has a built-in socket server interface, listening on a pre-determined port for JSON-structured strings. Any process on the server (or, security considerations notwithstanding, other networked servers) can open this port and send a JSON-structured string to it. Each EWD.js master process has a secret password assigned to it by the system administrator, and provided the incoming message includes this password, the master process will forward the message to one of three destinations:
- all browsers currently connected to the EWD.js server
- any browsers running a specified EWD.js application
- any browsers whose back-end session data matches the specified values
This allows messages to be sent to specific users from, for example, monitoring equipment that is gathering patient-specific data. Imagine, for example, a doctor being able to view a graph of such incoming information that is being updated in near-real time, displayed in the browser running on a tablet computer such as an iPad.
An Event-Driven Future
By harnessing these technologies and making use of the Node.js interface to Caché and GT.M, EWD.js provides a powerful and extensible framework and architecture for the next generation of VistA applications.
The key thing is that everything I’ve described in this posting is available today and ready for use. All the architectural components are free and Open Source. Hospitals such as Oroville are using EWD.js already, and I predict that use of this technology and architecture outside the VA is going to take off and snowball. It’s going to happen with VistA systems whether or not the VA wants to make use of it: this train has already left the station and won’t wait for anyone! So my message to the VA is: if you want to join this ride, get on board! Stop deliberating, just do it!
Alternatively, keep reading those Powerpoint slides, but don’t be surprised if you’re left behind!