Writing Edits – An Approach for a New Central Registry Edit Writer

Introduction

Data relationships, electronic formatting, logical viewpoint – all come together in edits to support the collection of useful cancer information. The edits in the standard metafile realize standards that apply to data collected at the national level, but the same edit tools and processes are available to central registries to manage additional local data requirements.

EditWriter

The edit software currently in use in the United States is EditWriter 6, published by the National Program of Cancer Registries (NPCR) in the Centers for Disease Control and Prevention (CDC). The edit writer must define the data relationships to be addressed, design the edit, and then use the software as a guide through the process of converting the design into an edit applicable to data records. The software guide moves through description, edit logic, administrative notes, and error messages for cases that fail.

Developing Edits

For national standards, the design process usually starts with a new data item or new coding system or standards. For a regional registry, the process might start with a new data item for registry use, a gap in a national standard, or a finding in a data quality study.

Questions to be asked and answered in the design:

• Are there data items, values, instructions where a new programmed edit would enhance data collection and use?
  • What data items are involved, either standard or registry custom items?
  • What data values are of interest?
  • Are blanks allowed?
  • What is the relationship between data items to be tested?
• Are there data items or values that should be excluded from the edit?
• Is the data relationship addressed in another edit that might be in conflict?
• Are the number of data items and discrete values better handled in a tabular format or through if/then logical statements?
• Are there special circumstances that should be noted regarding edit construction or application?

The second process is providing the description, including:

• General statement of what the edit is intended to do.
• Data items and values under which the edit may not apply (skip conditions).
• Data items and relationships to be checked.
  • Table of related items.
  • If/then logical statements.
• Notes:
  • Does the edit relate to other edits?
  • Does the edit apply a standard based on interpretation of a published standard?
  • Does the edit logic use a built-in function that needs explanation?

The description usually presents the desired relationships among data items and values, which the edit logic will translate as “pass” if met, and “fail” if not met. The third process is translating the formal natural language into software language implementing the “pass” and “fail” conditions. For a person, writing in a natural language is familiar (though the formal if/then logical construct may be new), however, writing in software language may present more of a challenge, depending on user experience and the technology. Crafting the edit in a natural language first allows the writer to move into the high-level programming language with a clear plan of how the edit should work.

Conclusion

Writing good edits starts with identifying a relationship among data items and values that can be detected and expressed. The edit writer explores the relationship and designs a series of expressive logical statements. The edit writer uses the software tools available to write a description and translate the description into programming language. The programming language and testing are the final steps. The success and usability of the edit depends on the clarity of the description and its correct translation into edit logic.

Resources

A link to the EditWriter software, a manual for developing central registry edit sets, and training tips are available on the NAACCR Edits page.