Q&A about the original design of VistA

I know that folks have a lot of questions about VistA, and that there are a lot of assumptions people make about it that are not always well-informed.  I was one of the original gang hired in 1978 to work on what is now VistA, attended the kickoff meeting in Oklahoma City, and generally worked on the initial design of the FileMan, Kernel, MailMan, and overall architectural concepts of the design (which I called "conceptual integrity" of the design, after Frederick Brooks' book, "The Mythical Man-Month."   I have a lot of papers, scanned and unscanned, that I can pull out to answer questions, as well.  

This is, of course, ancient history in some ways.  But I think that there are also a lot of lessons learned to be investigated, patterns to be recognized, and successes to be replicated.  

I just thought I'd open up a discussion thread for folks to post questions or responses about the original intent of the VistA architecture, as well as how it might move into the future.

Comments

donaldtford

Conceptual Integrity of VistA

Glad to have one of the original designers of VistA (and FileMan) available.

I'm interested in the ways FileMan might mutate - especially under open-source - but I have no specific questions (yet) about paths taken and not taken during development

 

Tom Munnecke

some thoughts about the data dictionary

 

It might help to look at FileMan from two perspectives: 1.  The data dictionary, providing a metadata-level definition of the data used in VistA, and2.  The programs that operate on this metadata (the DI* package) I think the metadata management could deserve an evolutionary life of its own, independent of the current procedural access to it via the FileMan routines.  I had visions of extending this to a "Universal Namespace" model, in which every health object in the VA, DoD, or IHS (or any other user of VistA) would have a unique name.  This would provide an *associative* model of access between systems, allowing dynamic and fine-grained access between instantiations.   Think of how we can link an Amazon.com book reference inside of a Tweet, simply by naming a URL.  We don't need to *interface* Amazon to Twitter, but rather, they just need to belong to the same *space* defining the URL.  That address is invariant across web browsers, smart phones, geographical location, and cable/fiber/wifi access points.  Amazon and Twitter are free to publish an *integrated* connection via APIs, but, by default, they can be freely associated.  So, one of my thoughts for simplifying the health care complexity crisis is to view health IT as an associative space, rather than an integrated system.  (I wrote up some of this ideas in my HealthSpace paper in 1998: http://www.munnecke.com/papers/HealthSpace.doc This introduces the notion of a loosely coupled system, opening the door to other forms of innovation in ways of bringing information together. This also opens the door to a much finer grained information security.  Infosec guru Mike Davis of the VA gave me a wonderful metaphor of "drawbridge" vs. "passport" security models.  In the drawbridge model, a castle keeps its information secure by monitoring who gets across the drawbridge.  In a passport model, individual's access privileges are check on an as-needed basis.   In looking back at my designs over the years, I've realized that I've always dealt with complexity through language - creating a higher level meta language, macro processor, or interpretive string to pull things together.  I saw myself as creating a "speech community," giving people language and tools to talk about health.  To my way of thinking, the organizational transformation (email, decentralization; the underground railroad), the clinical user communities, and the software were all intertwingled.  As grandiose as that vision might seem, I think it was easier to think of things at that level.  As Ward Cunningham said of how he felt about his initial design of the wiki, "it just felt right." If you look at the successful Ultra Large Scale systems out there today (e.g. the Web, Wikipedia), their binding is linguistic.  URLs, HTTP, and HTML are symbolic linguistic references to the behavior of the web, and wikis have their own hyperlink format.  We don't have an API to the web - just expressions that are interpreted in various ways. This a huge topic, but I think we need to bump up a few meta levels in our thinking about health, genomics, information flow, and complexity.  

Tom Munnecke

Why Metadata is so important

I posted some comments on the architecture section, but Drupal doesn't allow me to connect a reply across groups.  So, I refer readers of this comment to that reply.

In looking back at my designs from today's perspective, I've come to realize how focused I was on the data dictionary - the metadata that drives VistA.  My perspective is that VistA is metadata with some supporting programs.  This metadata served as the foundation for the VistA user community, the end users, the support personel, the folks generating ontologies and tables, developing their own class 3 apps, etc.  (folks might call that an ecosystem today, but I can't quite bring myself to use the term).

I sought to do things once at the meta level, and then let it happen many times as the packages flourished.  For example, we defined a standard date format in 1978 that was Y2K compatible.  This was not rocket science, but by building it into the system from its inception, it created a "path of least resistance" to create Y2K compatible systems.  As far as I know, VistA had little or no modifications required for the year 2000.  (I'm happy to hear otherwise).

It came as quite surprise when I discovered the Conor Dowling had reworked the VistA Data Dictionary into a semantic web format (see his Semantic VistA) and that VistA could be represented so easily in the current vernacular of the Semantic Web as a graph.  I felt a little like the character in the Moliere play who discovered that he had been speaking prose all his life.  Suddenly, there is this huge body of technology, people, and thinking that can overlay the work we have been doing with VistA all these years.  

The data dictionary - the metadata that has driven 33 years of patient data for a good chunk of the US health care - is an incredibly precious resource for research, clinical information systems, and improving our clinical knowledge.  This is something that is real and working today, not some future state development dream.

It also opens up new horizons for VA/DoD sharing.  With the addition of a similar concept model for Semantic CHCS we could open up a semantic graph seamlessly connecting VA and DoD medical information.  The semantics of the model would also define the security and privacy issues that are so critical to the success of the interface, and do so at a very fine granularity.

Today, it seems, the API is used as the standard way of connecting a system together.  I have to confess that in my entire technical career, I have never designed or implemented an API. I can see the reasons for using an API, and have used them in many situations outside of VistA.  But in looking back at my API-free design career, I realized that I was always designing metadata structures and languages to cope with complexity and adaptation.  The glue I used to stick things together was linguistic references, not static interface definitions.  This parallels the design of the Web itself, which uses a linguistic approach (HTTP, URL, HTML, XML, etc.).  There is no API to the web - it is a linguistic space.

The metadata approach also opens up the potential for a linguistic space for health care.   I had plans (never implemented) for a universal namespace in the kernel - giving every information object a name that was usable from anywhere.  This was universal: the name would not change depending on where it was.  (This is a key aspect of the Semantic Web: a Universal Resource Identifier for every part)

The metadata/semantic web approach opens up an entirely new way of looking at medical information.  Instead of an fixed set of APIs for an integration crunch at the lower levels of the system, this approach introduces the notion of a shared semantic space, overlaying the existing metadata with an intelligent query processor - that understands the privacy and security concerns of the data it is processing.  This approach is much simpler, and much closer to reality than most people think, I suspect.

Epic systems is based on a similar metadata model.  Judy Faulker, founder/CEO of Epic, was an active MUMPS Users Group participant at the same time the original VistA gang was being recruited by Marty Johnson.  Here is a 1979 paper describing some of her early work.  I don't think it would be hard to extend the semantic web concept to Epic systems, as well.

The other lesson from all this is that folks can't understand VistA simply by looking at the source code.  The data dictionary and the metadata approach to customization, localization, development, support, user community support, and the general gestalt of VIstA is based on a complex, evolutionary approach which is driven primarily by the metadata, not the source code.  

 

 

jmclemore

Medical 'Facebook'

Tom,

Thanks for all the insight, and kudos to Conor's work.  Semantic Web, or some close derivative is certainly a viable approach.

When I think of how VistA might move in the future, I think of the great web super-apps like facebook, so I will try a facebook tack on solving the VLER, or a ubiquitous healthcare record.

If we imagine our lifelong medical history as many sequential entries on our facebook wall, analogies start to appear.  Our 'friends' do not write on our medical wall, but our 'clinicians' do.  They do not write random comments, but post 'encounters'.  If during the encounter, the clinician justifies a CAT scan, the technician post the picture to your 'wall'.  While the CAT scan image may be stored at the lab, the virtual image appears in perfect sequence at the request of the medical 'wall'

The magic and scalability that make this feasible for all mankind is the web.  Starting with the URI, that CAT scan just became referenceable, (securely) searchable, and much more goodness, simply by posting.

Another great web feature is the content negotiation.  I get the URI for the personal health record, which renders text as text and .jpg binaries as pictures.

I know the community could come up with several viable candidates to participate in the 'lifetime patient record' game, but none more feasible than your great semantic start.

Tom Munnecke

You must have been listening in on my lunch conversation.

Thanks, James.   I happened to have lunch today with Conor Dowling, James Fowler (author of Connected), and folks from a large health care organization as well as a genomics company, talking about semantic overlay software architectures.  This would allow an organization to express their medical information in a structured semantic manner, using RDF and and standard Linked Data protocols.  This information could then be semantically linked to social networks as well as genomic information.  For example, a prostate cancer diagnosis could be linked to the latest genomic discoveries that influence whether the cancer is aggressive or not.  This linkage would happen in a semantic "mashup" using the latest available information.  The medical information would not need to "interface" to the genomic database through an API, it would simply represent itself in a standard RDF manner, and the semantic overlay logic would handle the rest.

One could link in all kinds of ways, for example, calculating Body Mass Index of a patient, looking up their address in a Geospatial database, and examine the BMI vs. distance to the nearest McDonalds.  This would be a straightforward SPARQL query... all done at the semantic layer with no "interfaces" or APIs needed.

There are obvious implications for this with VA/DoD sharing, as well.  I've developed three VA/DoD interfaces over my career that were technically correct but politically incorrect, so I don't waste my time worrying about this topic any more.  I leave it to the reader to solve this problem.

James Fowler is a fascinating thinker, deeply interested in applying the lessons of social networks to health care.  Here is one conversation I had with him, and here is another.  He sees incredible data mining potential in the VA for social network analysis... again, very well suited for analysis via a semantic overlay model.  I don't want to talk about specifics of our conversation, but there were some very parallel thoughts to your comments.

re: Facebook "Wall" metaphor.  I like this idea for many reasons (despite disliking Facebook in general, James points out that it is like the QWERTY typewriter keyboard.  I should just get over it and accept that it is the defacto standard.)  some things:

  1. It is a fresh metaphor for medical information.  I know there a frenzy about "electronic health records" today (look at the name of this web site).  But I question whether this is really the best metaphor for what we are trying to accomplish.  If we called it a "health communications system" folks would see things in a different way.  The privacy paranoia about "government records" would be diffused if the idea was "better communications with your doctor."  (I'll leave this for another rant)
  2. It decouples the organization chart from the medical information.  The wall on facebook would receive information from a variety of sources, putting them at the center and providers at the periphery.  This, of course, turns things upside down (Here is a paper Inverting our perspective I wrote with Rob Kolodner.  Unfortunately, today's model of the EHR is essentially "automating the org chart" first, and worrying about patients secondarily (or worse, turning them into "consumers.")
  3. It also introduces a notion of a circle of friends (see Fowler's work on social networks)... rather than "the enterprise" treating "the consumer" it becomes "an ensemble" working together towards some goal or transformation.  Rather than hard-coding the organization into the information system (where you become a "captured life" of the enterprise, this model provides a flexible framework for adapting the treatment team to the personal situation of the patient.  I talked about this in Ensembles and Transformations.  I'm sure that this relates to some organizational transformation stuff within the VA, somewhere :)