Specialty referral scheduling simulator

A patient-access app proposes a specialty appointment from a fictional referral. VeriProof checks the health system's rules before the app contacts the patient or reserves a slot.

How the simulation works

The app proposes a scheduling action. VeriProof checks the rules.

  1. The website simulates the patient-access app

    Each prepared scenario starts with a fictional referral and a proposed specialty appointment.

  2. VeriProof enforces the health system rules

    VeriProof checks recorded contact permission, identity, referral, and review facts before the action can continue.

  3. The mock app reports what happened

    A rule can stop the action, hold it for review, or permit the mock scheduler to reserve one sample slot.

Policy permission is not a booking confirmation. This demo reports an appointment as booked only when the mock scheduler returns that outcome. It uses fictional referrals and does not give medical advice, contact a patient, create a real referral, or book real care.

  1. Choose a specialty referralEach prepared scenario starts with a proposed scheduling action
  2. See the rule and application outcomeReview what VeriProof decided and what the mock app did next

Choose a scenario

The specialty referral

Each fictional referral ends differently. Pick one, or change the scheduling facts below.

Requested specialty
Cardiology
Referral priority, as reported
Routine
Proposed contact channel
Outbound voice
Contact permission is recorded
No
Identity is confirmed
Yes
Change scenario details

The patient-access app proposes to contact the patient and book the candidate slot.

The app finds a slot, but no patient contact permission is recorded. VeriProof stops contact and booking.

Records created in this public demo can be seen by other visitors, so use the sample data rather than your own.

Configuration details

How this demo is set up

Review the application settings, scheduling rules, and evidence fields used in this simulator.

VeriProof setup

Industry
Health Systems & Providers
Application
Specialty Referral Scheduler
Environment
Public demo workspace
Protected action
Contact the patient and reserve a sample slot
Rule enforcement
On, rules can stop or hold scheduling actions
Action executor
Deterministic mock scheduler, with no real system connection

Related frameworks

Industry context: HL7 FHIR Appointment · HL7 FHIR ServiceRequest

The patient-access app's own checks

The sample app finds a candidate slot and proposes a scheduling action. It does not own the health system rules.

  • Propose a booking when a candidate slot is reported as available.
  • Hold the referral for a scheduling coordinator when availability is not confirmed.
  • Report its proposal separately from the rule result and the booking outcome.

The health system rules VeriProof enforces

The organization sets these rules outside the patient-access app.

  • Stop contact and booking when contact permission is not recorded.
  • Stop booking when identity is not confirmed or referral information is incomplete.
  • Require nurse review when an expedited referral reports that triage is needed.
  • Require referral-coordinator review when the requested and receiving specialties do not match.
Review the details saved with each run

The decision record connects the fictional referral, rule check, and application-reported outcome. No real patient data is used.

patient_reference / referral_reference

The fictional patient and referral references for this run.

requested_specialty / referral_priority / healthcare_appointment_status

The requested specialty, reported priority, and proposed appointment state for the sample referral.

healthcare_patient_engagement_channel / contact_permission_recorded

The proposed contact channel and whether the sample record reports contact permission.

identity_confirmed / referral_information_complete

The identity and administrative readiness facts checked before booking.

receiving_specialty_match / nurse_triage_required / availability_confirmed

The specialty, review, and candidate-slot facts used by the scheduling rules.

proposed_action / governance_action / application_outcome

The app proposal, VeriProof result, and mock scheduler outcome saved as separate facts.

booking_attempt_key / booking_confirmation_status

The deterministic mock attempt and whether it returned a booking confirmation.