Sure. If your monsters have health, then their health is going to need updating pretty much by definition. Option 1 would be to make each entity responsible for updating itself with an overloaded `update` function in sort of a "classical OOP" fashion:

    for(auto &entity: entities) {
        entity.update();
    }

You're then responsible for weaving the health changes into your update (or getting it from your parent). Weird stuff can happen if one entity updates before another, too: you likely want all of the health updates to occur after all of the damaging events. So now this update function has to register a deferred health update to occur down the line.

Option 2 with something like an Entity-Component-System design would have a "Health" system that handles health updates across the board.

    for(auto &damageEntity: entitiesThatDoDamage) {
        damageEntity.registerDamage();
    }

    for(auto &healthEntity: entitiesWithHealth) {
        healthEntity.updateHealth();
    }

Neither of these options is strictly better than the other. Option 1 is good if you need a lot of bespoke logic for health updates (dragons update differently from humans which are different from vehicles etc.). Option 2 is better if everyone has `newHealth = oldHealth - damage`. Things are generally more similar than they are different, so you end up changing all values of a single "kind" (structures-of-arrays) more often.

So, in option two, you'd be using SoA with a

  double health[];

which is the value that would be updated by healthEntity.updateHealth() ? So because you're sequentially updating only that attribute it should lend itself to being cache friendly and potentially prefetch prediction? (can't remember the term)

Yes, exactly. If you have to update everyone's health (you do) and the updates are pretty much the same (they are), then things don't get any more cache friendly than this.