​ELR Auto-Importing in CalREDIE​

Everything You Want to Know About ELR Auto-Importing in CalREDIE

Updated September 13^th, 2024

What is Auto-Importing?

Auto-importing is a feature of the CalREDIE system that allows electronic lab results (hereafter “ELRs”) to bypass the Disease Incident Staging Area (“DISA”) and automatically process through to the main CalREDIE database. Auto-importing is primarily used for high-volume conditions with relatively simple workflows because it dramatically reduces a program’s workload at the expense of context-specific decision-making.

There are three possible outcomes for an auto-imported ELR, just like with manual importing:

• Creating a new patient and incident,
• Creating a new incident for an existing patient, or
• Attaching to an existing incident.

What conditions are set to auto-import?

As of January 2024, the following conditions are set to auto-import. Reinfection Periods and Workflows are explained further down in this document.

What matching criteria are used?

CalREDIE will attempt to match an incoming result to an existing person or person/incident using one of the following rules, in descending order:

1. Accession Number + Report Source*
2. First Name, Last Name, DOB, Gender + Disease + Within Reinfection Period
3. First Name, Last Name, DOB, Gender
4. SSN, DOB, Gender + Disease + Within Reinfection Period
5. SSN, DOB, Gender
6. Medical Record Number, Reporting Source, DOB, Gender + Disease + Within Reinfection Period
7. Medical Record Number, Reporting Source, DOB, Gender

If a match is made to a rule that includes the Disease criterion (and Reinfection, if applicable), the result will be attached to the matched incident. If a match is made to a rule that only contains patient matching criteria (i.e. a matching incident could not be found), a new incident will be created for the matched person. If no match is made at all, a new patient record AND disease incident are created. Most matching occurs on rules #2 and #3.

Please note that these criteria are extremely rigid, and require exact matches.

*This is a hardwired rule that looks for any incident in the system, regardless of patient name or disease condition, that contains an ELR with the same accession number from the same reporting source (i.e. laboratory). We stress to our submitting laboratories the importance of using unique accession numbers for each report to prevent false matching.

What is a re-infection period?

Certain conditions have an additional specification that limits potential incident matches based on the number of days difference between the incident’s Episode Date and the incoming ELR’s Specimen Collection Date. For example, if an incoming ELR finds a matching patient in the system, and that patient has a matching Gonorrhea incident from more than 31 days earlier, the ELR will not attach to it, but will instead create a new Gonorrhea incident for this person. This is useful for acute conditions where multiple, discreet infections are common. Meanwhile, other conditions like Chronic Hepatitis B do not use a re-infection period, meaning that an incoming report will attach to any Chronic Hepatitis B incident for a matched person, regardless of dates.

You can see whether a disease has a re-infection period (and if so, what it is) in the table above.

Note that re-infection periods are bidirectional, meaning that for a disease condition with a 31-day re-infection period, the incoming ELR’s Specimen Collection Date would need to be within 31 days after OR before the incident’​s Episode Date.

How does auto-importing interact with Process Status, Resolution Status, and Jurisdiction?

Because Process Status, Resolution Status, and Jurisdiction are set at the incident level, there are two different scenarios to discuss: when a new incident is created, and when an ELR attaches to an existing incident.

When creating a new incident

Process Status

Incidents created by auto-imported ELRs will always apply the first status of the workflow used for that condition. For most conditions, this is “Entered.” However, there are some conditions which will use "Closed by LHD – ELR". You can see what each condition uses in the table above. Please note that "Closed by LHD – ELR" is not a true "Closed" status in CalREDIE, meaning that incidents at this status will still be editable.

Resolution Status

Incidents created by auto-imported ELRs will always apply a Resolution Status of “Suspect.”

Jurisdiction

Incidents created by auto-imported ELRs will always be assigned to the jurisdiction of the geolocated patient address. When that address cannot be geolocated, the system will fall back on the geolocated Ordering Provider address. If this also cannot be geolocated, the incident will be assigned to “Unknown” jurisdiction, and the CalREDIE Help Desk will review and reassign based on available demographic information.

Keep in mind that a new incident can be created for a patient in one jurisdiction, even if all their prior incidents belong to other jurisdictions. Patient Records belong to all system users and are not LHJ-specific.

When attaching to an existing incident

The auto-importing feature does not consider the Process Status, Resolution Status, or Jurisdiction of incidents when determining an incident match, or any detail other than the patient-matching fields, Disease, and Episode Date.

For example, it is possible that a positive COVID-19 result belonging to Orange County could attach to a COVID-19 incident belonging to San Bernardino and set to “Closed by LHD” and “Not A Case,” as long as the patient demographic info matches and the ELR is within the incident’s re-infection period.

Furthermore, ELRs which auto-attach to existing incidents will never change any existing data on the Case Investigation Tab of that incident. To use this same example, this new positive ELR belonging to Orange will not update the Process or Resolution Status of the incident, nor will it change the LHJ from San Bernardino to Orange. Effective ownership of that ELR would pass to San Bernardino.

How are demographics reconciled with auto-importing?

Whenever an ELR is imported into an existing patient or patient/incident, there is a question of reconciliation: what do we do with the existing patient demographics in CalREDIE, and what do we do with the new demographics on the ELR? In CalREDIE, there are four demographic reconciliation options:

1. Add Multiple Demographics
2. Create New Person Version
3. Correct Current Person Version
4. Discard Incoming Demographics

First, we will explain what these options do. We can then proceed to explain when they are selected during the auto-processing process.

Add Multiple Demographics

What does it do?

This option takes the demographic information from the ELR and stores it in the Multiple Identities/Multiple Addresses sections of the existing, matching disease incident. These sections can be accessed by clicking the buttons to the right of the Age/Months/Days (Multiple Identities) and Zip (Multiple Addresses) fields. Effectively, this is a way to store multiple information for patients, such as multiple addresses or multiple phone numbers. It does not overwrite or add any information on the Patient Tab.

When is it used?

This option is used 100% of the time when attaching an ELR to an existing disease incident, but will never be used when a new incident is created.

Create New Person Version

What does it do?

True to its name, this option creates a new person version for the patient record. The prior “current version” information becomes a non-current version. This allows a new incident to contain the demographics from the ELR, while historical incidents remain untouched.

When is it used?

This option is only ever used when a new incident is created for an existing patient. In those situations, it is used when key Demographic fields on the ELR are populated with non-Null data different from the existing Current Version. In other words, when there is an apparent contradiction between the demographic information on the ELR and the demographic information in the current person version in CalREDIE. An example might be if the ELR has a different home phone number than what appears in CalREDIE.

This is the case approximately 70% of the time when a new incident is created for an existing patient.

Correct Current Person Version

What does it do?

This option will overwrite fields on the current person version with non-Null content from the incoming ELR, but will retain data from the current person version if the corresponding field on the ELR is blank. For example, if an incoming report has an address but no phone number, and the current person version has a different address but does have a phone number, the current person version will have its address updated but the original phone number is retained.

When is it used?

This option is only ever used when a new incident is created for an existing patient. In those situations, it is used when non-key Demographic fields on the ELR are populated with non-Null data different from the existing Current Version. In other words, when a minor piece of information (like the middle name) is present on the ELR but not in CalREDIE.

This is a very rare selection, used less than 1% of the time.

Discard Incoming Demographics

What does it do?

This option throws away the demographic information from the ELR, and defers to whatever is already in the current person version of the patient record.

When is it used?

This option is only ever used when a new incident is created for an existing patient. In those situations, it is used whenever the ELR contains no demographic information that is not already present in the existing current person version.

This is the case approximately 30% of the time.

Additional Frequently Asked Questions

What happens when there are multiple results on the same rep​​​ort?

Each of the results will be parsed out and processed individually. If the results are for the same condition, they will almost-certainly all end up in the same incident. If the results are for distinct conditions, each will be imported into—or as—a distinct incident. However, all results on that report will be visible from each incident.

For example, a panel test with three results for Flu, COVID, and RSV will generate three unique ‘records’ in CalREDIE, which will each process separately. Each of these records will either attach to or create an incident of the respective condition. However, all three results will be visible on the lab report of the Electronic Filing Cabinet (EFC) of each incident.

Will a non-positive result attach to a positive incident?

It depends on the condition, but typically no. Most non-positive results are not reportable, and are typically not sent to CalREDIE (or are suppressed). Reportable non-positives, such as for RSV, usually have their own disease condition in CalREDIE, which keeps positive and negative results separate. However, there may be some edge cases where a non-positive is incorrectly coded as positive and will attach to the incorrect condition.

Are Web Reports auto-imported?

No.

If there are duplicate patients or incidents in CalREDIE, into which will the incoming ELR attach?

The best rule of thumb is that it will choose the earliest, best match. See the scenarios below to learn more.

One matching patient record, two matching incidents

Uses the earlier of the two incidents based on incident’s “Date Create” field

Two matching patient records, one matching incident in each

Uses the earlier of the two incidents based on incident’s “Date Create” field

Two matching patient records, only one has a matching incident

Uses the matching incident rather than create a new incident for the other patient​

Two matching patient records, no matching incidents

Uses the earlier of the two patient records based on the patient’s “Date Create” field

Why am I seeing duplicates?

If you are seeing duplicate patients, each with their own incident, it is likely because the ELR failed to match to the patient on one of the matching criteria specified above. As a result, a new patient was created, and a new incident along with it. This is probably due to a typo, or a misspelling, the use of a nickname, the use of a maiden/hyphenated name, a missing gender, or a mismatched date of birth.

If you’re only seeing duplicate incidents within a single patient record (less common), it could be because:

1. The existing incident and ELR were assigned to distinct conditions at the time of import
2. If the condition uses a re-infection period, the ELR and incident were outside of the date range
3. There were duplicate patients, but were merged
4. Other, uncommon reasons

I’ve heard people mention Advanced Auto-Importing, what is that?

Advanced Auto-Import Rules (“AAIR”) are a new feature with CalREDIE v19 which allows us to customize the auto-importing process with significantly more precision. This includes everything from advanced person matching, LHD opt-out, and specific actions/routing based on the content of the incoming message and its relevant matches in CalREDIE. As such, much of the above guidance does not apply to AAIR.

This feature is slowly being rolled out to disease conditions upon state program request, as it requires substantial testing and development.​​