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.
My work to date has focused on modernising VistA’s User Interface through the use of our company’s web application development framework that is known as EWD (http://www.mgateway.com/ewd.html). EWD has pretty much become the de facto technology for web-enabling VistA, and is being used in conjunction with the very latest Javascript frameworks (eg ExtJS and Sencha Touch) to make it possible to access VistA via desktop browsers and mobile devices, with a UI that is as capable (if not more so) than that of CPRS (see http://gradvs1.mgateway.com/download/EWD_EXTJS4_Reference.pdf and http://gradvs1.mgateway.com/download/EWD_Sencha_Touch2_Reference.pdf).
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.
The EWD Files 
Thanks for the thoughts, Rob. I wanted to provide a couple clarifying points that hopefully you can incorporate in to your updates:
1. MDWS runs on Mono which means you can have an open source stack. It’s a fair argument that MDWS is implemented in C# which is, of course, not an open language. In the same breath I’d mention that C#/.NET web services are vastly superior to Java in both development and support. MDWS actually started out as a Java web service. .NET was so much more productive, the switch was made. Also, due to the way MDWS ‘talks’ to Vista, the environment in which MDWS is installed can be completely independent of the other pieces of the stack.
2. State is an illusion. You can move it around (and often times that’s a good thing!) but you’re always moving it – never disappears. MDWS has the capability to pool resources – I will talk about this on the OSEHRA AWG call December 4.
3. MDWS can write, too. Writing is no more difficult than reading. We’ve held back because 1) the business rules are often very complicated – no way to get around it 2) we’ve not had the resources to do so. I’d like to encourage the open source community with the technical expertise to tackle these problems with MDWS (it’s open source!). I’m always welcome to submissions
4. I’ve apparently done a poor job conveying that MDWS is in fact open source and anyone is welcome to contribute. Please see: http://code.osehra.org/journal/browse/publication/21
5. MDWS now has some REST web services! They even use psuedo-stateless connections. I plan on showing this off as well on December 4. Code will be out on Github when all my tests pass 😉
Thanks again, Rob. Take care
Of course a key point about openMDWS is that it is code-compatible with MDWS services, so existing MDWS services can be easily re-implemented as openMDWS versions and consumed, without change, by an existing client interface. This isn’t about replacing the MDWS concept: it’s about providing a more scalable underlying technical architecture, designed from the ground up for stateless, web service support with Mumps systems, tried and tested by some of the largest users of Cache, with fewer moving parts and therefore inherently easier (and therefore less costly) to support and less likely to go wrong. The largest EWD users have been running 24X7 non-stop operations, courtesy of the fully redundant architecture that the underlying web gateway architecture makes possible.
On the other hand, openMDWS is a much broader strategic solution than MDWS: current MDWS services represent just one possible use of openMDWS core functions. When the next big thing comes along (as it surely will), openMDWS core services will be ready to be re-purposed accordingly: as such it’s a future-proofed solution for code re-use.
Rob
This is an exciting development for VistA: a two-tier, high performance architecture that modularizes core functionality, and provides the VA and non-VA, open source community a common platform for development.
I would emphasize Rob’s comment that openMDWS is truly open source. It has no proprietary dependencies for programming nor any proprietary dependencies for deployment in a production setting. While one could theoretically deploy a .NET application using Mono on a Linux operating system, the version of Mono that is available has features and functionality equivalent to that of .NET 2.0 – far less functionality than the current .NET framework (v 4.0 or higher now). In addition, in a production setting, would would be required to deploy a .NET application on the Microsoft IIS server. This is not only an expensive development and deployment toolchain – but one that you will find absolutely no open source development or community.
For detailed description of MDWS, read the VistA Documentation here:
http://www.va.gov/vdl/application.asp?appid=192
Summary here:
Medical Domain Web Services (MDWS) (pronounced meadows) is a suite of Service Oriented Architecture (SOA) middle-tier web services that exposes medical domain functionality, Medical Domain Objects (MDO). MDWS is equipped with the capacity to virtualize any legacy Veterans Health Information Systems and Technology Architecture (VistA) Remote Procedure Call (RPC) as a web service. A web service is an Application Programming Interface (API), which uses Simple Object Access Protocol (SOAP), the standardized protocol to communicate with subscribed client applications.
History
Historically, the Department of Veteran Affairs (VA) developers use a standard, 2-tier (client/server) architecture to develop applications, such as the Computerized Patient Record System (CPRS) and the Remote Procedure Call (RPC) Broker. CPRS communicates to VistA through the RPC Broker.
1. Client – The top tier, or frontend, is the user interface (such as CPRS).
2. Server – The bottom tier, or backend, is the data source (a single VistA system).
MDWS evolved from the field development that Joe Gillon created with MDO at Ann Arbor Veterans Affairs Medical Center (VAMC). MDO is easier to implement/utilize than the traditional methods of accessing the VistA Legacy systems (such as the RPC Broker).
• MDO is a library of data structures with behaviors in the medical domain. It is an improvement over the Delphi RPC Broker by building in business rules to free other developers from implementing the same requirements in each application.
• MDO is written in C# .NET.
• MDO is capable of accessing a VistA system, enabling it to communicate directly with any VistA system and use all the standard local CPRS RPCs.
• MDO is capable of multi-site queries, allowing it to read data from all relevant VistA systems in parallel in the time it takes to receive data from one system.
The browser-based Electronic Medical Record Graphical User Interface (EMR GUI)/VistAWeb (VW) was developed to demonstrate MDO. VW not only demonstrated MDO, but also featured patient-centric data rather than geo-centric data. VW became a national Class 1 (C1) application in 2005.
VistAWeb Services (VWS) was developed to take MDO to Java 2 Platform, Enterprise Edition (J2EE), when it was realized that most clients can consume SOAP web services. Trying to produce J2EE web services proved painful, error-prone and time consuming. However, writing web services in the top level domain .NET was simple. VWS became a C#.NET web service exposing a pure Java library. Several web services were produced under VWS, as development moved toward a new set of web services with a new MDO written in C#.
The new service, MDWS, exposes MDO and provides transparent multi-site accessibility, while enforcing business rules. Although MDWS is not yet certified as C1 software, MDWS received a waiver from Systems Engineering for the C1 deployment of Suicide Hotline. MDWS will be the catalyst to make several VA mission critical systems operational in addressing compliance with VA requirements and White House/DHS mandates.
1. Healthcare-Associated Infection & Influenza Surveillance System (HAIISS) program tools
2. Electronic Surveillance System for the Early Notification of Community-based Epidemics (ESSENCE)
3. QcPathfinder
4. Bed Management Solutions (BMS) and other web-based applications
The current object set in MDWS focuses primarily on clinical information. Future development efforts may include other patient administrative areas, financial areas, etc. Much of the medical data comes from VistA,
• where data domain objects, such as Allergy, Medication, LabResult, etc., are created from the results of one or more VistA RPCs.
• where data comes from a relational source, the objects are created from recordsets.
• where data comes from XML sources the objects are created by parsing the Document Object Model (DOM).
Using MDO’s data structures and behaviors, MDWS interacts with a variety of data sources. MDWS queries several VA data sources for clinical data.
1. All the VistA systems
2. Master Patient Index (MPI)
3. Structured Query Language (SQL)
4. Extensible Markup Language (XML)
5. Health Level 7 (HL7)
6. Some Planning System Support Group (PSSG) sources
MDWS is used by a variety of field-developed products and is a component of several notable C1 efforts implemented across the Enterprise.
1. Adverse Drug Reaction
http://vhaannscm1.v11.med.va.gov/trac/medora/wiki/Clients/ADR
2. Apollo (CPRS Re-engineering (AViVA)
http://trac.medora.va.gov/web/wiki/Projects/Apollo
3. Athena
http://trac.medora.va.gov/web/wiki/Clients/Athena
4. BHIE
http://trac.medora.va.gov/web/wiki/Clients/BHIE
5. Chronic Disease Management
http://trac.medora.va.gov/web/wiki/Clients/CDM
6. Crisis Center (web service behind Suicide Hotline and Homeless Hotline)
http://medora.sharepoint.med.va.gov/sites/crisiscenter/default.aspx
7. Diversions
http://medora.sharepoint.med.va.gov/sites/diversions/default.aspx
8. Electrophysiology Reporting
Ann Arbor
9. EMERSE
http://trac.medora.va.gov/web/wiki/Clients/EMERSE
10. MOVE
http://www.move.va.gov/Default.asp
11. MyHealtheVet
http://www.myhealth.va.gov/
12. Mynapin (used in demonstrations)
3TUhttp://www.kabotintl.com/products.php?ProdCatID=7U3T
13. National Utilization Management Integration (NUMI)
http://medora.sharepoint.med.va.gov/sites/utilizationmgt/default.aspx
14. PatientFinder
http://medora.sharepoint.med.va.gov/sites/PatientFinder/default.aspx
15. Traumatic Brain Injury
http://trac.medora.va.gov/web/wiki/Clients/TBI
Anyone interested in finding out more about openMDWS and EWD should consider attending my training course that will be taking place before the WorldVistA Community Meeting in Sacramento in January 2013. Details can be found here:
https://groups.google.com/group/hardhats/browse_thread/thread/f789dcff5f29f2ba?hl=en-GB_GB
Rob
Hi. Joe Gillon here. This is very interesting and I need more time to read it but one thing I think might be useful immediately. Rob says,
“The VA themselves have recognised (sic) 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).”
Gotta say that cracked me up. Makes it sound like this was a VA initiative. MDWS was essentially forced on the VA. We simply wormed our way in by accumulating so many important client apps that the VA HAD to accept MDWS. This was not an official VA project. It was not conceived by VA management or supported or supplied by VA management other than the local folks in Ann Arbor who got us a few servers, some software and basically looked the other way. Hmm. Actually, more should be said there. Ann Arbor supplied personnel. The Medora team did next to nothing for Ann Arbor itself but functioned as a national development SWAT team that Ann Arbor paid for. Not that I’m bitter about that. Hurricane Katrina – my phone rang. Congress bitches about TBI – my phone rang. Congress bitches about suicide – my phone rang. Homeless vets – my phone rang. Ann Arbor picked up the tab for all that.
I’m bringing this up not only because it’s funny but I think it might be illuminating. To understand why MDWS is the way it is you have to know it was developed on a shoestring and without any official permission. It had to be done quickly and effectively with the notion of extensive refactoring later on. Which means there is going to be ugliness. The transfer objects, for example, are egregious. As Joel says, it was originally Java but Java web services in those days was hopeless. I spent 3 months on JBoss, WebLogic and Axis, then accomplished more in 30 minutes with C# and .NET. The switch was a no-brainer. Bottom line, my goal was simply to demonstrate HOW things should be done, not to provide the perfect answer.
Now to read the whole thing…
OK, back again. Item by item…
The whole Microsoft cost thing: actually, I don’t much care about this. These days I’m writing in PHP, Ruby, Python, and even some Java. But I will say it seems to me you’re only looking at one side of this coin – the cost of buying MS. You should look at the other side – the cost of developing in something that takes way more time and is way more prone to error. Maybe Java WS has improved since I made the switch, but maybe not.
RPCs: what you need to understand is we were under the radar. We needed to talk to ANY Vista system without credentials in each site. Credentials in one site, talk to all sites. And that could only have been done via the RPCs because only they had the ability to “visit”. Of course it would have been easier to use Cache. Duh. But then you need credentials in every site. Not something that was gonna happen when developing on the sly.
State: As Joel points out, not really as clear cut as one would think. But yes, I always considered this an issue and of course realized web services were supposed to be stateless. But you gotta dance with who brung you and that was RPCs which are stateful. I was gonna fake it with connection pooling but the Broker Security Enhancement made that too expensive. Joel tells me now he’s finally been given a MUMPS guy and they’ve worked out some clever pooling scheme so this issue should go away.
Writing data: again, Joel has pointed out you can write with MDWS. The devil is in the business rules which it seems to me you aren’t paying sufficient attention to. If I understand you correctly, openMDWS is IN VistA and is therefore, as Rafael says, two-tiered. If so, where are the BR? A simple example is patient sensitivity. Some patients are marked sensitive in VA and when selecting such a patient certain RPCs have to be made that aren’t usually made. Many a developer using the RPC Broker has intentionally or otherwise ignored this rule. Where does this get enforced in openMDWS? Where does the rule that a certain kind of note written by a particular provider needs a co-signer get enforced? It’s easy to just send the RPC that writes a note and be done with it. But that completely misses all the BR which are implemented via other RPCs.
Which brings up another issue. Some folks think MDO/MDWS is just a 1-1 mapping of call to RPC. Not so. Some calls require multiple RPCs and some operations require multiple calls (to enforce BR).
Can’t develop MDO/MDWS outside VA: I believe Joel addressed this with OSEHRA?
SOAP, JSON, etc. Ah yes, those bloody TOs. Still working on that…
More on Cache: one reason I was hot to implement federated user ID – so we could talk to Cache as well as RPC.
This notion of wrapping M functions: isn’t that exactly what RPCs do? But yes, could this be improved? Duh. Again, we had no access to M. We had to be national without national support, meaning we had to make do with was already in every site. No option to write our own wrappers which of course would have made life much easier.
The local vs. remote: maybe I don’t get this. There’s a browser, which means there’s a web server and the code on the web server talks to VistA. Therefore, ALL Vistas are remote. Ah, you’re putting your stuff inside Vista. I’m thinking that will be a cold day in VA when that happens. Altho… I ran into something called Vista Web Services from time to time. Not to be confused with my old VistAWeb Services, mentioned in the summary by Rafael. I believe someone may have anticipated your openMDWS by putting web services inside VistA. Might want to check that out. Though again, BR? BR are typically enforced in the middle tier – ie, three tiers.
Uh oh. I see it’s time for my mid-day beer. Gotta go.
Disclaimer: I do not work for VA in any capacity.
A few things that I think are wrong with this article and some thoughts on this whole mess:
C# and .Net is not “proprietary”, CLI is an ECMA standard that’s why Mono exists. Just because something is implemented in C# doesn’t mean it cannot be used by people outside the VA. On the contrary, C# adoption is far higher outside the VA than inside the VA.
Also please check the roadmap for Mono, it is .Net 4.5 compliant.
And no you do not have to use IIS Server to host stuff done in .Net – but you should when it makes sense.
The resistance to move on from MUMPS is absurd. MUMPS might have been the bees knees in 1970’s but really its 2012 now, the VA needs to embrace the right/newer technologies. Its a pity that in 2012, the VA still has the same text based green screen for scheduling (and many other mission critical software).
Of course I am not proposing dumping the MUMPS database altogether but gradually moving away from it e.g. For any new development move the business logic into a modern technology into its own tier.
OpenMDWS looks like a stepback trying to create a webservice stack in MUMPS. I have developed in MUMPS, FORTRAN, JAVA, C/C++, C#; IMHO MUMPS is a clunky and obsolete language that has no future, it doesn’t make sense to develop frameworks and things from scratch (which you will have to do in MUMPS – like people trying to write XML and JSON parsers) just because folks don’t want to use the huge amount of already proven and tested modern frameworks (most of which are open source by the way).
Also, its a pity that some people push the open source philosophy in everything. If a technology, framework, software adheres to “open standards” that is all you practically need. If its open source too that’s better. But not using an established technology because its not open-source is one of the many reasons why VA technology sucks big time. Healthcare providers don’t care if the software they use is “open source”. They want a software that’s designed right, is stable, user friendly. Organizations want software that they can sustain, can get great resources to develop it further.
Another blind obsession that leads no where is this cross-platform one-size-fits-all mantra. Create a software that works best for your target users and your target platforms. If VA uses Windows on the user workstations then use the best technology that’s available for Windows. And no everything doesn’t have to be web based. Users will get the most performance/responsiveness with something developed in native technology for the target platform or form factor. If my users are using iPad, I will develop the software in ObjectiveC and design the software specifically for that form factor to use the “specific features” provided by that platform.
The small group in VA moved in the right direction with MDWS, that’s not to say that I don’t have some reservations there as well but those I believe are primarily because they are supporting so many projects with little resources and can definitely be improved further e.g. MDWS layer should be updated to .Net 4 and use ASP.Net Web API for rest based endpoints or use barebones WCF _ instead of .Net 2 and ASMX.
And that’s my 200 cents 😉
Imran
I shall write a specific response to the issues you’ve raised, but in the meantime, most of what I’ll say is already covered in my comment to Chris Uyehara’s blog posting at http://www.osehra.org/blog/vista-based-open-source-web-services
Imran
Let me address a few specific points you’ve raised:
=========
“MUMPS might have been the bees knees in 1970′s but really its 2012 now, the VA needs to embrace the right/newer technologies”
I agree – have you read my posting “I have seen the future and it’s Node.js shaped”?
But on the other hand, newer technologies must not be embraced simply because they are the latest shiny new toys. As my earlier blog postings have tried to explain and demonstrate, Mumps can do pretty much anything required to co-exist in the modern networked, web world, and if it can do so more efficiently and more maintainably, then those techniques need to be embraced.
Sure -the Mumps community needs to learn more about what is happening in the wider IT world, and that’s something I’m trying to help happen. But equally the wider IT world needs to stop its blind and largely ignorance-driven prejudices against Mumps and discover what it can also do. For example, as a database, it’s second to none (see http://www.mgateway.com/docs/universalNoSQL.pdf), and it’s about time people started asking themselves: “so how come Mumps does seem to dominate healthcare worldwide, and how come it’s proven so difficult to replace with “modern” technologies?” That can’t simply be by luck or some quirk of history: perhaps there is something the “modern” world can learn by examining it properly.
===========
“OpenMDWS looks like a stepback trying to create a webservice stack in MUMPS. I have developed in MUMPS, FORTRAN, JAVA, C/C++, C#; IMHO MUMPS is a clunky and obsolete language that has no future, it doesn’t make sense to develop frameworks and things from scratch (which you will have to do in MUMPS – like people trying to write XML and JSON parsers) just because folks don’t want to use the huge amount of already proven and tested modern frameworks (most of which are open source by the way).”
The irony is that openMDWS is based on a web services framework that has been in existence since 1996, pre-dating every other “modern” web services stack by many years. This isn’t stuff we’re developing from scratch – it’s stuff that I’ve been using for over 15 years. The XML stuff has been around for many years and was recognised by the XML database guru Ronald Bourret about a decade ago (eg http://www.rpbourret.com/xml/ProdsNative.htm#extc). Actually it’s the “modern” technologies that have been playing catch up!
Secondly, the industry has, in my opinion, gone out of its way to make out that the web technologies and XML are somehow complicated. Those modern frameworks end up making it all an awful lot more complex than it really is, and of course people then end up assuming you need to use those modern frameworks to manage and handle it all. I’m afraid it’s mostly Emperor’s New Clothes.
Thirdly, there are two sides to the web services coin: exposure and consumption. I’m all for VistA services to be consumed by whatever technologies you want to use. But what’s the point of exposing VistA functionality as web services using needless “newer” technologies when:
– the core code being exposed is Mumps code; and
– there are tried and tested frameworks based on a native Mumps stack that will do the exposure as XML, JSON or whatever you want over HTTP, HTTPS, websockets etc
Furthermore, those native stacks have been in place and unchanged since 1996, unlike stuff like .Net which is “upgraded” frequently – but never in a backward-compatible way….all bad news for anyone adopting it (.Net isn’t the only culprit for this cavalier approach to upgrading either).
================
“Healthcare providers don’t care if the software they use is “open source”. They want a software that’s designed right, is stable, user friendly. Organizations want software that they can sustain, can get great resources to develop it further.”
I fully agree – strange that despite throwing almost unlimited amounts of $$$ and expert resources in a desperate attempt to replace it, VistA is still there…..perhaps because it was designed right, is stable and user friendly already? OK the resources available are slim right now, but that’s the incentive behind openMDWS – to encapsulate the small amount of existing Mumps knowledge and make it available for others to use without needing that Mumps knowledge.
=================
“Create a software that works best for your target users and your target platforms. If VA uses Windows on the user workstations then use the best technology that’s available for Windows.”
I agree – but that’s about consumption of web services, not their exposure
=================
“And no everything doesn’t have to be web based. Users will get the most performance/responsiveness with something developed in native technology for the target platform or form factor. If my users are using iPad, I will develop the software in ObjectiveC and design the software specifically for that form factor to use the “specific features” provided by that platform.”
With all due respect, this is absolute rubbish on numerous levels.
For example, have you seen this: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
But the whole mobile Native v Web issue is something I’m going to write about in more detail soon. For now I’ll just say that for healthcare applications, there are huge benefits in going web-based for mobile, and you’ll be starting to see some examples that demonstrate this over coming months. I’d go as far as to say that in my opinion there is no place for Native apps in healthcare.
Rob
Let me clarify a few things if they weren’t already .. or maybe my English is the issue as Joe pointed out 😉
1. My comments are not just about openMDWS and Web Services but the overall MUMPS/VistA business, I am not just talking about WebService exposure. I am talking about the over all ecosystem.
2. I did not propose picking up new technology as a shiny new toy but stressed using it if its best for the end-users experience and if its best for the organization to maintain and extend.
3. I also did not propose a silver bullet for every problem. Pick what’s best for the given scenario.
4. I am definitely talking about the fact that MUMPSters resist to learn what’s out there, and the way people push Open Source and Cross-Platform _ everything is web.
Now lets get back to your reply.
======
“As my earlier blog postings have tried to explain and demonstrate, Mumps can do pretty much anything required to co-exist in the modern networked, web world, and if it can do so more efficiently and more maintainably, then those techniques need to be embraced.”
======
Assembly language can do anything you want too, but you don’t do that unless the application/scenario has a specific need to use assembly! again use what’s best for the target scenario. if MUMPS is best for creating web services as you say, then use it.
=====
“But equally the wider IT world needs to stop its blind and largely ignorance-driven prejudices against Mumps and discover what it can also do.”
=====
I don’t have a prejudice against MUMPS, how could I… 8 years ago I only knew of MUMPS as a disease (so 8 years ago I was ignorant – I admit) Then I found out there’s a programming language with the same name (interesting choice) and that its the VA’s best kept secret. I learnt the language and did quiet a lot with it both for VA projects and outside VA projects – and I still think its a disease 🙂 and wont mind it being a secret till it dies. So now that I am not ignorant – my comments are not as an outsider who doesn’t know what he is talking about.
======
“so how come Mumps does seem to dominate healthcare worldwide, and how come it’s proven so difficult to replace with “modern” technologies?”
======
I think a better question is what’s so special about healthcare industry? how is the healthcare software different than any other mission critical software in any other industry. You know the history of MUMPS and VistA better than I do – but IMHO the mumps code base grew over the years, initially by people who worked in the hospitals who knew less about software and more about healthcare (which in a way, is good as they knew the domain better). And as many industries go, “don’t fix what’s not broken”, It kept on going.. and now its a huge legacy system – and it is broken – that will take a lot to completely replace. The software design is so clunky and filled with dependencies that it’s hard (but not impossible) to replace it module by module. So much for HIPPAA, CPRS uses a text based horrible RPC protocol that any newbie can sniff the traffic and see ASCII text. I hear there are some improvements in that area with BSE now.
========
“unlike stuff like .Net which is “upgraded” frequently – but never in a backward-compatible way….all bad news for anyone adopting it”
========
What is not backward compatible in .Net? Which versions of .Net have you been developing in if I may ask? or are you talking about the so called tech-journalists blogs. Please google for a video which shows a Windows 3.1 app running on Windows 8 desktop without changing a line of code. And by the way upgraded frequently is a GOOD thing. A software / technology/ product that’s not upgraded and improved dies a terrible death or at least fades out of the mainstream.. hmmm that sounds a lot like MUMPS.
The bad news is for MUMPS developers as they risk losing their jobs if VA invests more in modern technologies. I have first hand experience with MUMPS developers that felt threatened when shown a modern view on top of vista that the users liked!!
I am sure the newly hired developers love the fact that that the VA and may be others still adhere to the decades old “coding guidelines” (SACC) where code readability is a lesser concern than “optimizing” for space and character count. That they cannot put a space between an equal sign and the variable value because back in the day disk and memory space was very limited – spaces were evil. or that some MUMPS compilers need dots “.” for scoping the code in an IF block, or I am sure when the newer developers get old MUMPS code to maintain they will welcome the cryptic keywords (I for IF and S for SET) and the stupid limit on character count for variable names and routine names. Or the fact that their code has to rely on 10 other global variables that are named X,Y and Z. or that even with Fileman there is still code out there that directly accesses Globals and that Fileman even though much better than direct global access is still a very primitive access mechanism or that there are 10’s of fileman fields with an asterisk infront of them or that there are two set of code fields for the same thing because the DD character limit on the first set of code is up and we need more code sets.
I have nothing against NoSQL databses, I use them in a couple of web applications, but if you think MUMPS is easier to develop and maintain on an enterprise level than the newer NoSQL techs, I wont argue! But maybe Joe can chime in and defend MUMPS some more.
===========
“strange that despite throwing almost unlimited amounts of $$$ and expert resources in a desperate attempt to replace it, VistA is still there…..perhaps because it was designed right, is stable and user friendly already?”
===========
I don’t think a project failure means MUMPS is great. As a counter example – even though the VA has a failed $120MIL project for scheduling, IHS has a successful scheduling project in $400K.
LoL @ designed right and user friendly; have you spoken to VistA users – especially the newer generation who actually “know” what good software looks and behaves like? do they love working on command line screens to see a clinics schedule. Do they like it when one person opens patients demographic screens on the commmand line that the record is locked for everyone else? if it is so user-friendly why are there contracts out for providing a better software? Software needs to be maintained and improved. Something that was the best in 1970 is rarely the best in 2012.
==========
With all due respect, this is absolute rubbish on numerous levels.
For example, have you seen this: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-st
I’d go as far as to say that in my opinion there is no place for Native apps in healthcare.
==========
LoL – First let me say that I am really excited about HTML5 and the improved JS frameworks around it. I am using it for one current project. I am always in for newer and better technology and I am using it for some projects _ where it makes sense_!!!
But do you really think HTML/Javascript runs faster than native code?
I am not in for toy consumer apps with 3 pages in total, show me any Enterpise Mission-critical Real-time application in any industry that is done in HTML/Javascript that provides a great user experience and is not a pain in the butt to maintain.
What’s important is that this is not about a bunch of super developers who love coding in Notepad or VI editor. Its about a big resource pool (probably average developers at best) that an enterprise can rely on. Its about the whole application lifecycle. Show me a development environment for HTML5 and Javascript that is as mature as the one for mainstream techs – lets say .Net or Java or C++. Show me great debugging tools at the same level. Show me great code refactoring tools at the same level.
With the current state of toolset around HTML5/Javascript I would love to read about an EHR developed with 50 developers working on different parts and maintaining it over 2 years and all the while keeping the healthcare providers happy with user experience.
Its a good thing that its not the developer enthusiast who decides what has place for what in the any business/industry. Its the USER who decides, because they can see what performs and feels and looks best. If I want to develop a website for broader reach, sure I would be stupid to use native tech – or maybe even for a patient facing portal! But to say that there is no place for native apps in healthcare……
I am happy that you mentioned it though, as it is a newer tech that shows promise.
MUMPS is not in the mainstream, because it hasn’t kept up. Its not being taught in schools, there is no general demand for MUMPS or BASIC or COBOL or FORTRAN. No disrespect meant to you Joe, but the fact is that oldies are having a hard time letting it go. The MUMPS expertise is very slim and when the oldies retire or say goodbye to this life, it will be panic in the VistA world OR someone will make a lot of money out of the situation 🙂
Hmm. OK, Rob wants to know why VistA has been so hard to replace. I can only talk about the VA and its effort which was utterly tragic. First thing I have to say there is I wouldn’t have hired the folks VA hired to clean my bathroom. VA has some serious problems. IT management is largely a bunch of amateurs that can’t be fired for incompetence. You get some smart folks at the very top and some smart folks at the developer level and the stuff in between… Yikes.
Second, VA continues to insist on revolution instead of evolution. They learned absolutely nothing from the HealtheVet fiasco. Imran mentions scheduling. There’s also no HDR. CPRS Reengineering is back from the dead under a new name but is still bent on a complete new rewrite instead of evolving current CPRS into the desired web app. There is a beautiful migration path they insist on ignoring. And when funding dries up, as it did with HealtheVet, the users will still be stuck with CPRS.
Bottom line, the failure to get away from Vista is more about incompetence than anything else. It’s certainly not because it’s well designed. Have you looked at labs? Or appointments? In fact, incredibly awful design is probably reason #3 for the failure. Trying to tease out the business rules is a disaster.
Rob also asks, “But what’s the point of exposing VistA functionality as web services”? Did you read my previous reply? BR, BR, BR. That and hiding the schema.
Now Imran: “maybe Joe can chime in and defend MUMPS some more.” Huh? And: “No disrespect meant to you Joe, but the fact is that oldies are having a hard time letting it go.” Imran, you DO realize the Joe in this thread is Joe Gillon, right? You know, the Joe Gillon who’s never written a MUMPS procedure? Who upchucks when he has to try to make sense of any of the shit in Vista? The Joe Gillon who struggles to write those DDR LISTER IDENTIFIER one-liners? I’m gonna defend MUMPS? You’ve been drinking those Long Island ice teas again haven’t you?
Oops. Forgot this Imran comment:
CPRS uses a text based horrible RPC protocol that any newbie can sniff the traffic and see ASCII text. I hear there are some improvements in that area with BSE now.
Chuckle. Well, the AV codes are encrypted. Of course if want to decrypt them you have two options. One is to call the DECRYP function via XWB GET VARIABLE VALUE (you can get around the “security” by enclosing the call in a $P call), or you can look at the cipher pad in any number of places. But who’s gonna do this? Who gives a rat’s?
Joel can correct me on this but I don’t believe BSE addresses this at all. I know it’s a shock but BSE is pretty ineffectual. The basic assumption was the user was a logged in Vista user so it wants to go to the authenticating Vista for a token. Problem is, some apps don’t have such a user. MyHealtheVet, for example. The user is a vet. Data requests from outside VA, like from DoD, the user has not logged onto a Vista system. So they had to allow verification of credentials by a web site and all you have to do then is put a DB at that site, put the credentials you want verified there, then tell the target Vista to go there for verification. One of the primary reasons VA needs federated user ID. I previously mentioned a second, which was access to resources like Cache. A third was connection pooling but Joel and his M buddy have worked out a nifty scheme to implement that. They simply save the user’s symbol table and reinstate it each
request! Gotta love it.
I’m going to propose an exercise, but first I have to pay homage
to the level of writing in this thread. OK, Rob’s a Brit and as
we Yanks know, ALL Brits speak and write perfect English. But
Joel, besides being a Yank, was a math major, and Imran! Imran
was raised in a hut with goats and stuff grazing in the living
room. I have no clue who Rafael is but it wouldn’t surprise me
to learn English was not his mother tongue. And yet, as near as
I can tell, my own blathering excepted, perfect English all
around. Now, having read a lot of techie writing, I know how
rare that is and I am duly impressed.
OK, the exercise. In VistaNoteDao there is a function called
“okToCreateNote”. It holds the VA’s business rules re progress
note creation, as culled from CPRS. First of all, these BR are
not documented anywhere that I know of. The only place they
existed, prior to MDO, was in CPRS. Who knows how many developers,
me included, wrote apps that created notes incorrectly? That’s
on the VA.
So one goal of MDO was to get those BR somewhere they could be
used by ANY developer and since MDO was in C#, I needed to expose
it as SOAP web services to make it available to apps in other
environments. That’s actually the only, or at least, main reason
there is a thing called MDWS.
That said, these BR shouldn’t even be here. These are VA rules and
would lock any non-VA VistA-based organization into those VA rules.
I knew when I wrote them they should be in a separate BR engine but
who had time for that? An example of the “just do it and refactor
later” strategy I alluded to earlier. The main Medora motto was
“it’s better to ask forgiveness than permission” but another was
“perfection is the enemy of progress”.
If we look at them specifically we can see how VA-centric they are.
The first one is one of my favorite VA-isms. It rules out the
creation of surgery notes. Yet CPRS does in fact create surgery
notes, so WTF? I searched several sites for ANY note that was
designated a surgery note, per the RPC “TIU IS THIS A SURGERY?”
and NEVER found a single one! Notes with blatant surgery-related
titles were NOT surgery notes! I concluded that there was a time in
CPRS history when it couldn’t create surgery notes but once that
constraint was removed the VA, instead of removing the BR from CPRS,
simply unmarked the surgery note flag in VistA. I had to conclude
this because, again, not documented anywhere that I know of and,
being an outlaw developer, I did not have access to the people who
made the decision, whatever it was.
The next one took some time to understand, but I believe it rules
that some visits can have only one note. So an undocumented VA BR
would be that some visits may have multiple notes by multiple
providers (probably in multiple hospital locations) while others
can have only one note with those additional providers making
addenda. Get that – “addenda”. I got some English too.
Some of the other rules I suspect are incomplete. For example, VA
checks to see if a consult ID was provided on a consult note but it
doesn’t seem to check that this note is in fact the note for that
consult. Same with patient record flags.
So all of that is VA vagary and shouldn’t be visited upon non-VA
institutions. Which leaves us where? These BR shouldn’t be in CPRS,
not only for the same reasons they shouldn’t be in MDO, but also
because in CPRS they are unavailable to other apps. Apps using a naked
RPC broker are even worse. Then the developer needs to reinvent all
this stuff which I can tell you simply does not happen. And it seems
to me that openMDWS has this same problem. You’re making unpackaged,
stateless calls to the DB and that puts the BR burden on the developer
of every app. I should also point out that broker-based, Cache-based,
GT.M-based, openMDWS-based apps need to know the underlying schema,
another wheel reinvention MDO was designed to eliminate.
OK, say we write a layer in between the app and openMDWS that does
package the business rules and hides the schema and that app uses
all that nice openMDWS stuff. Hmm. That begins to look a lot like
MDO with a BRE. And maybe that’s better than existing MDO/MDWS.
Certainly, I totally agree the BR need to be extracted to a BRE.
But is it really so important to rewrite MDO/MDWS in some other
language when there are so many other issues to be addressed? Or,
in other words, has the time come for massive refactoring of
MDO/MDWS? Or just tweaking like exposing the functionality via WCF?
How much effort and time that could be otherwise directed to
problems still at ground zero should be invested in getting
MDO/MDWS out of C#?
Having said all that and having sounded like a totally partisan
MDO/MDWS guy, I myself am actually poking around with other solutions.
I’ve made RPC brokers in PHP, Ruby, Python and Java (to be used in
ColdFusion apps) but I’m still unclear as to stack architecture.
I think my goal is something like a Rails gem that does for VistA
what the Rails ORM/MVC stuff does with SQL DBs, ie, the semi-automatic
creation of a web app a la Yii’s Gii. Not too clear yet how to get
there.
Enough with the goats dude… I have moved on to better stuff 😉 _ let your imagination go wild _
I’m just jealous. Only wildlife roaming around my childhood home was cockroaches.
Wow, good debate here! Well as the very first client of MDWS back in 2005 (or was it late 2004 Jo?e – can’t remember those days of yore too well now), I’ll chime in and say I see good points being made all around, but I have to agree with Joe that the real improvement I see needs to be made to MDWS is extracting the business rules into a BRE. I’ve been exploring that with some other projects and it is a huge key to reusibility. Also, going full WCF with it and ditching the ASMX. I know Joel has already been exploring this and there are backward compatibility issues with older clients (like my Suicide and Homeless Hotlines) that are reliant on the ASMX services, but eventually those should be worked around and all the main facades be presented as WCF services.
Rob, do you have a plan in openMDWS to deal with the real problem I see here – the embedding of core business rules into CPRS where they don’t belong and aren’t being forced on VA developers via some mechanism. Correct me if I’m wrong Joe, but in my understanding one of the key purposes of MDWS was providing a “safety layer” (I won’t use Joe’s term!) for developers against VistA data by by enforcing these BRs on MDWS users. Over the last couple years this, in my mind, has become one of the most urgent issues they need to deal with. Forget upgrading to a better data system or architecture (we all know that’s never going to happen with VA’s entrenched bureacracy even though it is sorely needed like Imran says), they need to clean up the system they already have. VistA could work well enough provided all the right filters were put on each VistA’s files to prevent bad data entry and RPCs were written that could encapsulate the BRs that are needed so that whether it be MDWS or openMDWS or hitting RPCs directly with Mumps they would be using the data properly.
Jason
Hey Jason. Yes, VA is clueless re business rules. I’ve even had CPRS authors inform me the BR are ALL in VistA! The very guys who’ve embedded rules like note signing and co-signing in CPRS. Also, as you’ve heard me whine many times, the BR are not documented anywhere. They are embedded in MUMPS and Delphi code and that’s it, near as I can tell. MDO should be seen as merely step one in remedying this – getting the BR into a middle tier and making them available to ALL client apps. A huge step in the right direction. Next, as you say, is a BRE so they can be dealt with directly, especially with SME input. My one concern there is performance. The now defunct HealtheVet architecture was incredibly complex with the data bouncing from one server to the next before getting to the user, and that was one of the main reasons for the project’s failure. Well, that and good old incompetence.
BR in the middle tier is like a condom – it protects both partners. VistA doesn’t get crappy data and the developer doesn’t get fired.
I have been using openMDWS to build a VistA scheduling replacement. (VistA scheduling might not be the best example as the original developers seems to ignore many VistA standards) and I have tried, as far as is possible, to build the rules directly into the openMDWS calls so that they are encapsulated in the function.
As you say many of the rules are not documented and embedded directly in the code but certainly pass/fail rules can easily be encapsulated in this way.
Guidelines and warnings are a little harder but it should not be beyond the wit of man to create a standard for openMDWS to handle these.
Chris Casey
A new county heard from. Welcome to the thread. <= me being friendly. I don't understand what you're saying though. First, and probably not very important, your comment about the original developers ignoring VistA standards. The only surprising thing there is the implication that there are "VistA standards". What might they be, for example?
Second, the rules. You're building them directly into the openMDWS calls? Are you doing the same thing I did with MDO, encapsulating groups of calls in functions? For example, in the MDO call to write a note there are a whole passel of RPCs to check if the user is permitted to sign that kind of note or needs a cosigner, to associate the note with some visit or stay or consult, to validate the esig, etc. The client app has to pass all the required info in the call to MDO or it spits it back. Is that what you mean? And yes, that sort of thing can have unit tests (and does). If that's not what you're doing I'd like to hear more.
If it is, I regard that as a sort of half-way solution. At least the logic is out of VistA which then provides a migration path away from Vista and yes, Vista should be migrated away from. It gets a lot of good press but it's a shambles. It shouldn't have all that logic in it, it shouldn't have the data for non-medical things in it, like inventory, finance, etc. Scheduling. Why is scheduling in VistA? The only possible argument for a hierarchical database is its speed which may be fine for POC medical use cases but completely unnecessary for an employee entering leave requests. And even then the medical data is a bloody mess. The labs data is a notorious joke. We couldn't make a simple multi-site radiology interpretation app where a radiologist sits at a screen and pops images off a stack, images from a multi-site catchment area, because the image file is a subfile of a subfile. Who thought that was a good idea? Who figured it was cool to have two appointments subfiles? In fact, who thought subfiles were nifty? Even the VA wanted to replace it a few years back but incompetence roached the effort. Which then led to this "VistA is wonderful" craze. Whatever. Getting the rules out of VistA is only half-way because they eventually need to be in a BRE where SMEs can manipulate them rather than programmers.
Joe
I think many of us would agree that VistA is much like the old joke about the Irishman who is asked the way to Cork by a tourist who is lost in the middle of the country, and responds: “Well if it was me, I wouldn’t be starting from here”
The unavoidable reality is, with VistA, we are where we are, like it or not. And, has been proven many times before, attempting to rip and replace VistA is a non-starter. So, it’s all about finding ways to move forwards in an evolutionary way, building a way out of the legacy code, and in a way that allows the use of a new generation of developers who don’t need to learn the Mumps language.
openMDWS is one part of the way forward, and Chris has proven that it works and works well. I’ll let Chris explain in more detail how he handles the rules, but my understanding is that what he does is very much in line with your approach. All I was interested in doing was to create the framework that is openMDWS and then let others who know and understand VistA use it to begin encapsulating and migrating that VistA functionality.
Perhaps it’s only a half-way house, but at least it’s a step in the right direction. Sure there’s lot’s more needed to be done as well, but Rome wasn’t built in a day
Rob
Hi Rob. Everything you said excepting the bits about openMDWS sounds like I wrote it. I’m forever preaching evolution vs. revolution. In fact, there’s a project going on inside VA now that sounds like my understanding of openMDWS in that it’s M/Cache stuff _inside_ VistA. Like Joel and Imran I don’t like the idea of the web services being inside VistA. Maybe I don’t understand openMDWS, been a while since I read about it. I don’t like developers having to know the schema of a datasource. An app should just ask for allergies or meds or whatever and neither care nor know how they arrive. Didn’t you say somewhere that an app could have direct access to M globals? That may be efficient and it may work and work well, but I’m still ‘agin’ it. Nor do I consider MDWS a final solution. It’s more a step forward. It too works and works well, but that doesn’t make it the best way to do things.
Hmm. Maybe I don’t understand. Maybe it’s about nomenclature. If I ask myself would I replace or at least supplement MDO’s (not MDWS’s) RPC broker with something that could statelessly manipulate M globals, then yeah, certainly. I often wanted to do that with HL7 messages but VistA doesn’t have enough of those. The RPCs suck, no doubt about it. There’s a new, more efficient one, which is nice but still… Maybe I’ll take a closer look at openMDWS, maybe the name is misleading and the true value is not at the web service layer but the layer between the web services and VistA. I don’t like client apps knowing the schema but of course the Vista access layer has to know something about it. I’m working on a technology and methodology to evolve away from the roll’n’scroll and my main conduit to VistA is the DDR LISTER RPC which I’d love not to deal with. And I certainly need to know the schema to use DDR LISTER. So maybe this is not so much MDWS vs. openMDWS as MDO broker vs. openMDWS?
Just my $0.05, I like evolution approach that openMDWS offer. So, the idea is great but implementation…. Node.js is great compliment to MUMPS database like GT.M because it shares similar concept such as subscripts and JSON structures. Even more, Node.js based frontend is great idea, EwdLite is leap in the right direction. The only problem now is well documented API to the legacy code. Sorry but if we are talking about VISTA only, MDWS or CPRS broker are not a good choice because of flexibility and usability. Ideally, I would rather say it should be stateless API on the top of FileMan such as part of this project https://github.com/OSEHRA/fileman-22p2/tree/master/ewd/fileman It gives you an access to all power of old Fileman including features missing in CPRS from the one hand. From the other hand, it is not just direct access to the globals without any sanity check and business logic. You leverages from hundreds of man-years already invested into routines. This is a big plus to my mind.
[…] NHSVistA – VistA [wikipedia] is an open source clinical system used in the USA for healthcare within the Veteran’s Association. Although in its present form it is clearly not suitable for use by NHS GPs, we are considering whether certain elements of it might be usable and there are a number of people coming to the THM who support this view. Rob Tweed on VistA/MUMPS/MDWS/EWD etc […]