Now I’ve seen everything…

The president and CEO of OSEHRA recently posted the following announcement:

The Department of Veterans Affairs yesterday announced a decision to select a new electronic health record system based on the same platform that DoD purchased a couple of years ago. The announcement recognizes many unique needs of VA that differ from the DoD. VA would thus not be implementing an identical EHR. VA is trying to create a future health IT ecosystem that takes advantage of previous investments with this new platform, as well connections with many other IT systems in the private sector. The industry trend toward open platforms, open APIs, and open source software is expected to remain integral to VA’s strategy to build a new and interoperable ecosystem. OSEHRA provides a valuable link joining VA to the broad health IT community. This activity will remain critical to the success of VA’s transition strategy by eliminating future gaps and conflicts in an ever more complex ecosystem. Transition to a new EHR system will require years of efforts and in-depth expertise in VistA that currently resides mostly in the OSEHRA community. Innovations in health IT such as cloud-based implementations, analytics, clinical decision support systems, community-based care, and connected health will come from domains external to traditional EHR systems. Recent VA investments in eHMP and DHP are examples of open source innovations external to traditional EHRs, and they are expected to evolve as new platforms within the VA’s emerging health IT ecosystem.

Seong K, Mun, PhD
President and CEO

I suppose if we have our heads in such a place where the sun doesn’t reach, we can pretend that the VA’s adoption of a proprietary EHR is somehow a victory for open source.

I suppose, however, that I shouldn’t be surprised, considering that OSEHRA is just a dog-and-pony show to allow the government to pretend that it supports open source while doing exactly the opposite.

It helps little that large and critical components of eHMP–which is admittedly an extremely impressive project–aren’t even published in OSEHRA’s code-in-flight releases.

In the sand hast thou buried thine own heads, OSEHRA. An ally you are not.

Hasta la VistA, Baby!


This article implies that VA dropping VistA would be good for VistA. This makes the assumption that the extra-governmental VistA community and private vendors (like MedSphere and DSS) would step in to fill the void left by VA’s departure from VistA development. If, instead, this community continues to expect salvation from within the VA bureaucracy, VistA will die.

Also, please remember that I do not in any way fault individual VA developers for the bumbling mismanagement of the product.

It brings me no joy to express the grim reality, but I believe that at least someone needs to speak the difficult truth: politicians have never been friendly to VistA, government cannot effectively manage software projects, and the only bright path forward for VistA is to get it out of the hands of corrupt government cronies like Shulkin.

I’m not going to wring my hands today.

Instead, I’d like to extend my sincerest good wishes to Secretary Shulkin and his team as they embark upon what is sure to be a long and difficult transition to the Cerner EHR. I really do hope it works out for them.

I’m also hardly able to contain my excitement for what this could mean for the future of VistA. Provided the VA stays the course with this plan, its future has never been brighter.

The VA has been trying to get out of software development for years, and has had VistA limping along on life support the whole time. Outside, private-sector vendors have been understandably hesitant to make major changes to the VistA codebase, because they haven’t wanted to break compatibility with the VA’s patch stream. But now, there’s a chance that the patch stream will dry up, along with the stream of bad code, infected with the virus of Cache ObjectScript, and the VA’s marked indifference towards fixing structural problems with core modules like Kernel and FileMan. The VA always hated VistA, and they were atrociously incompetent custodians of it, from the moment it emerged from the rather offensively-named “underground railroad”. They suck at software development, so they should get out of that business and let the open source community take the reins.

This is not to say that there weren’t or aren’t good programmers at the VA: far from it, but VA’s bumbling, incompetent, top-heavy management bureaucracy forever hobbled their best programmers’ best intentions. And let’s be real: had Secretary Shulkin announced that VA was keeping VistA, it would be status quo, business-as-usual. VistA would still be VA’s redheaded stepchild, and the bitrot already plaguing it would get even worse. There was never the tiniest chance that the VA would wake up and start managing VistA well, much less innovating with it. And even if this Cerner migration fails (which is not at all unlikely), there will never be such a chance. Its successes stem entirely from its origins as an unauthorized, underground skunkworks project by those great VistA pioneers who courageously thumbed their noses at bureaucratic stupidity. VistA only ever succeeded in spite of the VA; not because of it.

But, what about patient care? Won’t it get worse as a result of dropping such a highly-rated EHR?

Worse than what? VA sucks at that too, and always has. Long waiting lists, poor quality of care, bad outcomes, scheduling fraud, skyrocketing veteran suicides: none of this is related in any way to VAs technology, for better or worse. It’s just that pouring money into IT changes is a quick way for a bureaucrat with a maximal career span far too short to affect any real change to appear that they’re doing something. When IT projects fail, they can dump it in their successors’ laps, or blame the contractor, and go upon their merry way visiting fraud, waste, and abuse upon the taxpayer, while those who committed to making the ultimate sacrifice in service of king and country are left wondering why it still takes them months just to be seen.

So I sincerely do wish the VA the best of luck in its witless endeavor, and hope that they succeed, by whatever comical measure of success their bumbling allows. Hopefully, this will open the door for the open-source community to take the awesomeness that is VistA and bring it forward into a brighter and happier future.

Feel free to join me. Virtual popcorn and soda is free.

Tried Solutions are not Tired Solutions

This article provides a great argument to why a tried-and-tested database like the one provided in GT.M is a better solution than the trendy, buzzword-compliant, Johnny-come-lately industry darling of the day. If a social networking package finds MongoDB’s consistency problems unacceptable, imagine the disaster lurking for its use in the kinds of apps currently being supported with MUMPS databases! Also, the problems inherent in querying these kinds of databases for any but the most simple set of predicates is barely even covered.

While one could argue that MUMPS suffers from a lack of sex appeal that keeps it a little-known and oft-ridiculed language, let’s remember that the resilience of our flagship VistA–in spite of its mother agency’s constant and concerted efforts to kill it–is in large part due to the small and dedicated community that has built up around supporting and improving it. Perhaps we should entertain the idea that a smaller, more focused community of good people is better for our language and its applications than a large and well-known group, which would invariably be fated to follow the unstable and expensive path dictated by the wiles of a fickle and short-sighted industry.

Long story short, we should focus on improving the existing MUMPS language and database, and be extremely careful to avoid being distracted by the lure of bright, shiny objects. There are no silver bullets, and anything that sounds too good to be true probably is.

What an object-oriented MUMPS could look like, without breaking existing code

A little idiomatic support for the OO paradigm is something I’d love to see MUMPS embrace in the future. This is not to say that you can’t write OO code in MUMPS ’95–you can even write OO code in assembly language–but, the syntactic sugar would be nice, as well as the scoping protection and encapsulation this would give. The introduction of the dot-notation paradigm would lend itself very well to creating clean new API libraries. Some of you may not know, but the dot-notation API is used by some MUMPS vendors for calling out to external (non-MUMPS) routines.

We’d add a few new things:

  1. Overloading the NEW command so that it can also be a unary operator. This will allow operations such as:
    set myCar=new $$Car()
  2. Adding a $OBJECT() intrinsic, which would take two parameters: a variable name and a type name.

    would return a true value if the node referenced by variable (which can be a global variable or a local, either could include subscripts) matches the type defined by type.

  3. Adding a this keyword, which would return the entire current object.
  4. Adding conventions to the language. Any NEW commands at the top level of a routine would define instance variables, and the top-level routine without any tag specified becomes the default constructor for an object.

The main thing I’d like to see, though, is the ability (shown in the hypothetical sample below) to store entire object instances in MUMPS globals and retrieve them later:

;; when tag and routine are same, use the default constructor
 new color,doors,started 
 set color="",doors=0,started=0
;; overloaded constructor (limitation: 
;; you could only overload the constructor once)
 set this.color=color,this.doors=doors
 quit this
;; procedure method
 set this.started=1
 write "Car started",!
;; procedure method
 set this.started=0
 write "Car stopped",!
;; extrinsic function method
 quit this.color
;; extrinsic function method
 quit this.doors
;; extrinsic function method
 quit this.started

 ;; new as a unary operator as well as a command
 new wifeCar
 set wifeCar=new $$Car("blue",5)
 new myCar
 set myCar=new $$Car("silver",4)
 ;; we're now going to store myCar and wifeCar in subscripts 
 ;; of the ^persistentCars global
 set ^persistentCars("John")=myCar 
 set ^persistentCars("Miri")=wifeCar
 ;; $object(variable,object) would return null if "variable"
 ;; is not of type "object"
 new memCar
 if $object(^persistentCars("Miri"),Car) do 
 . ; this use of the new operator will fail 
 . ; if ^persistentCars("Miri") is not a Car
 . set memCar=new $object(^persistentCars("Miri"),Car) 
 . ; we can now access Car's methods from memCar
 . do memCar.Start 
 . if $$memCar.Doors()>2 write "family car!",! else write "coupe!",!
 . set ^otherPersistentCars("Miri")=memCar
 else write "The global did not contain a valid Car",!