2. Create and configure the Ovok project
What we are building
A sandbox project with patient self-registration and policies that scope each member to their own record. A separate, controlled practitioner flow will be added in step 8.
What you should already have
- The Expo project from step 1.
- Project-admin access to Ovok Console.
- The canonical project setup, patient registration and AccessPolicy docs.
The implementation
Ovok Console configuration
- Create or select a sandbox project for this tutorial and note its tenant code.
- Enable patient sign-in with
PATIENT_LOGIN_ENABLED. - Enable patient self-registration with
PATIENT_REGISTRATION_ENABLEDand configure a default Patient AccessPolicy on the Project. Registration needs both; the setting alone is not enough. - Create a patient AccessPolicy that grants the minimum operations for the signed-in member's own Patient, Questionnaire, QuestionnaireResponse, Observation and Goal records. Use the project AccessPolicy editor and verify every rule against the AccessPolicy model. Do not copy a broad policy from another product.
- Confirm the project CapabilityStatement exposes the resource interactions you will use. Start at FHIR R4 capabilities; a listed resource does not automatically mean your project policy allows a request.
- Map a patient welcome email only if your onboarding product needs one. See email template setup.
Set every sign-in/registration switch to the intended value. The settings API can display an unset Boolean as false while some flows behave as enabled when unset; the project setup guide explains the difference.
Coach configuration is separate
The coach account is a Practitioner, not a Patient. Configure the practitioner app URL, a restrictive default practitioner AccessPolicy, invitation settings and the two patient-sharing email templates only if you will use the built-in invitation flow. Follow Share a record with a practitioner exactly.
The built-in patient-to-practitioner share grants access to the patient's whole record. Use a dedicated project with synthetic tutorial data, and do not use this flow if whole-record access is not appropriate. A CareTeam does not narrow or grant that access.
Application configuration
Set the tenant and sandbox API base URL from step 1. Do not put project-admin tokens or backend credentials in the application.
Confirm the configured environment using your test account before importing any health data.
Important Ovok decisions
- New Patients receive the project's default Patient AccessPolicy. It must be least privilege.
- A project setting controls whether a flow runs; an AccessPolicy controls which FHIR resources and operations a signed-in user can access.
- Patient and coach accounts must have different policies.
- Patient-to-practitioner sharing is broad at the record level. A FHIR relationship resource is not an authorization rule.
- The app remains useful if the member never grants HealthKit / Health Connect permission.
Expected result
A sandbox project permits a test patient to register and sign in, while project policy restricts the patient's FHIR access. You have documented whether coach sharing is appropriate for this isolated project.
Common errors and troubleshooting
| Symptom | Check |
|---|---|
| Patient registration is refused | Confirm PATIENT_REGISTRATION_ENABLED and a default Patient AccessPolicy are both configured. |
| A resource reads in the Console but not in the app | Check the signed-in user's AccessPolicy and the project's CapabilityStatement separately. |
| Coach cannot accept a share | Check practitioner invitation settings, app URL, AccessPolicy and both required email templates in the sharing guide. |
| You need to share only wellness records | Do not use the whole-record share as though it were fine-grained. Design a server-enforced narrower authorization workflow before production. |