TEST: OHIE-CR-09-FHIR
Patient Merge Governance / Security Enforcement
This test ensures that the Client Registry is capable of protecting identities from being merged/manipulated by sources which do not have authority over the records. For example, if HOSPITAL_GREEN
instructs the Client Registry to merge records from HOSPITAL_RED
, the Client Registry should block/prevent the merge from occurring, or should take on appropriate alternate actions.
This test is based on governance rules rather than syntactic or semantic interpretation of a message. Therefore, some Client Registries or deployments may permit the actions and cross-domain merges of patient identity.
Discussion
It is generally bad practice to allow clients full control over merging/de-activating records on the server since this requires each client communicating with the PMIR service to properly implement and govern merges. SanteDB has three different types of merge:
LOCAL>MASTER: In which a flagged candidate
LOCAL
record is reconciled and linked/merged with an appropriateMASTER
record. Clients which make these calls are required to have theWrite MDM Master
permission.LOCAL>LOCAL: In which a client indicates that a registration they have previously sent is a duplicate of another record they had previously sent. This action requires no special permissions and is the default method of using a
replaces
link.MASTER>MASTER: In which two golden or
MASTER
records are merged. This process includes the migration of all local references, and the record from truth from one master (the victim) to another (the survivor). Generally this merge is not permitted by clients unless theMerge MDM Master
permissions is granted (which is bad practice as it bypasses all governance controls on the server).
These merge strategies and the conditions under which they are permitted are described in the Master Data Management architecture article.
Furthermore SanteDB requires establishing ownership over a particular LOCAL
record in order to determine if a source is permitted to merge two records. Generally, source HOSPITAL_A
is only permitted to indicate merges of data only submitted from HOSPITAL_A
and should not allow HOSPITAL_B
records to be merged into HOSPITAL_A
.
Pre-Conditions
Prior to running this test ensure that the pre-conditions from TEST: OHIE-CR-04 and TEST: OHIE-CR-06 have been run.
Authenticate as TEST_HARNESS_FHIR_A
The test harness authenticates against the SanteMPI IdP using a client_credentials grant for the test-harness-a account.
Register New Patient Identity in TEST_A
The test harness sends an authenticated request to create a new patient with a new identifier in TEST_A domain. Patient details:
Identifier
FHRA-090
inhttp://ohie.org/test/test_a
Identifier
NID090
inhttp://ohie.org/test/nid
Name: BLOCKED MERGE JONES
Gender: Female
DOB: 1989-02-12
Expected Behaviour
Authenticate as TEST_HARNESS_FHIR_B
The test harness authenticates against the SanteMPI IdP using a client_credentials grant for the test-harness-a account.
Register New Patient Identity in TEST_B
The test harness sends an authenticated request to create a new patient with a new identifier in TEST_B domain. Patient details:
Identifier
FHRB-090
inhttp://ohie.org/test/test_b
with useofficial
Identifier
NID091
inhttp://ohie.org/test/nid
Name: BLOCK MERGE JONES
Gender: female
Expected Behaviour
Attempt Cross-Domain Merge
In this test step, the test harness will attempt (while authenticated as TEST_HARNESS_FHIR_B
) to merge the record created by another sender. This type of merge is generally not permitted from a data governance perspective (as harness B would have no authoritative control over data from harness A).
Expected Behaviour
Last updated