Version control is a long-standing challenge when work is handed over from a global team to its local affiliates. In health economic models, a global model is adapted to each market's perspective and health care system, and in that handover versions drift and assumptions are misread. HEORACLE keeps one record of every version, change and adaptation, so global and local teams work from the same source.
The global team uploads the model as Global version 1. The platform builds and tests it, and from then on that version is locked, so any change becomes a new version.
The team publishes it to GitHub. The platform rebuilds the model from the files it is about to publish, checks they are identical, and writes the version with its tag and a changelog entry.
Everything about a model family sits on one screen in Model Coding: its versions, its members, and the change requests that countries send.
The global team lists the people who work on the model and gives each one a role. A global owner controls the model's logic. A country editor works only on their own country's version, and only on the inputs the global team allows.
The global team sets up a version for each market from the published global model.
Each country version shows the rules up front. The country may change some inputs directly, such as costs and discount rates. Others need the global team's approval, such as efficacy and transitions. The model's structure stays fixed.
The country analyst makes changes in plain language, and each change is recorded with its reason. For many values at once, the analyst downloads a workbook of exactly the inputs the country may change, fills in the local values with their sources, and uploads it.
A restricted input goes to the global team as a request through the platform. The global owner reviews it and approves it, and the new value enters the country version.
Before anything is published, the platform lists every value that differs from the global model, with its source, who changed it, when, and why. Nothing is published until every changed value has a source.
The country version is published to the same repository, stamped with its own version number and linked to the global version it adapts. In GitHub, the global team sees exactly what the country changed, value by value, with the source of each.
To update the model, the global team starts in Model Specifications with the Revise a global model card, and opens the latest global version. The platform first asks whether the model structure stays the same. For a change of values it does, and the parameters open for editing.
The team records a reason for each change, reviews what the model will now do, and saves it as Global version 2. Version 1 stays as it was.
Publishing version 2 shows what it means for each country. A published country version stays on its current global version, and nothing in a country version moves until that country decides.
The changelog tells each country what changed, why, and what the change does to the results, so a market can judge what adopting the new version would mean before it takes it.
Everything lives in the company's own GitHub repository, and every published version is tagged there.
Each version holds the specification, the R model, the Excel workbook and the results. Each country holds its changes, its own built model and an adaptation report.
On every publish, GitHub reruns the R model and checks that it reproduces the published results. A team takes a model with one download, and the README shows how to run it.