For enterprise healthcare and medtech teams

Connected healthcare infrastructure for enterprise product teams.

Evaluate the FHIR foundation, supported-device workflows, AWS Frankfurt hosting, access model and deployment terms against your architecture and procurement requirements.

01

Architecture before procurement

Trace the data and decision boundaries.

Ovok is the FHIR and application-infrastructure layer. Signals is a separate optional alert-evaluation component for enrolled patients. Your applications decide how people use the records and decisions.

  1. 01

    Inputs

    Supported device data and documented HealthKit or Health Connect imports enter the product workflow.

  2. 02

    Ovok FHIR R4 foundation

    FHIR records, identities, Access Policies and platform services support the customer’s applications.

  3. 03

    Optional Signals branch

    Eligible vital-sign readings from enrolled patients go to Signals for alert evaluation and return as alert decisions.

  4. 04

    Customer-owned products

    Patient and practitioner applications present records and define product-specific workflows.

Signals enrollment is configurable per patient. Data that is not eligible for Signals evaluation remains in the FHIR workflow.

02

Hosting and deployment

Compare the published deployment choices with your operating model.

Hosting region

Pricing lists AWS Frankfurt hosting across Developer, Growth, Scale and Enterprise plans.

Enterprise plan

The Enterprise plan includes an isolated database and compute, with custom environments available on request.

Dedicated deployment

Published pricing starts at €29,500 per month and includes 5,000 monitored patients. The stack can run in Ovok’s AWS Frankfurt account or your AWS account.

Device telemetry retention

Enterprise pricing allows custom telemetry retention up to 10 years. This term applies to device telemetry; FHIR Observations and other clinical-record retention periods need separate confirmation.

Review current pricing and deployment options

03

Identity, access and audit

Review each layer of authorization on its own terms.

For an enterprise architecture review, trace who signs in, which project they use, how records relate to people and which operations each project member may perform.

Patient and Practitioner identities

The authentication documentation describes sign-in for both identity types; MFA continuation applies when an account is enrolled.

Read about Patient and Practitioner identities

Project settings and features

Check project settings and configuration boundaries for the environments and teams in your service.

Read about Project settings and features

Access Policies

Policies control project members’ resource and operation access. A missing policy is not restrictive; confirm the rules your project requires.

Read about Access Policies

FHIR audit trail

Pricing lists a FHIR audit trail on every plan. Review the documented AuditEvent resource and validate its fit with your audit requirements.

Read about FHIR audit trail

04

Device strategy

Check coverage at the model and workflow level.

The catalogue documents 50+ supported devices and measurements. A catalogue match is a starting point for review, not a blanket statement that every model, firmware version or deployment path is supported.

Supported-device catalogue

Check the documented families and supported measurements against your intended workflow.

Read about Supported-device catalogue

Native SDK

Review the documented Bluetooth integration for patient mobile applications and the device workflows you need.

Read about Native SDK

HealthKit and Health Connect

Review the native health-data import behavior, permissions and resulting FHIR Observations.

Read about HealthKit and Health Connect

Live connected-system ingestion

Live ingestion through the Ovok IoT Service requires setup with the Ovok team; include that dependency in the technical evaluation.

Read about Live connected-system ingestion

05

Product and regulatory boundary

Keep infrastructure and regulated product claims separate.

Ovok

  • FHIR backend and application infrastructure
  • Supported-device workflows and documented integrations
  • Not a certified medical-device product

Signals

  • Optional alert evaluation for enrolled patients
  • Only eligible vital-sign readings are sent for evaluation
  • Signals is MDR Class IIa

A product built on Ovok does not inherit Signals’ regulatory status. Regulatory scope for a complete application depends on its intended purpose and architecture; review that boundary with your own regulatory specialists.

06

Enterprise evaluation checklist

Bring concrete requirements to the architecture review.

Use the published documentation and pricing to identify what is known and what needs a project-specific answer.

Backend

FHIR R4 resources, custom operations, required data-ingestion paths and project configuration.

Applications

React or React Native SDK fit, device requirements and HealthKit or Health Connect needs.

Application services

Questionnaires, CMS, email and video-call needs; video calls require the service to be configured for the project.

Authorization

Identity types, roles, Access Policies and project boundaries for each workflow.

Operations

Environment count, hosting or dedicated deployment, telemetry retention, clinical-record retention and support/SLA terms.

Commercial and governance

Monitored-patient volume, DPA, deployment model and any Signals terms to review with Actimi.

07

Implementation examples

Use published guides to inspect the implementation surface.

Each guide is an architecture example of platform primitives used in an application flow, not a prebuilt regulated application.

Blood Pressure RPM

Supported Bluetooth readings are normalized and saved as FHIR Observations for an app to read back.

Read about Blood Pressure RPM

Medication Reminder

FHIR medication requests, app-scheduled local reminders and patient-reported administrations form an adherence history.

Read about Medication Reminder

Type 2 Diabetes Risk Screening

A QuestionnaireResponse and supported glucose measurements are combined in an example screening workflow.

Read about Type 2 Diabetes Risk Screening

Whole-Person Healthspan & Coaching

Selected HealthKit or Health Connect data, reflections, goals and human coaching in a wellness example.

Read about Whole-Person Healthspan & Coaching

Review with your product and engineering team

Make the architecture, deployment and commercial questions explicit.

Enterprise conversations can cover deployment, commercial terms, the included DPA and Signals terms. Bring your own workflow, device and operational requirements for review.