Buying software for a healthcare institution is usually an uncomfortable decision. Traditional options ask you to decide today what you will only know tomorrow: which features you will need, at what volume, for which services. You pick a large package "to be safe", and pay for half of things you never use. Or you pick a small package, and a year later you have to replace everything.
A modular system solves this dilemma differently: you start with the base and add capabilities when the need is real.
Pay for what you use
In a modular model, the base platform delivers the essentials and each extra capability is a module you enable when it makes sense. The institution does not fund idle features: the cost tracks usage.
In RVer's case, the base covers the immersive experience: it helps manage pain and anxiety, and brings comfort. Those who need guided movement enable RVer Motion; those who need cognitive activities enable RVer Neuro. Those who do not need them, do not pay. RVer Motion and RVer Neuro are modules in development, not covered by the Class I medical device registration, which covers the base product.
Enable per device, not per whole contract
Fine-grained modularity brings a second advantage: modules are enabled per device. A physiotherapy service can have Motion active on its equipment, while the geriatrics service uses Neuro on theirs: all on the same platform, with no parallel contracts.
This lets you trial a new capability on one ward before extending it to the whole institution. Small, reversible decisions, instead of a single expensive commitment.
Grow without migration projects
The biggest hidden cost of monolithic software is not the licence: it is migration. Every time you need something new, there is a project, downtime, repeated training and risk.
In a modular system, growing means enabling the next module. The base is the same, the team already knows it, and the new capability comes in without interrupting what already works.
Continuous improvements, no effort from the institution
Because everything sits on a common base, software and content updates reach all modules at the same time, automatically. The institution does not manage versions or contract upgrades: the system improves on its own, and every improvement benefits all active modules.
One base, many possibilities
A good modular system is not a collection of loose programs. It is a registered, secure base on which specific capabilities sit. In RVer, that base is a Class I Medical Device (base product) registered in EUDAMED and with INFARMED (Portugal), running locally and complying with GDPR, and those guarantees hold, whatever the active modules.
For a healthcare institution, this translates into a simple advantage: start with what you need today, confident that what you need tomorrow is already one click away, without starting from scratch.
On the infrastructure side, the questions this raises are in “The eight questions hospital IT asks”.
Frequently asked questions
What does it mean for a system to be modular?
It means the base platform works on its own and that additional capabilities (such as motor rehabilitation or cognitive stimulation) are enabled as independent modules, per device, when the institution needs them. You do not have to buy everything at once, nor replace the system to add a function.
Does a modular system cost more overall?
Usually not. You pay for the base and add modules according to real usage, which avoids paying for features you never use. For larger volumes there is adapted pricing, but the logic is always to align cost with use.
What if we need a new capability later?
You enable the corresponding module, with no migration project and no downtime. In RVer's case, modules like Motion (rehabilitation) and Neuro (cognition) are enabled per device in the settings.
Does modularity compromise security or compliance?
No. In a good modular architecture, all modules share the same registered base and the same security and privacy rules. In RVer, the platform is a Class I Medical Device (base product) registered in EUDAMED and with INFARMED (Portugal), runs locally and complies with GDPR, regardless of the active modules. RVer Motion and RVer Neuro are modules in development, not covered by the Class I medical device registration, which covers the base product.