TEST: OHIE-CR-09-FHIR
Patient Merge Governance / Security Enforcement
Last updated
Was this helpful?
Patient Merge Governance / Security Enforcement
Last updated
Was this helpful?
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.
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 appropriate MASTER
record. Clients which make these calls are required to have the Write 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 the Merge 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 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
.
Prior to running this test ensure that the pre-conditions from and have been run.
The test harness authenticates against the SanteMPI IdP using a client_credentials grant for the test-harness-a account.
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
in http://ohie.org/test/test_a
Identifier NID090
in http://ohie.org/test/nid
Name: BLOCKED MERGE JONES
Gender: Female
DOB: 1989-02-12
Requirement
Option
Description
MUST
PMIR Only
Return MessageHeader with response.code = ok
MUST
Return HTTP code of 201 Created
SHOULD
PMIR Only
Include an OperationOutcome entry in the response
SHOULD
Include a Patient entry in response containing created patient
SHOULD
Include a link to the master identity with code refer
The test harness authenticates against the SanteMPI IdP using a client_credentials grant for the test-harness-a account.
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
in http://ohie.org/test/test_b
with use official
Identifier NID091
in http://ohie.org/test/nid
Name: BLOCK MERGE JONES
Gender: female
Requirement
Option
Description
MUST
PMIR Only
Return MessageHeader with response.code = ok
MUST
Return HTTP code of 201 Created
SHOULD
PMIR Only
Include an OperationOutcome entry in the response
SHOULD
Include a Patient entry in response containing created patient
SHOULD
Include a link to the master identity with code refer
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).
Requirement
Option
Description
MUST
Return HTTP code of 422 UNPROCESSABLE ENTITY or 400 BAD REQUEST or 403 FORBIDDEN
MUST
Return a Bundle
with a MessageHeader
carrying a response
code of fatal-error
MUST
Carry an OperationOutcome
resource which indicates that the merge could not be completed due to invalid authority to merge.