Narrative:

I was working R21 (dominion) which is a low sector at ZDC. Raleigh approach is at the south side of the sector 12000 ft and below. Richmond is at the northern boundary 9000 ft and below. Above raleigh approach, this sector owns up to FL230. North of raleigh's boundary this sector owns FL200 and below. Traffic for this sector is rdu departures to the north. Richmond departures to the southwest. Richmond lands from the west and south. Also, a variety of other aircraft. Aircraft Y departed rdu and was handed off to me. The sector had moderate traffic and I had just handled many rdu departures. Normal procedure is to climb jets to FL230 and hand them off to sector 20 (blackstone) for climb. I climbed aircraft Y to FL230 and attempted to hand off the aircraft to sector 20. Apparently my computer entry was unsuccessful. When you hand off an aircraft, the data block flashes and when the handoff is accepted, the data block is constant with an 'right' next to the identify number in the data block. I looked back and noticed the constant data block. Thinking sector 20 had radar on the aircraft, I switched him to sector 20. 7 mins later, a conflict alert went off between aircraft X and aircraft Y being descended to dulles. Aircraft Y had checked on with sector 20, but since they did not see a data block, the controller told the aircraft Y to stand by. I was complacent in my routine and saw what I expected to see. When I saw the constant data block for aircraft Y, I did not think that my handoff entry was unsuccessful. I simply thought the data block had flashed and the next sector took the handoff. An aircraft incident resulted in another controller's airspace. Supplemental information from acn 418876: did not received handoff or data block of climbing aircraft. Supplemental information from acn 418822: aircraft was climbed into my airspace without a handoff.

Google
 

Original NASA ASRS Text

Title: A LOW ALT ARTCC RADAR CTLR DOES NOT ENSURE CORRECT HDOF PROCS AND AN FK10'S COM IS XFERRED TO A HIGH ALT CTLR. THE NON IDENTED FK10 COMES IN CONFLICT WITH A DSNDING B757 PRIOR TO BEING RADAR IDENTED.

Narrative: I WAS WORKING R21 (DOMINION) WHICH IS A LOW SECTOR AT ZDC. RALEIGH APCH IS AT THE S SIDE OF THE SECTOR 12000 FT AND BELOW. RICHMOND IS AT THE NORTHERN BOUNDARY 9000 FT AND BELOW. ABOVE RALEIGH APCH, THIS SECTOR OWNS UP TO FL230. N OF RALEIGH'S BOUNDARY THIS SECTOR OWNS FL200 AND BELOW. TFC FOR THIS SECTOR IS RDU DEPS TO THE N. RICHMOND DEPS TO THE SW. RICHMOND LANDS FROM THE W AND S. ALSO, A VARIETY OF OTHER ACFT. ACFT Y DEPARTED RDU AND WAS HANDED OFF TO ME. THE SECTOR HAD MODERATE TFC AND I HAD JUST HANDLED MANY RDU DEPS. NORMAL PROC IS TO CLB JETS TO FL230 AND HAND THEM OFF TO SECTOR 20 (BLACKSTONE) FOR CLB. I CLBED ACFT Y TO FL230 AND ATTEMPTED TO HAND OFF THE ACFT TO SECTOR 20. APPARENTLY MY COMPUTER ENTRY WAS UNSUCCESSFUL. WHEN YOU HAND OFF AN ACFT, THE DATA BLOCK FLASHES AND WHEN THE HDOF IS ACCEPTED, THE DATA BLOCK IS CONSTANT WITH AN 'R' NEXT TO THE IDENT NUMBER IN THE DATA BLOCK. I LOOKED BACK AND NOTICED THE CONSTANT DATA BLOCK. THINKING SECTOR 20 HAD RADAR ON THE ACFT, I SWITCHED HIM TO SECTOR 20. 7 MINS LATER, A CONFLICT ALERT WENT OFF BTWN ACFT X AND ACFT Y BEING DSNDED TO DULLES. ACFT Y HAD CHKED ON WITH SECTOR 20, BUT SINCE THEY DID NOT SEE A DATA BLOCK, THE CTLR TOLD THE ACFT Y TO STAND BY. I WAS COMPLACENT IN MY ROUTINE AND SAW WHAT I EXPECTED TO SEE. WHEN I SAW THE CONSTANT DATA BLOCK FOR ACFT Y, I DID NOT THINK THAT MY HDOF ENTRY WAS UNSUCCESSFUL. I SIMPLY THOUGHT THE DATA BLOCK HAD FLASHED AND THE NEXT SECTOR TOOK THE HDOF. AN ACFT INCIDENT RESULTED IN ANOTHER CTLR'S AIRSPACE. SUPPLEMENTAL INFO FROM ACN 418876: DID NOT RECEIVED HDOF OR DATA BLOCK OF CLBING ACFT. SUPPLEMENTAL INFO FROM ACN 418822: ACFT WAS CLBED INTO MY AIRSPACE WITHOUT A HDOF.

Data retrieved from NASA's ASRS site as of July 2007 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.