Three hospitals, three answers
In a single-doctor clinic, the doctor takes the vitals during the consultation. In a busy polyclinic, a nurse takes them in a side room before the patient goes in. In a larger hospital, they are taken at a station between registration and the consulting room, by someone the doctor never speaks to.
All three are correct. Software that hard-codes one of them forces the other two to either change how they work or record vitals in the wrong place, and they will choose the second.
The failure is quiet
Nobody reports this as a bug. The nurse types the blood pressure into a notes field, or the doctor writes it in the examination text, and everyone gets on with the day.
Six months later the hospital asks for a trend of a patient’s blood pressure and discovers there is no structured data to trend. It is prose scattered across a hundred consultations. The workflow assumption did not break anything visibly; it just quietly made the record less useful.
Configuration, not a branch
The right shape is that the hospital declares which vitals it takes and at which point in the visit, and the software puts the capture step there. It is a setting, not a code path, so a clinic that changes how it works next year changes a setting.
The related decision is who may read that configuration. A permission named for the screen that edits a setting is the wrong key for the screens that merely use it. If only the administrator can read how vitals are configured, the nurse’s form fails against the settings that describe it. Read and manage are two different keys.
The general principle
How a hospital runs is configuration. What a hospital may do is entitlement. Who may do it is permission. Keeping those three apart is most of what makes a system fit more than one customer without forking.
When you evaluate software, it is worth asking which of your workflows are settings and which are the vendor’s assumptions. The second kind become your problem later.