...if you're afraid to change something, it is clearly poorly designed. – M.FOWLER

 

Our team has just finished our first Sprint and we are gearing up for the second one.  The following is an update of the past few weeks:

We have posted our XINDEX-based tool here: https://github.com/OSEHR/M-RoutineAnalyzer.  There have been a number of improvements to the original version, such as identifying global dependencies from Fileman calls and adding Option and RPC Entry tags to the interface tags of the packages.  Currently it is essentially a list of Entry Tags that can be used to generate reports which are text files.  The reports require an initial step where all the existing routines are parsed and a Mumps global with relevant information is formed.   It is essentially an alpha version at this point, but we will continue adding unit tests and increasing functionality.  Please let us know of any bugs you may find and any additional functionality needed; we appreciate your feedback and will take a look at it for future implementation.  Already there has been some discussion on providing an RDF output, and we plan to spend some time on that.

On the testing front, we could not obtain any VA test plans, so we are forming our own!  We will post them as they become available.  Our team is looking at NIST Meaningful Use test criteria (http://healthcare.nist.gov/) as our starting point and applying them to VistA.  Since it is not clear at this time what test data needs to be used for OSEHRA certification, we will include patient/clinic creation as part of the plan.  Initially these tests will be manual, but we will look into automating them later on.  In addition to these functional tests, we are looking into using MUnit for unit tests as we start the actual refactoring. 

We spent some time looking into newly contributed Eclipse MEditor and MDebugger plugins.   Together with git plugin EGit, we believe Eclipse will be a productive IDE and we are in the process of adopting it as our development environment.  We will look into possibility of providing a Refactoring menu and M-RoutineAnalyzer as a plugin in the future.

Our team has also taken time to investigate the Problem List code.  A summary of “Problem List Dependency Notes” has been uploaded to the Documents section of this project group; it summarizes Problem List package Entry Tags, Files, Direct Global Usage, and calls to and from other packages.

Option Entry Tags are used by the Scroll and Roll interface.  There are few in this list, such as GMPL ASSIGN LIST, which are direct entries.  But most of the Problem List package Scroll and Roll functionality is built using List Manager (another package that provides a user interface infrastructure.)  We identified List Manager Templates that belong to the Problem List package; most List Manager Templates specify a Header Tag, Entry Tag, Exit tag, Help tag, and a Protocol menu.  In turn, the Protocol menu specifies actions tags in Protocol File; these tags are all listed in “Problem List Dependency Notes.”

RPC Entry Tags are used by CPRS and other GUIs. It should be noted that the Problem List package has no direct RPC Entry Tag.  Instead, a number of direct RPC Entry tags use Tags in Problem List package routines; these are also listed in “Problem List Dependency Notes.”

As we head into our next Sprint, we will start refactoring and concentrate on Option, Protocol, and RPC Entry tags.  Our first order of business will be to form a set of core Entry Tags by extracting the commonalities.  These Entry tags will not have any user interface (no Write commands or List Manager Update calls) and will not have any assumed inputs or outputs. In fact, such a core set is almost ready  in Problem List in Order/Entry/Result Reporting package in routines ORQQPL*. These tags will be our starting point.  Here is a more detailed plan as we see it right now:

1.       Move tags in ORQQPL to a GMPL routine and add formal parameters as needed.  Call the tags in GMPL from ORQQPL. Some refactoring such as removing unnecessary indirection usage will also be done.

2.       Extract commonalities in Option and Protocol Entry tags by calling the tags that are moved from ORQQPL.

3.       If functionality in some of the Option and Protocol Entry tags is not covered by the core tags, then create a user interface free version and add it to the core tags.

4.       If Option or Protocol contain more than a single call to a tag (sometimes there are if conditions, multiple calls or write commands), then create a new single tag with the context and call that tag from Option or Protocol.

5.       Support error messages in the core tags (most likely follow Fileman DBS method of passing root of a local or global to store messages.)

6.       Look into converting direct global access into Fileman calls.

We will also try to add MUnit tests for the core tags; these should also apply with little change to ORQQPL tags.  For Options, we will work on test plans and manual testing and will leave automation to future. As we progress in our efforts, we plan to put our changes kthlnkeating/VistA-FOIA in github.

Please look for the next blog update around March 9th (unless we somehow figure it all out between now and then, and post that we have solved all of the world’s VistA refactoring problems!).

Again, many thanks to everyone for following our team’s progress – we really appreciate your involvement in this project! And certainly in the meantime if you want to know more about what our project does or what our team is doing, please feel free to contact us here - we welcome your involvement and inquiries!

like0