VistA knowledge / comments

Technical (archive)
1

Is anyone here familiar enough with the open source VistA system here in the U.S. to offer any comments about it in general and specifically about it’s storage subsystem? There’s info on VistA at http://www.va.gov/vista_monograph/

Thanks,
Bill

2

Hello Bill,

You would be better off going to http://www.hardhats.org and subscribing to
the hardhats mailing list. That is where the real VistA experts are.

Todd Smith <todd.smith@camc.org>

3

From: Bill Walton
To: openehr-technical@openehr.org
Sent: 4/23/2003 6:00 PM
Subject: VistA knowledge / comments

Is anyone here familiar enough with the open source VistA system here in
the U.S. to offer any comments about it in general and specifically
about it's storage subsystem? There's info on VistA at
http://www.va.gov/vista_monograph/

Todd Smith wrote:

Hello Bill,

You would be better off going to http://www.hardhats.org and subscribing

to

the hardhats mailing list. That is where the real VistA experts are.

Tim Cook wrote:

You may want to start (open source wise anyway) with a study of GT.M
from Sanchez http://www.sanchez-gtm.com/

The next layer up is the Fileman modules:
http://www.hardhats.org/fileman/FMmain.html

Hi Todd, Tim;

Thanks for your replies. I joined the Hardhats list about three weeks ago
and have been lurking there to get a feel for what's going on,
development-wise, with VistA at this point. I've also checked out the
Fileman docs although I haven't dug into the implementation details.

I apologize for not stating my question more directly. Basically, it's
this. Given that VistA exists as an open source system with an architecture
that includes a logically seperate storage subsystem with a database API
that looks, at first glance, like it could be pretty easily implemented as
an independent service, what drives this group to develop the openEHR server
rather than simply seperate and potentially extend Fileman?

If you'll permit me to make an uninformed guess, it looks to me (again, with
open admission that I haven't researched VistA sufficiently) like there are
at least a couple of motivations. First, openEHR seems to implement a
higher level of abstraction than Fileman, moving more of the knowledge of
content and structure (and access rights if what Sam's forwarded me gets
implemented) of an EHR to the server and out of the application. Second, as
a result of that, openEHR seems to allow more decoupling and simplification
of the application than Fileman by allowing an application to query the
server about the existence of content rather than requiring the application
to try to access content and then deal with the case where the access fails.

Am I anywhere close?

Thanks in advance for your help.

Best regards,
Bill

4

Hello Bill,

I can't really speak for the OpenEHR experts but I assume that much of the
OpenEHR work predates the availability of Sanchez GT.M to provide an
open-source M complier to run VistA on. I remember some of the Thomas
Beale's papers being posted on the Open-health list before the Sanchez
announcement.

If you are interested in the just the database API, then I assume that you
have researched the Diamond package provided by the Hardhats.
http://www.hardhats.org/projects/installs/gems.html This allows you to
built pretty much what you would like and have nice infrastructure tools
available.

Todd Smith <todd.smith@camc.org>

I apologize for not stating my question more directly. Basically, it's
this. Given that VistA exists as an open source system with an

architecture

that includes a logically seperate storage subsystem with a database API
that looks, at first glance, like it could be pretty easily implemented as
an independent service, what drives this group to develop the openEHR

server

5

Bill Walton wrote:

Second, as
a result of that, openEHR seems to allow more decoupling and simplification
of the application than Fileman by allowing an application to query the
server about the existence of content rather than requiring the application
to try to access content and then deal with the case where the access fails.

Am I anywhere close?

I am ignorant of fileman (but interested to see comparisons posted here); what I can say that might be useful is that openEHR applications are very likely to be template driven, where a template is a particular combination of archetypes plus localisations like default values etc. An example template would be a diabetic review, an antenatal visit and so on. So if we consider archetypes as knowledge, then a fair part of the GUI does not need the knowledge hard-wired in - it is able to use separate knowledge artifacts, namely templates. Enough work has been done to show that this is possible, but not enough work has been done (IMO) to show how much of the GUI still needs to be custom built - because despite everything, GUIs are not just a reflection of domain knowledge structures, but are heavily dependent on user preferences, temporal usage patterns, relative priorities and so on.

Querying the server can be done with the use of archetypes as a guiding mechanism. There are a few initial examples at the end of the "Shared Language for Archetypes - Part II" paper (available from home page of http://www.deepthought.com.au).

- thomas beale