Greg

I believe the randomized MRNs will remain in place, but I will bring this topic up with our ONC sponsor.

-Dave Czulada

dczulada: Thanks very much for the details.  I'll be updating our logic accordingly. 

"Keying solely on the MRN in the duplicated patient records was a bit of a loophole for testing patient deduplication."   Are you saying the Cypress, at least in CY2020 test data, will no longer present duplicate patients with the same ID?  Or, is that still a possibility?

Greg-

You are correct, this was an intentional change we made between Cypress v4 (for CY2019) and Cypress v5 (for CY2020).

Keying solely on the MRN in the duplicated patient records was a bit of a loophole for testing patient deduplication.

One of the use cases for the patient deduplication for the “Import and Calculate” criteria is to mimic a scenario where QRDA files are being imported from multiple sources (which may use different MRNs).

The Import and Calculation criteria does not require that the patient deduplicate be automatic and a human could be in the loop.

For example:

Consider importing 2 QRDA files:

Dave Czulada (birthdate 4/4/1980) MRN 1234

David Czulada (birthdate 4/4/1980) MRN 4321

When importing those patient files, a user may be prompted that there are 2 files that appear to be for the same patient.  At which point, the user may need to investigate if the records are in fact for the same patient.

-Dave

Prior to Cypress adding this duplicate-patient feature, our application followed the guidelines of CMS and TJC.  That is: When they receive a patient (same hospital, same quarter, same ID, etc.) who they already have, the data of existing patient is completely replaced by the new data.  But in order to support Cypress tests, we had to "throw a wrench" in our logic.  That wrench has been in our app since 2018.  That special logic worked because the different Cypress files for the same patient used the SAME patient ID.  But now, for CY2020 tests, we're seeing the Patient IDs are DIFFERENT for patients that are apparently the same people.  I'm having to hard-code the IDs in the logic in order to keep the one patient Cypress is expecting.  Why can't Cypress keep the IDs the same for duplicate patients, like they were before?

CY2019 tests, VTE-1, 3_Anthony_Hansen.xml and *4_Anthony_Hansen.xml, both files had *SAME Patient ID of: 8739eb36-6352-43a8-8397-02db6b4839ba_27.

CY2020 tests, PC-5, 5_Sean_S.xml and 6_Sean_Shaw.xml, both files have DIFFERENT Patient IDs of 5e78da9fdfe4bd03a59dc88a and 5e78da9fdfe4bd03a59dc8a1, respectively.

Thanks dczulada for the quick response.  However, none of this makes it clear (to me) how our program can look at these two files and know they are for the same patient.  In the real world, this would be done by matching on the Patient ID - a hospital would assign the same ID (ex: Medical Record #) to multiple records for the same person.  If that ID couldn't be used, it would be "best-guess" using things like DOB, last name, address, other identifiers, etc.  In ticket example, the IDs are different.  Also, while the two DOBs are the same, the last name is not - only they both start with "S".  How can we change our application, which real hospitals use, to make it think two people with same DOB but different last name are the same person??  Lots of people share the same DOB.  The only way I see this happening is: 1) We let our software know it's loading Cypress data, and 2) hard-code that "Sean S." and "Sean Shaw" - and add more exceptions like this as we continue to test.  What am I missing?

In Cypress 3.2 we expanded the variability in patient duplication. The Cypress test patient follow the same pattern when being duplicated:

Introduce duplicate files with modifications to a patient’s name and demographics

• Name differences include: nicknames, initials, misspellings
• Demographics include discrepancies in: race, gender, ethnicity
• Discrepancies in Date of birth: missing, different, imprecise
• The clinical information in the duplicate files will remain consistent
• Note: For reporting, either name or demographic can be chosen

Introduce duplicate files with modifications to a patient’s clinical information

• Documents will be split one of multiple ways:
  • Temporally (e.g., Jan – June, and July - Dec)
  • Data types (e.g. encounters in one file, lab results in another)
• Name and Demographics will remain consistent
• Information in ’split’ files will be additive (i.e., files will not contain duplicate information)
• Clinical Information will need to be combined to achieve a complete patient record

-Dave Czulada

Thank you for submitting your question/issue. We will assign this to a team member and respond in one business day