UI and data modules
The package combines reusable UI with typed native integrations. Use a root import for common screens and a subpath for optional features so an app loads only the integrations it needs.
| Module | Typical use |
|---|---|
| Authentication | Sign-in, registration, password reset, profile, and session UI |
| Bluetooth | Device discovery, pairing, measurement callbacks, and device controls |
| Patient and measurement | Patient cards, measurement lists, and observation details |
| Questionnaire response form | Render and submit questionnaire responses |
| Theme and tile | Consistent tokens, theme-aware components, and workflow cards |
| Content and journal | Content, diary, and journal experiences |
| Data sync | HealthKit and Health Connect authorization and import |
| Background sync | Durable Bluetooth delivery and scheduled Android work |
| UI integrations | Composable flows such as manual entry and health import cards |
| PDF and image | Native PDF viewing and optimized remote images |
| Socket | Realtime connection components and hooks |
Many screens use the client, active patient, or theme from their provider context. Mount the app shell before rendering them and use the documented public subpaths listed in the API map.
Keep clinical behavior on the server
The native components present and collect information; the Ovok APIs store FHIR resources and enforce project permissions. If an app shows Signals alerts, follows a clinical pathway, or grants access to patient data, use the backend contracts and your product’s intended purpose. Read Signals, access policies, and settings and features before implementing those flows.