Figure 2:3.104.4-1: Interaction Diagram

A Patient Identity Source notifies the Patient Identifier Cross-reference Manager that a patient has been added or revised in the Patient Identity Source. The Patient Identity Source notifies the Patient Identifier Cross-reference Manager that duplicate records were resolved in the Patient Identity Source. If the Remove Patient Option is supported the Patient Identity Source notifies the Patient Identifier Cross-reference Manager that a patient record was removed in the Patient Identity Source.

2:3.104.4.1 Add or Revise Patient

This message is implemented as an HTTP conditional update operation from the Patient Identity Source to the Patient Identifier Cross-reference Manager described in Section 2:3.104.4.1.2 Message Semantics.

2:3.104.4.1.1 Trigger Events

The Add Patient message is triggered when a new patient is added to a Patient Identity Source.

The Revise Patient message is triggered when the patient information is revised within a Patient Identity Source (e.g., change in patient name, patient address, etc.).

The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic on messages received from Patient Identity Source Actors.

2:3.104.4.1.2 Message Semantics

A Patient Identity Source initiates a FHIR request using Conditional Update as defined at http://hl7.org/fhir/http.html#cond-update on a Patient Resource.

A Patient Identity Source shall be able to send a request for either the JSON or the XML format as defined in FHIR. A Patient Identifier Cross-reference Manager shall be able to support the JSON and the XML format and support the conditional PUT operation.

The Patient Identity Source shall provide the identifier of the Patient Identification Domain of the Patient Identity Source.

For example:

The identifier for a patient with identifier IHERED-994 assigned by authority “1.3.6.1.4.1.21367.13.20.1000” would be represented as:

identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-994

If a FHIR server in the source domain with base http://fhir.mydomain.com is the assigning authority, a patient on that server with a Logical id of “123” the identifier would be represented as:

identifier=http://fhir.mydomain.com|Patient/123

2:3.104.4.1.2.1 Patient Resource constraints

The Patient Identifier Cross-reference Manager shall be capable of accepting elements specified in profile PIXm Patient: https://profiles.ihe.net/ITI/PIXm/StructureDefinition/IHE.PIXm.Patient. This is to ensure that the Patient Identifier Cross-reference Manager can handle a sufficient set of corroborating information in order to perform its cross-referencing function.

If a Patient Identifier Cross-reference Manager constrains or specifies additional elements (e.g., extensions), it shall constrain the PIXm Patient profile see example and reference this as a supportedProfile in the CapabilityStatement.

2:3.104.4.1.3 Expected Actions

The Patient Identifier Cross-reference Manager shall provide a CapabilityStatement with the capabilities interaction and indicate that conditionalUpdate is available on the Patient.

A Patient Identifier Cross-reference Manager shall support the Conditional Update based on the identifier parameter as outlined in http://hl7.org/fhir/http.html#cond-update. The identifier parameters carries either the Logical id or the business identifier as outlined in Message Semantics. The identifier parameter needs to be used for the cross-referencing.

The Patient Identifier Cross-reference Manager is not required to maintain a Patient resource, only to cross-reference provided identifiers.

The Patient Identifier Cross-reference Manager shall only recognize a single Patient Identity Source per domain.

The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient Identifier Cross-reference Manager, but its specification is beyond the scope of IHE.

Once the Patient Identifier Cross-reference Manager has completed its cross-referencing function, it shall make the newly cross-referenced identifiers available to PIX queries.

2:3.104.4.1.4 Response message

See http://hl7.org/fhir/http.html#cond-update for response.

2:3.104.4.1.5 Example

Add Patient Alissa Mohr:

PUT http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-994 HTTP/1.1
Accept: application/fhir+json
Content-Type: application/fhir+json

{
  "resourceType" : "Patient",
  "identifier" : [
    {
      "system" : "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
      "value" : "IHERED-994"
    }
  ],
  "active" : true,
  "name" : [
    {
      "family" : "MOHR",
      "given" : [
        "ALISSA"
      ]
    }
  ],
  "gender" : "female",
  "birthDate" : "1958-01-30"
}

Revise Patient Alissa Mohr with updated demographics (given name Alice instead of Alissa):

PUT http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-994 HTTP/1.1
Accept: application/fhir+json
Content-Type: application/fhir+json

{
  "resourceType" : "Patient",
  "identifier" : [
    {
      "system" : "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
      "value" : "IHERED-994"
    }
  ],
  "active" : true,
  "name" : [
    {
      "family" : "MOHR",
      "given" : [
        "ALICE"
      ]
    }
  ],
  "gender" : "female",
  "birthDate" : "1958-01-30"
}

2:3.104.4.2 Resolve Duplicate Patient

The Patient Identity Source notifies the Patient Identifier Cross-reference Manager that duplicate records were resolved in the Patient Identity Source.

This message is implemented as an HTTP conditional update operation from the Patient Identity Source to the Patient Identifier Cross-reference Manager described in Section 2:3.104.4.2.2 Message Semantics.

2:3.104.4.2.1 Trigger Events

A Resolve Duplicate Patient message is triggered when the Patient Identity Source does a merge within its Patient Identification Domain.

2:3.104.4.2.2 Message Semantics

A Patient Identity Source initiates a FHIR request using HTTP PUT as defined at http://hl7.org/fhir/http.html#cond-update on the duplicate patient record based on the identifier parameter.

In the Patient resource a link of type ‘replaced-by’ shall be added with the identifier pointing to the surviving patient identifier, see https://www.hl7.org/fhir/patient.html#dup-records.

A Patient Identity Source shall be able to send a request for either the JSON or the XML format as defined in FHIR. A Patient Identifier Cross-reference Manager shall be able to support the JSON and the XML format and support the conditional PUT operation.

2:3.104.4.2.3 Expected Actions

The Patient Identifier Cross-reference Manager shall provide a CapabilityStatement with the capabilities interaction and indicate that conditionalUpdate is available on the Patient.

When the Patient Identifier Cross-reference Manager receives the Resolve Duplicate Patient message it shall replace any references it is maintaining internally to the subsumed patient identifier with the patient identifier in the ‘replaced-by’ link.

After the identifier references are replaced, the Patient Identifier Cross-reference Manager shall reapply its internal cross-referencing logic/ policies before providing the updated information via the PIX Query transactions.

2:3.104.4.2.4 Response Message

See http://hl7.org/fhir/http.html#cond-update for response.

2:3.104.4.2.5 Example

Patient Maiden Alice has been subsumed by Patient Mohr Alice in the Patient Identifier Domain urn:oid:1.3.6.1.4.1.21367.13.20.1000. The HTTP conditional update operation is done with the subsumed identifier ‘IHERED-m94’ from Maiden Alice in the request and referencing the surviving identifier ‘IHERED-994’ of Patient Mohr Alice in the message:

PUT http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-m94 HTTP/1.1
Accept: application/fhir+json
Content-Type: application/fhir+json

{
  "resourceType" : "Patient",
  "identifier" : [
    {
      "system" : "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
      "value" : "IHERED-m94"
    }
  ],
  "active" : false,
  "name" : [
    {
      "family" : "MOHR",
      "given" : [
        "MAIDEN"
      ]
    }
  ],
  "gender" : "female",
  "birthDate" : "1958-01-30",
  "link" : [
    {
      "other" : {
        "identifier" : {
          "system" : "urn:oid:1.3.6.1.4.1.21367.13.20.1000",
          "value" : "IHERED-994"
        }
      },
      "type" : "replaced-by"
    }
  ]
}

2:3.104.4.3 Remove Patient

This message enables the removal of patient identity data if the Remove Patient Option is supported.

This message is implemented as an HTTP conditional delete operation from the Patient Identity Source to the Patient Identifier Cross-reference Manager described in Section 2:3.104.4.3.2 Message Semantics.

2:3.104.4.3.1 Trigger Events

A Removed Patient message is triggered when the Patient Identity Source has removed a patient within its Patient Identification Domain.

2:3.104.4.3.2 Message Semantics

A Patient Identity Source initiates a FHIR request using HTTP DELETE as defined at 3.1.0.7.1 Conditional delete on a Patient Resource based on the identifier parameter.

A Patient Identity Source shall be able to send a request for either the JSON or the XML format as defined in FHIR. A Patient Identifier Cross-reference Manager shall be able to support the JSON and the XML format and support the conditional DELETE operation if it supports the Remove Patient message.

2:3.104.4.3.3 Expected Actions

The Patient Identifier Cross-reference Manager indicates in the CapabilityStatement that conditionalDelete is available on the Patient if this message is supported.

When the Patient Identifier Cross-reference Manager receives the Remove Patient message, it shall remove any references it is maintaining internally to the patient identifier provided.

After processing the Remove Patient message, the Patient Identifier Cross-reference Manager shall not return the removed identifier in response to PIX Query transactions.

2:3.104.4.3.4 Response Message

See 3.1.0.7.1 Conditional delete for the response.

2:3.104.4.3.5 Example

Remove Patient Maiden Alice:

DELETE http://example.org/fhir/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED-994 HTTP/1.1
Accept: application/fhir+json

2:3.104.5 Security Considerations

See ITI TF-2: Appendix Z.8 “Mobile Security Considerations”, which includes guidance on the use of ATNA and IUA to protect the communication, access control, and audit logging.

The Patient Identifier Cross-reference Manager should check that the Patient Identity Source is only making changes to Patient Identifier Domain for which it is authorized.

2:3.104.5.1 Security Audit Considerations

The Security audit logging will conform to the RESTful interactions following IHE-BALP Basic Audit Logging Patterns.

2:3.104.5.1.1 Patient Identity Source Audit

The Patient Identity Source when grouped with ATNA Secure Node or Secure Application actor shall be able to record AuditEvents. The Patient Identity Source will log a Delete or Update. The Patient Identity Source can’t distinguish a Create from a Update.

• on an Update - PIXm Feed Update Source Audit Event Log.
  • Audit Example for a PIXm Feed Update transaction from source perspective.
• on a Delete - PIXm Feed Delete Source Audit Event Log.
  • Audit Example for a PIXm Feed Delete transaction from source perspective.

2:3.104.5.1.2 Patient Identifier Cross-reference Manager Audit

The Patient Identifier Cross-reference Manager when grouped with ATNA Secure Node or Secure Application actor shall be able to record AuditEvents. The Patient Identifier Cross-Reference Manager can distinguish a Create and Update so is expected to record Create and Update specifically.

• on a Create PIXm Feed Create Manager Audit Event Log
  • Audit Example for a PIXm Feed Create transaction from manager perspective.
• on an Update PIXm Feed Update Manager Audit Event Log
  • Audit Example for a PIXm Feed Update transaction from manager perspective.
• on a Delete PIXm Feed Delete Manager Audit Event Log
  • Audit Example for a PIXm Feed Delete transaction from manager perspective.

2:3.104.5.2 Use with the Internet User Authorization (IUA) Profile

The Internet User Authorization (IUA) Profile provides support for user authentication, app authentication, and authorization decisions. When PIXm actors are grouped with IUA actors there are additional security and privacy functionality enabled by this grouping. There are additional requirements and functionality enabled through scope definitions that are transaction-specific.

A Patient Identity Source, when grouped with an IUA Authorization Client, shall use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Identity Source, to provide notifications with the Patient Identity Feed FHIR [ITI-104] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72].

The Patient Identifier Cross-reference Manager, when grouped with an IUA Resource Server, shall require Incorporate Access Token [ITI-72] in all Patient Identity Feed FHIR [ITI-104] transactions, shall enforce the authorization decision in the token, and may further enforce policies beyond those made by the Authorization Server such as consent or business rules.

scope: ITI-104

This scope request authorizes the full [ITI-105] transaction. This scope implicitly request patient-specific Create/Update/Delete for Patient resources as defined in [ITI-104]. Further scope refinement is allowed in realm or project-specific situations; these scopes would be in addition to the scope defined here.

2:3.104.5.2.1 AuditEvent Augmentation

The Security audit logging interactions should be augmented following IHE-BALP Basic Audit Logging Patterns, to include agent details from the OAuth Security token.