Orchestrate - Identity Lite
While the Identity API traditionally services large scale patient populations, the same proven and trusted privacy-preserving record linking (PPRL) technology is also available for smaller populations of less than 100,000 patients, at the click of a button.
How Identity Lite Works
Identity Lite performs a matching operation on a batch of records, applying the Identity API’s record matching algorithm to link records from the same individual. Unlike the full Identity API, each batch is treated as an atomic operation. No data (hashed or unhashed) is stored on the Identity server, and records from one batch will not be linked with records from any prior or future batch.
Before matching records, Identity Lite performs an irreversible cryptographic hash operation on the demographic data with a randomly generated salt. This is effectively the same as the privacy-preserving (“blinded”) mode of the full Identity API. All matching processes use the hashed values, thus blinding the data. See How Identity Secures Data for more details on how the hashing algorithm works.
The process begins when you load the batch of records into Identity Lite’s web app or command-line (CLI) tool. Regardless of which version you use, Identity Lite will:
- Hash the data.
- Send the hashed data to the Identity API for matching.
- Return your original data with a
PersonID assigned to each record. Records from the same person will share the same PersonID.
Tip
Hashing is performed on your local machine (either in the browser or in the CLI tool). Unhashed data never leaves your computer. A new randomly-generated hash key is used for each batch.
For example: the General Hospital Sleep Study program has records from its own app (capturing patient-reported outcomes) as well as clinical records from a partnering health system. The program wishes to link clinical records and app records for the same individual. There may be multiple records for a single person, with any combination of app or clinical data. Identity Lite will process the entire batch of records (both clinical and app data) in a single operation and assign a PersonID to each record. Mary and Robert’s records receive the same ID, even though they’re from different sources.
| Data Source |
First Name |
Last Name |
PersonID |
| App |
Mary |
Smith |
1 |
| App |
Jack |
Twinsy |
2 |
| App |
Jace |
Twinsy |
3 |
| App |
Robert |
O’Blue |
4 |
| Clinical |
Robert |
O’Blue |
4 |
| Clinical |
Mary |
Smith |
1 |
| Clinical |
bob |
O’Blue |
4 |
Note: The above is just a simplified example to illustrate the matching process. First/last name alone is not sufficient for a match, and PersonID is returned as a GUID, not an integer value.
Data Limits
Identity Lite supports up to 15,000 records via the web app and up to 100,000 records via the command line tool.
Plan Usage
Your account plan usage will be charged based on how many records are processed.
Batch Processing Considerations
Because Identity Lite is an atomic operation, no data is stored on the server and each batch is treated as a self-contained data set. This has a few noteworthy implications:
- You cannot match records across different batches, even if they belong to the same individual.
- If you process the same batch of data multiple times, you will get different
PersonID values each time.
Thus, if you have new or updated records, you will need to re-submit the entire batch and get new PersonID values for everyone.
See the following article for detailed instructions on how to use the Identity Lite tools: