EWD.js on FHIR

Last Monday (13th January), the Vista Novo team, led by Mitre, demonstrated their software to the OSEHRA Architecture Working Group.  A day or so later the team released a document explaining, in their view, the relationship between EWD.js and Vista Novo.

I’d like to thank the Vista Novo team for doing this: not because their document’s conclusions were correct – they were actually somewhat off the mark – but because it spurred me into creating a new, powerful and vital piece in the EWD.js technical architecture that allows it to fully meet every one of the requirements of REST-focused initiatives such as Vista Novo.  Indeed, as a result, I would like to propose that there is no longer any reason whatsoever for EWD.js to not be considered as the technical architecture to underpin future modernisation and integration efforts relating to VistA.

The ewdrest Module

The new addition to EWD.js is a generic REST Server interface module named ewdrest  This is a Node.js module, based on the fully industry-standard Restify module.  The ewdrest module was developed because EWD.js’s built-in Web Service capability, whilst fully secured using HMAC-SHA digital signatures, is HTTP-based, not REST-based (see the Chapter titled Web Service Interface in the EWD.js User Guide).  So the new module now fills that gap by performing several actions:

• it presents an industry-standard RESTful interface to back-end EWD.js systems
• it rewrites incoming REST URLs as digitally-signed EWD.js HTTP Web Service requests and returns the resulting JSON response to the awaiting REST client
• it can be configured to connect to as many EWD.js systems as you like.

The re-routing of incoming REST requests is determined by the first element in the URL path, which is mapped by a user-defined object which defines the hostname, port and security credentials of the EWD.js system(s).  Furthermore, the second element of the REST URL is used to map to a back-end EWD.js module that will handle the parsing and processing of the incoming request.

In other words, the ewdrest module does not, in itself, do any parsing or processing apart from URL rewriting and message forwarding: all the actual processing is carried out in the EWD.js system to which the contents of the REST messages are passed.

For example, an ewdrest configuration object might look like this:

   var params = {
     // REST server listener port
     restPort: 8081,
     // service module mapping
     service: {
       myService: {
         module: 'myModule',
         service: 'parse',
         contentType: 'application/json'
       }
     },
     // EWD.js server mapping
     server: {
       somewhere: {
         host: 'www.somewhere.com',
         port: 8080,
         ssl: true,
         secretKey: 'TakeARest!',
         accessId: 'RESTServer'
       }
     }
   };

This tells ewdrest:

• to listen for incoming REST requests on port 8081.
• if the first element of any incoming URLs is /somewhere/, then they will be re-routed to an EWD.js server that resides at http://www.somewhere.com and is listening for SSL requests on port 8080.  The accessId and secretKey will have been registered on the EWD.js server – without this the EWD.js server will refuse to accept its requests.
• if the second element of any incoming URL is /myService/, then the EWD.js server will be asked to invoke a service named parse in a back-end module named myModule.

URLs handled by this ewdrest module would therefore be of the form:

  http://my.ewdrest.com:8081/somewhere/myService/further/path/elements....etc

Authentication is currently supported via the Authorization HTTP request header, whose value would be initially negotiated via an EWD.js application.

A simple ewdrest architecture can be summarised by the following diagram

Of course, the ewdrest module can be configured to support multiple EWD.js servers, allowing requests to be distributed securely across multiple, remote or local EWD.js machines, eg:

EWD.js On FHIR

With this new capability, it is now possible for EWD.js to provide a fully-federated, secured architecture for integrating VistA systems using HL7 FHIR.  All that’s needed is a back-end EWD.js module that can parse incoming FHIR requests, access a Cache or GT.M-based VistA system to create data records within VistA and/or return VistA data in HL7 FHIR JSON format.  I’ve already created a starting point for this: a Node.js/EWD.js module named FHIRServer.

During the three days of last weekend’s WorldVistA Community Meeting in Sacramento, I reverse-engineered and demonstrated the Vista Novo blood-pressure monitoring application, using three EWD.js machines spread across the world:

• one running on a server at my home in the South of England.  This runs the user-facing web application.  The ewdrest server also runs on this machine
• a second one, provided by George Lilly, which runs on a Rackspace cloud.  This one holds VistA-generated CCDAs, stored in JSON format within a GT.M database (saved and retrieved by EWD.js using its _setDocument() and _getDocument() APIs)
• a third one which I’m running in the Amazon EC2 cloud which stores patient-created blood-pressure readings, in HL7 FHIR JSON format, stored as persistent JSON data in a GlobalsDB Mumps database using the EWD.js _setDocument() API

The set-up is summarised below:

The FHIRServer.js module currently just supports the creation and retrieval of blood-pressure-specific HL7 FHIR Observation records (which is as much as the Vista Novo demonstrator did).  These are retrieved from VistA-derived CCDAs using Josh Mandel’s Vitals JSON extraction logic and then transformed into HL7 FHIR format.  The patient readings are sent in HL7 FHIR JSON format and saved directly in this format too.  A later demo is planned using MongoDB, rather than GlobalsDB, to store these patient readings.

I’ve now made this demonstration application available for anyone to try out.  Please feel free to run the blood-pressure application from the following URL:

https://www.mgateway.com:38080/ewd/FHIRDemo/index.html?a

The username is rob and the password is secret

When you log in, the application makes two simultaneous HL7 FHIR REST requests:

• one to fetch the definitive results from George’s CCDA server
• one to fetch patient-entered results from my EC2 server

The results are merged and plotted on a graph.  The definitive results from VistA are plotted as green points; the patient-entered ones as red points.

You can then add a new result which is immediately added to the graph.  To prevent corruption of the patient database, I don’t store the newly entered point, but I can turn on this capability for a full read/write system – it’s already capable of supporting the /create request.

By the way, if you run the application using the Chrome browser and open up its Developer Tools console window, you’ll be able to see the HL7 FHIR JSON responses being received via the REST server – prove to yourself that there’s no smoke and mirrors going on!

Meeting the Requirements of Vista Novo

This EWD.js-based architecture has addressed most, if not all, of the requirements of the Vista Novo project to date, including many not demonstrated by the Vista Novo team, eg:

• secure, federated integration with real, working VistA systems (instead of mocked up EHRs).  Rather than using the VistA-derived CCDAs, I could just as easily have used a JSON-based getVitals() API such as the one developed at Oroville Hospital, or the equivalent used for Tony Shannon’s NHS VistA demonstrator.
• integration of CCDAs which, of course, could have come from any EHR, not just VistA systems.
• proper user authentication via an EWD.js application, with requests securely transferred to VistA systems via digitally-signed requests over SSL, and the authentication checked again by each back-end FHIRServer module.

Furthermore the sheer agility and speed of development when using EWD.js has been demonstrated yet again.  In total, including creating and registering the ewdrest module, re-jigging the application to use this module and moving parts of the demo to new machines, and writing this article has taken me a mere 5 days from scratch.

Next Steps

What I’d like to see is a re-appraisal of the Vista Novo architecture.  Whilst its team believe that the role of EWD.js would be limited to use by the Open Source community, I would suggest that my work and demonstration proves that it has a role within the VA’s architecture also.  Unlike the Vista Novo project’s architecture, EWD.js has been proven to work and is available today.

My basic and rudimentary FHIRServer module clearly needs to be worked up to include parsing and processing of all HL7 FHIR resource types.  This task is laborious but straightforward, and can be done entirely in JavaScript.  There are already a number of Mumps wrapper functions that would provide a starting point and template for the JSON-mappings to/from VistA.  EWD.js makes such mapping a quick and simple exercise for a VistA expert and involves a bare minimum of Mumps coding around the core FileMan APIs.   There would, of course, be many such wrappers required, but EWD.js at least makes the programming quick and simple once the mapping logic for each HL7 FHIR resource is figured out.

Conclusions

EWD.js now has a new and powerful addition to its armoury: a fully-fledged industry-standard REST interface that allows secure federation across EWD.js systems and direct integration with VistA systems.  If you want ultra-agile, low-cost development, in addition to high performance and scalability, I’d suggest the VistA community looks no further.  Vista Novo is now achievable, courtesy of EWD.js.