RADx® MARS: Identifying Unique Test Results for Purposes of De-duplication

Share:

EmailFacebookLinkedInXWhatsAppShare

Problem statement

Applications may be configured to send test results to multiple intermediary destinations, which may then relay the results to common final destinations. The final destinations may then have duplicates of the same test results. Test results need to be "de-duplicated" to avoid erroneously counting the same test result multiple times.

For instance, a mobile application may send a test result to APHL and to USDS Report Stream. APHL then relays the result to a specific State (e.g. Michigan State). The State health system and Report Stream then relay the result to HHS Protect. Data analysts in the HHS Protect Team need to know how to identify the duplicates

Key elements to encoding test results in the HL7v2 message

An App is assigned a unique App-specific identifier (Assigner OID)

These identifiers can be assigned by an authorized entity. For the purposes of mobile applications reporting COVID testing results, APHL has set up a mechanism to assign these identifiers. The identifiers are included in multiple locations of the HL7v2 message, and all can be the same value:

Table 1: App-specific identifiers assigned by authorized entity. All can have the same value.

Field HL7v2 Element
Sending system OID MSH-3.2
Sending facility ID MSH-4.2
Filler Order Number Assigner OID OBR-3.3
Filler Order Number Assigner OID ORC-3.3
Patient ID Assigner PID-3.4.2
Specimen ID Assigner OID SPM-2.2.3

 

The App creates an identifier for each user

It is the responsibility of the App developer to create an ID for each user of the App. This ID needs to be unique to the App, but does not need to be globally unique.

Table 2: Patient ID generated by each App is unique to App but need not be globally unique

Field HL7v2 Element
Patient ID PID-3.1

 

Acceptable scenario:

Acceptable scenario: Two Apps assign same ID to same person or different IDs to same person

  Person A Person B
App 1 ID: 1 ID: 2
App 2 ID: 1 ID: 2
App 3 ID: 2 ID: 3

 

Unacceptable scenario:

Unacceptable scenario: Same App assigns same ID to two persons

  Person A Person B
App 1 ID: 1 ID: 1
App 2 ID: 2 ID: 2

 

The App creates an identifier for each instance of a test taken

It is the responsibility of the App developer to create an ID for each instance of a test taken. This Specimen ID is unique not to the type of test taken, but to each instance of the test taken (each sample provided). This ID needs to be unique to the App, but does not need to be globally unique.

Table 3: Specimen ID generated by App is unique to each instance of test taken

Field HL7v2 Element
Specimen ID SPM-2.2.1

Test result de-duplication process

Sending and receiving systems should abide by these rules:

  1. Sending systems should create an internally unique ID for each patient and specimen (Tables 2,3)
  2. Sending systems should never re-use IDs over time
  3. Receiving systems should store app-specific identifiers (Table 1) in addition to the patient and specimen IDs (Tables 2,3)

Assuming these rules are followed, two test results arriving in a destination system can be determined to have originated from the same source and same event when the two test results have the same:

  1. Specimen ID assigner AND
  2. Specimen ID

For example, the following messages can be determined to be from the same test result even though they were sent from different intermediary systems:

Although sent through different intermediary systems, these two messages represent the same result

Same patient, same testing instance Intermediate System Source of message in HHS Protect

Specimen ID Assigner OID
(SPM-2.2.3)

Specimen ID
(SPM-2.2.1)

App A sends result to: State health system A 1
App A sends result to: USDS Report Stream A 1
EmailFacebookLinkedInXWhatsAppShare