- 01
Supported devices and selected health data
Bring in supported device measurements and, where the patient grants permission and data exists, selected HealthKit or Health Connect records.
- 02
Questionnaires and medication workflows
Store structured responses and medication-related resources used by the application.
- 03
FHIR R4 patient record
Use Patient, Observation, QuestionnaireResponse and other supported resources to represent the data your product needs.
- 04
Patient and practitioner experiences
Build separate application views against the same record, with access configured for each role.
Use case / Product architecture
Build longitudinal monitoring on one patient record.
Chronic-care products accumulate measurements, questionnaires, medication and practitioner interactions over time. Ovok provides a FHIR foundation; your team builds each condition-specific workflow.
01
Architecture
Many inputs can contribute to one longitudinal record.
Select the resource and ingestion path for each product workflow; optional Signals evaluation is one branch, not the destination for every record.
02
Longitudinal model
Use the FHIR resources that fit the workflow.
These resource families are available in Ovok's FHIR R4 surface; the product team decides its own clinical and operational model.
Patient and Observation
Represent the person and supported measurements collected across devices and time.
Read about Patient and ObservationQuestionnaireResponse
Keep structured check-ins distinct from device-derived measurements.
Read about QuestionnaireResponseMedication resources
Use MedicationRequest for a plan and MedicationAdministration for a patient-reported administration event where that model fits.
Read about Medication resourcesGoal, CarePlan and CareTeam
Use these resources where the application models goals, care plans and care-team relationships; a relationship does not itself grant data access.
Read about Goal, CarePlan and CareTeam03
One foundation, different products
Condition-specific workflows remain yours.
Blood pressure
A connected measurement path can add supported readings to an Observation history.
Read about Blood pressureGlucose-related screening
A guide demonstrates a questionnaire-led risk-screening flow alongside supported glucose measurement; it does not diagnose or interpret glucose as advice.
Read about Glucose-related screeningRespiratory and sleep-related data
Use only the measurements documented for each supported source and preserve their original semantics.
Medication and goals
Compose medication records, goals and product-owned reminders or review workflows around your intended use.
Read about Medication and goals04
Access and teams
Model identity and authorization separately.
Chronic-care products often involve patients, practitioners and teams with different access needs.
Patient and practitioner identity
Use the platform's FHIR identities to build patient and practitioner-facing applications.
Read about Patient and practitioner identityCareTeam is a relationship
A patient-practitioner or CareTeam relationship does not itself authorize resource access.
Read about CareTeam is a relationshipAccess Policies control project operations
Configure intentional project-member access for the resources and operations each role needs.
Read about Access Policies control project operations05
What each team owns
A platform layer is not a disease-management product.
Ovok provides
- FHIR R4 backend and patient/practitioner identity
- Supported-device and documented health-data paths
- Questionnaire and medication resource support
- Access Policies and optional Signals evaluation
Your product team owns
- Condition-specific UX and care pathway
- Clinical thresholds, interpretation and escalation
- Patient enrollment, consent and data selection
- Regulatory strategy and product-specific business logic
06
Signals
Enroll patients deliberately; keep other data in FHIR.
07
Relevant documentation
Follow the primitives your product needs first.
Evaluate the product pattern
Build against the infrastructure your team will use.
Start in the Developer sandbox with test data, then validate supported-device and workflow requirements against the current docs.