Your policies, filled in and ready to redline
Six answers. The five starter policies come back with your institution, your owner, and your review cadence written into them — as an editable Word file, not a locked PDF. No form before the download.
Read the policies firstYour six answers
Anything you leave blank stays a bracketed field in the document.
.docx · opens in Word and Google Docs · no email required
Live preview
Updates as you type
Data Governance Starter Policies
Adopted by [Institution name] for Graduate Medical Education (GME). Policy owner: [Policy owner], [Owner title]. Effective [Effective date]. Reviewed: annually. Accreditation context: ACGME.
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.
How [Institution name] uses this document
Each policy fits on one page on purpose. [Policy owner] owns the set and reviews it annually. Every new coordinator reads it in their first week. Any remaining bracketed field is a decision [Institution name] still has to make.
| # | 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. |
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 the [Institution name] employee or student ID, then by name variants. Email is never the matching key: one person often has a university address and a hospital address.
03. One email wins. The system of record uses the institutional [Institution name] email address. 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 the team [Policy owner] designates. 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 [Policy owner], who merges or deactivates it within five business days and notes the surviving account.
Discussion prompt: 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 student information system is the source of truth. Course and rotation names and codes match the [Institution name] 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. The canonical code stays searchable everywhere.
03. The naming page is owned and reviewed. [Policy owner] keeps the one-page standard current and reviews it annually. 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.
[Institution name] vocabulary table
| Canonical name | Code | Never use |
|---|---|---|
| Internal Medicine | im (site variant: im-riverbend) | “Med-IM”, “IM Rotation” |
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 [Institution name] 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 the team [Policy owner] designates.
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. Deletion rights are held only by roles [Policy owner] names in writing. 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 [Institution name] trainee is answerable within two business days from archived records alone.
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.
[Institution name] system-of-record registry
| Domain | System of record | Owner |
|---|---|---|
| People, roles & contact details | [Policy owner] | |
| Courses, rotations & curriculum | ||
| Clinical schedules & site assignments | ||
| Evaluations, assessments & logs |
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.
03. An access review on the calendar. On the review cycle set above (annually), [Policy owner] 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 are visible only to the roles that file reports requiring them. FERPA applies to student and trainee records; examples and screenshots never include real trainee data.
Making it stick: ownership, cadence, and adoption
A policy without an owner and a calendar is a suggestion. The owner is [Policy owner], [Owner title]. The calendar is below, and it is reviewed annually against ACGME expectations for Graduate Medical Education (GME).
Quarterly — one starter metric, watched as a trend. Pick one number that reflects hygiene, not performance, and watch its direction rather than its value.
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 checkpoint. Archive graduates, verify site and faculty lists, and confirm the registry in Policy 04 still names the right systems.
Adoption
| Adopted by | Date | Next review |
|---|---|---|
| [Institution name] | [Effective date] | annually |
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.
Want us in the room for the IT review?
We'll walk your IT and compliance team through the policies and answer the questions that usually hold up a decision.
Contact us