Version Control Playground
Every FHIR profile, clinical decision rule, terminology map and hospital config lives in a repository — and 'who changed this rule, when, and who approved it?' is an audit question, not a developer one. Learn the whole vocabulary with no command line: repo, commit, branch, merge, pull request, clone, fork, push, pull, tag, release, revert, CI/CD, deploy, rollback. Follow one change to an allergy-alert rule from edit to live, then work the disasters — a committed API key, patient data in a repo, a force-push that erased a colleague's work. Turn on 'Show code' for the real git commands. Synthetic data only.
What version control is, in one sentence — and why it belongs in a health-IT course. Clinical logic is code now: a drug-interaction alert and a FHIR profile are both files that change, so 'who changed this and who approved it' is a governance question.
In one sentence
Version control is a system that remembers every version of every file, who changed it, when, and why — and lets you go back.
If you have used Track Changes in a document, you already have the idea. Version control is that, for an entire system rather than one file — and it never forgets. Git is the tool that does this; GitHub is a website that hosts Git repositories and adds review and collaboration on top. They are not the same thing, and the difference confuses everyone at first.
Why this belongs in a health-IT course
Because clinical logic is code now. A drug-interaction alert, a FHIR profile, a terminology map, an order set — each is a file that changes, and each change can affect what a clinician is told about a patient. So the questions version control answers — what changed, who changed it, why, who approved it, and can we put it back — are governance questions, not developer conveniences. That is the whole argument.
Four situations you may recognise
allergy-rules-FINAL-v3-revised-DrRao-USE-THIS-ONE.xlsx sits on a shared drive.
One file in a repository, with every past version recoverable and labelled.
You have almost certainly seen the first pattern. Nobody can say which file is authoritative, and the person who knows is on leave. Version control makes 'which one is current' unanswerable-by-accident.
A clinical decision rule changes and the alert starts firing on the wrong patients. Nobody knows what changed.
Every change is a commit: what changed, who made it, when, and why — with a one-click view of the difference.
This is the audit question, and it is the strongest argument for version control in health IT. Not developer convenience — accountability. 'Who approved this rule reaching production?' must have an answer.
Two analysts edit the terminology map at the same time. One saves last and silently erases the other's work.
Both work on branches; the system detects the overlap and forces a human to decide.
Silent overwrite is the failure mode of shared drives. Version control cannot prevent disagreement — it just refuses to let it happen invisibly.
A broken FHIR profile is deployed on Friday. Fixing it means remembering what it looked like before.
Roll back to the previous release in seconds, because the previous release still exists exactly as it was.
The ability to undo is what makes it safe to change things at all. A team that cannot roll back will avoid deploying, and a system that is never updated is its own kind of clinical risk.