#3237 CML labs are being matched to the wrong patient

[Jarrett Chisholm]

Serious problem with lab matching algorithm. This particular issue is occuring with CML labs.

Labs are being matched to the wrong patient.

Reproducable on RELEASE_12 and RELEASE_12_1.

Customer, McMaster, is on the current build:

Build Date: 2012-08-04 09:02 AM
Build Tag: oscarMcmaster-12 38
Clients Browser: Firefox latest (not ESR)
Clients OS: Windows & MacOS
Server: Debian 6.05 32bit

Preconditions:

1. CML lab for international students have HIN in PID-2 (instead of PID-4). Format for HIN is 'MUddddddddd' where d is a digit.
2. OSCAR therefore does not get a HIN after parsing the lab. HOWEVER, the HIN is parsed as an empty string (i.e. '') instead of null.
3. OSCAR thinks there is a hin (hin != null). The lab matching matches on:
   select demographic_no, provider_no from demographic where hin='" + hinMod + "' and " + " year_of_birth like '" + dobYear + "' and " + " month_of_birth like '" + dobMonth + "' and " + " date_of_birth like '" + dobDay + "' and " + " sex like '" + sex + "%' "

Because the International student HAS a hin number, the student is not matched. There are often other demographics, however, that DO match the above query.

They match because the query uses only the first and last initial, instead of the full name.

Steps to reproduce:

1. Have 2 demographics, one with a HIN for an international student, and one with NO hin.
   The 2 demographics have the same first/last initial, dob and sex.
2. upload a lab (You can use the attached 'test.cml' if you like) for the demographic with a HIN, but the HIN is in PID-2 (for an international students health insurance number).

Expected Result:
OSCAR either matches the correct demographic, or at least, does NOT match the incorrect demographic.

Observed:
OSCAR matches the incorrect demographic.

[Marc Dumontier]

On the issue of the HIN in PID-2 for int'l students..do we need to make an FR for that separately to add in the functionality.

[Jarrett Chisholm]

Yeah that sounds like a good idea.

I'm confirming with the customer what exactly the PID-2 field looks like (I just want to make extra sure we test with data that is valid).

[Jarrett Chisholm]

Confirmed with customer that the field is correct in the sample I uploaded.

[Jarrett Chisholm]

FR created for international student HIN parsing: https://sourceforge.net/p/oscarmcmaster/feature-requests/1003/

[Daniel Sin]

Here is a couple of options that could help advoid the incorrcet matching

1. Do not match “blank” or PID2 strings HINs. This means if the system found that a lab comes back with empty string “HIN” it will not attempt to match them. This could be the easiest match but it depends on how often this happened for your client.
2. When OSCAR found duplicate matches with the current condition, it will not match the lab when the lab has a blank or PID2 “HIN”.

Please let us know ASAP the preference so we can implement it as a fix.

[Jarrett Chisholm]

Hey Daniel

Basically, if no HIN is parsed from the lab, we need to make sure the 'hin' variable is 'null'. If it is null, OSCAR already ensures it doesn't use the hin for matching.

As for PID2, in my mind it makes sense to:

1. Check PID4 for HIN
2. if hin exists, use it
3. if no hin in PID4, check for hin in PID2 (If the lab is a CML lab)
4. if hin exists, use it
5. if no hin was found, set hin to null

As for the case when there is no hin, I would suggest matching on FULL first and last name, DOB, and SEX.

This is strict, but should ensure we don't get any eronneous matches.

[Daniel Sin]

Marc,

If you agree, please take this as the final recommendation from Prylynx. You can fix it or have Victor follow up on this one. We want to get this done by end of April also.

[Sarah Allen]

Fixed in [feature-requests:#1003].

12_1 commit: https://source.oscartools.org:8080/10252
Trunk commit: https://source.oscartools.org:8080/#/c/10253/