This post is the first of many as we complete our 12 month project. Look out for more weekly updates starting on Fridays!
Last week, we dedicated our time to familiarizing ourselves with VistA documentation provided by OSEHRA and looking at some Mumps code. This week we started looking at XINDEX (with respect to the utility’s results and what it is doing) in the context of a couple of specific applications -- Oncology and Problem Lists. Note: these choices were random. Our goal is to work in the context of a specific application before generalizing it. One option we are considering is if there is interest in altering XINDEX to further refine its capabilities to look further into an application’s code (if you have any ideas, please feel free to push them our way).
A couple of observations from the code and documentation:
1) Fileman can be considered the database layer for VistA. It has a “Classic” version which provides command line user interface facilities for VistA applications in addition to database management. This form appears to be the primary mode of usage for a lot of applications.
2) However, Fileman also has a DBS (Database server) interface which has a well-defined “silent” interface and appears to be isolating the database layer quite well. This does not mean all the applications are using this “good” interface…actually, we doubt they do, but at least we already have a database layer.
3) The Fileman database layer is built on top of Mumps, but the structure is very similar to a relational database. In fact, there is even some recommended relational database structure (SQLI) for an SQL interface. (And if anyone has more information or recommendations for specific commercial SQL interface packages, please feel free to let us know). We are under the impression that they provide read interface, however it was not clear if there were any write interface; this requires more investigation on our part.
A few thoughts on some applications briefly browsed:
They have a command line interface with a menu item structure: you choose a menu item from a selection list and you are presented either with another menu list or the item goes ahead and executes the action. The documentation essentially describes the actions in the menu items. It should be possible to list all the actions (essentially Mumps tags) from Option File (files are essentially SQL tables in VistA terminology). That is something to keep in mind for dependency listing; we may want to specialize to tags instead of routines.
The applications that have a GUI (CPRS Problem List for example) appear to be better structured with defined APIs. We think this is expected since those need at least a client and a server layer since more work is done on them. There is an RPC broker and you can use it for any language to do calls to Mumps.
Just as a heads up for what this project is looking for in the short term: towards the end of the month we will have to finalize documentation for lists of interfaces, common services, and all application layer modules...hence the 'sprint before the marathon.' We will have another update to you next Friday with our XINDEX results and more – stay tuned!