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.

類型 流程圖標準 Sugiyama layered DAG + orthogonal routing引擎 schematex-flowchart更新時間 2026/9/24

需求

“Create an event storming diagram for a clinic appointment: Book appointment causes Appointment booked; a reminder policy causes Reminder sent; check in patient causes Patient checked in; record consultation causes Consultation completed; then a follow-up policy creates a follow-up task. Color commands blue, events orange, and policies green.”

接著試試Add an Appointment cancelled event before check-in.Add a Patient aggregate after Appointment booked.

這張圖裡有什麼

看懂背後的決策。

01Define ownership

Clarify who can book and cancel.

02Model reminders

Treat reminder scheduling as a policy.

03Capture outcome

Record consultation completion as a business fact.

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

瀏覽所有流程圖範本 →

常見問題

Why model a reminder as a policy?

It reacts automatically to a booked appointment rather than being the booking command itself.

Is Patient checked in an event?

Yes. It records a fact that has occurred after the check-in command.

What should be added next?

Model cancellation and rescheduling paths with the people who run scheduling.