For growing digital-health products

Scale the product without fragmenting its healthcare foundation.

Keep patient records, supported measurements and access rules on an FHIR R4 foundation while your own application evolves across users, devices, teams and workflows.

ovok.com/console/patients
Patients
SandboxStagingProduction
Signals
Felix BraunPraxis Süd
Lena HoffmannKlinik Nord
Peter WolfKlinik Nord
Aylin KayaPraxis Süd
Mia SchulzPraxis Süd
Jonas BeckerKlinik Nord
Felix BraunPraxis Süd
Lena HoffmannKlinik Nord
Scale planMonitored patients/ 1,000 includedSub-tenants14

01

The next set of constraints

Growth adds more than patient volume.

As a working product expands, separate implementations and assumptions can become harder to maintain across the app, care team and integrations.

More monitoring workflows

Additional patient groups, measurement types and follow-up paths need consistent records.

More devices and sources

Teams need to check exact supported models and decide how device and health-platform data enter the product.

More product surfaces

Patient apps, practitioner tools and internal operations may share data but need distinct access.

More environments and tenants

Production changes and customer or product boundaries need deliberate configuration.

More engineering ownership

Authorization, integration behavior and monitoring terms become architecture decisions, not isolated tickets.

The Console billing page with a plan and usage for a synthetic project

Switch between sandbox, staging and production in the Console, and review usage, plans and invoices on its billing pages.

02

One foundation, several experiences

Keep the record model underneath the product consistent.

The React, React Native, Java, Python and Flutter SDKs, along with the REST APIs, work with the same FHIR backend, so teams can build distinct app surfaces around shared records and workflows.

  1. 01

    Patient and practitioner identity

    Represent users and care-team workflows in the product’s FHIR-backed project.

  2. 02

    FHIR R4 records

    Store supported measurements and the other resources used by your app workflows.

  3. 03

    Product capabilities

    Combine devices, questionnaires, goals, CMS, email and video calls where they fit the workflow and project configuration.

  4. 04

    Apps your team owns

    Use the same backend foundation for patient, practitioner and internal applications.

03

Connected data

Extend device coverage without treating every integration as a new product.

Ovok documents a device catalogue of 800+ entries and a normalized measurement layer. Use the live catalogue to check your exact device and model before you commit to a product workflow.

Supported-device catalogue

Review the documented device families and supported measurements; exact model and firmware support should be confirmed.

Read about Supported-device catalogue

React Native Bluetooth

Use the Native SDK for documented Bluetooth discovery and device workflows in a mobile app.

Read about React Native Bluetooth

Health platforms

The Native SDK documents selected HealthKit and Health Connect data imports as FHIR Observations.

Read about Health platforms

04

Optional alert evaluation

Choose which patients are enrolled in Signals.

Device data is stored in FHIR. Only eligible vital-sign readings from patients enrolled in Signals are sent for alert evaluation; enrollment is configurable per patient. Signals returns alert decisions for your product workflow.

Signals is MDR Class IIa. This status applies to Signals; Ovok itself is not a certified product.

Read about Signals

05

Projects, environments and access

Make boundaries explicit as teams and products grow.

Plan tiers set commercial environment and sub-tenant limits. In the application model, identity, FHIR resource relationships and Access Policies have separate jobs.

Growth and Scale

Growth includes two environments and 25 sub-tenants; Scale includes three environments and unlimited sub-tenants. Enterprise environments are custom on request.

Identity

Patient and Practitioner identities authenticate to a tenant; MFA continuation is available for enrolled accounts.

Read about Identity

Resource relationships

FHIR relationships describe the records and people connected to a workflow; they do not replace access policies.

Access Policies

Policies govern project-member resource and operation access. A missing policy is not restrictive, so define intended access deliberately.

Read about Access Policies

06

Commercial model and evaluation

Move one workflow first, then decide what to standardize.

You do not need to migrate the whole product to evaluate the platform. Map one bounded workflow and compare the limits that matter to its usage.

  1. 01

    Map what exists

    Identify current patient records, measurement formats, integrations and authorization boundaries.

  2. 02

    Test a representative workflow

    Validate the FHIR mapping and SDK/API behavior in the sandbox; plan separately for live IoT ingestion setup.

  3. 03

    Compare production fit

    Review included monitored patients, additional patient and device pricing, environments and support terms.

Growth includes 250 monitored patients and Scale includes 1,000; each monitored patient includes Signals and one supported device. Additional monitored-patient and device pricing varies by plan. Compare Growth and Scale pricing

Scale the product. Not the infrastructure burden.

Compare a forward-looking three-year operating model, including existing application engineers, unsupported connectors, migration, and the residual team your product still needs.

Three-year infrastructure comparison · forecast and staffing are editable assumptions. Existing application development is counted equally on both sides; historical build spend is excluded.

Product and platform
patients
%
FTE

Same application team is included in both scenarios.

€/year
FTE
FTE
FTE
FTE
Infrastructure and integrations
€/month
€/month
€/year
€/year
connectors
engineer-months
engineer-months
devices
Pricing and planning
Use an Enterprise quote for sensitivity
€/year

Enter your actual quote; leave at zero until you have one.

patients

2,500 is an editable planning assumption based on the published Enterprise starting band.

Patient overages use the published bands; confirm included volume and contract terms with Actimi.

Keep scaling in-house

€4,557,0003-year total cost

Move the platform to Ovok

€3,086,6203-year total cost

Potential cost avoided€1,470,38032.3% of the in-house estimate

Swipe or scroll horizontally to view the full comparison.

YearPatientsKeep scaling in-houseMove the platform to OvokCumulative difference
11,200€1,559,000€997,000€562,000
21,620€1,499,000€1,027,800€1,033,200
32,187€1,499,000€1,061,820€1,470,380

Year 1 cost categories

Keep scaling in-house

Custom connector implementation
€60,000
Platform engineering
€450,000
Maintenance
€180,000
Product application team
€720,000
Infrastructure
€84,000
Security and operations
€65,000

Move the platform to Ovok

Custom connector implementation
€60,000
Migration
€60,000
Residual platform team
€50,000
Residual maintenance
€25,000
Product application team
€720,000
Infrastructure
€12,000
Security and operations
€23,333
Ovok subscription
€46,667

Patient-growth sensitivity

960 starting patients€1,522,707
1,200 starting patients€1,470,380
1,440 starting patientsEnterprise quote required

Estimated cumulative break-even near month 2.

Scenario only, not a quote or customer savings claim. Prices exclude VAT, one-time setup, unsupported integrations, hardware and support extras unless included in your editable assumptions.

A bounded technical evaluation

Put the healthcare foundation on a path your product can keep growing on.

Choose one record or device workflow, validate its access boundaries, then compare the production plan against the way your service is priced.