Edits Examples for Central Registry

INTRODUCTION

This article introduces a new group of example edits for central registries included in the NAACCR v25 metafile. Just as central registries build on the State Example edit set in the standard metafile to create custom metafiles for their reporting facilities, they may build on these examples to add new edits to their custom metafiles. These edits on address data items are offered as examples of custom edits requested by two central registries that may be of value to other central registries. Any interested registries would need to adapt their descriptions and edit logic to their own specifications. For two of the edits, central registries would also need to develop a lengthy table for their own jurisdictions.

BACKGROUND

The NAACCR edits metafile supports the accurate and consistent coding of data items designed to capture the essential components of cancer diagnosis, prognosis, treatment, and follow-up. This information is used in cancer surveillance – an accounting of the human experience with cancer from an international to an individual level – and research into the causes of cancer and treatment methodologies.

A significant interest of cancer epidemiology has always been the location of cancer patients when they are diagnosed, both for any insights into cancer causation this might provide, and for the placement of education services for the general population and treatment facilities to serve patients. Thus Address at Diagnosis is a longstanding construct for cancer registries.

For the NAACCR membership, data items collected directly from health records include: Addr at DX–City, Addr at DX–Country, Addr at DX–No & Street, Addr at DX–Postal Code, Addr at DX–State, and Addr at DX–Supplementl. An additional six items are also collected for Address Current, as a necessary part of patient follow-up: Addr Current–City, Addr Current–Country, Addr Current–No & Street, Addr Current–Postal Code, Addr Current–State, and Addr Current–Supplementl.

Central registries collect these data items from their reporting facilities. They further manipulate the information, through a process of geocoding, to attain the precision of latitude and longitude coordinates for address at diagnosis. The NAACCR Data Dictionary includes a number of data items based on the results of geocoding, related to Census Tract, Census Block Group, Latitude, and Longitude, and additional items assessing the quality of the results, such as Census Tract Certainty, GIS Coordinate Quality, and Geocoding Quality Code and Quality Code Detail.

Ultimately, the accuracy of geocoding depends on the accuracy of the originally submitted address information. Reflecting the importance of address at diagnosis, the NAACCR metafile contains longstanding edits on these data items: 18 edits on Address at DX and 19 edits on Address Current. These edits check valid values for the data items. They also check consistency of codes between data items, such as county codes and postal codes by state and state by country.

An edit including city at diagnosis, along with state, county, and zip code, would provide an additional check on the quality of the reported address, though it might fall short of verifying legitimate street addresses by city. This last would seem an unattainable goal, but edits checking for city are feasible components for central registry custom metafiles. It would be highly impractical for the standard metafile to maintain appropriate edits and tables for 61 central registry jurisdictions, but each central registry may have the resources to develop a reference table linking city, county, and zip code for its own jurisdiction.

EXAMPLE EDITS FOR CENTRAL REGISTRY

The NAACCR v25 metafile includes three new edits, gathered in a new Central Example Edits edit set. The first edit checks the precision of county coding, while the others check the consistency among city, county, and zip code for a state. These edits contain state-specific language, and thus must be modified, or customized, for state-specific use.

N7159  Central_EX, State at DX, County at DX (NAACCR)

N7160  Central_EX, Addr at DX–City, County, Postal Code (NAACCR)

N7161  Central_EX, Addr Current–City, County, Postal Code (NAACCR)

N7159 is based on a recent request from South Carolina, to develop an edit that requires County at DX Reported to be coded 998 for all addresses outside the state, and does not allow the data item to be coded 998 for any address within the state. For registries that collect valid county codes from outside the state, the part of the edit that checks that 998 is not coded within state may be useful.

N7160 and N7161 are based on longstanding edits within the Florida metafile. These edits verify consistent coding of county, zip code, and city, referencing a table with these values included in the metafile. The Florida table is also used to replicate edits in the standard that validate county and zip code values, but including city in the table and edits is unique.

The three edits and the table are included in the v25 metafile with agency NAACCR, so they must be copied and given your own agency and tag to be included in any custom edit set. You can modify the description to reflect your jurisdiction, replace the example value (highlighted) for your value in the logic, update the Administrative Note appropriately, and substitute custom error messages if desired. See edit content below.

Note that the table must be constructed carefully, to include all possible combinations of county, city, and zip code for the state, with no repetitions of combinations. Cities may extend into more than one county, cities may include multiple zip codes. (The edit does not check for zip codes that extend or lie outside city boundaries.)

Inaccuracies in the table may prohibit reporting facilities from entering correct county, city, zip code combinations. The central registry must thoroughly vet their table prior to release of these edits to reporting facilities, running the edits against registry data to identify any inaccuracies in the table. Central registries should also be prepared to update the table should changes be made to county, city, or zip code boundaries.

N7159-Central_EX, State at DX, County at DX (NAACCR)

Description for N7159:

This edit verifies that County At Diagnosis Reported is not coded 998 for county within central registry state.

This edit verifies that County At Diagnosis Reported is coded 998 for county outside central registry state.

This edit is an example edit only. Highlighted Value in Address at DX–State must be customized for central registry using edit. South Carolina is included in the edit as the example only.

Logic for N7159:

if(AT(#S”Addr at DX–State”,”SC”)!=0)

{

if(AT(#S”County at DX Reported”,”998″)!=0)

return FAIL;

}

if(AT(#S”Addr at DX–State”,”SC”)==0)

{

if(AT(#S”County at DX Reported”,”998″)==0)

return FAIL;

}

return PASS;

Administrative Note for N7159:

New edit – NAACCR v25 Metafile

Default Error Message for N7159:

7586: %F2: %V2 is not valid for %F1: %V1

%F1 is Addr at DX—State, %F2 is County at DX Reported

N7160  Central_EX, Addr at DX—City, County, Postal Code (NAACCR) &  N7161  Central_EX, Addr Current—City, County, Postal Code (NAACCR)

N7160 and N7161 are very similar, N7160 using address at diagnosis fields and N7161 using address current fields. They both reference the same table.  N7160 is shown here.

Description for N7160:

This edit validates the combination of Addr at DX–City, County at DX Reported, and Addr at DX–Postal Code. If not found in the reference table, an error is generated.

This edit is skipped if any of the following conditions are true:

Any of the fields are blank:

• Addr at DX–State is not central registry state
• Addr at DX–City = “UNKNOWN”
• Addr at DX–Postal Code = 99999 or 999999999
• County at DX = 999

This edit is an example edit only. Highlighted value in Addr at DX-State must be customized for central registry using edit. Florida is included in the edit as an example only. This edit references a table containing columns for County, Zip, City, and concatenated County, Zip, and City – CNTYZICI. The first few lines of the table are included in this metafile as a reference.

Logic for N7160:

char czc[60];                                                                                               declare local variable

If (EMPTY (#S”Addr at DX–Postal Code”)                                           pass if empty fields

or EMPTY (#S”Addr at DX–State”)

or EMPTY (#S”Addr at DX–City”)

or EMPTY (#S”County at DX Reported”))

return PASS;

If (not INLIST(#S”Addr at DX–State”,”FL”))                                          if not my state, pass

return PASS;

If  (INLIST( #S”County at DX Reported”, “999”)                                if any unknown values, pass

or INLIST (#S”Addr at DX–Postal Code”, “999999999,99999”)

or INLIST (#S”Addr at DX–City”, “UNKNOWN”))

return PASS;

STRCPY (czc, #S”County at DX Reported”);                                      concatenate (bring together)

STRCAT(czc, #S”Addr at DX–Postal Code”);                                     field values into local variable

STRCAT(czc, trim(#S”Addr at DX–City”,right));                                 for table lookup

If (NOT SQLLOOKUP(“FL_CZC”,trim(“CNTYZICI”,right), czc ))     check values against table

return FAIL;

return PASS;

Administrative Note for N7160:

New edit – NAACCR v25 Metafile

Default Error Message for N7160

8645: Conflict for %V2 among %F4: %V4, %F1: %V1, and %F3: %V3

%F1 is Addr at DX—Postal Code, %F2 is Addr at DX—State, %F3 is Addr at DX—City,

and %F4 is County at DX Reported

Table for N7160: FL_CZC

Click here for detailed instructions on developing tables for this edit.

The table consists of four columns, for County, Zip, City, and concatenated county, zip, and city. A very short version of the entire table (10 lines from 3225) is included in the metafile. You would copy the table into a new table with an appropriate name and agency, create the table for your own jurisdiction in a spreadsheet, zap the contents of the copied table, and then import your table contents into the table form.

CONCLUSION

With these new edits, we are hoping to expand the usefulness of data editing through the standard metafile.  We are demonstrating what other central registries have done, and providing templates for the construction of custom edits and tables. All three edits discussed here check coding at the abstract level and are appropriate for use by reporting facilities as well as the central registry.

The sample edits could potentially improve the accuracy of the county, city, and zip data collected by central registries. However, central registries must be confident the tables used to check these fields are accurate and up-to-date.

We will gladly take suggestions or recommendations for other edits that could similarly be shared among registries as useful examples for data editing, with or without the need for modification.