Linking lung nodules across CT scans using nodule centroid anatomical coordinates

Support
,
1

Hi,

Here is the setup for my question: I have lung CT scans from multiple time points for multiple patients. Our team’s radiologist is using Slicer to perform semi-automated contouring of lung nodules. In addition, he is saving/recording the [xyz] coordinates of the nodule centroid in anatomical space. Each nodule identified in the CT scans has an ID number. Unfortunately, the nodule IDs are not consistent across scans. The IDs are assigned in order the nodule was observed, and so lesion #1 on one scan might be lesion #2 on another scan, even if they are the same lesion.

So, of course we can have the radiologist manually review scans to determine which lesions IDs are actually the same lesions across scans. But this is prohibitively slow to do. I thought I should be able to use the nodule centroid anatomical coordinates to link lesions across scans. So we looked at the data for two scans for two lesions we know are the same, and yet the anatomical [xyz] differed substantially. We realized the origins differ, and these numbers are relative to the origin.

So I extracted the image origin coordinates from DICOM header using Slicer, and then calculated the nodules “distance from origin” using the origin and centroid coordinates. For example:

First scan: centroid [126.3, -38.5, -166.7]; image origin [185.2, 180.0, -347.7]
Second scan: centroid [121.4, 103.2, -215.9]; image origin [180.6, 316.6, -382.2]

Subtracting the nodule coordinate from the origin coordinate, we get the “distance from origin”:
First scan: [58.9, 218.5, -181.0]
Second scan: [59.2, 213.5, -166.3]

These numbers are fairly close, which suggested to me I was on the right track. I would expect these numbers to be identical ONLY if the fiducial for the centroid was placed in the EXACT same physical location across scans, right? Does anyone have any thoughts on whether this approach could be used to “link” nodules from different scans?

2

Did you have a look at registration options?

https://www.slicer.org/wiki/Documentation/4.10/Registration/RegistrationLibrary

It can be tough to line up cases exactly, but should be possible to reasonable results for your use case. Have a look at the pet/ct longitudinal example.

3

Hi @pieper

Thanks for the response. I did momentarily think about registration, but to be honest, I wasn’t sure if registration would be helpful retroactively. The (perhaps) problem is that we already have the centroid coordinates for thousands of nodules, and we know that most of the nodules appearing on follow-up scans are present on previous scans, without a concrete way of linking them. I am trying to think of the most robust and least manual way of using any/all available information to connect nodules across scans.

Would after-the-fact registration help in this respect?

4

Registration is probably the most automated option. You can register the follow up scans of your patient to their initial scan, convert your centroids into a multi-label labelmap, and apply the resultant transformation from your registraiton to those binary maps. This will bring everything into patient’s initial scans coordinate system. There you can do quite a bit of stuff (intersection, finding the closest point, changing ids etc).

1 Like
5

This does sound like a promising option. I am definitely going to look into this approach further.

Do you have any resources you could point me towards to learn more about how to actually achieve all of this in Slicer in a non-GUI manner?

6

I am sure there is with some python code, others might give you better pointers. I usually do this in R with ANTsR.

1 Like
7

Origin is usually chosen by the imaging tech based on the scout scans. If your imaging protocol specifies where to place the origin then you can expect that anatomical coordinates (LPS) to be fairly consistent. If they don’t pay attention to the origin placement but the size and position of the anatomical region is consistent between the scans then subtracting the centroid would probably somewhat consistent, too (within a couple of centimeters).

This is a relatively easy image registration task (same imaging modality, same imaging protocol, same patient, same patient orientation), so any registration toolkit should work well. Slicer provides graphical user interface for Elastix and BRAINSFit. I would expect that Elastix will work well with the default parameter settings, BRAINSFit probably requires some parameter tuning.

8

Thanks for the insight. I will look into Elastix to learn more about it. Can image registration with Elastix be codified (i.e. automated) for hundreds to thousands of registrations? Or is the Slicer GUI the only approach?

As a follow-up, I get the logic behind registering two CTs in order to align them anatomically, but how exactly does this registration translate into me being able to take existing sets of nodule centroid coordinates and aligning them anatomically. I think I am conceptually missing the connection.

9

Thanks for bringing this package to my attention. I am very comfortable using R, so I am happy to find out a package may exist to solve this problem.

10

I thought your challenge is not aligning, but making sure the labels of nodules are consistent across scans? I would probably try something along the lines where you take the centroid (a point), convert them into small spheres (may be 5mm depends on the size of the nodules, I guess). So from the registered scans, anyone that intersects a sphere with the first scan, you relabel the others.

So if nodule2 from scan2 and nodule4 from scan 3 intersect with nodule10 from original scan, you relabel the others as nodule10, or make some sort of a table matrix of correspondences.

Or you can calculate distances of new centroid coordinates from aligned scans to the reference scan, and pick the label of the one that it is closest to…

Isn’t that’s what you are trying to solve? If not, apologies I got your question completely wrong…

1 Like
11

No, I think you are understanding my issues rather well from my limited description. Indeed, we have a dataset whereby we have nodules that are identified at baseline and their ID is assigned starting at 1 and incremented by 1 for each subsequent finding. The same ID’ing and incrementing strategy is using for the second and third follow ups, but without consideration for previous scans. We do have a variable in our data that indicates whether a nodule on follow-up scans was pre-existing on the previous scan(s), however, since the ID assignment is based on whatever nodule the radiologist identified first, second, third, etc., the IDs are not consistent across scans, even for the same nodule.

So your suggestion to create a sphere around the nodules (perhaps with the size of the sphere dependent on the nodule size), and then look for intersection of spheres to determine if they are the same nodules could indeed work. But this approach would similarly require registration, or am I misinterpreting?

Or you can calculate distances of new centroid coordinates from aligned scans to the reference scan, and pick the label of the one that it is closest to…

Yes, I guess this was sorta my initial line of thinking. If the follow-up CTs were registered to the baseline scan, and we compared new nodule coordinates to the baseline nodule coordinates, we could do some sort of fuzzy matching to assign baseline labels to follow-up nodules.

1 Like
12

This fuzzy matching and alignment of points is implemented in SlicerIGT extension’s Fiducial registration wizard module. You need to provide the input as two markup fiducial lists (one point at each centroid), which can be implemented in a couple of lines of Python code (but for initial testing you can do it manually). If you enable point matching option in Fiducial registration wizard then number and order of input points do not need to match: the module performs an exhaustive search for the best match and gives you the transform between the two point sets. After you apply this alignment transform, the point coordinates should be quite close, so it should be easy to do the relabeling.

2 Likes
13

Thanks again for the great suggestion, @lassoan. This sounds like it could be a good solution to my problem. I will test drive this option and report back with my experiences.

14

So I have added the SlicerIGT extension and tried to play around with the Fiducial Registration Wizard, but I am unclear on a few things.

  1. I am getting a status/warning that Status: 'From' fiducial list has too few fiducials (minimum 3 required). I am unclear why this restriction is in place.

  2. I am unclear how this module could possibly spatially align two fiducials/coordinates without knowing the geometry of the CT scans from which they were derived. I have all of the CT scans in DICOM and NRRD format, shouldn’t I be using this information somewhere to help with the fiducial alignment?

For all of the work we have been doing in Slicer, we have been saving the fiducial file (.fcsv) for the centroids, so I have those data handy. Anyway, for a test case, I have selected the fiducials for a nodule I know is the same nodule on two different scans. The fiducial on baseline scan is [126.3, -38.5, -166.7], and for the 1-year follow-up scan is [121.4, 103.2, -215.9]. As you mentioned before, same imaging modality, protocol, patient, orientation, but it just so happens that for this specific case they are using different vendors (GE vs. Siemens, if that matters). How would it be possible to determine if these fiducials are spatially aligned without considering image geometry? Or am I misinterpreting how the Fiducial Registration Wizard works?

Sorry for my confusion, I really appreciate everyone’s help.

15

If you have at least 3 points (that are not arranged in a symmetric pattern) then only one transform exists that aligns them. Fiducial registration wizard displays a warning if multiple similarly good alignments exist due to symmetry in the point pattern.

16

Upon second thought, this method doesn’t appear to be able to solve my problem, correct? I only have a single point for each nodule (i.e. the centroid). Is image registration the only viable approach?

17

Yes, if completely different nodules may be found on different images (e.g., one found on each image and they are not the same) then your only choice is to register the images. If they are close enough to each other you could assume that they are the same.

1 Like
18

Thanks for confirming.

I have just ran the image registration using the Elastix extension in Slicer. It was very user-friendly. I set the baseline CT as the fixed volume, and the 1-year follow-up CT as the moving volume; I used the generic (all) preset (please let me know if you think another preset might be preferred for lung CTs).

I see that it produced two outputs, Volume.nrrd which I presume is the follow-up CT registered to the baseline geometry, and Transform.h5 which I’m guessing describes the transformation for resgitering the moving volume to the fixed volume. Am I now able to apply that transformation to the nodule coordinates? Any suggestions on how to do this next step?

For all the nodules in both scans for this patient, I have the nodule centroid coordinates saved in .fcsv files, and I also have binary segmentation masks in .nrrd files.

19

You can apply the computed transform to the point position in the coordinate system of the other image.

20

Does Slicer offer this functionality? I am not sure how to do this. Sorry for the helplessness, this is all fairly new to me.

Not to further complicate things, but when I was writing out my last comment, it struck me that it might be better to transform the binary masks than the centroid coordinates, do you agree? Thinking back to @muratmaga’s suggestion to form spheres around the centroid and check for intersection, couldn’t the binary mask be viewed as a (deformed) sphere around the centroid?

Would it be more reliable to see how much voxel intersection there is between the original mask and the transformed mask, rather than fuzzy matching the transformed centroid coordinate?