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 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 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.

POST http://localhost:8080/auth/oauth2_token HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 94
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)


grant_type=client_credentials&scope=*&client_secret=TEST_HARNESS&client_id=TEST_HARNESS_FHIR_A

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 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

{
    "resourceType": "Patient",
    "id": "ohie-cr-09-10-fhir",
    "active": true,
    "identifier": [
      {
        "use": "official",
        "type": {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
              "code": "PI"
            }
          ]
        },
        "system": "http://ohie.org/test/test_a",
        "value": "FHRA-090",
        "assigner": {
          "display": "Test Harness A Patient Identity"
        }
      },
      {
        "use":"usual",
        "system": "http://ohie.org/test/nhid",
        "value":"NID090"
      }
    ],
    "name": [
      {
        "use": "official",
        "family": "JONES",
        "given": [
          "BLOCKED","MERGE"
        ]
      }
    ],
    "gender": "female",
    "birthDate": "1989-02-12",
  }

Expected Behaviour

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

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.

POST http://localhost:8080/auth/oauth2_token HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 94
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)



grant_type=client_credentials&scope=*&client_secret=TEST_HARNESS&client_id=TEST_HARNESS_FHIR_B

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 in http://ohie.org/test/test_b with use official

• Identifier NID091 in http://ohie.org/test/nid

• Name: BLOCK MERGE JONES

• Gender: female

{
    "resourceType": "Patient",
    "id": "ohie-cr-09-20-fhir",
    "active": true,
    "identifier": [
      {
        "use": "official",
        "type": {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
              "code": "PI"
            }
          ]
        },
        "system": "http://ohie.org/test/test_b",
        "value": "FHRB-090",
        "assigner": {
          "display": "Test Harness B Patient Identity"
        }
      },
      {
        "use":"usual",
        "system": "http://ohie.org/test/nid",
        "value":"NID091"
      }
    ],
    "name": [
      {
        "use": "official",
        "family": "JONES",
        "given": [
          "BLOCK","MERGE"
        ]
      }
    ],
    "gender": "female"
  }

Expected Behaviour

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

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).

{
  "resourceType": "Bundle",
  "type": "message",
  "entry": [
    {
      "fullUrl": "MessageHeader/ohie-cr-09-30-fhir",
      "resource": {
        "resourceType": "MessageHeader",
        "id": "1",
        "eventUri": "urn:ihe:iti:pmir:2019:patient-feed",
        "source": {
          "endpoint": "http://ohie.org/test/harness"
        },
        "focus": [
          {
            "reference": "Bundle/ohie-cr-09-30-fhir"
          }
        ],
        "destination": [
          {
            "endpoint": "http://ohie.org/test/endpoint/Bundle"
          }
        ]
      }
    },
    {
      "fullUrl": "http://ohie.org/test/Bundle/ohie-cr-09-30-fhir",
      "resource": {
        "resourceType": "Bundle",
        "id":"ohie-cr-09-30-fhir",
        "type": "history",
        "entry": [
          {
            "fullUrl": "http://ohie.org/test/Patient/ohie-cr-09-30-fhir",
            "resource": {
              "resourceType": "Patient",
              "id": "ohie-cr-09-20-fhir",
              "active": false,
              "identifier": [
                {
                  "use": "official",
                  "type": {
                    "coding": [
                      {
                        "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                        "code": "PI"
                      }
                    ]
                  },
                  "system": "http://ohie.org/test/test_b",
                  "value": "FHRB-090",
                  "assigner": {
                    "display": "Test Harness B Patient Identity"
                  }
                }
              ],
              "link": [
                {
                  "other": {
                    "type": "Patient",
                    "identifier": {
                      "value": "FHRA-090",
                      "system": "http://ohie.org/test/test_a"
                    }
                  },
                  "type": "replaced-by"
                }
              ]
            },
            "request": {
              "method": "PUT",
              "url": "Patient/ohie-cr-09-30-fhir"
            },
            "response": {
              "status":"200"
            }
          }
        ]
      }
    }
  ]
}

Expected Behaviour

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.