HEALTHCARE

Clinic Appointment Event Storming

This event storming map follows a clinic appointment from booking through a completed consultation. It separates actions, recorded facts, and automated policies so clinical and administrative stakeholders can discuss the process without starting from database tables. The scheduled reminder is a policy because it reacts to a booking; the reminder-sent event records that the action occurred. This is a starting point, not a clinical record design. A working session should add appointment cancellation, rescheduling, eligibility checks, consent, and follow-up ownership based on the clinic's actual process. Avoid putting sensitive patient details in a broad workshop diagram. Review the underlying definitions and totals before using this view to make an operational decision.

UPDATED 2026-09-25
EXAMPLEClinic Appointment Event Storming
Make this diagram your own.

Open it in the AI editor with a prompt pre-filled — keep what works, change what doesn't.

CASE ANALYSIS

Scenario

Clinic scheduling domain discovery

Key decisions

  • Define ownership: Clarify who can book and cancel.
  • Model reminders: Treat reminder scheduling as a policy.
  • Capture outcome: Record consultation completion as a business fact.

When to reuse this

Use to discuss a clinic workflow with operational and software stakeholders.

FAQ

Frequently asked questions

Why model a reminder as a policy?01
It reacts automatically to a booked appointment rather than being the booking command itself.
Is Patient checked in an event?02
Yes. It records a fact that has occurred after the check-in command.
What should be added next?03
Model cancellation and rescheduling paths with the people who run scheduling.
Open this example in the editor →

Tweak it with chat, export PNG/SVG, or fork it for your own use case.