Master File/Registry Control Act Wrapper

The Master File/Registry control act wrapper is a specialization (extension) of the generic Trigger Event Control Act Wrapper and is used for Registry and Master File related messages.

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.

Note that the only thing the PRPA_IN201104 does is nullifying one Registration, and identifying another registration as its replacement. Registrations are being merged. At the business process level the sender and receiver may agree that this also means that the Role identifiers (of the payloads of these registrations) have been merged. The static model however does NOT in any way describe this. If your interactions have such implied/hidden assumptions about linking/merging payload Roles than this better be documented in the Storyboards of the domain as well as in the documentation of the interactions.

The PatientLivingSubject interaction Resolve Duplicate Person Registrations (PRPA_IN101004) focuses on registration acts, and does not talk about the linking of payloads, nor of the nullification of the "old" payload. It does however state that (after the resolve duplicates interaction) "A copy of the surviving person record is sent in a Revised Person message (PRPA_MT101002)." (i.e. you have to update the person record with the new merged ID as an OtherId). This documents the additional workflow expectations above the simple merging registrations.

Master Registry Entry

This section is absed on use of a PatientLivingSubject Registry, a.k.a. an MPI.

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.

It is assumed that all MPIs create a "Master Registry Entry" to link one or more registrations. In our scenario: 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 (which are modelled as OtherIDs in the PatientLivingSubject models).

• The ID as used by the MPI for this "Master Registry Entry" is mostly a new one created by the MPI (e.g. 98), but it could also re-use one of the identifiers of the patient, e.g. a national patient identifier. The receiver of MPI messages should therefore consider the entire list comprised of (PatientRole.id 1..1, OtherIDs.id 0..*) to be identifiers for roles of the playing person, PatientRole.id should not be ignored (even though mostly it is an MPI internal ID).

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. All messages sent by the MPI, in the form of query responses or otherwise, contain the "Master Registry Entry".

Frequently asked questions about MPI:

• 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, and not the registry entries as created by A and B.
• What is returned if one sends a query with the OtherIDsScopingOrganization query parameter valued to contain A? The Master registry Entry is returned, with the ID as used by the MPI in PatientRole.id (in our example scenario: 98), and one single occurence of the OtherIDs class (containing the ID as used by scopingOrganization A, in our example scenario: 5). The scoper of the OtherIDs class is specified to be A.
• If Patient Identity Source B is a subscriber to updates for the patient with ID 22 (probably triggered by the fact that Patient Identity Source B orginally registered the patient), and Patient Identity Source A updates the address, what does Patient Identity Source B receive: an updated "Master Registry Entry" (with primary ID 98), or an updated version of its own registry entry (with primary ID 22)? It receives an updated "Master Registry Entry" (with primary ID 98).

Open issue: there is a use case where one would like to query for an ID according to a specific identification scheme (e.g. "givel my local ID 5, return the national paient identifier"). Currently there is no query parameter to support this. There is a workaround however: one can query for all identifiers and subsequently filter based on the root OID.