1
Capture required information
Web intake collects the minimum administrative details needed for revenue readiness. SMS can follow up for missing fields.
CompleteIncomplete
Pre-visit authority
How Dicyd decides—before scheduling happens.
Dicyd turns structured, non-clinical intake information and explicit location rules into an auditable revenue-readiness decision before an appointment enters downstream systems.
The decisionShould this appointment proceed, require staff review, or stop?
A decision, not a suggestion
Revenue readiness becomes a prerequisite.
Dicyd evaluates only the administrative information required for the clinic's configured rules. Ready cases proceed. Exceptions become staff tasks. Cases that fail an explicit rule stop.
Every outcome includes a reason code and the location rule-set version used to reach it.
The decision flow
Three deterministic steps before scheduling.
The same inputs and the same rule-set version always produce the same result.
2
Evaluate explicit rules
Location-versioned rules evaluate payer acceptance, plan referral requirements, authorization readiness, and configured intake fields.
AcceptedReviewNot accepted
3
Transition and act
The case enters a defined state. Staff receive tasks for exceptions; messages and downstream handoffs follow the recorded outcome.
ProceedStaff taskStop
Human control
Automation for explicit rules. People for exceptions.
Dicyd does not infer policy or silently decide ambiguous cases.
Deterministic work
Completeness checks and configured payer, referral, and authorization rules run consistently without subjective interpretation.
Exception work
Unknown payers, incomplete evidence, callbacks, and configured review scenarios enter a staff task queue with the reason and available context.
Explain every result
An immutable record for every state change.
Decision transparency is part of the architecture, not an optional report.
Transition
Every record captures the previous and next case status so the full state history can be reconstructed.
Reason
A consistent reason code and human-readable detail explain why the transition occurred.
Rule version
The exact location rule-set version ties the outcome to the policy that was active.
Trigger and actor
The inbound event, system or staff actor, and timestamp show what caused the change.
Why start with a pilot
Validate infrastructure with evidence.
A 90-day pilot lets the clinic test its rules, exception workflow, and operational impact before a broader rollout.
Review stopped and reviewed casesSee which administrative conditions prevented a case from proceeding.
Inspect every reasonConfirm that outcomes reflect the clinic's documented policies.
Measure staff workloadCompare focused exception work with the clinic's prior verification process.
Refine location rulesVersion changes explicitly as the clinic validates its operating policy.
Product boundaries
Purpose-built pre-visit infrastructure.
Not an EHR
Dicyd does not store clinical notes, diagnoses, histories, or manage patient charts.
Not billing or RCM
Dicyd does not submit claims, post payments, or manage collections.
Not a chatbot or clinical system
Dicyd does not give medical advice, diagnose, conduct clinical triage, or replace staff judgment.
Decide early. Prevent unpaid work.
Start with explicit rules and a measurable 90-day pilot.