Case stage 01
Service request and intake
A request arrives from a provider, patient, payer, partner, or internal team. It becomes a governed workflow with a purpose, requested service, priority, due date, consent context, and accountable owner before processing begins.
Partly builtReference parts exist; the solution layer is designedIntake and duplicate search have reference implementations. Partner-specific request forms and system mappings are configured per implementation.
What happens
- The request arrives through a portal, FHIR API, HL7 message, partner API, secure email, or uploaded document.
- The request fields are validated, and the sender, patient or member, organization, and care context are resolved.
- A workflow is opened with its service-level clock, consent and purpose-of-use context, and duplicate check.
How the AI platform addresses it
- Intake reads the structured request or attached document and extracts fields with provenance back to the source.
- Duplicate candidates are ranked on name, date of birth, claim or reference number, and sender, so a coordinator sees the matching fields before deciding.
- The request, participants, and status are synchronized with the appropriate CRM, EHR, or operational system through the shared workflow record.
AI role
Extraction of request fields, classification, and ranking of duplicate candidates. The model proposes; an authorized coordinator confirms.
Approval
The workflow owner confirms identity, purpose, consent context, priority, and service level before processing begins.
Systems involved
- Portal and APIs
- EHR or CRM
- Records intake
- Workflow record
Reference components
- Claims document intake
- Policy search and duplicate candidates