Re: How Debian Packaging practices could apply to VistA maintenance and distribution

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

Adding my two bits' worth, for what they're worth.

First, the easy part.  The mechanics of creating a Debian package of VistA will be completely straightforward.  I know because I have created many VistA installers.

VistA will be distributed as a large number of source program files and database extracts, 100% ASCII source code.  The Debian package will be around 175MB (33MB routines zipped, 141MB database extract zipped, less that 1MB miscellaneous zipped, such as shell scripts).  Routines will be compiled on the local machine by the postinstall script.  In fact, compiling routines can even be optional because GT.M compiles them on demand.

A binary Debian package doesn't make sense: the object files will be approximately twice the size of the routines and both routines and object files will be need to be in the package anyway - one of the features of the M language is a $TEXT() function that allows a program to look at its source code at run time, and most M applications use $TEXT().

VistA consists of over 25000 routines of M source code.  For example, with the WorkdVistA EHR flavor:

gtmuser@gtmworkshop:~$ ls -l /opt/WorldVistAEHR/VOE10/r|wc
  25164  201306 1559911
gtmuser@gtmworkshop:~$ du -sh /opt/WorldVistAEHR/VOE10/r
142M    /opt/WorldVistAEHR/VOE10/r
gtmuser@gtmworkshop:~$

M source code, especially as written for VistA is information dense.  Here is a completely random sample:

IEN . ; otherwise, we're in the IEN subscripts & need to process
 .
 . I DIVAL="" S DIDONE=1 Q
 . I DINDEX="B" N DISKIPMN,DIMNEM S DISKIPMN=0 D  Q:DISKIPMN
 . . I $D(@DINDEX(DISUB,"ROOT")@(DIVAL))#2 Q:'^(DIVAL)
 . . E  Q:'$O(@DINDEX(DISUB,"ROOT")@(DIVAL,""))
 . . I DIFLAGS["M" S DISKIPMN=1 Q
 . . S DIMNEM="" Q
 . I $G(DINDEX(DISUB,"TO")) D  Q:DIDONE
 . . Q:$D(DINDEX(DISUB,"IXROOT"))
 . . D BACKPAST^DICLIX1(DIFLAGS,.DINDEX,DISUB,DIVAL,.DIDONE) Q
 . D TRY
 . Q

There are a couple of (proprietary) M to Java converters, and the story has it that when someone tried running one on the VistA code base, they ended up with around 5GB of Java source code.

So, from a size point of view, VistA on the server side will be about the size of a pure-server GNU/Linux distribution.  It is a character mode application.  Client applications are completely separate.

The complexity of VistA comes from its vertical integration.

Consider an office suite or a web server.  The package is quite separate from the content.  It's easy to upgrade LibreOffice without touching the documents, spreadsheets and presentations created with it, or to upgrade Apache without touching the web pages that it serves.  VistA is not like that.

In VistA, the code and database are tightly integrated.  Even sites that use only part of the functionality of VistA invariably install all of it, because even if you only want to implement minimal functionality (e.g., Admission/Discharge/Transfer), it's almost impossible to pull that apart from everything else.  Once you start configuring a VistA environment (e.g., by defining locations), it becomes more integrated.  Once you add patients, that's another layer of integration.

So, what a VistA Debian package can do is provide the core VistA system that can be installed on a computer and from which environments can be created on that computer.  Existing environments cannot be upgraded by installing an updated Debian package.  VistA has its own package management system (called KIDS) and each installed VistA environment on that computer will need to be upgraded by applying KIDS packages.

I hope this is good beginning.

Regards
-- Bhaskar

On 01/24/2012 12:37 PM, Luis Ibanez wrote:

This is email is the continuation of a conversation

that started here:

http://lists.debian.org/debian-med/2012/01/msg00293.html

VistA has a large code base (~2.5 million lines of M code,

that are probably equivalent to ~10 MLOC in C language).

This is complemented with a family of applications that 

include GUIs and web interfaces among other things.

          http://www.va.gov/vista_monograph/

OSEHRA (http://www.osehra.org) is creating an open source

environment for VistA to thrive on and to be made available to

a larger user base.

VistA is currently composed of 168 Packages:

             http://code.osehra.org/dox/packages.html

and it has been compared to a combination of an operating

system with a collection of related applications.

The packages are not completely independent among 

them, and therefore require some form of versioning 

care when they are patched, updated and distributed.

When we picture the challenge of growing an open source

community that would be able to properly take care of VistA,

we can imagine the scenario where each one of the 168 packages

is guarded (or "sponsored" to use Debian terms) by one or two

developers. (which means that we need between 200 to 350 

VistA 'packagers').

Along with the packagers, the actual maintenance and daily care

of the code will require about 10 time more developers. For an

estimated total of about 3,500 developers. For all this to be 

effective, these developers should be collaborating closely

with about 7,000 people with clinical background (doctors

nurses, pharmacists...). That close collaboration is one of the

reasons why VistA fit so well in the medical environment.

This estimation of a ~10,000 people strong community would

follow the typical power-log distribution of participation, where

a small group does most of the work.

A large fraction of this community would have to be composed

by  the developers, managers and clinical personnel that take care

of these tasks at the VA today. They would be complemented

with members of the larger open source community, and by

a new generation of M developers that we need to start training

and educating today.

Just to clarify, here we are not talking about creating a Debian 

package for VistA.  Although that is certainly something we 

want to do, and that it seems that it will be the next best target

once we have a Debian package for  fis-gtm.   (we probably 

should follow up on this in a separate thread).  Instead, of a 

VistA Debian package, the conversation here is about:

     Could VistA build an open source community 

     after the model of Debian packaging community ?

It would seem that the human+technology infrastructure,

+ governance, that Debian has established for its own

packaging is the proper level of support and organization

that will be needed to take care of the natural complexity 

of VistA. In particular, Debian has found the sweet balance

between agile behavior and formal processes, that make

possible to keep up with the rapid innovation of the upstream

packages, while still maintaining structure and organization.

To answer that question above we would need to get the 

combine the expertise of Debian packagers with the

experience of VistA developers and users.

I hope this topic is of interest to this list, and if so,

we probably should make an effort to bring more

VistA developers into this conversation as well.

     Luis

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.