OpenVista Server

Two Service Packs released simultaneously due to run up of MU certification and CareVue Beta testing program.  Apologies for bundling them together. You can download the releases as either KIDS builds (for upgrading  existing installations) or as ... [More] full databases (for new installs) from our  downloads page. From the release's NEWS file:  1.5 Service Pack 6 ================== Service Pack 6 includes defect corrections and minor enhancements. Defects Corrected * artf9655:  Failure to alert (allergies) during inpt med order entry * artf9862:  ADT: Cancel Admit message * artf10164: VA GUI Vitals Patient Lookup not working for "ALL" * artf10191: Missed Med Report Inaccurate Compared to Med Admin History * artf10192: Alt billing method (340b) not sending proper calc price in the DFT msg * artf10193: Manual Charge Does Not Send a Credit (CR) type in the Message * artf10202: Glucophage - Contrast Media Order Check not working * artf10205: Rad Case Edit (Contrast Complication) on new Rad Patient causes Error * artf10206: AP orders (Lab Collect, not Ward Collect) ia CoPath, do not cross * artf10212: Duplicate Record Merge Not Working in PROD * artf10278: <(ACTLSTEXP)>OUT^JAOPSIVL * artf10280: CPRS error when viewing Inpatient Medication Order Details. * artf10294: MSCDGDIS <(NULSUBSC)>GET 10^XPAR * artf10345: Timeout bug in XQBUILDTREE option * artf10383: Get error that the order cannot be released to the service * artf10400: Pharm option of PSJU HOLD ALL does not invoke an outbound HL7 message * artf10401: Removing a med order 'hold' creates HL7 msg with a status of NW in ORC1 * artf10415: auto discontinue not work on admission, discharge, transfer * artf10419: CPRS doesn't show new outpatient visit after A07. * artf10435: MedRec: when transfering home med triggers msg and no change is made * artf10455: Dupe Record Merge issues when the patient has entries in pick list. * artf10461: MedRec: Order detail for home med not showing all order activities * artf10494: Lab Notifications are not working * artf10570: ADM Outbound Messages are missing Data * artf10591: BCMA crashes on GT.M * artf10645: A4 Interface errors after SP4 upgrade * artf10676: TIU Interface not Posting Transactions * artf10677: Error Trap error after SP4/5 upgrade * artf10685: Account number selection ignored for Manual Charge Entry Problems * artf10711: Entering an allergy in CPRS results in GTM error * artf10739: Entering an allergy in CPRS results in DIKC errors * artf10743: Override orders do not always populate dispense drug * artf10745: Outbound orders message to Omnicell sending incorrect Patient Number * artf10778: Print Rx function for Prescription Blank DEA number Enhancements * artf8972:  Need a released Scrambler program * artf9686:  Create a new version of the Rad Order Request with the Order Barcode * artf10163: Customer IV label enhancement request * artf10168: Medical Director (Pathologist) to Display in CPRS/CA State Requirement * artf10170: OV pricing engine results via charge on admin * artf10222: EGFR FOIA calculation needs to made customizable * artf10262: Need Multiple Label Formats at BGD * artf10268: Add print parameters for RX IV labels not printing when using reprint * artf10279: Enhance %SS to show which processes are zlinked to a routine * artf10324: About OV "SP6" * artf10596: Allow user access to set or change package size and additive strength * artf10623: Font settings for Pharmacy Unit Dose Label * artf10680: Lab Interface Unsolicited Results * artf10701: Modification of billing for Lab Micro and Sensitivities * artf10726: Specific Pt Location should print on Outpt IV labels 1.5 Service Pack 5 ================== Service Pack 5 includes more defect corrections and minor enhancements. Defects * Lab accession labels were not correctly formatted. * Charing based on dispensing in BCMA was not working properly. * Doctors Orders and Chart Copy Orders formatting issues were resolved. * Medications administered at midnight were omitted from BCMA reports that    include a time window. Enhancements * Collection dates/times for CPRS are now fetched from File 69 or 68 instead    of File 63. * Users can now enter the collection date/time and the person who did the    collection for specimens that are built on a collection list. * Add a leading zero to decimal doses. * Capture pregnancy status for radiology. * Allow printing long radiology case numbers on bar codes. * Duplicate order check for premixed IV medications marked as solutions. * Upgrade to FileMan 1039. [Less]

We've been a little behind with our OpenVista Server releases, so Service Pack 3 and 4 are being released simultaneously.  From the NEWS file: 1.5 Service Pack 4 ================== Service Pack 4 contains defect corrections and minor ... [More] enhancements.  These are some of the higher priority corrections and enhancements that have been implemented: Defects * Several problems with ADT and billing interfaces were resolved. * The most current diet was not displaying in the Current Diet patient data    object. * Several HL7-related problems when running on GT.M were resolved. * ASPIRIN allergy under VA classification was not triggering an allergy alert. * After setting up Incomplete Record Tracking (IRT), a crash was occurring on    the orders tab. * Sulfa Drugs allergies were not triggering an allergy alert. * An infinite loop when looking up an item in the lexicon was fixed. * Discontinued or auto-discontinued inpatient orders were not viewable in the    terminal interface, but were still visible in CPRS. * Several problems with laboratory and radiology interfaces were resolved. * BCMA was not reading patient movement file correctly. Enhancements * A parameter was added to allow charging based on BCMA versus charging on    dispensing. * ZTMGRSET no longer attempts to recompile routines that have not changed. * New point of care specimen collection system from IntelliDOT. * Multiple enhancements to laboratory interfaces. * Options were added to write nightly Pharmacy MARs and Profiles to the HFS    where they can be obtained in case of downtime. * Several new pharmacy reports, including billing and medication    administration summary by ward. * Radiology auto registration creates a case number when radiology orders are    submitted, allowing sites with a PACS system to populate the PACS worklist. 1.5 Service Pack 3 ================== Service Pack 3 is another service pack release that contains defect corrections and minor enhancements.  These are some of the higher priority corrections and enhancements that have been implemented: Defects * Multiple problems with various interfaces were resolved. * The IRT UPDATE STANDARD DEFICIENCIES option only updated Discharge Summary    notes. * OWN MEDICATION orders were not changing to Signed status. * The Ward Collect Report was printing an extra blank page at the beginning. * Consult tracking updates were not being shown when IFC language was    disabled. * Radiology exam requests were not being printed automatically when ordered    via the command-line interface. * Entering an ICD number from CPC/ICD9CM coding caused an error. * HL7 listeners did not show correct shutdown state. * Medication replenishment report was incorrectly calculating number of doses    administered. * Infinite loop in LEXAS6. * Undefined variable error on Orders tab after setting up IRT. * Allergy of ASPRIN listed under VA Classification does not fire allergy alert. * "Sulfa Drugs" allergy did not work. * Printing to a network printer caused an error. Enhancements * Pick Lists can be printed with or without Ward Stock items. * Three order request forms have been created for use by Radiology users. * Added new Transfer To Inpatient and Transfer to Outpatient statuses for home    medications. * About OpenVista option shows copyright and version information. * Report showing Medication Administration Summary by Ward was added. * Automatically check patients into radiology system and assign a case number    to radiology orders when an exam is ordered.  As usual, Service Pack 4 includes the latest OVID and GT.M Integration work.  If you are doing a new install, note that ^%ZOSF("CLUSTER") has been pre-set to GTM and the BOX:VOLUME pair in the TASKMAN SITE PARAMETERS file has been pre-set to OPEN:GTM.  You no longer have to configure the BOX:VOLUME pair with the hostname of the machine you're running on.  If you want the old behavior back, simply K ^%ZOSF("CLUSTER").  See LP #422885 for more details. You can download the releases as either KIDS builds (for upgrading existing installations) or as full databases (for new installs) from our downloads page. [Less]

The bazaar repository upgrade has been completed.  OpenVista Server's mainline branch still shows an "updating" message on Launchpad.net, but the branch itself is completely upgraded and we've been able to push new revisions to it.  If you have a checkout of OpenVista Server, please upgrade your repository with "bzr upgrade".

Since my last post, Lucid has been released and bzr-2.1.1 is now available in EPEL.  OpenVista Server's mainline branch on Launchpad.net will be upgraded to branch format 7/repository format 2a next week to take advantage of the performance improvements described in my last post. 

While installing Service Pack 3 this week, I noticed that bzr diff and bzr revert were taking a very long time -- upwards of 20 minutes each for files like P.zwr.  Of course, P.zwr is a ~200MB text file, so I wasn't expecting blazing performance, but ... [More] 20 minutes on several-year-old hardware made me think that there might be room for improvement.  Since I had time on my hands while I waited for the commands to finish, I looked to see what branch/repository format I was using and what the latest format was.  As it turns out, I was using the pack-0.92 repository format with a version 6 branch format.  This was on bazaar 2.1.1 on a Lucid beta box.  I tried upgrading to the new 2a repository format, then re-ran the slow commands.  To my surprise, they finished in 10-15 seconds. Obviously, this is an improvement worth upgrading for, so I began to research what it would take to upgrade the mainline branch hosted on Launchpad.net.  Again, I was pleasantly surprised -- I don't have to do anything!  The Bazaar 2.0 upgrade guide explains: "To allow isolation between public and private branches, Launchpad uses stacked branches rather than shared repositories as the core technology for efficient branch storage."  So the choice of repository format is a local decision.  If you're running a version of bazaar that can support 2a repositories, all you have to do is create a 2a repository, then branch the OpenVista Server mainline branch in it.  Version 6 branches can be hosted in a 2a repository, so the mainline branch on Launchpad.net can remain at version 6 for backwards compatibility. Bazaar versions >= 2.0 use the 2a repository format by default when you run bzr init-repo, and Bazaar version 2.1.1 is included in Lucid.  Also, there's a bug in RedHat's bugzilla to upgrade the version of bazaar in EPEL to version 2.1.1, so if QA goes well, 2.1.1 will be in EPEL, too.  The bottom line is: if you're running an older version of bazaar or have migrated an existing repository created with an older version of bazaar, upgrade to the 2a repository format for much better diff/revert performance on large files.  If you're starting out with a newer version of bazaar, which will be installed by default in both Ubuntu and EPEL soon, you don't have to do anything! Update: unfortunately, I can't push back to the older-format Launchpad branch from the new branch in my local 2a repository, so it looks like I'll have to upgrade the branch/repository on Launchpad.net after all. I'll revisit this once bazaar 2.1.1 is more widely available in a few months. [Less]

We released a new version of OpenVista Server today.  From the NEWS file:Service Pack 2 includes all patches that have been completed, tested, and packaged for the 2nd quarter.  This release contains defect corrections and minor enhancements.  ... [More] These are some of the higher priority corrections and enhancements that have been implemented: Defects: * Not all HL7 exceptions/errors were sent to an Exceptions file or the Error    Log. * Visits were created without an authoritative source. * When merging patients, images were not properly linked to the correct    patient. * Dispensing extra medication units caused an error. * The medical reference file loader was updated for 2009. * Health factor could not be added as an element to Reminder dialog box. * The system was storing and converting weights from kg incorrectly. Enhancements * The date/time of each Alert will be shown on the first display list. The    previous 80-character limit on the length of an individual Alert message    (XQAMSG variable) was removed. * The OVID patches are included in this release, so it is no longer necessary    to install OVID separately. * The OpenVista/GT.M integration project patch is included in this release,    so it is no longer necessary to install it separately. This release is available in a number of formats -- as routines and globals for new GT.M installations, as a CACHE.DAT for new Cache installations, and as a series of KIDS builds to upgrade existing installations.  Not being a clinical person myself, the part I'm excited about is the inclusion of OVID and the GT.M Integration Project work.  Having these two builds already installed out-of-the-box will make it a lot easier for people who are new to OpenVista to install OpenVista and develop with OpenVista.  We've also done some work to pre-configure the RPC broker and give users the right keys for a smoother install. Another important change we've made is to re-license the core modules as LGPL.  We've written a FAQ about this license change, so if you're curious about why we did it or how you're affected, please take a look at the FAQ. Finally, this is our first release that is available both as a new database and as a series of KIDS builds, so if you've installed OpenVista Server in production previously, you can upgrade your installation the same way we do.  You can determine the sequence in which the patches should be installed by looking at the ChangeLog file. You can download the new Server release from the usual place.  We'll be releasing a new version of the Appliance that includes this new Server release and today's CIS release within the next few days. [Less]

BackgroundIn my last blog post on the topic of OpenVista Server Revision Control, I talked about some changes we wanted to make to our revision control process for OpenVista Server.  In particular, we wanted to store globals in ZWRITE format and we ... [More] wanted to switch from Mercurial to Bazaar.  In that post, I discussed the advantages for each change and promised to do benchmarks to see if these changes were feasible. MethodologyWe tested two methods of storing globals, GT.M database format and ZWRITE format.  For each of these formats, we tested several iterations of a series of common source control operations using two revision control tools, Mercurial and Bazaar.  The initial repositories were created manually, then a script was used to translate changes from our current Mercurial repository to the desired format for the benchmark. More specifically, the script updates a working copy of our current Mercurial repository to a certain revision, then rsyncs the routines and globals over to the benchmark repository.  For the ZWRITE  repositories, the globals are exported into a number of text files and the original database files are removed.  “status”, “add”, “diff”, and “commit” commands are then benchmarked.  After the commit to the benchmark repository, the script checks the file sizes of the repository files to see how much they have grown.  Finally, the script updates the working copy of the current Mercurial repository to the next revision, starting the process over again. The script was run for 48 revisions.  In that time, there were several types of commits made to the main repository – some commits were data changes only, others represented the installation of a KIDS build, others were just tags (resulting in very small commits), and there was even one commit where the GT.M database files were upgraded, causing the repository to grow significantly for the two repositories that were storing globals in GT.M database file format (upgrading the database files had no effect on the ZWRITE format of the globals). All tests were run on the same machine – a Dell Dimension 4700C with a Pentium 4 2.8GHz HT Processor, 1GB of RAM, and Maxtor 6L100M0 hard drive (100GB, 7200RPM, 8MB cache).  The machine was running Ubuntu 8.10 (Intrepid Ibex); the kernel was 2.6.27-7-generic #1 SMP i686.  Both Mercurial and Bazaar were installed from the Ubuntu repository.  The version of Mercurial used was 1.0.1 (1.0.1-5.1); the version of Bazaar used was 1.10 (1.10-1~bazaar1~intrepid1). ResultsIn general, Bazaar was slower than Mercurial, but used less disk space.  This was particularly apparent when globals were stored in ZWRITE format.  The following graph shows the disk usage of all four test repositories, excluding the working copy files – in other words, how much space the revision control tool needs to store its data (lower is better).  The blue squares represent the baseline; this is what we're doing today (Mercurial storing GT.M database files).  You can see that Mercurial's disk usage increases steadily, except for a dramatic increase in the baseline at revision 83 when we did a “mupip reorg upgrade” after upgrading to a new version of GT.M.  As mentioned earlier, the ZWRITE repositories are not affected by this.  Bazaar periodically compresses the repository, so on certain revisions the repository size actually shrinks.  I'm not sure what Bazaar is doing at revision 64/65 - those commits were not large commits, but the repository size grew significantly.  It makes up for it 12 revisions later, when the repository shrinks back down to ~175MB.  While it's hard to tell for certain with Bazaar being so erratic, in the long run, it appears that Bazaar managing ZWRITE-formatted globals are going to use the least amount of disk space. This space savings is actually pretty impressive if when you consider that globals in ZWRITE format are about 375MB larger than globals in GT.M database format.  Both Mercurial and Bazaar seem to do a pretty good job with compression.  Unfortunately, there are downsides with the ZWRITE format besides the larger working copy size.  Exporting the data out of GT.M requires 5-6 minutes, and the larger working copy size slows down all of the Mercurial/Bazaar operations we tested. This next graph shows the time it takes to run "hg status" or "bzr status" against the various test repositories.  The ZWRITE repositories are at a disadvantage here because the larger files take longer to scan.  Bazaar is more consistent; with Mercurial there are spikes and dips between revisions.  Running the status command on the first revision of the GT.M database repositories took uncharacteristically long for both Mercurial and Bazaar, so I adjusted the graph's maximum value so we could get a clear picture of what's going on for the rest of the revisions.  I would guess that the 2+ minute long timings were because Linux had not populated the filesystem cache yet.  Fortunately, even though the ZWRITE repositories took longer to scan, the difference was only a few seconds on average. The next graph shows the time it takes to run "hg add" or "bzr add".  Without arguments, the entire repository is scanned and any unknown files are added.  While the status graph was primarily divided by the global storage format, this graph is primarily divided by the revision control tool used.  Mercurial has a clear lead over Bazaar, but the difference is always less than 3 seconds. The next graph shows the time it takes to run "hg diff" or "bzr diff".  The diff command takes much longer than the status or add commands.  From the graph, it appears that Mercurial handles binary files better, while Bazaar handles text files better.  Even still, Bazaar handling globals in ZWRITE format trails Mercurial handling globals in GT.M database format by at least a minute. The final graph shows the time it takes to run "hg commit" or "bzr commit".  Like the diff command, the commit command takes a few minutes to run.  Mercurial handling ZWRITE formatted globals is able to commit in the shortest amount of time.  Initially, Mercurial handling GT.M database files is faster than Bazaar handling ZWRITE formatted globals, but after the database upgrade at revision 83, Bazaar pulls ahead.  Bazaar handling GT.M database files is a non-starter, taking an order of magnitude longer to commit than the other test repositories.  I adjusted the graph's maximum value to more clearly illustrate the differences between the lower values.  Commits at 65, 87, and 98 were tags in the original repository, so they are essentially no-ops for the GT.M database formatted repositories in this test.  Exporting the same database still changes the ZWRITE files because they contain timestamps of when the database was exported, so the commit times do not fall to 0 for the ZWRITE formatted repositories. ConclusionLooking at the data, there does not appear to be a clear winner.  Each tool and global storage format comes out ahead at different times, but it's important to focus on the actual time savings – a 3-second victory for one tool is not nearly as important as a 100-second victory for another. In general, Bazaar still seems to trail Mercurial in speed, but it looks as though Bazaar will use less space in the long run.  With the exception of Bazaar's abysmal commit times when managing binary GT.M database files, the speed difference seems to be acceptable.  When you consider that the tests were run on an older machine, the actual wall-clock time difference may be smaller on faster hardware.  Further, I believe the benefit of using the same revision control system as OpenVista CIS and the benefit of storing globals in a GT.M-version-neutral format outweigh the performance penalties. Future WorkPerhaps the most obvious benchmark missing from this blog post is the performance of cloning/branching, especially over the network. Also, it would be interesting to add other revision control tools to this benchmark - most notably Git and Subversion. Finally, committing the entire database is still a crude approach to revision control for OpenVista Server.  Some research should be done to determine if some tools can be written on the M/OpenVista Server side of things to "meet us halfway" and provide a more granular set of objects to revision control.  This could lead to repository size gains, performance gains, and perhaps most importantly, improvements that will allow us to get meaningful diffs across revisions and automated merging of code. [Less]

What is Revision Control?Software source code revision control tools are designed to store multiple revisions of a software's source code.  Each change to the software's code is stored along with some metadata about that revision of the code ... [More] , including who made the change and when.  Usually, a short message is also associated with each revision. Why use Revision Control?Revision control is useful for many reasons - it documents the change history of the software, it allows software developers to go back in time to trace when bugs were introduced, and it allows developers a certain degree of freedom to experiment - if it doesn't work out, they can always roll back to a previous version of the software.  Revision control tools, along with bug tracking tools, help to ensure that proposed changes to a piece of software don't get lost, because it's easy to tell whether or not a particular change is in the code or not (and if it is, when the change was made, and by whom).  Revision control tools, especially distributed revision control tools, also help software developers communicate changes in the software with one another. Current PracticeInternally, we have been using Mercurial to track the OpenVista Server codebase.  At the time we started using Mercurial, we chose it for the combination of its speed, relative familiarity/ease of use (compared to Git), and extensibility (Mercurial is mostly written in Python).  Our approach is fairly crude - we have an instance of OpenVista Server running on GT.M, and whenever we want to do a commit, we stop all the mumps processes, run down the database files, and commit everything.  Whenever we install a KIDS build, we also add the KIDS build to the repository and commit it alongside the globals and routines. This gets us very basic revision control, but it's far from ideal.  Probably the biggest drawback is speed - Mercurial takes on the order of ten minutes to do a commit because the database is over 400MB.  Mercurial also needs to search through 24,000+ routines to see if any of them have changed.  Fortunately, Mercurial does a pretty good job of figuring out which database regions have changed and records reasonably small deltas, i.e., each commit does not add 400+ MB to the Mercurial repository.  Another drawback is compatibility - since we're committing actual GT.M database files, all of our developers need to be using the same version of GT.M (note that we do not commit compiled object files). Also, "hg diff" is unable to display the differences between one revision of the globals and another because it's just a gigantic binary blob. Future DirectionAs we work on opening up the OpenVista Server development process to the community, we would like to address some of these shortcomings.  One of the easiest things to do is to store the globals in a more universal format.  Committing globals in ZWRITE format (see the mupip documentation) would allow us to remain GT.M-version agnostic (actually, MUMPS-database agnostic) while providing the additional benefit of meaningful "hg diff" output (thanks to Bhaskar for this suggestion).  Of course, "hg diff" would show global-level differences and not FileMan-level or application-level differences, but there are utilities in MUMPS (such as the % routine) that can perform such comparisons.  Of course, the disadvantage to exporting the globals before committing them is that the commit process will take longer because it takes some time to export globals in ZWR format.  The checkout process will also take longer because it takes time to import the globals. Another possible enhancement is to switch revision control systems.  Since we're already using Bazaar for OpenVista CIS development, it may make sense to switch to Bazaar for OpenVista Server, too. At the time we started using Mercurial, Bazaar was not fast enough for us to consider it, but Bazaar continues to be developed and improved at a remarkable pace.  In particular, Bazaar stores its data differently now, and Bazaar's latest repository format may actually provide some performance benefits over Mercurial when checking out routines (24,000 small text files).  We hope to post some concrete benchmarks showing the performance of various tools when working with OpenVista in the near future. Finally, we want to build some tools around viewing code repositories directly into the Medsphere.org site - see VistA code repositories at Medsphere.org for a more detailed discussion on that topic. [Less]