Result Routing and Matching

Lab Network receives results from connected laboratories, identifies the originating order, provider, and organization, and validates the patient before posting each result to a chart. Whether the patient on the result matches the patient on the order decides which patient the result lands on and whether it reaches your system.

Solicited and Unsolicited Results

Every result arrives in one of two situations, and the difference shapes how Lab Network handles it.

• Solicited: The order was placed through Lab Network, so the result carries a Lab Reference ID that ties it to that order.
• Unsolicited: The order was not placed through Lab Network, so there is no order to trace. Lab Network identifies the ordering provider from the result and searches the organization for the patient.

Identifying the Order, Provider, and Organization

Before validating the patient, Lab Network identifies the order, provider, and organization for each result, in a fixed sequence: the originating order, then the provider, then the organization.

A Lab Reference ID is the identifier Lab Network assigns when an order is placed through it. A result that carries one traces back to the originating order, the most reliable identification path, and the order supplies the provider and organization. Identifying the order routes the result to the correct organization; it does not link the result to the order. Linking happens later, only after the patient is validated.

When a result does not have a Lab Reference ID, Lab Network identifies the ordering provider from the result. When the provider belongs to more than one organization, or cannot be matched, Lab Network also uses the account number, plus any provider-level account details the laboratory supplies, to resolve the provider and organization.

Validating the Patient

Before posting a result, Lab Network compares the patient on the result against the patient on the order on the following: first name, last name, date of birth, sex, and the patient identifier on the message. Matching is not an exact, character-for-character comparison: minor formatting differences do not by themselves cause a mismatch. However, nicknames and aliases are not expanded, so a result that uses a nickname will not match a patient recorded under a different given name. When both records specify a sex and the values differ, the patient does not match. A missing or unknown value on either side does not rule a patient out.

When the result and the order identify the same patient, the result posts. When they do not, Lab Network treats the result as a normal result and routes it by its own demographics rather than posting it to the order's patient.

Searching Your Organization for a Patient

When there is no order to compare against, or the patient on the result does not match the order, Lab Network searches your organization instead.

That search checks the patient identifier your organization supplied on the message first. When the identifier resolves to a patient already in your organization, matching stops there.

Otherwise, Lab Network searches on first name, last name, date of birth, and sex, and the result must carry at least one of postal code, phone number, or Social Security number for that search to run at all. A result carrying none of the three is treated as not found, however accurate its name and date of birth are, and Lab Network creates a new patient instead. Date of birth tolerates a difference of a single day before it counts against a match.

When several records match, Lab Network files the result under one of them, because multiple matching records are treated as duplicates of the same person rather than as competing candidates.

Outcomes: Posting, Linkage, and Delivery

The comparison produces one of three outcomes, and each decides where the result is filed and whether it reaches your system.

• The patient matches: Lab Network files the result under that patient and posts it to the chart. For a solicited result, it also links the result to the order. The result is delivered through your FHIR Subscription and by fax.
• The patient does not match, and the result has complete demographics: When the result carries a complete date of birth and a first and last name, Lab Network matches it to an existing patient or creates a new patient, files the result, and delivers it through your FHIR Subscription and by fax. This applies both to a solicited result whose patient fails to match the order and to an unsolicited result with no match in the organization. The result does not post to the order's patient and is not linked to the order.
• The result cannot be placed: When the demographics are incomplete, or no provider, organization, or patient can be resolved, Lab Network holds the result in the Unassigned Queue for manual review and records a reason. A held result does not post to any chart and does not reach your system through your FHIR Subscription or by fax; review it in the Lab Network UI.

Demographic validation is more than a safeguard because a mismatch re-routes the result to the patient its own demographics indicate. The demographic comparison determines which patient your outbound DiagnosticReport is filed under and whether the result is delivered at all.

When a result's demographics do not match the order, Lab Network may create a new patient and deliver the result under it, with a Health Gorilla identifier your system has not seen before. Because that identifier is new to your system, your system should match the result by its demographic fields rather than by the identifier.

Duplicate Patient Records

Because a result whose demographics do not match an existing record produces a new record, repeated differences in how a patient's details arrive can produce several records for one person.

The most mechanical cause is a result that carries none of postal code, phone number, or Social Security number. Lab Network will not attempt a demographic search without at least one of them, so it creates a new record however accurate the name and date of birth are. Results that consistently arrive without those fields generate a duplicate for every patient.

Beyond that, the common causes are:

• A given name that arrives shortened on some results and in full on others
• A date of birth that differs by a digit or is transposed
• A patient identifier that is absent from some messages, or that changes
• A name change reflected in some sources and not others

A separate cause has nothing to do with the inbound message: when your organization already holds more than one record for the same person, a result that matches several of them is filed under one, which may not be the record your staff expect.

Merging Duplicates

Lab Network does not reconcile duplicate patient records automatically. A record created by a mismatch stays separate until it is merged. Merging is available to you in the Health Gorilla portal, and your administrators can merge records for your own organization. Health Gorilla can also perform merges on request, which is worth using when the duplicates are numerous or span a long period.

Merging is worth doing periodically rather than case by case, because each unmatched result adds a record and the same underlying difference tends to recur.

Reducing Duplicates at the Source

The most effective step is improving what reaches Lab Network on the inbound message. Results that carry a consistent patient identifier, a complete date of birth, a full legal given name, and at least one of postal code, phone number, or Social Security number match existing records far more often. Where you control what a laboratory sends, or can ask a laboratory to change it, those fields matter most.

Duplicates, Repeats, and Corrections

Separately from duplicate patient records, a laboratory often sends the same result more than once as it moves through its lifecycle. Lab Network recognizes these repeat transmissions and updates a single record instead of accumulating duplicates.

Identifying a Result

Lab Network identifies each result by the identifier the laboratory assigns to it, which is unique to that laboratory. When a laboratory re-sends a result Lab Network has already stored, Lab Network updates the existing record instead of creating a duplicate.

The Result Lifecycle

A result moves through stages, and each stage updates the same record:

• Preliminary: An early result, expected to be followed by a final value
• Final: The completed result
• Corrected: A revised result that supersedes a value already reported as final. A correction is expected after final, and a result can be corrected more than once.
• Canceled: A result the laboratory has withdrawn, for example when a test is canceled or a specimen is rejected

Lab Network does not move a result back to preliminary once it is final or corrected. A panel of several tests can finish one test at a time, so one report can carry a mix of preliminary and final results before the whole report is final.

Detecting Changes Through the API

For consumers reading results through the FHIR API, the lifecycle maps to DiagnosticReport.status.

To track changes, apply these rules:

• Watch for status changes after final: A change appears as status becoming corrected or cancelled.
• A correction updates the same resource: It updates the existing DiagnosticReport and keeps the same resource ID, so a consumer subscribed through FHIR Subscription receives the update on the same record. Re-read the full report rather than expecting a separate corrected copy.
• A later preliminary does not overwrite a final or corrected result: Treat the latest final or corrected status as authoritative.
• Read observation statuses for per-test detail: Each result carries its own Observation.status using the same value set. DiagnosticReport.status is set from the source message, not derived from the observations, so to track how individual tests finalize in a panel, read the observation statuses.
• Treat a cancelled result as withdrawn, and an unknown status as unresolved: On cancelled, the earlier values are no longer valid to display. When the source status does not map to a known stage, status is unknown, and you cannot assume the result is final.

Keeping Distinct Results Separate

Lab Network recognizes a repeat by the result's identifier, not by comparing clinical content, so two genuinely different results are always stored as separate records. Before updating a record with a repeat, Lab Network also confirms the repeat belongs to the same patient. If a laboratory reuses an identifier for a different patient, Lab Network stores a new record rather than merging two patients' results onto one.

Examples

A. Clean Match

A solicited result arrives with its Lab Reference ID. Lab Network links it to the originating order, confirms the patient on the result matches the patient on the order, and posts the result to the chart.

B. Name and Date-of-Birth Mismatch

Lab Network traces a solicited result to its order by its Lab Reference ID, but the patient on the result does not match the patient on the order. Lab Network does not post the result to that patient and does not link it to the order because the result has complete demographics.

Instead, Lab Network files it under a matched or newly created patient and delivers it. Had the demographics been incomplete, Lab Network would hold the result in the Unassigned Queue and not deliver it.

C. Unsolicited Result

A result arrives without a Lab Reference ID. Lab Network identifies the ordering provider from the result and searches the organization for a matching patient. If a patient matches, Lab Network posts the result. If none matches and the demographics are complete, it creates a new patient and delivers the result. If the demographics are incomplete, it holds the result in the Unassigned Queue.

D. Correction After Final

A result already reported as final arrives again as corrected. Lab Network updates the same record, sets its status to corrected, and delivers the update through your FHIR Subscription.

E. No Postal Code, Phone, or Social Security Number

An unsolicited result arrives with an accurate name and date of birth, no patient identifier that resolves to a record in your organization, and none of postal code, phone number, or Social Security number. Because no identifier resolves, Lab Network falls through to the demographic search, and because none of the three confirmation values is present, that search does not run. Lab Network creates a new patient, files the result under it, and delivers it. The patient identifier on the delivered result is one your system has not seen before.

Had the same result carried a patient identifier your organization already uses, it would have matched on that identifier and never reached the demographic search.