The code blocks shown on this page are implemented in the sample code available here: Sample Integration Code.
The following block shows the pseudo-code for performing an initial synchronisation between the RCS and PainChek. It would be invoked on an ad-hoc basis (when synchronisation is first turned on, when the whitelist of sites is updated or if there was a need to re-synchronise the two systems).
for rcs_resident in the RCS:
if rcs_resident.current_site not in whitelisted_sites:
# skip this resident
continue
# Process the rcs_resident record (which will lead to a PainChek resident being created in the case that the soft match above failed)
process_resident(rcs_resident)
Notes:
- This logic assumes that the RCS is recording the PainChek UUID for each resident (i.e. here: rcs_resident.painchek_uuid). If we find an RCS record already has a PainChek UUID recorded, then we assume we have a valid link between the RCS and PainChek records.
- "whitelisted_sites" is the list of facilities/sites where PainChek is currently deployed to and hence only the data from those facilities/sites should be synchronised with PainChek
The following table summaries the key functions referenced in the code above:
|
Name
|
Accepts
|
Returns
|
Comment
|
More details
|
|---|---|---|---|---|
| process_resident | RCS Resident Object | n/a | This function looks at the RCS resident record, looks at the corresponding PainChek record (if any) and makes the necessary calls to update PainChek to bring it in-line with the RCS. | See Best Practice Guide - The "process_resident" function |