Consider maintaining NAACCR numbers for non-standard output variables

[depryf]

This library already defines the NAACCR (XML) ID for all the non-standard output variables.

The numbers were not added because we through difference dictionaries would use different numbers.

It turned out all the dictionaries that need to reference these variables end up using the same numbers.

Because of that, it will be easier for everyone if we start maintaining them in this project.

I will start by providing a list of non-standard variables.

[depryf]

@howew I think we should do this, but there were too many things happening for this next submission. I think we should address that after this next submission. The only thing that will be difficult to deal with is if we assigned a different number to different dictionaries; hopefully we didn't do that (if we did, some of the numbers will need to change).

I am going to put this on hold for a few months.

[depryf]

@howew just a reminder this is still on my list. I intend to come back to this very soon. I will start by listing all the non-standard fields and what number we assigned to them in the various user-defined dictionaries...

[depryf]

Here is the (current) list of non-NAACCR-standard items that are computed by the library along with the NAACCR number that we previously used in various user-defined dictionaries:

• acsPctPovAIAN: 9615
• acsPctPovAllRaces: 9612
• acsPctPovAsianNHOPI: 9616
• acsPctPovBlack: 9614
• acsPctPovHispanic: 9619
• acsPctPovWhite: 9613
• acsPctPovWhiteNonHisp: 9618
• ayaSiteRecode2008: 9444
• ayaSiteRecode2020: 9445
• cancerReportingZone: 9415
• cancerReportingZoneTractCert: 9416
• cdcSVI2018: 9600
• countyAtDxAnalysisFlag: 9440
• daysToTreatment: 9750
• epht2010GeoId20k: 9994
• epht2010GeoId50k: 9995
• epht2010GeoId5k: 9993
• iarcMpIndicator: 9400
• iccc: 9420
• icccExtended: 9422
• ihsPurchRefCareDeliveryArea2017: 9970
• napiiaNeedsHumanReview: 9430
• napiiaReasonForReview: 9431
• seerBehaviorRecode: 9411
• seerBrainCnsRecode2020: 9455
• seerLymphNeoplasmRecode2021: 9450
• seerSiteRecode: 9410
• tractEstCongressDist: 9405
• yostQuintileState: 9611
• yostQuintileUS: 9610

[depryf]

@howew this one might affect your software.

The only thing that would really break is if you are checking that the number is null as a way to recognize standard vs non-standard items. That won't work anymore because they all have a number now. That was replaced by an actual method "isNaaccrStandard()" on the field class.

As to the non-standard numbers, it's up to you how to use them:

• you can completely ignore them (but that would be kind of a waste).
• you can use them in unit tests to verify that the numbers you assign to any user-defined dictionary you maintain/create agrees with what the library uses.
• you can use them in your software to dynamically create user-defined dictionaries with those numbers (if that's something you do).

The one thing to keep in mind is that whenever an algorithm is added and its sets some non-standard fields, we will need to create a number for those right away. It's not a bad thing IMO, just a slightly different process from before.