E-standards for Cancer Registries

E-standards for Cancer Registries -- A Status Report

A presentation to the Workgroup on National Health Information Infrastructure
July 24, 2002

By Barry Gordon, Ph.D.,
C/NET Solutions and the California Cancer Registry
barryg@askcnet.org

Thank you for the opportunity to present to you today.  I’ve been concerned with standards issues throughout most of my 35 years work with cancer registries.  I’d like to start by describing some of our standards work, give a kind of status report as I see it, and provide some examples of what we are learning from our current projects.  I will end with some ideas on how to foster the extension of structured standards both within cancer registries and between them and other key players.  Warren Williams has just provided a nice overview of cancer registry standards, and I’d like to add some specifics showing what is working and what is not.

Several of us joined the standards venture early, when the possibility of electronic reporting first became recognized.  When PC’s became available widely,  physicians were starting to invent their own coding systems for their homebrew registry systems.  We decided in California to produce freely available PC software as a pre-emptive act to encourage the use of the newly forged standards agreed upon by NCI and the American College of Surgeons.  Then when we were proposing the California regulations to mandate electronic reporting as a part of our new statewide registry, we had even more of a reason to hammer out common data codes and formats.  The speed with which we implemented statewide reporting and data collection was at least in part due to our ability to provide clear electronic standards and the software that carried them out. 

As the fledgling NAACCR (North American Association of Central Cancer Registries) was being formed to support state registries, I helped found a standards committee to define a national data exchange standard for case reporting.  The easy part was creating a simple, inclusive structure that would meet the variety of reporting requirements.  The hard part was getting SEER and the College to agree on how treatment and staging should be coded.  There was the inevitable conflict between the desire for a consistent coding system over time to study trends by epidemiologists (SEER) and the clinical view (ACoS).  Clinicians need to keep up with how changing clinical knowledge and practices affect the staging of cancers d in terms of predicted outcomes.  This work was helped by the recognition of the clear gains in efficiency that agreement could bring, along with plenty of motivation from vendors and states having to interface across boundaries.

I believe this cancer registry standards effort has been a success so far.  First, let’s look at the status within California.   We now have all 450 hospitals using standard electronic case reporting to our eight regional registries, using a common set of required edits and online coding manuals.  Specifically, the standards include:

• A mandated ASCII layout used by all vendors
• Nationally-agreed-upon code sets, supplemented by California extensions
• Online coding manuals presenting the detailed requirements for each field
• A common edit set to enforce validation and completeness rules.

A second standards effort is being undertaken in California involving standards for reporting of potential cases by pathology laboratories.  We are devoting a lot of attention to improving electronic casefinding.  The sheer volume of reports from various sources encourages an electronic approach.  We can summary these different sources by tabulating one data item we collect for each case: how the cancer was first identified. 

As you can see, the most common sources are various departments within a hospital, especially medical records and path lab reports.  I will be discussing  some of these sources in relation to structured messaging in a moment.

Turning to national standards within cancer surveillance, I believe we have  another success story.  Here’s where we are today:

• We have a neutral organization in place (NAACCR) to host the standards for cancer registry data.
• The geographic scope of these standards is the entire US and Canada
• The key players are all participants:  The ACoS, SEER, CDC, software vendors, and states health departments.
• We’ve achieved data harmonization between partners, although this is a continuing effort.
• Common tools include distributable dictionaries, code sets, electronic coding manuals, and standard edits.
• States get measured on their ability to meet data standards and quality standards by the CDC and NAACCR.  Each year, NAACCR awards gold and silver awards to states meeting their standards, and included them in there combined data publication.

What did it take to achieve this level of harmonization?

• Recognition that hospitals were reporting the same cases to agencies with conflicting standards, creating much duplication of effort
• Commitment by national organizations to achieving common definitions for shared data items.
• The federal funding of state registries, contingent on their using common standards for case reporting be used.

The ingredients for success in this case seem to be, first, a commitment to standards; secondly, the tools to encourage them; and thirdly, the courage to measure and report compliance.

I’m particularly proud of our distributable edits technology as a tool that strongly encourages standards.  Using a common workbench and cross-organizational ‘metafile’ of standard edits that are callable from any Windows application, it supports each national organization in maintaining edits for their part of the common dataset, and support easy distribution of the edits nationally.  The portable edits software was developed by CDC in consultation with several vendors including C/NET, and are used by the College, SEER, and NAACCR to maintain edits.  In California, they are built into our CNExT front end software and our Eureka statewide registry software  for complete vertical integration.

Not everything has been a success.  As soon as we look for connectivity outside of cancer registries, we see harmonization problems and lack of well-structured reporting.  This is of highest concern in relation to HL7.  Although much work is being done in this area, we find few implementations.  In the past three years, progress has been made in several areas:

• Complete HL7 mapping of cancer reporting data items into an ORU HL7 message.
• Complete HL7 mapping of pathology report items required for cancer reporting.

How much have these been used?  Not very much.  I’ll discuss why in a moment.

Current Projects and what we can learn from them

I’d like to mention four current registry projects that involve HL7 interfaces.  These are:

2. HL7-based cancer case reporting
3. Discharge-based registry casefinding using HL7
4. Electronic Pathology Reporting using HL7
5. Reporting Pathology Protocols using HL7

1.  Project to create HL7-based cancer case report message.

CDC has helped fund work to completely map the cancer reporting data items into an ORU HL7 message.  We used LOINC (Logical Observation
Identifier Names and Codes) to unambiguously identify registry-specific fields.  In California we tested this structured message by developing software that creates, sends, and receives HL7 messages as defined in the NAACCR HL7  Implementation Guide.  This project was successfully, at least technically.  However, there is no clear business case motivating organizations to use this format for cancer reporting.  I’m not aware of anyone else who has even done a pilot implementation.  The biggest impediment is that state registries lack an economic or regulatory motivation to switch to HL7 for cancer reporting.  No national funders are requiring the switch.  The harmonization work to better align NAACCR with standard HL7 representations is not seen as worth the effort for this particular message. 

2.  Integrating in-hospital messaging into cancer reporting.

Most cancers are diagnosed in hospitals, and yet cancer registries are still cut off from most of the interesting HL7 traffic that passes routinely between departments.  In this project, we are implementing software to capture discharge messages, select those coded with a possible cancer ICD-9 code, and bring them into our CNExT registry software for evaluation and pre-population of electronic cancer reports.  We also are studying how best to merge pathology messages with discharge messages to further save cancer data collection efforts.

Casefinding can involve a great many different hospital systems.  In one analysis carried out at UCSF, 21 different departments or systems had reports that could identify cancer cases.  We are finding that the majority of discharge systems already use standard HL7 messaging.  However, there is much less penetration into the pathology lab software systems.  Although path reports are the gold standard for diagnoses, discharge scanning may get rapid casefinding up more quickly in many hospitals.

3.  Electronic Pathology Reporting

In California we are working hard to set up electronic reporting between our path labs and the state registry.  This is particularly important for stand-alone labs, but any regional or state registry that needs rapid casefinding for special studies needs to have high-speed access to large hospital path labs as well.

Nationally and locally, we have some successes and issues to report.

A standard path lab electronic message has been agreed upon by NAACCR, with significant leadership from CDC.  As a compromise with existing methods, both a column-delimited and HL7 version are available.  There is also a nationally-maintained list of key search phrases for recognizing potential cancers through scanning the report text.   There have been some use of these standards in several states, including California.  However, there are issues:

• It can take a long time to get lab buy-in to electronic reporting.
• Confusion over HIPAA issues make some labs and facilities nervous about electronic transfer, even though the current methods such as postal delivery of diskettes are far from secure.
• There is no agreement in the registry or vendor community as to which secure transport protocols and authentication schemes to use to carry out the communications, so cross-system interchange is not facilitated.  There are a number of efforts, including the CDC’s NEDDS model, and some B2B solutions, but I don’t see any consensus.  Without this it is hard to build clinical/public health connectivity.
• Message schemes that depend on new HL7 formats don’t work when the facilities use out-of-date software systems.

4.  The Reporting Pathology Protocols project.

This project builds on the excellent recent work of the College of American Pathologists.  They created standard synoptic checklists for cancer cases which hopefully can replace the largely idiosyncratic text-based reports currently used.  We are implementing data capture and HL7 messaging of the colorectal synoptic report, then putting it through a live test to see what kinds of efficiencies it might produce. In California we are working with the UC Irvine Cancer Center.  If this approach works, among other benefits it will lead to more rapid and consistent identification of potential cancers for cancer registry and less manual coding. As we proceed with this work,  we are discovering again the substantial effort needed to convert something that looks good on paper to algorithms that unambiguously capture standard data behind the form. 

I believe this project has the ingredients for success because of participation by:

• National standards-setters (CAP and CDC)
• Standards agencies (SNOMED, HL7, LOINC)
• State registries (California and Ohio)
• software developers (C/NET, Rocky Mountain, and Co-Path)
• Practitioners (pathologists)

It also helps that they are focusing on implementing and evaluating the new standards and techniques.

Going beyond the four projects I’ve just mentioned, there are many other systems that registries could benefit from interfacing.  Some of these include:

• Clinical Lab Electronic-reports
• Hospital Discharges
• Hospital Information Systems
• Radiation Treatment Center systems
• State Vital Status Records
• Clinical Trials Systems
• Rapid Casefinding systems for Interview Studies

To summarize, I believe the following steps will help us all make progress toward more consistent and widespread structured standards and reporting:

• Public health and clinical groups need to value connectivity with others, and include it in their high-level agendas.  They also need the courage to measure compliance.
• More ‘glue’ projects are needed to create structured standard interfaces and prove their worth.
• These pilot projects need to be funded well enough to include representatives from standards organizations and all the key players in the interface, along with software developers.
• New proposed coding and message structures, no matter how well designed, must be implemented in real messages and environments before their design is complete.
• Standards work best when accompanied by portable edits and other tools to implement them.