Merge, Link and Unlink Use Cases for Immunization I G v2.8.2

HL7 Public Health Workgroup

Alean Kirnak

Abdul Malik Shakir

DRAFT

4/9/20

 

 


Instructions from Provider A involving only Provider A data

Below, “identity” refers to a record with an identifier that refers to a single individual person.  Use Cases 1.1-2.1 are illustrated below:

 

Merge

Use Case 1.1:  Provider A discovers they created two identities (records) for a single individual person.   The word “duplicate” will be applied to this situation.  Provider A merges them in their EHR. 

Use case 1.2:  Provider A sends a “merge” ADT to the IIS.

Use case 1.3:  IIS follows the HL7 definition of a “merge” operation to merge the two records, resulting in one surviving and one non-surviving record.

The drawing below introduces actors of Use Cases 1.1 and 1.2:

These illustrate Use Cases 1.1 and 1.2:

 

Split

Use Case 2.1:  Provider A discovers they erroneously created a single identity for two individual people.  Since no unmerge operation is defined, they must manually split the records by the following steps: 

  1. Create a second identity for the second individual person.
  2. Associate the correct data for person #2 into identity #2.
  3. Delete the data for person #2 from identity #1.

Use case 2.2:  Provider A sends two messages to the IIS: 

  1. Update person #1’s record;
  2. Create person #2’s record.

Use case 2.3:  IIS processes the messages.

Link

Use case 3.1:  Provider A has two legitimate records for the same patient.  This can happen if the enterprise has two or more systems generating records (for example, at different subsidiaries) which it links in an enterprise Master Person Index (MPI).  Provider A links them internally. 

Use case 3.2:  Provider A sends a “link” instruction to the IIS. 

Use case 3.3:  The IIS response is determined by local business rules:

  1. An IIS that implements a link operation will link the two records by associating both of them with an internal, IIS-generated identity, as per the HL7 definition of a link.
  2. Alternatively, an IIS may merge the two records as per Use Case 1.3.

Unlink

Use Case 4.1:  Provider A has two records which it determines it has erroneously linked.  This can happen if the enterprise has two or more systems generating records (for example, at different subsidiaries) which it links in an enterprise Master Person Index (MPI); and it makes a matching error.  Provider A unlinks them internally. 

Use Case 4.2:  Provider A sends an “unlink” instruction to the IIS. 

Use Case 4.3:  The IIS response is determined by local business rules.

  1. An IIS that implements an unlink operation will unlink the two records by removing the one record from the linked group containing the second record, as per the HL7 definition of a link.
  2. An IIS that does not implement an unlink instruction may flag the record for manual split, similar to Use Case 2.1.
  3. Alternatively, an IIS may simply delete the identity containing the erroneously linked records.

Instructions from Provider A involving Provider A info and IIS info

Provider discovers IIS should link its patient to another IIS record

EHR user discovers that one of its identities should be linked to a particular IIS identity to which it is not presently linked.  To determine this, it might have done a demographic query – see Query/Update Activity Diagram.   (The query is implemented by IHE PDQ, which is QBP,  or IG query which is also QB P).   It gets back a list of candidate matches.  It finds the one IIS identity to which its identity should be linked. 

Provider sends a link message to IIS specifying the ID of its own record, plus the identifier of the record from which to unlink.  This identifier can be in the form of the IIS  “global ID” or in the form of an assigning authority/ID of a local ID in the group to link to.   IIS response is locally defined.

Provider discovers IIS should unlink its patient from an IIS group of linked records

EHR user discovers that one of its identities has been wrongly linked to a particular IIS identity.   It might infer this from wrong data being mixed into the IIS record, or it might discover the list of identifiers to which its record is linked via a PIX Query, which returns the list of linked <assigning authority/ID> pairs; then use each returned link to query and examine the linked records.

Provider sends an unlink message to IIS specifying the ID of its own record, plus the identifier of the record from which to unlink.  This identifier can be in the form of the IIS  “global ID” or in the form of an assigning authority/ID of a local ID in the group to link to.   IIS response is locally defined.