Part 2 multiple-enrollment data limit

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Current rule checkpoint

Live 42 CFR 2.34(a)(2) limits the initial multiple-enrollment disclosure to three categories: patient-identifying information, the type and dosage of the drug, and relevant dates. The pathway does not include the full chart, counseling notes, narrative assessments, payer history, unrelated medications, or attachments simply because a recipient might find them useful.

Use an allowlist

Current § 2.34(a)(2) supplies three categories. Define the exact identifiers, medication fields, units, dates, and code values needed for the route. Treat free text and attachments as blocked unless another verified authority applies.

Inspect what left

A template is only design evidence. Preserve the generated payload, message manifest, field mapping, recipient, event, consent, transmission timestamp, acknowledgment, correction, and reviewer. Test hidden metadata, default fields, copied narrative, and interface expansions.

Separate later coordination

The HHS fact sheet summarizes the current Part 2 framework. A later permitted communication under § 2.34 must stay within its own purpose and facts. The initial data limit is not a blanket authorization for the complete record.

Define an explicit field allowlist

List each permitted identifier, drug field, dosage value and unit, and date needed for the approved route. Record data type, source, transformation, required status, code set, null handling, owner, and reviewer. Use the narrowest identifying fields that reliably match the patient under the registry or program specification.

Keep free text, document attachments, diagnoses, treatment narratives, progress, assessments, laboratory data, payer fields, unrelated prescriptions, staff notes, and hidden application context outside the payload unless another independently verified authority supports a separate disclosure.

Map and test every source field

Trace EHR and medication-order fields through interface mappings, message construction, middleware, vendor transformation, logs, retries, storage, and recipient display. Check default segments, headers, filenames, comments, custom fields, metadata, debug output, and copied objects that can add data beyond the visible template.

Use synthetic and controlled test cases for long identifiers, dosage ranges, units, multiple medications, missing dates, corrected orders, and special characters. Preserve mapping and test versions.

Verify the actual transmission

For each event, link patient, treatment trigger, consent, recipient, distance where applicable, payload manifest, field values, message version, timestamp, secure method, acknowledgment, correction, and reviewer. A design document proves intent; the sent payload proves execution.

Where systems cannot retain the full protected payload safely, preserve a protected manifest or integrity record that lets reviewers verify fields without creating unnecessary copies. Apply access, retention, and sanitization controls.

Handle corrections and later communication

When identifying, medication, dosage, or date information is wrong, contain the error, send an authorized correction, link both versions, verify receipt, and assess any privacy or clinical risk. Prevent an updated medication record from silently generating unrelated fields.

Paragraphs (c) through (e) permit specific communications after registry responses in defined circumstances. Analyze those facts and purposes separately. The initial three-category allowlist does not become a full-record permission.

Audit for excess and omission

Sample successful, failed, retried, and corrected transmissions at the raw-message level. Confirm all required fields are present and accurate, no extra fields appear, recipients match, and logs do not expose broader content. Investigate both overdisclosure and missing medication or date data that can undermine safety.

Monitor mapping changes, vendor releases, new drug fields, code-set changes, and migrations. Require privacy and clinical review before promoting a modified payload.

Protect payload evidence and interface logs as Part 2 information. Limit access, encrypt storage and transfer, define retention, monitor exports, and sanitize test or retired media through approved procedures. Avoid copying raw production messages into ordinary development tickets.

Example

Twenty-one outbound messages are sampled. Eighteen contain only approved identifiers, medication type and dosage, and relevant dates; three include an assessment attachment. Payload compliance is 18 of 21 messages.

Payload-limit checklist

• approve a field-level allowlist for identifiers, drug type and dosage, and relevant dates;
• block narrative, attachments, diagnoses, payer data, unrelated drugs, and hidden metadata;
• trace fields through source, interface, middleware, vendor, logs, and recipient display;
• link every sent payload to event, consent, recipient, distance, and acknowledgment;
• control corrections and analyze later communications on their own authority; and
• audit raw successes, failures, retries, mappings, omissions, and excess fields.

The correct payload is both minimal and operationally accurate. A narrow rule does not excuse missing safety-critical values within its allowed categories.