The classical user-story describes a desired feature from the point of view of a user. It is very synthetic in view of the 3 C: stories are written on a Card, they are the promise for a Conversation (an interactive exchange with users), and they are completed with a Confirmation (criteria for checking that expectations are met).
With this in mind, user stories only tells who needs what feature for which purpose:
As a doctor, I want to prescribe medication so that patients get the right dose
But it's hardly sufficient to produce useful software. It's only a reminder that you have to talk to a doctor about the medication prescription and clarify how the software could best help to achieve this goal. That discussion -- the direct interaction with the user to understand the needs -- is the real key to success with user-stories. The story template is just a mean to this end.
The textual narrative is story telling. It's the outcome of the discussion with the user, if captured/written down. It is very useful, because the doctor can project herself in the future and imagine how it could work with the software, and the team can understand what is to be delivered with the relevant details. It is vital to tell this story with a focus on what should/could be, and not on what was until now.
The task-based presentation is a further decomposition of the narrative into key parts, that provide the more precise description of the feature along with expectations that the software shall meet.