Both the RCS and PainChek systems will record the same resident details and hence there needs to be a means to link the records together.
A "hard-match" (or unambiguous match) is possible when the identifier of one system is known to the other.
PainChek has 2 identifiers for a resident record:
-
uuid or patient_id - This is a mandatory UUID generated by PainChek
-
external_id - This is an optional string supplied by the RCS (i.e. the unique identifier for the resident as far as the RCS is concerned)
The RCS can use the following approaches for hard-matching PainChek residents:
-
Record the PainChek UUID in the RCS and use it when accessing the PainChek API.
In this case, the RCS needs to extract and record the UUID returned when creating resident (i.e after a POST to "../api/patients/")
-
Record the RCS identifier (RCS Id) in PainChek and use it to fetch the PainChek resident details.
In this case, supply the "external_id" field in the request payload when creating a resident (i.e when making a POST to "../api/patients/").
The external_id can be used to fetch the details for a PainChek resident (i.e by invoking a GET to "../api/patients/external_id={RCS Id}"). The RCS must, however, use the PainChek UUID (returned by that GET call) to perform most actions (such as updating the resident details or their admission record).
Note
The recommended approach is to supply an external_id to PainChek and to not record or use the PainChek UUID. This will generally minimise the work required when integrating.
A "soft-match" uses the details of the resident (first name, last name, gender and date-of-birth) to link records from the RCS to PainChek. Due to the risk of this approach (e.g. duplicates matches or typos leading to expected matches not being made), this approach should only ever be used for initial data migration phase.
If soft-matching is used during migration, then either:
-
Record the PainChek UUID returned from the soft-matching in the RCS, or
-
Update the "external_id" field of the PainChek resident record with the RCS Id (by invoking a PATCH to "../api/patients/{PainChek UUID}").
Note
When soft-matching, some translation might be required - e.g. PainChek uses "m" (male), "f" (female) and "x" (Indeterminate/Intersex/Unspecified) to identify the resident gender, whereas the RCS might use a different convention.