The patient name field identifies the patient whose Part 2 records are covered by written consent. It anchors the consent to the correct person, while other fields govern the authorized discloser, records, recipient, purpose, expiration, signer, and date. Programs should match the name to an authoritative patient record, preserve historical and preferred names appropriately, resolve ambiguity, and avoid using name matching as proof of signer authority.
Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.
Identity is required, authority is separate
42 CFR 2.31 lists the patient's name as a required element. The signer may be the patient or another authorized person under a separate rule. Record both patient identity and signer identity so one field never substitutes for the other.
Show the patient's name in a form the patient and disclosure reviewer can recognize, while linking it internally to a durable restricted identifier. Keep signer name, signer role, authority, patient relationship, and signature event in separate fields. A portal proxy, parent, policyholder, caregiver, representative, or emergency contact should not replace the patient-name field.
Match identity through authoritative records
Use a controlled patient index and minimum necessary identifiers such as internal record number and date of birth in protected workflow fields where appropriate. Compare legal, former, preferred, and corrected names; program and service dates; duplicate or merged records; and identity confidence. Avoid requiring broad demographic data on the consent when internal linkage can distinguish the patient safely.
Protect name searches and match queues because their location in a Part 2 workflow can reveal program participation. Restrict access, mask results where practical, and avoid external filenames, email subjects, fax headers, print labels, or shared drive names that expose SUD context unnecessarily.
Match without overcollecting
Use the minimum identifiers needed to distinguish the patient, such as record number and date of birth in protected workflow fields when appropriate. Preserve corrections and aliases. Avoid displaying sensitive SUD status in broad search tools or external filenames.
Preserve the name shown at signing, authoritative patient record, aliases, change reason, effective dates, source, reviewer, and audit history. A later legal or preferred-name change should update current workflows without rewriting the signed artifact. When records were merged or split, retain the identity lineage and re-evaluate consent linkage.
Use a hold for duplicate candidates, demographic conflict, program mismatch, deceased-person identity, identity theft concern, missing durable identifier, or a consent tied to a merged record. Clarify through an approved safe route and qualified identity process. Do not select the closest match simply to meet a release deadline.
Validate every dependent consent field after identity match
Once the patient is identified, confirm the consent still covers the authorized discloser, meaningful records, recipient, purpose, expiration, signer authority, signature date, revocation, and actual request. A correct name does not cure a different defect. Likewise, a minor spelling variation may be correctable under policy without discarding otherwise valid consent; preserve the correction rather than altering the original.
Automated releases should use durable patient and consent identifiers, not name alone. Test hyphens, spaces, suffixes, transliteration, diacritics, aliases, twins, same-name patients, duplicate accounts, and name changes. Prevent a search result order from becoming identity evidence.
Require a documented match decision before release.
Review errors and downstream copies
If a consent or release linked to the wrong patient, stop pending work, preserve artifacts and logs, identify recipients and records, restrict access, and route privacy, security, legal, clinical, and patient communication decisions. Correct the patient index and dependent systems without deleting the original trail. Review whether the same matching rule affected other consents.
Example with identity review
Twenty-four consents reach review. Twenty-two match one patient record; one uses an unresolved duplicate and one contains a material demographic conflict. Identity readiness is 22 of 24 consents.
The program holds both releases, resolves one duplicate through authoritative records, and keeps the demographic conflict under restricted investigation. Eventual readiness becomes 23 of 24 without changing the original 22-of-24 result or overwriting the signed forms.
Patient-name checklist
- Record the patient and signer as separate people and fields.
- Link the displayed name to a durable restricted patient identifier.
- Preserve legal, preferred, former, corrected, and signed names.
- Protect search, filenames, queues, messages, and printed labels.
- Hold duplicates, conflicts, merges, and uncertain identities.
- Validate every other consent field after patient match.
- Investigate wrong-patient linkage across recipients and systems.
Owner controls
The 2024 final rule provides current consent context. Use authoritative identifiers, duplicate detection, signer separation, restricted access, correction history, mismatch holds, escalation, and audit evidence.
Monitor exact and ambiguous matches, duplicate records, merged identities, name corrections, held releases, wrong-patient events, and resolution age. Audit from consent-based disclosures back to one authoritative patient and from patient-index changes into active consents. Retest after matching, portal, EHR, migration, or program changes.
Related terms
Sources
Take the next step with clarity
Whether you are finding care, growing as a clinician, or building a stronger ABA practice, Finni brings the people, tools, and support together to help you move forward.
Start or grow your ABA practice with Finni