Read the docsStart free

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.

Start with Growth Review the architecture

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.

02

One foundation, several experiences

Keep the record model underneath the product consistent.

The React SDK, React Native SDK and 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.

React SDK: @ovok/core React Native SDK: @ovok/native

03

Connected data

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

Ovok documents 50+ supported devices 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

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.

Start with Growth Read the technical docs