NHIA patient values different across tumors

[firthr]

Hi Fabian,

Recinda requested naaccr prep and the algorithm address the issue of the NHIA value being different across tumors. This occurs because of the option selected for the algorithm, based on % population county at diagnosis codes, and the patient moving from one county to another (with a different pop threshold). It causes the records to fail the inter-record edits program. It is very rare but i have been addressing it for the last couple years to make the values consistent across the records. Below is what i was told how to address (details for can be found in the naaccr squish project, issue 65034 and 64839). Here is an inter-record error report from CO as an example. co.2018cfd.inter-record_detailed-rpt.pdf

[depryf]

Hey Rick,

The NHIA field is defined as a Patient-level field by NAACCR.

While it is true the algorithm uses the county at DX tumor field, the output of the algorithm is a single Patient-level value.

When submitting a NAACCR XML file, it is actually impossible to provide different values for the tumors since the value appears under the Patient level.

The only way I can think of for this issue to happen is when the SAS code is used on a flat file, and it computes one variable per line (so per tumor).

I think what you requested is how the algorithms works now.

Do you agree, or am I not understanding this request correctly?

[howew]

Hi Fabian,

What happens if a registry uses a fixed-width layout and they have different patient level information, like last name? I know what you are thinking... if the database is designed properly this shouldn't happen but some registries are very behind in that regard. The algorithm doesn't know about all of those names... just the patient info from the first record (at least that's what prep gives it).

Thanks, Will

[depryf]

Maybe I misunderstood.

Is this a request to return multiple values of NHIA per tumor?

[howew]

No. It should still return a single value, but that value should be consistent across all records for a patient.

[depryf]

OK, then I do not understand what needs to change in this library.

The algorithms returns one value per Patient, it never returns a different value per Tumor.

This library is not aware of fixed-column vs NAACCR XML; it returns a DTO representing a Patient and that DTO has a single field for NIHA.

If another software uses that information to create a NAACCR XML file, the unique value would be written under the Patient level. If it creates a flat NAACCR file, the unique value would be written on each line, but it will obviously be the same on each "tumor-line".

And so again, I am unclear what problem needs to be addressed in this particular library.

[depryf]

We talked about this as a group. The SAS code is going to be changed to handle the case where demographic items come with different values.

There is no changes needed for this library.