Re: [code-convergence] VistA 'Onion' Diagram

Tom wrote: "Next up: (if anyone reads this) Some thoughts on the future of the onion diagram." Please press on. Not only is it interesting reading, but I cling to the hope that those within who are making decisions now will understand maybe just a little. "VistA is a process not a product." -maury- ----- Original Message ----- From: Tom Munnecke To: Code Convergence Sent: Monday, March 26, 2012 12:53 PM Subject: Re: [code-convergence] VistA 'Onion' Diagram I sketched the original version of this diagram on a placemat at Coffee Dan's restaurant in Loma Linda, Ca. over dinner with George Timson in June, 1978. It's an amazing experience to see this diagram still floating around, nearly 34 years later. At the time, Ted O'Neill and Marty Johnson of the Computer Assisted Software Support Staff (CASS) were pulling together a team of programmers to work on a standardized, decentralized hospital information based on the MUMPS language. Marty Johnson scoured the country to collect a team of really skilled programmers who had a lot of experience in health informatics, chosen for their skill and creativity over a range of specialties, but not necessarily their ability to "color inside the lines." We planned to use minicomputers in hospitals, which at the time was a radical concept. IBM mainframes dominated "real" computing, and were held in large computer centers doing mostly batch processing of administrative data. The notion of using small, interactive computers to meet medical needs was seen by these centralists as 1) technically impossible, and 2) an existential threat to the centralized computing model. The VA had a scattering of medically-related systems, all running in incompatible hardware, software, and administrative "stovepipes." Most VA employees interacted with computers through forms that were keypunched, sent in to the Austin Data Processing Center, and never seen again. Hospital barber shops would send in detailed forms to central office about the number of haircuts they performed, but there was no system for doctors to see lab information, clerks to find patients, or schedule appointments. Information quality was atrocious: crosschecking the statistics generated by the centralized Patient Treatment File (PTF) and the Automated Management Information System ("Something is amiss with AMIS") were off by 600%. (I recall explaining to some central office folks about a way of extracting this information automatically - and reliably - from daily operations, they said, "But we rely on this data for our reporting to congress." Being able to pick and choose data to suit their reporting needs was of great value to them. This was my first taste of "beltway logic" - and the huge difference between technically correct and politically correct software development. I formalized this later into Munnecke's Law of Software Productivity: that software development is inversely related to the square of the distance from VA Central Office. (There were some exceptions to this rule, notably the imaging work done at Washington VA.) I drew the original onion model to show how we might develop a common core infrastructure, driven by metadata contained in a data dictionary. This would support a shared information environment upon which the applications would layer would sit. The idea was to create a system that was "integrated" by the virtue of the fact that we had not "disintegrated" into pieces. I didn't start with the pieces, then try to put them together, Humpty-Dumpty style, but rather tried to create a path of least resistance to a comprehensive, hospital-wide shared information system. I just wanted to make it easier to doing things in an common manner, which was one of the goals of the kernel. The original diagram had ANS MUMPS as the innermost layer. Today, this could be called a Virtual Machine, as it was a simple interpreter based on 19 commands, 22 functions, one data type, on one language. Porting this VM to another platform, ( coupled with the machine-specific function coding contstrained to Kernel ). We can still see the effectiveness of this design decision today, as VistA can operate on either the proprietary Cache or the open source GTM interpreters. One of the things I noticed was that everywhere I went in the VA org chart, people wanted to have things decentralized above them and centralized below them. One of the critical inital design choices of the VistA effort was to decide where to anchor the design - was the center of the onion Central Office, a region, a hospital, or an individual service within a hospital? DHCP focused on the individual hospital as this anchor point. Given the technology of the time - "high speed" communication networks used 9600 baud modems; home computers were just appearing as hobbyist toys - I think that this was the appropriate choice. When I saw features sprouting up at innappropriate layers of the onion diagram, I called them "warts on the onion." The are quite visible on today's version, most noticably the Austin Automation Center poetically portrayed as an external amoeba-like lump. This illustrates a key issue: the onion was designed to be a meta-level diagram of the connectivity and flow of information in a hospital, but now we have added a wart on the diagram that is based on the organization chart, not the data flow. Instead of embedding the data flow into the inner layers of the diagram (I put it inside of the Kernel when I lead the kernel development team), it is now portrayed outside the onion, layered on top of COTS and Class III software. This is a serious breach of conceptual integrity - we are moving down the slippery slope of "automating the organization chart" rather than meeting the needs clinical needs of the clinicians. We can see this in the OSEHRA architecture design, which goes into great detail about the organization chart objects, but seems to give scant attention to anything patient-related. In looking back at the evolution of the VistA system from such simple origins, I am struck by a number of things: 1. The endurance of this diagram after all these years. Perhaps it is just bureaucratic inertia, but there is something charming about this diagram that pulls people to it. Lesson learned: a successful, long term system needst to have a certain charm about it.... not too simple, not too complicated, but just enough so that folks can relate to it. 2. The VA has failed to upgrade the infrastructure over the years, focusing on the outer layers of the onion... This can be seen in the confusing mish-mash of outer layers/warts as well as the ancient components of the inner layers that need a lot of modernization. 3. My biggest regret is naming the communications services subsystem "MailMan." I was really designing a network infrastructure, with transaction processing, queuing, security, file formats, and social networking elements. The actual delivery of email - what one sees with Outlook, for example - was just a minor portion of the design. I wrote it as part of the March AFB/VA Loma Linda sharing effort, using an approach very similar to today's HHS Direct Project. Next up: (if anyone reads this) Some thoughts on the future of the onion diagram. But enought of the past 34 years.... what about the next decades? -- Full post: Manage my subscriptions: Stop emails for this post: