Master File/Registry Control Act Wrapper

FAQ

Linking/Merging Identifiers

• Linking Identifers

The primary identifiers of the patient (as used as primary keys by the Patient Identy Source) are contained in the Patient.id attribute. The OtherIDs class (which has cardinality 0..*) contains either a patient ID used by another healthcare provider, or an ID of a non-Patient role.

If the Patient Identity Source adds (or removes) an OtherIds class from a registration then the PatientLivingSubject Information Revised (PRPA_IN201102) interaction is used. This interaction updates an existing registration by an updated registration (which may contain a different set of OtherIDs).

Example: if we have a patient with primary key 1, and otherIDs 10, 11 and 12, then these (as part of the patientLivingSubject model) have been registered at the MPI. If it becomes know that this patient also has OtherId 22, then the registration is updated, at which point in time the MPI will become aware that IDs 1, 10, 11, 12 and 22 are linked to one and the same patient.

• Merging Registrations

The Resolve Duplicate Patient Registration (PRPA_IN201104) interaction is only used if a Patient identity Source wants to merge two prior registrations by a new one. This typically occurs when merging patient identifiers because of temporary registrations (emergency admit, administrative errors).

Example: a Patient Identity Source has a patient with primary ID 2, and another patient with primary ID 3. The Patient Identity Source has registered both with the MPI. It has detected that these patients are actually one and the same, so it would like to nullify one registration in the MPI (e.g. the one with ID 3), and let the other registration (with ID 2) be the primary one for this patient. To achieve this the Patient Identity Source sends the Resolve Duplicate Patient Registration (PRPA_IN201104) interaction to replace (and nullify) the ID 3 registration with an updated version of the ID 2 registration. The update of the ID 2 registration is the fact that ID 3 is included as an OtherId.

Master Registry Entry

Consider the following scenario: Patient Identity Source A registers patient "Johnson, Eric Peter" with primary ID 5. Patient Identity Source B subsequently registers patient "Johnsson, Erik Peter" with primary ID 22. The MPI (using its duplicate detecting mechanisms, probably involving a person) determines that these two patient registrations are related to one and the same person.

The MPI creates a new "Master Registry Entry" which combines the best/latest demographic data of this patient/person, assigns a new ID 98 (with the MPI as the assigning authority) and IDs 5 and 22 as secundary IDs.

• There are federated circumstances where a) the MPI does NOT assign its own ID, b) the MPI does assign an ID but this may never be communicated in messages.

If Patient Identity Source A updates its registration (e.g. an address change for the patient with ID 5), then depending on the rules/configuration of the MPI these changes may be copied to the "Master Registry Entry" to ensure that it contains the "latest" data.

If one sends a generic query to the MPI "give me the MPI entry for patient with name Johnson" what registry entry is returned? The Master registry Entry or the ones sent by A and B.

Should the registry entries created by A and B only be returned if the query had populated the scopingOrganizationID query parameter?