I’ve been doing a lot of work over the last few years within the WorldVistA community (http://worldvista.org/): this is a community that is enhancing VistA (the Electronic Healthcare Record [EHR] developed by the US Dept of Veterans Affairs [VA]) for use outside the VA. Through WorldVistA’s endeavours, VistA is now in use in growing numbers of hospitals in the US (eg Oroville Hospital in California) and throughout the world (eg Jordan and India). VistA is currently being scrutinised for its potential in Ireland and there is a campaign in the UK for its consideration in the NHS (http://nhsvista.org).
VistA is a very highly-regarded EHR and has been a major contributing factor in the VA’s transformation of its healthcare provision to the best available in the US (see http://www.washingtonmonthly.com/features/2005/0501.longman.html). However, two criticisms are commonly levelled at VistA:
– its user interface (UI) is very old-fashioned. being based around “green screen” terminal access: not surprising since this was the style of UI when it was being developed through the 1980s. Many users of VistA use an application called CPRS: this provides a more modern graphical user interface (GUI), but the technology that was used (Delphi) is now something of an obsolete backwater and doesn’t allow VistA’s use in browsers of mobile devices;
– VistA is written using the Mumps language and database. Once again, the style of Mumps programming used in VistA reflects the time when it was developed. I’ve already discussed this in another of my postings: A Case of the Mumps (https://robtweed.wordpress.com/2012/10/21/a-case-of-the-mumps/). There’s also a commonly-held misconception that VistA, and Mumps more generally, is difficult to integrate with other technologies.
I’ve also been involved in a project that has now made it possible to integrate Harvard Medical School’s SMART Apps (http://smartplatforms.org) with VistA (see http://gradvs1.mgateway.com/download/smartApps_phcsg.pdf).
These strands of work are helping to modernise VistA and open it out so that it is now becoming more of a healthcare platform than simply an EHR.
However, VistA application development and modernisation has still required a large degree of Mumps programming expertise that has further required a detailed knowledge of and understanding of VistA’s old-fashioned and arcane style of coding. Additionally, it has required a detailed knowledge and understanding of the core functionality of VistA together with knowing how and where to find the code within VistA that is needed to perform the task(s) you’re wanting to make use of: this can be something like looking for a needle in a haystack! As a result, there is only a relatively small number of highly-skilled and knowledgable VistA-savvy developers who can perform this kind of work. Clearly if VistA is to establish itself more widely around the world and become a major Open Source healthcare platform, it is critically important to address this situation.
The VA themselves have recognised this issue and have embarked on an ambitious project to identify VistA’s core functionality and make it available as a set of Web Services. This initiative is known as Medical Domain Web Services (MDWS). In my opinion, this is one of the single most important recent developments to take place within and around VistA: if successful, it will not only document and describe VistA’s core functionality, it will abstract that functionality as a set of services that can be used by any developer using any technology. The need for specialised Mumps programming expertise to build upon VistA will potentially become a thing of the past.
However, there are a few key problems with the approach taken by the VA in developing MDWS:
– the technical architecture makes use of and relies upon closed-source, proprietary technology. MDWS is written using C# and .Net. This makes it unacceptable to non-VA users of VistA who require a fully open-source stack and do not want to (or can’t) be dependent on Microsoft technologies.
– MDWS makes use of the so-called RPC Brokers that are used behind the scenes by CPRS. By their very nature, the RPC Brokers are stateful, and therefore not only inevitably suffer from limited scalability, but fly in the face of the whole philosophy of web services which are supposed to be stateless.
– MDWS services, to date, have been largely read-only. It is not clear how much of VistA’s read/write functionality will be able to be exposed.
– it’s also not clear how anyone outside the VA can enhance and augment MDWS. The scale of the task is such that the more people who can expose and abstract VistA’s functionality as MDWS services, the better
– MDWS is focused entirely on exposing VistA’s functionality as HTTP/XML-based web services. This makes it a very limited solution. For example, increasing numbers of developers already want and expect to receive the output of web services as JSON objects. SMART Apps expect their data to be provided in RDF format, but it would be nice to not have to reinvent a set of wheels to serve up data for SMART Apps from VistA. Additionally, HTTP-based services make sense for accessing remote VistA systems, but present a significant overhead if you want to use those same services locally, eg on the same system – again meaning a reinvention of wheels for local versus remote use of VistA.
My earlier blog postings have described the natively stateless architecture that is available to both Caché and GT.M systems and gave also described how EWD can be used on top of that architecture to support web applications and web services (The Stateful Illusion). These should suggest that there is therefore a much better and more sensible architecture that can be used as the basis of MDWS. Over the past few weeks I’ve been working on this and wish to announce what I am calling openMDWS.
openMDWS is designed to be a fully open source architecture that addresses all the issues I’ve described above. It is completely compatible with and interoperable with the VA’s MDWS initiative, but will allow MDWS services to be developed and used on both Caché and GT.M systems, without requiring any additional technologies: openMDWS makes use of the natively-available stateless architecture in Caché and GT.M systems and also makes use of EWD for many of its core capabilities.
An important and key feature of openMDWS is that it is not limited to HTTP/XML-based services: HTTP/XML-based services are just one potential projection of each core piece of VistA functionality.
In openMDWS, the starting point for each service is to create a generic Mumps function that wrappers a piece of VistA functionality as an entirely atomic, self-contained block of code. Although each openMDWS core function will contain the old VistA Mumps code required to perform its specific task, that code is wrappered using proper, modern variable scoping techniques, so that it doesn’t rely on leakage of globally-scoped variables, and doesn’t leave any globally-scoped variables lying around after it has finished.
openMDWS provides a standard structure and pattern for these functions that their authors must adopt. Additionally, openMDWS core functions are not restricted to read-only functionality: they can just as easily define update transactions that include all the appropriate error/edit checks to allow or reject the transaction on the basis of its inputs.
Once a core, re-usable openMDWS function is written, the next step is to build a second function that wrappers the core openMDWS function and projects it and exposes it in the way you require, which might include:
– an HTTP/XML service
– an HTTP/JSON service
– an RDF function for use with SMART Apps
Again, openMDWS provides standards and patterns of coding for these outer functions to which developers must adhere.
The key point of openMDWS is that it encourages (and depends on) a one-off task where someone who is knowledgable about VistA and Mumps coding can encapsulate a piece of VistA’s functionality as a re-usable, generic, atomic Mumps function. Once done, that wheel never needs reinventing. That Mumps/VistA expertise is encapsulated once and for all in a way that can then be reused in any number of ways (and those ways can change and evolve into the future). Anyone with VistA and Mumps knowledge can develop these core functions, and it doesn’t matter whether they develop them on Caché or GT.M systems. This means that it will be possible to mobilise the entire VA and non-VA development communities to address the huge task of identifying and encapsulating VistA’s massive portfolio of functional capabilities as openMDWS core functions.
openMDWS has one further trick up its sleeve. When you write an HTTP/XML wrapper for a core openMDWS function, you actually don’t have to worry about writing any XML-based code. Instead, openMDWS includes an automated bi-directional mapping between XML and Mumps local arrays: the HTTP/XML Wrapper function simply maps the output of the core openMDWS function into a Mumps array that corresponds to the required XML response. openMDWS looks after the task of converting this array into a corresponding XML document and dispatching it as an HTTP response. On the client application side, you can use EWD to build a web-based application that makes use of openMDWS services. Your EWD scripts invoke those openMDWS services using a set of openMDWS client API functions. The really cool trick is that openMDWS can determine whether the service you’re invoking is on a remote system or on the same system and:
– if the service is on a remote system, it is invoked via an HTTP request and the XML response is parsed automatically into a corresponding local Mumps array
– if the service is on the same system, the openMDWS function is called directly and the Mumps array is returned directly.
This means that openMDWS services can be used for locally-implemented VistA applications without incurring the overheads of HTTP transport and XML parsing that would otherwise be expected to be incurred if a web service wrapper was invoked. In fact, using VistA functionality exposed as openMDWS services will be just as efficient as making use of direct Mumps calls to the core VistA code (which is the current state of the art)!
This means that openMDWS is of huge strategic importance, because it can be used for any style of VistA application development or enhancement: ie openMDWS is not simply limited to web-service based applications. Additionally, openMDWS provides a single standard architecture that will allow VistA to be turned into a completely service-oriented healthcare platform, allowing all of its functionality to be described as a set of re-usable, technology-independent services. In my opinion, it represents the key building block on which the future evolution of VistA as the open source EHR will depend. I’m therefore pretty excited about it, and I’m hoping others in the various VistA communities will feel the same way.
Watch this space for a follow-up posting that will describe in detail the coding patterns and standards that will need to be adhered to for openMDWS core functions and their HTTP/XML service function wrappers, along with some examples that developers will be able to try out for themselves. In the meantime, feel free to let me know what you think about the openMDWS concept: all comments welcomed.