ADT in Canada

In Canada, your system sends HL7 v2 admission, discharge, and transfer (ADT) messages to Health Gorilla. Health Gorilla uses them to keep each patient's record accurate and up to date as the patient moves between facilities.

The Canadian ADT service works differently from the United States ADT Data Service: there's no patient roster to maintain, and Health Gorilla doesn't send notifications back to your system. Your system sends ADT messages, and Health Gorilla returns an HL7 v2 acknowledgment for each one.

Patient Identifiers

Include both of these identifiers in the PID segment of every ADT message, each tagged with its identifier type code:

• Health Card Number (HCN): identifier type HCN. Identifies the patient across facilities.
• Medical Record Number (MRN): identifier type PT. Identifies the patient within the facility that assigned it.

Health Gorilla uses these identifiers, along with the patient's name and date of birth, to match each message to the correct patient. A message for a patient Health Gorilla hasn't matched creates a new record, and a message that matches an existing patient updates it. Health Gorilla needs a first name, last name, and date of birth to create or update a patient from a message.

On any message other than a Patient Merge (A40), a Medical Record Number that differs by letter case, by a leading zero, or by a prefix isn't matched, so a second record is created for the same patient. The message is still acknowledged as successful, so nothing signals that it happened. A merge behaves differently and is rejected, as described under Patient Merge (A40).

Supported ADT Event Types

Health Gorilla accepts the following HL7 v2 ADT event types in Canada. If you send an event type outside this set, Health Gorilla returns an HL7 v2 acknowledgment rejecting the message.

Canada accepts the A40 patient merge event. The A29 patient delete event is accepted in the United States only.

Patient Merge (A40)

When Health Gorilla receives an A40 message, it merges the two patient records named in that message, so the patient's information stays consolidated. Send one when your system finds a duplicate.

Requirements for a Merge Message

Three fields are required on an A40. Several conditions beyond field presence also apply, and those are described after the table.

Health Gorilla matches both patients on the Medical Record Number. The Health Card Number identifies a patient across facilities on other message types, and Health Gorilla still validates it on an A40, but it matches a merge on the Medical Record Number alone. Health Gorilla rejects an A40 that carries only a Health Card Number.

Both Medical Record Numbers must already identify a patient Health Gorilla holds, and each must match exactly one patient. Three consequences are worth planning for:

• The primary patient has to exist first. Health Gorilla rejects an A40 whose primary patient it hasn't seen before rather than creating one.
• A Medical Record Number has to be unique across your whole organization, not only within the facility that assigned it. If two facilities issue the same number to different patients, Health Gorilla matches both records and rejects the message.
• A Medical Record Number has to match character for character, exactly as your organization sent it when the patient was first recorded. Health Gorilla compares the number exactly, so it rejects a merge when the number differs by letter case, a leading zero, or a prefix on one side. The identifier type code is the exception, and PT and pt are equivalent.

The patient's name and date of birth don't affect whether the merge is applied. Health Gorilla updates the primary patient's demographics from the A40 only when the message carries a first name, a last name, a full date of birth, and a gender. Without all four, the merge still applies and the demographics are left as they are.

Example Merge Message

In the following A40, Health Gorilla merges the patient with Medical Record Number MRN20055 into the patient with Medical Record Number MRN10022.

MSH|^~\&|SENDING_APP|1.2.3.4.5|HEALTHGORILLA|HG|20260901120000||ADT^A40|MSG00001|P|2.5
EVN|A40|20260901120000||Merge
PID|1||MRN10022^^^^PT~1234567890^^^^HCN||DOE^JANE^A||19850214|F|||123 MAIN ST^^TORONTO^ON^M5H2N2^CAN||^PRN^PH^^^416^5551234
MRG|MRN20055^^^^PT

Acknowledgments

Health Gorilla returns an HL7 v2 acknowledgment for every A40.

Health Gorilla always gives the reason for a rejection in MSA-3, so start there when a merge doesn't take effect. When more than one thing is wrong, the reasons are joined with a semicolon. A reason can name a segment twice, as in Missing patient MRN at PID segment at MRG segment. Read the last segment named; that's the one to correct.

If a rejection doesn't match any of the causes above, contact Health Gorilla.

Health Gorilla rejects a replayed A40 whose merge already applied, because the duplicate record no longer exists.

Health Gorilla also rejects an A40 whose PID-3 and MRG-1 resolve to the same patient, because there's nothing to merge. The comparison is made on the resolved records rather than on the identifier strings, so two different Medical Record Numbers that resolve to one chart are rejected as well.

After a Merge

The primary patient's identifiers are used going forward, and the duplicate patient's information is consolidated under the primary patient. Requests that use the duplicate patient's former identifier still resolve to the primary patient, so no change is needed on your side.

The merge applies only within Health Gorilla. It doesn't change records in your system or in a provincial registry.