You could do this by first setting the health value to 150 and then setting up a timer to restore that value after the desired amount of time, but that will not scale well, particularly once you have scenarios where other subsystems can be affecting (directly or indirectly) that value.
The more typical approach to this problem is to create an object represent the modifier or buff that is applied to some target. Part of that object's data is the remaining duration of the modifier. You maintain a list of these active modifiers somewhere that makes sense within the context of the rest of your game logic.
When you need to know the health (for example) of a character, you call that character's "get health" method, which in turn looks at all the active buffs that might modify health and applies them to the baseline health of the character before returning the value.
Then, since your game logic should ideally be functioning off of elapsed time between successive updates (as opposed to assuming every frame will last exactly the same amount of time), you go through each of these active modifiers every game logic update and decrease the time remaining on the modifier by the elapsed time since the last update.
If during that process, a modifiers remaining time reaches or falls below zero, you destroy that buff, which should in turn prevent that buff from being involved in the computation of whatever attributes or values it modified during the next game logic update.