Page 1 of 1
Question | what is the expected behavior for DB Events when a patient is merged?
Posted: Tue Aug 12, 2025 3:27 pm
by rinse-dental
When a patient is merged, what DB Events are fired?
I'm aware of two Patient Events, for example:
- PatNum #1 w/ Status: Archived (PatNumFrom)
- PatNum #2 w/ Status: Patient (PatNumTo)
In this example, will the Appointment and PatField's fire for PatNum #2? And, will AppointmentDelete fire for PatNum #1?
Thank you!
Re: Question | what is the expected behavior for DB Events when a patient is merged?
Posted: Fri Aug 29, 2025 2:54 pm
by SLeon
Good afternoon,
I set up subscriptions in a demo database to test your scenario.
- PatientTo had one Appointment booked and one PatField ("PatFieldDefA") filled in.
- PatientFrom had one appointment booked and two PatFields ("PatFieldDefA" and "PatFieldDefB") filled in.
At the time of merge, Open Dental recognized that PatientTo already had a value for PatFieldDefA, and asked if I'd like overwrite it with the data from PatientFrom. I clicked 'Yes'.
I received two subscription payloads:
- One for the previously-PatientFrom appointment, correctly showing the PatientTo patnum on the appointment
- One for the previously-PatientFrom PatFields. Because one was transferred/new and the other overwritten, this payload contained two patfields.
You can set up subscriptions in a testing database if you have questions about other tables, but expect them to behave the same.