TEST: OHIE-CR-04-FHIR
Patient Identity Feed - Blocks Inappropriate Assigner
This test ensures that an assigner cannot inappropriately attempt to assign an authoritative (official) identity for a domain which it does not have appropriate authority to do so.
References
Discussion
In a jurisdictional MPI environment, it is important that a centralized client-registry or MPI govern the issuance and trust of identity for certain domains. For example, a national health identifier registration submitted by the NHID authority / software may be indicated as an "authoritative" source whereas a new NID submitted by an EMR might be "informative".
SanteMPI provides mechanisms for two types of identity domains:
Open Identity Domains - Whereby any caller from any source can freely assign new identifiers in that domain (for example: in use cases where the DLN authority is not directly integrated to the MPI you can allow any EMR to assign / register a DLN)
Protected Identity Domains - Whereby only the registered source for identities in that domain can assign new identifiers and be authoritative. For example, only the national health insurance provider may notify the MPI/CR about new health insurance numbers, or only Hospital A can notify the CR about official identifiers form Hospital A.
When protected identity domains are used, other sources may provide identifiers in protected domains, however they are treated as informative rather than "official" authoritative sources. This information can be taken into consideration when weighing a candidate match. Additionally, non-authoritative sources can link their own records with existing identifiers in a protected identity domain.
Pre-Conditions / Setup
Create TEST_A Domain
Create an AssigningAuthority domain which has the following attributes:
URL of http://ohie.org/test/test_a
OID of 1.3.6.1.4.1.52820.3.72.5.9.2
Device TEST-HARNESS-A with authoritative source for identifiers
SanteMPI Seed Data
Create TEST_B Domain
Create an AssigningAuthority domain which has the following attributes:
URL of http://ohie.org/test/test_b
OID of 1.3.6.1.4.1.52820.3.72.5.9.3
Device TEST-HARNESS-B with authoritative source for identifiers
SanteMPI Seed Data
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-040
inhttp://ohie.org/test/test_a
with useofficial
Name: JENNIFER JONES
Gender: Female
DOB: 1984-01-25
The patient is being sent from a source with the expectation that the information is scoped from the worldview of the sender. So the sender may use an MRN or Patient Internal Identifier (PI) as the "official" identifier for the patient in its own world, which may (or may not) match the view of the patient from the jurisdictional worldview.
Expected Behaviour
Validate Patient Created
The test harness executes a query against the receiver to ensure the record was created domain
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-b account.
Attempt to Register New Patient Identity in TEST_A
The test harness sends a registration message to the receiver, attempting to incorrectly register a new official identifier in the TEST_A domain (an identity domain for which it does not have authority to assign new identities).
Identifier
FHRB-041
inhttp://ohie.org/test/test_b
with useoffical
Name: JENNIFER DOE
Gender: Female
DOB: 1989-01-25
Expected Behaviour (Option 1 - Rejection / Strict)
If the receiver is behaving in a strict mode (i.e. emulating the behavior from HL7v2), then.
Expected Behavior (Option 2 - Flag as Informative)
If the receiver is operating in a mode that is lenient for identity domains, it should process the message and flag the identifier as informative.
Attempt to Register New Patient Identity in TEST_B with existing Identity in TEST_A
The test harness sends a registration for a new patient in its own identity domain where the patient has an existing identity in another protected domain.
This mimics a use case where TEST B is registering a patient on a referral that came from TEST A or where TEST A is, in fact, a health insurance number or some other identifier domain from an official source.
Identifier
FHRB-042
inhttp://ohie.org/test/test_b
with useofficial
Identifier
FHRA-040
inhttp://ohie.org/test/test_a
with useusual
Name: JENNIFER JONES
Gender: Female
DOB: 1984-01-25
Expected Behaviour
Validate Patient Created / Linked
The test harness executes a query against the receiver to ensure the record was created domain
Expected Behaviour
Last updated