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.