In today’s health economics and outcomes research (HEOR) landscape, demonstrating value is not just about having the right evidence, it is also about articulating the underlying narrative of the value proposition in a way that is meaningful and clear to a wide range of stakeholders. As health economists, we have seen methodologically robust economic models, built in both Excel and R, sit unused by broader teams because they are hard to navigate or interpret without considerable technical expertise. 

This often leads to:

• Missed opportunities for strategic input from cross-functional stakeholders
• Delays in decision making due to economic models being siloed tools 
• Reduced clarity around the value proposition

Despite its clear computational strengths, R has been slow to gain traction in health economic modelling, largely due to a lack of technical expertise among both modellers and end users. The arrival of platforms like R Shiny is beginning to challenge the slow adoption by enabling modellers to create clean, intuitive interfaces where users can explore assumptions, adjust parameters, and view outputs in real time, all without writing or interacting with, a single line of code. 

As part of an internal project at Symmetron we developed an economic model in R to assess structural uncertainty in the cost-effectiveness modelling of anticoagulation for stroke prevention in patients with atrial fibrillation.^1-3 An R Shiny platform was developed to improve usability, enabling colleagues and stakeholders to use the model without any programming expertise.

The aim of this blog is to share the steps we took, what worked well, what we learned, and what we would do differently in future.

The process

Defining the user experience

Before any development began, we gave considerable attention to the end user experience. Key questions guided our planning: Who would be using the app? What questions would they want to explore? What outputs would they expect to see, and how much flexibility would they require?

With this understanding, we created a mock-up to guide the build. The early design provided a tangible reference for discussions with colleagues to gather feedback on layout, terminology, and usability before any significant technical work began. This approach proved effective, keeping focus on the core user interface design rather than becoming distracted by the wide range of available customisation options.

Implementation

With the user experience mapped out and the mock-up as a guide, we began the implementation phase with a minimally working (pilot) version of the app. This allowed rapid testing of the connection between the interface and the underlying R code.

We then added functionality iteratively in layers; input controls were created first using numeric fields, and drop-down menus fed directly into model parameters. These inputs were linked to the model logic through Shiny’s reactive functions, ensuring that changes triggered instant recalculations and updated outputs in real time.

Throughout, we used the mock-up as a reference to maintain a focus on usability. While there were opportunities to incorporate advanced Shiny features, adhering to the planned structure ensured the build stayed on track and aligned with user needs.

Debugging

Debugging was an inevitable part of the process. In Shiny (as with all programming generally), even small errors in reactive logic could cause outputs to fail to update or plots to break unexpectedly. We used built-in developer tools, simple print statements, and browser() calls to trace the flow of logic and identify problems. Incremental testing of changes, combined with good version control practices, proved essential to maintaining stability during development.

Challenges

Developing the Shiny app brought both technical and creative hurdles:

Technical

Adapting to Shiny’s reactive programming model required a significant shift in approach, moving away from the linear flow of sequential scripting to a mindset focused on interdependent components, event triggers, and dynamic updates. As the interface evolved, it became increasingly important to keep the Shiny app code well-documented and in sync with the underlying economic model.

Creative

Designing an interface that was both intuitive and engaging meant striking the right balance between simple enough for non-technical users to navigate with ease, yet flexible enough for experienced analysts to explore in depth. Every visual choice, from chart types to colour schemes, needed to support the story the model was telling and guide stakeholders toward meaningful insights.

Lessons learned

Developing a Shiny app for a health economic model reinforced some principles that are true for any user-facing tool, yet we found they were particularly critical when working in Shiny:

In short, this project showed that building a successful Shiny app for HEOR goes far beyond writing code, it is equally about thoughtful design, rigorous testing, and close collaboration with stakeholders.

Symmetron delivers end-to-end solutions, from rigorous health economic modelling to interactive R Shiny applications, enabling stakeholders to explore evidence with clarity and confidence. Contact us to discuss how we can support your next project.

References

1. Whitaker J, Pollit V, Rinciog C, Serra-Sastre V. Does the choice of modelling approach matter when modelling stroke prevention therapy? Value Health. 2022;25(Suppl 12S):P39.

2. Whitaker J, Rinciog C, Diamantopoulos A. Using cloud computing to improve the run-time of individual patient simulation models. Value Health. 2022;25(Suppl 12S):SA46.

3. Rinciog C, Whitaker J, Cudworth S. A cloud computing solution for improving the run-time of individual patient simulation models. 2022 [cited 2025 Aug 20]. Available from: https://www.symmetron.net/insights/a-cloud-computing-solution-for-improving-the-run-time-of-individual-patient-simulation-models

4. Tappenden P. Conceptual modelling for health economic model development. HEDS Discussion Paper. 2012 [cited 2025 Aug 20]. Available from: https://core.ac.uk/download/pdf/9257307.pdf