Skip to main content

How releases work in Rio Evo

This article explains the Rio Evo release model: how updates are delivered, what the different release types mean for your organisation, and what your teams need to do for each.

Written by Connor Baeza

The shift from fixed releases to continuous deployment

Rio EPR delivers updates through a fixed release schedule, where changes are bundled into platform wide releases on a set cadence. Rio Evo takes a fundamentally different approach: updates are deployed on a per module basis as features are ready, rather than accumulated into large releases.

This means your organisation receives improvements and fixes faster, with smaller and more manageable updates rather than periodic large releases requiring significant preparation.


Release types

There are five release types in Rio Evo, each with a different process and level of customer involvement:

Standard Quality of Life release. Contains bug fixes and minor improvements. Does not introduce new user visible functionality, alter clinical workflows, or require any data changes. Deployed directly to production following internal testing. No customer preview or action required.

Feature release. Contains significant functional changes to a module. Your organisation receives a minimum of one month's notice ahead of the preview deployment, with release notes published through your standard Access Health communication channel. A two week preview period follows, during which the changes are active in your preview environment but held inactive on your production system via feature flag. This allows your teams to test and train before the feature goes live. At the end of the preview period, the changes are promoted to production.

Demo release. An early preview of features in development before they reach formal beta preview. Provides the opportunity to engage directly with the Access Health product and engineering teams to review and shape upcoming functionality.

Mobile app release. Contains updates to the iOS and Android mobile applications alongside any required backend changes. Given the coordination involved on both sides, mobile releases are managed to avoid overburdening customers with frequent rollouts. Your teams will need to install the updated application as part of each mobile release.

Emergency release. An accelerated deployment in response to identified clinical, operational, or security risk. All emergency changes are communicated immediately to all affected customers and managed by the Access Health support team.


The preview model in detail

For feature releases, the preview model works as follows. When a feature release is ready, it is deployed simultaneously to your preview environment and to your production environment. On production, the new feature is held inactive via a feature flag. On the preview environment, it is active.

This means your teams can test and train in the preview environment against the same underlying data and configuration as your live system, without any risk to live clinical workflows. When the preview period ends and your organisation has validated the changes, the feature flag is activated on production and the update goes live.

The preview period runs for two weeks by default. It will only be extended beyond two weeks where testing identifies issues carrying material clinical risk, formally assessed by the Access Clinical Safety Officer.

Did this answer your question?