Returning on the hungarian notation for Java, one very important thing to consider is how to maintain coherent information. If you don't pay attention to maintain your "fbsStatus" and other "hcnChilds" up to date with their real type and use across the refactoring cycles, it's more a danger than a help. That means we must have a dimension of variable naming in the refactoring patterns.

Let's take a simple example. A property "available" has a boolean type and its no more sufficient for the exemple use, so you change its type to int. 
boolean m_bAvailable => int m_bAvailable

In parallel, you must rename it.

int m_bAvailable => int m_nAvailable

The type has changed, you must change the accessors.

void setAvailable(boolean p_bAvailable) => void setAvailable(int p_nAvailable)
boolean isAvailable() => int getAvailable()

And then change the calling code, that is change the variable types and names where applicable. The complexity of this refactoring is almost doubled compared with the one without hungarian notation. So we need style checker which can handle this (I wonder if Checkstyle does it?). By the way, there is a little problem now, "getAvailable" doesn't sound right at all, it should be "getAvailability", *sig*.