Client Registry to Shared Health Record reconciliation of persons

The Problem

A person is registered at clinic1 and their record is send to and stored in the client registry. They also have various encounters captured during their visit and these are send to and stored in the shared health record and linked to the person record in the client registry via their ECID, ECID1, found in the client registry record. a while later that same person goes to a different clinic, clinic2, for a visit. The demographics entered at the clinic do not return any results from the client registry, so the registration clerk does a new registration. This registration record is sent to the client registry. In the client registry it is not automatically matched to the existing person record that already exists. The patient goes on to see a clinician and encounter are sent to the shared health record and saved with a link to the the new ECID, ECID2. We now have 2 separate records for a single person in the client registry and 2 separate records for clinical encounter for each of the record in the client registry, identified by ECID1 and ECID2 respectively.

The problem we encounter is that when a administrator of the client registry attempts to link the 2 records in the client registry we have to also link the 2 record in the shared health record. this is because OpenEMPI chooses one of the ECIDs to remain as a global ID for the 2 records and retired the other ECID. This poses a problem as the shared health record stores the encounter for a particular person identified by their ECID. Now that one ECID has been retired be have a dnagling reference to encounter that cannot be accessed. In order to solve this we need a mechanism to link records in the shared health record when when records are linked in the client registry and vice versa when record are unlinked.

Possible solutions

1. Client registry notifies other systems of links and unlinks

In this solution the CR provides a mechanism to notify other system of link and unlink events. It is the responsibility of the other systems to read the notification and deal with the complexity of linking and unlinking the records themselves. This would involve the other system having to store additional metadata for when records have been linked and metadata on how to undo this if needed.

How this could be implemented in OpenEMPI: OpenEMPI could extend it's REST API to have another endpoint that publishes link and un-link events in a notification stream. It could be implemented by exposing an RSS or ATOM feed that lists the lin and un-link events in a time series.

How this could be implemented in OpenMRS SHR: We could develop a module that polls the notification RSS/ATOM feed and for each link or unlink event the module would link or unlink it's records using additional metadata to store details of the link or unlink so that the changes can be reversed if needed.

2. Client registry returns mutiple ECIDs for a person

In this solution the CR should be made to return both the current and retired ECID for a person records if they have been linked. If it is queried for a specific record's unique identifier it will respond with all the global identifiers that the linked record where ever known by. This would require the interoperability layer to have to query multiple records from the SHR (one for each ECID) and combine them before returning them to the requesting client.

This option seems to be the weaker off the 2 and requires fundamental changes to the CR and some complex orchestration by the interoperability layer so we don't recommend it.

Recommendation

Each of the options mentioned above required some extensive changes to some of the RHEA systems. Due to time constraints we can't recommend either of the solution as viable for the time frame. We recommend disabling the manual (only the manual) linking and un-linking functionality in OpenEMPI. This will solve all the problems but we will not be able to reconcile duplicate records in the CR. This can be addressed by adding one of the above options as a task to be done in the next phase of RHEA after the September deadline.

Overall, we recommend that option 1 should be implemented, however this should only be implemented in RHEA phase 2. For now turning off the linking and un-linking functionality would suffice.