We were approached by an internal research team within the UEA, made up of Health Economic and Computer Science professionals, who had developed a ground-breaking algorithm which was able to perform cost-effectiveness analysis in less than ten thousandth of the time set by existing pharmaceutical industry standards with no statistical difference detected.
Whilst the speed, accuracy and potential of the results the algorithm was capable of producing was unquestionable, all the UEA team had in terms of a GUI at this stage was a crude prototype. It was a very basic Flash application which had many major limitations in terms of both functionality and usability, not to mention its rudimentary aesthetic appearance.
The team at the UEA knew that in order to stand a decent chance of getting this novel economic modelling tool to market, they needed it to have a slick interface that was easy to use and highly accessible, which is why it made sense to turn it into a web application that could follow the SaaS model. When they approached us they had a loose idea of what they needed but no idea what form it would take.
We knew that the essence of economic modelling was quite a dry subject, so we wanted to try and make the application’s interface as approachable and user friendly as possible. We also knew that we couldn’t stray too far from the typical appearance of a Markov Chain model to ensure that the application would be immediately recognisable and intuitive to its intended audience.
There was a lot of information that needed to be captured by the interface in order to run the algorithm calculation, which got exponentially higher for every new state that was introduced into the model as the number of interlinking relationships increased. The nature of building up an economic model in this way also inescapably lead to a lot of repetition in the data input required of the user, i.e. insert the probability value and associated cost for this transition, then this transition, and so on and so forth. We needed to produce a user interface which made this process as quick and easy as possible.
From the outset one of the ultimate goals of the application was to make iterative changes to models as simple as possible, to enable quick comparison and provide near-immediate results without requiring the same information to be entered again and again. We needed to group models into projects and facilitate rapid duplication so that the same model could be progressively modified whilst always retaining its version history.
The algorithm the team at the UEA had produced was written in Python and then wrapped within Java so that it could be made available to us as a compiled JAR file and run as a standalone service. We needed to write an API in order to securely communicate with it as necessary.
The results the algorithm returned were nothing but raw data in the form of a JSON string. We needed to evaluate this output, store it within a local database and then reinterpret it as a series of useful graphs and ICER calculations to make the results more user-friendly and comparable.
After a couple of meetings with the client to initially fully understand the requirements of the project and then to scrutinise the UI wireframes that we had produced as a result, we were ready to begin developing the application. We started by focusing solely on producing an MVP which we could then iteratively improve upon.
At first it was solely a GUI which enabled users to create / edit / delete and drag model nodes around. This worked well and allowed us to quickly visualise various states within a particular econometric model. Each states’ X/Y canvas coordinates were stored immediately upon them being moved so that upon refreshing the page the model could be redrawn in exactly the same way as it had been left.
The process of creating and editing states was quite simple, all of the required information could easily be entered and saved by a single form as necessary - there was no real ingenuity required here. However developing an intuitive interface for the repetitive task of entering every single transition probability and its associated cost for the relationships between each and every state was always going to be far more challenging.
To solve this problem we came up with a secondary perspective entitled, “Focus Mode”, which could easily be toggled on and off. Entering Focus Mode would always involve concentrating upon a single state at a time, moving it to the center of the canvas and prominently displaying all of the transitions which were leaving it by fanning them out uniformly above. This allowed the user to click through each transition that needed its values adjusting one by one in an orderly manner. We then presented any transitions which had been edited during the current session in a different colour to help the user keep track of their progress as they routinely went from one transition to the next. Whilst working like this, clicking on any of the other state nodes directly would change the focus again, allowing the process of going through each of the transitions for the new state to begin. We found that this way of working simplified the process of entering transition possibilities and costs as much as possible, and by introducing smooth animation between the different state views it was also very easy for users to comprehend too.
Having perfected the model editing GUI from a usability point of view, we could then move our attention to its aesthetic appearance and developing the surrounding web interface. We quickly added important features such as the ability to duplicate an existing model in order to make minor adjustments for comparison without having to recreate everything from scratch. We also implemented several help facilities; such as optional help tips, an interactive “tour guide” explaining how to use the application and messaging to inform the user whenever calculation data had become stale after a model change.
We produced a reporting page to display several useful line graphs showing different analysis of the algorithm results, that even allows for a second model’s data set to be plotted in conjunction. This facility coupled with the speed at which top-line results can be calculated is what really sets the Modeac application apart from its competition.
The application uses a lot of AJAX requests to communicate user actions via the comprehensive API to a PHP/MySQL back-end server without causing any perceivable interruption to the user - which helps the website to perform very efficiently and creates an experience more like that of desktop software. The calculation algorithm service itself is configured to reside on an entirely separate server to ensure that its processing power is never compromised and may be scaled to the user base as required.
The reporting pages make use of the AMcharts graphing library to good effect. This allows the user to seamlessly zoom in on any particular section of the graphs for closer inspection and selectively remove data elements to reduce the displayed data range, for example an anomaly which is skewing the Y axis dramatically. You can even export the graph as an image, as it was first rendered or in any subsequently user-modified state, for inclusion within a written report.
The application includes a full user registration and authentication facility, to not
only keep projects private but also to allow a payment gateway and subscription model
to be implemented at any time.
Register your interest in the application here