Form requirements tell circleOS which forms need to be completed for a patient or workflow. Once configured, missing forms can show up in Live Mode, patient workflows, booking workflows, and plan-related workflows where enabled.
How requirements work
A requirement combines four things:
| Setting | What it controls |
|---|---|
| Form | Which form needs to be completed |
| Required from | Who completes it — patient or provider |
| Required at | When it becomes due. In the current day-to-day UI, staff mainly choose pre-appointment and during plan. |
| Validity | How long a completed submission should still count before it needs refreshing again. |
Under the hood, circleOS supports more combinations than the everyday staff UI exposes. For most teams, the practical choices are service requirements, plan requirements, and one-off patient requirements.
Attaching requirements to a service
Use this when a form should be required for every appointment of a specific service, for example intake, consent, or a pre-op questionnaire.
- Go to Settings → Services and open the service.
- Open the Forms tab.
- Use the Patient or Employee section, depending on who should complete the form.
- Add forms under the side that should complete them.
- Review the timing and validity for each requirement.
New service requirements start as pre-appointment. You can then adjust timing, participant, and validity on the requirement card.
Once configured, these requirements appear automatically whenever a patient has a booking for that service. Patient requirements feed the patient-facing forms flow. Provider requirements stay as internal team work.
In the service setup, patient and provider requirements are managed separately. That is why you see separate sections for each side.
Patient-specific requirements
Sometimes one patient needs a form that is not part of the normal service setup. Add that one-off requirement directly from a required-forms list, for example from Live Mode.
These requirements behave like tasks for one patient only. In the current UI they are added as patient requirements with pre-appointment timing, and they can be removed later from that same requirements list. Service-level and plan-level requirements stay managed from their original settings screens.
Satisfying a requirement
A requirement becomes complete when circleOS has a valid submission that still counts for that patient:
- Patient submits the form: the shared forms flow links that submission back to the patient.
- Staff uploads a completed PDF: click the upload icon next to the missing requirement, select the PDF, and confirm. circleOS stores it as a form submission and updates the requirement immediately.
If a submission should no longer count, open it and use Invalidate. That changes the completion status without deleting the submission or linked document.
See Form Submissions for more on viewing and managing submissions.
Where requirements appear
- Service settings: where you define the default requirements for a service.
- Live Mode: the forms card shows patient requirements for today's visit with missing/complete status. Staff can send the patient forms link by QR code, email, or SMS, upload a completed PDF, or add a patient-specific requirement on the spot. Provider requirements configured as pre-appointment can also surface in the visit workflow, but they stay internal. See Forms in Live Mode.
- Plans: plan requirements can be tracked in plan workflows where enabled.
- Submission views: patient and booking submission screens let you review what was actually submitted, even though requirement setup happens elsewhere.
Common patterns
- Pre-appointment for anything the patient should complete before arriving, such as intake, consent, or medical history.
- During plan for items you want to surface as part of an active plan workflow.
- Validity / refresh windows for periodic updates, for example a health-history form that should be refreshed every 90 days.
- From provider for internal checklists and operational steps completed by the care team.
- Patient-specific requirements for one-off exceptions. Keep the default workflow on the service and use these sparingly.
The underlying model also supports timings such as pre-checkout and signup, but those are not the main self-serve options in the current staff UI.