- 01
Discharge and enrollment
Your application or operational process determines whether a patient starts using the monitoring product.
- 02
Patient app
The product guides device setup, measurements, symptom check-ins, questionnaires and other intended interactions.
- 03
Ovok FHIR record
Supported readings and other selected product data are stored in the patient's record.
- 04
Optional Signals evaluation
Only eligible vital-sign readings for a patient enrolled in Signals can take this evaluation path.
- 05
Care-team review and follow-up
The customer defines staffing, review cadence, escalation rules and communication with the patient.
Use case / Product architecture
Extend the product workflow beyond discharge.
Connect supported measurements, check-ins and medication-related records to a longitudinal FHIR record. Your team builds the follow-up experience; Ovok does not supply a discharge protocol.
01
Continuity pattern
Discharge starts a product workflow; it is not an automatic integration.
Enrollment, patient instructions and the follow-up plan are product and care-team decisions.
02
Beyond vital signs
Compose the follow-up around the records that matter.
These are supported building blocks that a product team can assemble; they do not form a prebuilt post-discharge application.
Measurements
Use supported device data and FHIR Observations for the measurement flows selected by your product.
Read about MeasurementsQuestionnaires and check-ins
Use FHIR Questionnaire workflows to collect structured patient responses alongside measurements.
Read about Questionnaires and check-insMedication-related workflow
Represent a medication plan with FHIR resources; the example app schedules local reminders and records patient-reported administrations. Ovok does not run the reminders.
Read about Medication-related workflowEducation and visits
Documented CMS and video-call capabilities can support product content and remote interactions when configured.
Read about Education and visits03
Record and systems
Use FHIR as the foundation for continuity.
A FHIR-backed record can form part of a broader longitudinal record and can be integrated with surrounding clinical systems using the appropriate implementation.
FHIR record
Build on supported FHIR R4 resources for observations, questionnaires and medication workflows.
Read about FHIR recordConfigured ingestion
Connected-system ingestion is an explicit setup path; the use-case page does not imply automatic EHR synchronization on discharge.
Read about Configured ingestionAccess
Configure project access for patient and practitioner operations. A resource relationship alone does not authorize access.
Read about Access04
Ownership
The care pathway stays with your product and clinical team.
Ovok provides
- FHIR backend, supported measurement paths and SDKs
- Questionnaire and medication resource capabilities
- CMS and video-call building blocks
- Optional Signals evaluation for eligible readings and enrolled patients
Your product team owns
- Discharge enrollment and patient communication
- Medication reminder scheduling and adherence interpretation
- Review cadence, staffing and escalation rules
- Clinical protocol, intended use and regulatory strategy
05
Implementation examples
Combine examples; do not mistake them for a complete pathway.
Each guide demonstrates a limited technical composition that can inform a product architecture.
Blood Pressure RPM
Connected device measurement through FHIR Observation and patient display.
Read about Blood Pressure RPMMedication Reminder
MedicationRequest, local app reminders and patient-reported MedicationAdministration workflow.
Read about Medication ReminderType 2 Diabetes Risk Screening
A QuestionnaireResponse-centered screening example with a connected measurement step; it is not a diagnosis or post-discharge protocol.
Read about Type 2 Diabetes Risk Screening06
Signals
Keep alert evaluation optional and enrollment-based.
07
Relevant documentation
Validate the patient, device and follow-up workflow.
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.