Migrate from Oracle Health to Intakeq.
2 documentation-derived translation patterns — what carries over and what to watch for. Cited to the Feature Parity Map; the audit tells you whether the move is worth it.
IntakeQ exists to collect pre-visit intake — branded forms, consents, and assessments completed online before the appointment. A practice already running Oracle Health does not need the separate IntakeQ contract for this: move those forms into the Oracle Health Patient Portal 'Get Ready' and Arrival workflows. Patients upload ID, confirm/update demographics and insurance, e-sign consent forms, answer custom health questionnaires, and request history updates that providers reconcile straight into the chart, then check in from their own device. Because intake is one module of the system of record, answers flow into the same Oracle record used for documentation, orders, and billing — removing the IntakeQ re-key step. Keep Oracle Health, cut IntakeQ. Rebuild IntakeQ's conditional/adaptive questions as the portal's custom registration questionnaires.
- Warning: IntakeQ form templates and consents do not import into Oracle Health — they must be rebuilt as portal registration questionnaires/consent forms by the Oracle build team, so configure and validate them before cancelling IntakeQ.
- Warning: Export IntakeQ historical data first: its CSV/PDF export drops File Attachments and Signatures (per the 'Export Your Data from PracticeQ' support article), so prior uploaded IDs/insurance images and signed consents must be retrieved separately for the legal record.
- Warning: Confirm the org is on the current Oracle Health Patient Portal Cloud Service (the HealtheLife successor); the Get Ready / Arrival intake steps cited reference the March 2026 portal release, so an older HealtheLife build may not expose the full self-arrival intake set.
IntakeQ/PracticeQ sells client self-booking via an embeddable widget on a metered practice-management tier. A practice on Oracle Health can retire that paid widget and use the Oracle Health Patient Portal's self-service online scheduling instead: patients find and book appointments against real provider availability, use 'Book again' from past visits and favorites, get scheduled/rescheduled/canceled notifications and confirmation links, and can cancel as a portal self-service action. Because the portal writes into the same scheduling and patient record the EHR uses, a self-booked slot becomes a real encounter that flows straight into pre-registration and intake — not an appointment a third-party widget hands back. Keep Oracle Health, cut IntakeQ. Put the portal's scheduling entry point where the IntakeQ 'Book Now' widget used to sit.
- Warning: Provider availability, bookable visit types, and scheduling rules must be configured in Oracle Health scheduling first — this is build work, not a port of IntakeQ's per-practitioner booking settings.
- Warning: Migrate or reconcile future-dated appointments out of IntakeQ before cancelling so already-booked clients are not lost at cutover; verify the live schedule in Oracle Health.
- Warning: Self-service scheduling features cited (Book again, Ask Oracle navigation, confirmation links) reference the March 2026 portal release — confirm the org's portal version exposes them before relying on them as the IntakeQ replacement.