Articles in this section

Best Practice Guide - Event-Based Resident Synchronisation

  • Updated

Event-based synchronisation can be used to update PainChek regularly by responding to relevant events generated by the RCS.

There are a number of methods the integration logic can utilise to be notified of such events, including: webhooks, message buses, queues and subscribe & publish schemes.

The choice of notification method will depend on what the RCS makes available and then the implementers' personal preferences. It is beyond the scope of this document to evaluate and/or recommend the alternative that should be used.

The integration process would need to be notified when the following types of events occur in the RCS:

  • A resident is added

  • A resident is updated (this only applies to the basic details that PainChek cares about - first name, last name, gender, date-of-birth and nickname)

  • A resident avatar (photo) is updated or removed

  • The residents' admission details change - i.e. they are moved to another room or site

  • The resident is permanently discharged

This type of synchronisation process would run on-demand and would push the updates to PainChek in real-time (assuming there are no material delays in the event notification process).

Note

Note that there is an alternative to Event-Based synchronisation which is discussed here: Best Practice Guide - Update Stamp Based Resident Synchronisation.

The following block shows the pseudo-code for performing event-based synchronisation:

def process_rcs_event(event):
 # Check to see if the event is relevant
 if not rcs_event_is_relevant(event):
 return

 # Get the last recorded update stamp value
 rcs_resident = get_rcs_resident_from_event(event)

 # See if this resident belongs to a site of interest to PainChek
 if rcs_resident.current_site not in whitelisted_sites:
 return

 # Process any changes to the resident
 process_resident(rcs_resident)

 # Requeue the event in case of failure:
 if error:
 requeue_event(event)

Note

  • "rcs_event_is_relevant" examines the supplied event and ensures that it is relevant for PainChek data synchronisation process

  • "get_rcs_resident_from_event" fetches the RCS resident record associated with the event

  • The "process_resident" function returns an indication of success and also an indication if a retry-able error was detected (e.g. if the PainChek API was down).For more details on the "process_resident" function, see Best Practice Guide - The "process_resident" function

  • "requeue_event" is called in the case that the "process_resident" process fails (e.g. if PainChek was down for a period of time). It places the event back into the queue (or performs whatever is appropriate for the event notification platform) so that the event can be reprocessed later (when, for instance, the PainChek system is back online and allowing synchronisation).

Related articles