Oroville Hospital’s Scheduler: a winning technology

Rob TweedOn October 3rd, the US Dept of Veteran’s Affairs’ (VA) announced the winners of the Medical Appointment Scheduling Contest.  In second place was the OH Scheduler, which was the submission from Oroville Hospital in California.  I’d like to expand on their press release and provide some background to the technology that was used to develop their scheduler: it’s very much a case study of everything I’ve been talking about in my blog The EWD Files.

As it happens, the OH Scheduler was first and foremost designed and developed for use at Oroville Hospital.  However, since their Electronic Healthcare Record (EHR) is based on the VA’s VistA system, Oroville Hospital believed that it should also meet many of the key requirements of the VA and therefore submitted it as a contender for the VA’s competition.

Development of the OH Scheduler took about 7 months, between mid-November 2012 and mid-June 2013.  Since then, the version at Oroville Hospital has been further refined and extended, but June 13th was when the code had to be frozen for evaluation by the VA.

I think there were two keys to the success of the project:

• The close involvement of both the technical developers and all the staff within the hospital that a scheduler would impact: the executives, physicians, nurses, technicians, clerical and EHR support staff.  This wasn’t a piece of software that was developed by programmers in a vacuum: the people who would ultimately depend on it in their daily professional lives were intimately involved in its design from the outset and were bought into it and would share in its success;
• The technology that was used by the development team.

In this article I want to focus on the latter, but the importance of the former cannot be underestimated and forms a key part of Oroville Hospital’s successful IT strategy.

The technical development team was very small and focused: again, I think, a key success factor.  It was overseen by Zach Gonzales, manager of development at Oroville Hospital’s who heads up their EHR Development Office.  He provided the vital interface with the users, and in doing so was able to filter this and focus the work of the core developers:

• The front-end user interface (UI) was developed by me;
• The back-end integration with VistA was developed by Chris Casey, who also provided a Project Management role for the team and kept a weather eye on the VA’s specific requirements at all times.

Zach worked closely with both me and Chris to ensure that our work met the hospital’s requirements.  He also assisted Chris with the back-end development, in particular VistA-specific issues about which Zach had more knowledge and experience than Chris.

One further interesting aspect of the project: Chris and I carried out all our development work remotely from the United Kingdom.

The Key Technologies

A key feature of the OH Scheduler is that it is a browser-based application.  This allows it to be run on standard PCs using modern browsers, potentially from anywhere within the hospital and, if required and subject to adequate security controls, from outside too.  It also ensures that all the business logic is in one place on the server, with nothing to install or maintain at the user-end.

We decided to use Sencha’s ExtJS framework for the UI.  The starting-point was their example calendar component which was then significantly enhanced and adapted to meet the scheduling requirements: all pure JavaScript/ExtJS programming.

I’ve discussed my EWD technology extensively in this blog: it was used as the web application framework that links the browser to the VistA Mumps back-end.  The ExtJS calendar component’s JavaScript was modified at the appropriate places to integrate with EWD.

Rather than use the more “traditional” architecture for EWD which, for a Linux-based site such as Oroville Hospital, makes use of the Apache Web Server, we opted to use the more recent Node.js-based architecture.  The key reason was that we wanted to make extensive use of WebSockets to provide real-time, event-driven behaviour between schedulers.  For example, suppose two scheduling clerks are booking appointments and are both looking at the same day for the same clinic: by using WebSockets, we’ve been able to update both schedulers’ calendars simultaneously when one of them makes an appointment – effectively preventing the double-bookings that would otherwise be a risk of an Ajax-based system, and removing the need for polling to keep each scheduler’s calendars up to date.

At the back-end, Chris packaged up all the points at which he accessed the VistA system as openMDWS services.  His starting-point for these were the relatively small and limited set of MDWS services that had been created by the VA: these were re-engineered as openMDWS equivalents.  He then added new services for scenarios where no equivalent MDWS services existed, in particular adding read/write services that, subject to appropriate built-in validation checking, allowed the VistA database to be updated.

One of the key requirements of the VA’s competition was that the scheduler had to be able to interoperate securely between sites: ie a scheduler at one VA site must be able to be book patients into clinics at another VA site.  The VA provided us with three virtual machines, each with an instance of VistA installed on which we installed a copy of the OH Scheduler and its associated underpinning technologies.  Interoperation between sites was pretty-much automatic for us: openMDWS services automatically detect whether they are being accessed locally or remotely:

• If a local invocation is made, the back-end openMDWS function is invoked directly without the overhead of an HTTPS request/response;
• If a remote invocation is made, the client system automatically sends an HTTPS request to the remote system.  The openMDWS response is unpacked at the client end as a JSON response that looks identical to what would have come from an equivalent local invocation.  Furthermore, the HTTP request is automatically digitally signed, using an HMAC-SHA256 mechanism that follows an identical approach to that used by Amazon Web Services.

As a developer, Chris really didn’t have to do much extra to integrate all three VistA systems: EWD and openMDWS did almost everything for him.

One final key aspect of the OH Scheduler: it had to be able to operate not only against the GT.M database that is used to support VistA at Oroville Hospital, but also the Caché environment used by the VA.  Once again, most of this was automatically handled by EWD and openMDWS which supports both Mumps technology variants.

Historical Context

So, in summary, our small but experienced team managed to put together, in 7 months, a scheduler that not only met the operational requirements of Oroville Hospital, but also beat some stiff competition from very large players in the industry to win a prize in the VA’s Scheduling Competition.

What’s truly revealing and, I’d suggest, a testament to the effectiveness and productivity that’s possible from our chosen technology stack, is to compare what we achieved against the historical context that led the VA to run their competition in the first place.

Proof of the Pudding

As I’ve said before in several blog articles, I believe that the future of Healthcare IT will depend on browser-based applications, JavaScript and Node.js, with EHRs such as VistA being abstracted into JSON-based services.  These now form the key technologies at Oroville Hospital where JavaScript is now the development language and data flows are described in terms of JSON.

Finally, I’d like to thank Bob Wentz, CEO at Oroville Hospital, and Zach Gonzales for their their support of these technologies.  In the light of Oroville’s win, I think we’ve been able to justify their enthusiastic commitment.