Data Governance Starter Policies
Written for GME, UME, and veterinary programs. The bracketed fields are yours to customize; the downloadable version is a Word file your institution can edit and adopt as its own.
Every distrusted report was a hygiene failure six months earlier. The report is where bad data becomes visible. It is never where bad data begins.
The five policies
| # | Policy | The rule in one line |
|---|---|---|
| 01 | Identity & duplicates | One person, one account, matched on an identifier that never changes. |
| 02 | Naming standards | One written page of canonical names and codes that outlives any coordinator. |
| 03 | Retention & archiving | Deactivate, never delete. A 15-year-old verification request takes two minutes. |
| 04 | System of record | Every data domain has one authoritative system. Copies inherit corrections, never make them. |
| 05 | Access & privacy | Access matches the current role, ends with it, and is reviewed once a year. |
How to use this document
Fill in the bracketed fields. Name one owner per policy. Adopt it at a program or department meeting, note the date in the adoption block at the end, and have every new coordinator read it in their first week. Each policy fits on one page on purpose.
Policy 01 — Identity & duplicate prevention
A duplicate account is free the day it is created and expensive the day someone reconciles years of split records by hand. This policy makes duplicates hard to create and quick to resolve.
01. One person, one account. An account follows a person across roles. When a resident becomes faculty, or a student becomes a trainee, the existing account is promoted. A role change is never a reason to create a new account.
02. Match on an identifier that never changes. Before creating any account, search by employee / student ID, then by name variants. Email is never the matching key: one person often has a university address and a hospital address. GME programs: use the identifier your IRIS reporting requires.
03. One email wins. The system of record uses the institutional email. All other addresses are recorded as secondary, never used to create a record.
04. One door for new accounts. New accounts are created only by role or team. When two departments share a trainee, the second department requests access to the existing account rather than creating its own.
05. Duplicates get merged within a week. Anyone who finds a suspected duplicate reports it to owner name, who merges or deactivates it within 5 business days and notes the surviving account.
Discussion prompt for your team. Do we have a written rule for which email or ID wins when there is a variation, or does each coordinator decide in the moment?
Policy 02 — Naming standards
Three labels for one rotation split every count three ways, silently. Nobody notices until totals stop matching. The remedy is one written page that outlives any single coordinator or chief resident.
01. The SIS is the source of truth. Course and rotation names and codes match your student information system exactly, in every downstream system, spreadsheet, and report.
02. Site variants extend the code, never replace it. When a rotation runs at multiple sites, keep the canonical code and append a site suffix: Internal Medicine at Riverbend becomes im-riverbend. The canonical code stays searchable everywhere.
03. The naming page is owned and reviewed. Owner name keeps the one-page standard current and reviews it every academic year. New names in any system require the owner's sign-off before creation.
04. Retired names are mapped, not abandoned. When a name changes, the old label is recorded next to the new one so historical reports still reconcile.
Start your vocabulary table
| Canonical name | Code | Never use |
|---|---|---|
| Internal Medicine | im (site variant: im-riverbend) | "Med-IM", "IM Rotation" |
GME. Rotation and site codes should reconcile with the sites on your IRIS cost report, so FTE lands at the hospital that can claim it.
UME. Curriculum tags drift fastest: "Cardio" vs "Cardiology Block" vs "CV Systems". Standardize tags before accreditation mapping, not during.
Veterinary. Procedure lists breed near-duplicates. Sort the list alphabetically once a year and read adjacent pairs: most duplicates are neighbors.
Policy 03 — Retention & archiving
Verification requests arrive 10, 12, 15 years after training ends. A deleted record means paper files, someone's memory, and a week of phone calls. An archived record means a two-minute lookup.
01. Deactivate, never delete. Once a record has been used (a person evaluated, a form submitted, a procedure logged), it is archived, never deleted. This applies to every system the program uses, not only the ones that enforce it.
02. Archiving is part of offboarding. The offboarding checklist for graduates, departing faculty, and closed sites includes an "archive, don't delete" step, owned by role or team.
03. Clutter is a view problem, not a data problem. If staff delete records to clean up their screens, fix the default views and filters so archived records stay out of daily work. Fix the system, not the person.
04. Deletion rights are rare and logged. Only role holds deletion rights. Any deletion request is logged with the reason and the requester before it is carried out.
05. Verification readiness is the test. The standard: any verification request for a former trainee is answerable within 2 business days from archived records alone.
Discussion prompt for your team. In each of our systems today, who can delete a record, and would we know if they did?
Policy 04 — One system of record per domain
When the same fact lives in three systems, the systems will eventually disagree. This policy decides the winner in advance, so corrections happen once and flow downstream.
01. Every domain has exactly one authoritative system. For each data domain below, one named system holds the truth. Every other system, spreadsheet, and report is a copy of it.
02. Corrections happen at the source. Fixing a wrong name or date in a downstream report fixes one report, once. Fix it in the system of record and every future copy inherits the correction.
03. Disagreements resolve upstream. When two systems disagree, the system of record wins by default. If the system of record is the one that's wrong, it gets corrected first, then the copies follow.
04. Bulk imports use the same door. A spreadsheet import is record creation at scale. Every import is checked against the duplicate rules (Policy 01) and the naming standard (Policy 02) before it lands.
Your system-of-record registry
| Domain | System of record | Owner |
|---|---|---|
| People, roles & contact details | HR system / SIS | |
| Courses, rotations & curriculum | Student information system | |
| Clinical schedules & site assignments | ||
| Evaluations, assessments & logs |
Discussion prompt for your team. For each row, could two people in your program name the same winning system without conferring first?
Policy 05 — Access & privacy
Accounts outlive roles. The coordinator who changed jobs in May can often still edit records in November, and nobody remembers why. Access is part of data governance, not an IT afterthought.
01. Least privilege by default. People get the access their current role needs, nothing more. "Admin for convenience" is how accidental edits and deletions happen.
02. Role changes end access, the same day. The offboarding checklist that archives records (Policy 03) also revokes access, for departures and for internal role changes, owned by role or team.
03. An annual access review. Once a year, owner name reads the full user-permission list. Every entry either matches a current role or is removed.
04. Sensitive identifiers stay need-to-see. Government identifiers (such as SSNs where IRIS reporting requires them) are visible only to the roles that file those reports. FERPA applies to student and trainee records in all three segments; examples and screenshots never include real trainee data.
Discussion prompt for your team. Could you produce, today, a list of everyone who can edit trainee records, and would anything on it surprise you?
Making it stick: ownership, cadence, and adoption
A policy without an owner and a calendar is a suggestion. Owners live in the registry in Policy 04; the calendar lives here.
The calendar
Quarterly — one starter metric, watched as a trend. GME: % of evaluations completed within 14 days of rotation end. UME: % of curriculum objects mapped to the standards framework. Veterinary: % of logged procedures with both site and supervisor recorded.
Monthly — the exception report. A short list of records that break the rules: accounts without an ID, procedures without a supervisor, evaluations mapped to retired items, names that aren't on the standard. Work the list, not the whole database.
Quarterly — the data downstream review. The people who read the reports show the people who enter the data what broke. Thirty minutes. Visibility, not blame.
Annually — the segment checkpoint. GME: every June, before the interns arrive, archive graduates and verify site and faculty lists. UME: rotate audits so one clerkship or block is reviewed each month, and verify data before MSPE drafting starts. Veterinary: treat the COE interim report as the annual hygiene review and attest every active clinical site.
Adoption
| Adopted by | Date | Next review |
|---|---|---|
Starter language, not legal advice. Your institution's counsel, privacy office, and compliance team own final approval and any changes required by local policy or law.