Written for GME, UME, and veterinary programs. Five one-page policies stop the failures that show up late in a report nobody trusts: duplicate people, drifting names, deleted records, disagreeing systems, and leftover access. Fill the brackets, name an owner, and treat that as the adopted policy. The Word file is a meeting handoff, not the system of record.
Verified September 1, 2026 against FERPA on studentprivacy.ed.gov and ACGME Residency CPR effective July 1, 2026. Sources at the end.
What problem do these five policies actually stop?
Five failure modes that show up late, in a report nobody trusts: duplicate people, drifting names, deleted records, disagreeing systems, and leftover access. Each policy fits on one page on purpose. Fill the brackets, name an owner, and treat that as the adopted policy.
| Policy | Owner | Clock | Artifact | Failure if skipped |
|---|---|---|---|---|
| 01 Identity | Identity owner who creates accounts | Before any new account; merge within five business days | One person, one account, matched on an identifier that never changes | Years of split records reconciled by hand |
| 02 Naming | Naming-page owner | Reviewed every academic year; sign-off before a new name is created | One written page of canonical names and codes | Three labels for one rotation split every count three ways |
| 03 Retention | Offboarding / archive owner | At graduate, faculty, and site offboarding; verification in two business days | Archived record; GME final evaluation in the resident's permanent institutional record | A deleted record means paper files, someone's memory, and a week of phone calls |
| 04 System of record | Domain owner named in the registry | Standing; corrections at the source before copies | One named authoritative system per domain | Three systems disagree and nobody knows the winner |
| 05 Access | Access-review owner | Same day as a role change; full permission list once a year | Access that matches the current role | The coordinator who changed jobs in May can still edit records in November |
How do we use this document?
Fill in the bracketed fields, name one owner per policy, and 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.
Download the editable policy set (Word). Same five policies, in a file your counsel and privacy office can mark up. Put names on the adoption block. The standing registry then lives in the system of record. The Word file is a meeting handoff, not that system.
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. This guide's own GME practice: 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.
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. This guide's own GME practice: 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 you map curriculum objects to a standards framework, not during the mapping.
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 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. A 15-year-old verification request takes two minutes.
For GME, this is not only local hygiene. Deactivate, never delete, is this guide's own rule. ACGME does not print a universal keep-it-N-years clock.
| Body | Clock | What it is not |
|---|---|---|
| ACGME 5.2 | The program director must provide a final evaluation for each resident upon completion of the program. | A coordinator courtesy, or a file you may delete once the screen looks cluttered. |
| ACGME 5.2.b | The final evaluation must become part of the resident's permanent record maintained by the institution, and must be accessible for review by the resident in accordance with institutional policy. | A keep-it-N-years term printed by ACGME. |
| Background and Intent | primary verification of graduate medical education is important to credentialing of physicians for further training and practice; such verification must be accurate and timely; Sponsoring Institution and program policies for record retention are important to facilitate timely documentation of residents who have previously completed the program. | A national retention calendar. The clock lives in your institutional policy. |
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. This guide's own rule is still: deactivate, never delete.
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. This guide's own standard: any verification request for a former trainee is answerable within [2] 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.
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 |
Name the winning system for enrollment, evaluations, and outcomes before you fill the calendar metrics. Copies inherit corrections. They never make them.
Policy 05: Access & privacy
Who may open a trainee file, and when does access end? Access matches the current role, ends with it, and is reviewed once a year. 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. Education records are not an open drawer. Fill the table, then ask counsel which of your files it covers. This template does not interpret other privacy statutes.
| FERPA object | What the fetched page says | What this template does not settle |
|---|---|---|
| Education record | Education records are records that are directly related to a student and that are maintained by an educational agency or institution or a party acting for or on behalf of the agency or institution. | Whether a given GME or hospital file is an education record is a question for your privacy office and counsel, not a sentence this template can settle. |
| Coverage | FERPA applies to educational agencies or institutions that receive funds from programs administered by the U.S. Department of Education, including postsecondary institutions, such as colleges and universities. | Automatic coverage of every GME, hospital, or veterinary file. |
| School officials | FERPA does not permit disclosure of personally identifiable information from students' education records to any of its employees without consent. Disclosure without consent is limited to school officials within the educational agency or institution that the institution has determined to have legitimate educational interests in the information. Generally, a school official has a legitimate educational interest if the official needs to review an education record in order to fulfill his or her professional responsibility. | Other privacy statutes. Government identifiers stay need-to-see: visible only to the roles that actually file the reports that use them. Examples and screenshots never include real trainee data. This template does not interpret other privacy statutes. |
How do we make this stick?
A policy without an owner and a calendar is a suggestion. Owners live in the registry in Policy 04. The calendar lives here.
| Cadence | What you watch | Whose clock |
|---|---|---|
| Quarterly | One starter metric, watched as a trend. This guide's own starter metrics, not accreditor clocks. 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. | This guide |
| 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. | This guide |
| 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. | This guide |
| 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. | This guide. Veterinary COE interim is this guide's own annual hygiene cue, not fetched AVMA requirement text. |
Adoption
| Adopted by | Date | Next review |
|---|---|---|
Where this lives in Medtrics
Named owners run the five policies as a standing process: people first, then a written page, then a platform that keeps enrollment, evaluations, and outcomes from splitting across copies. The Word file is a meeting handoff into that process, not the system of record.
Medtrics is one such platform: Enrollment, evaluations, and outcomes live in one system of record with a governed KPI layer and exportable analytics. For curriculum names and maps, start at curriculum mapping. For GME retention of the final evaluation as a permanent record, see GME Leaders.
None of this replaces the five policies. Named owners, the registry, and the calendar still do the work. A platform makes that structure durable when people leave.
Sources and status
This template was verified on September 1, 2026 against the FERPA pages and the ACGME Residency Common Program Requirements named above. After publication, the current editions on studentprivacy.ed.gov and acgme.org remain the only authoritative statements of any requirement. Fill-in fields, GME identifier practice, the verification-lookup standard, and the calendar metrics are this guide's own operating model.
- Education records: records directly related to a student and maintained by an educational agency or institution or a party acting for it. What is an education record?
- FERPA coverage: educational agencies or institutions that receive funds from programs administered by the U.S. Department of Education, including postsecondary institutions such as colleges and universities. To which educational agencies or institutions does FERPA apply?
- School officials: disclosure without consent is limited to school officials with a legitimate educational interest; not every employee. May an institution disclose education records to any of its employees without consent?
- ACGME Residency Common Program Requirements effective July 1, 2026: final evaluation becomes part of the resident's permanent record; Background and Intent on primary verification and record-retention policies. FAQs incorporated July 1, 2026 and effective July 1, 2026. Common Program Requirements
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.
ACGME and the U.S. Department of Education are named descriptively. This article is an independent operational template from Medtrics, not Department of Education or ACGME guidance, and nothing here promises any accreditation outcome.