HIPAA Audit Checklist for Radiation Oncology CT Simulation Export Workflow to Medical Physics

HIPAA Compliance Requirements for DICOM-RT Data

DICOM-RT objects used in a radiation oncology CT simulation—CT images, RTSTRUCT, RTPLAN, and RTDOSE—can contain Protected Health Information (PHI) in both metadata and pixels. Treat every export to medical physics as an ePHI disclosure, whether the recipient is internal or an external partner.

Apply the HIPAA Privacy Rule’s minimum necessary standard and the Security Rule’s administrative, physical, and technical safeguards. If any external party (e.g., offsite physics group, cloud vendor, or routing service) handles the data, a Business Associate Agreement (BAA) must be executed that specifies permitted uses, safeguards, breach notification, and subcontractor obligations.

Classify each dataset before export: fully identified (clinical care), limited dataset, or de-identified per Data De-identification procedures. Document your rationale for the chosen level and retain it with the export record to support audits.

Checklist

• Confirm purpose of export (QA, secondary calc, commissioning) and apply the minimum necessary standard.
• Verify a Business Associate Agreement (BAA) is in place for every non-covered-entity recipient and service in the chain.
• Complete risk analysis for DICOM-RT export pathway and approve compensating controls.
• Define data classification (identified, limited, de-identified) and document justification.
• Map responsibilities for privacy, security, and breach response across teams.

Pre-Export Documentation and Training

Standardize the CT simulation export workflow with a written SOP that covers selection of required objects, de-identification settings, QC steps, encryption, and delivery methods. Train staff who perform exports (therapists, dosimetrists, physicists) and assess competency annually and after system changes.

Require pre-export forms that capture the requestor, patient pseudonym or MRN, destination, dataset scope, de-identification profile, and approval. Maintain training records, signed acknowledgments, and versioned SOPs for audit readiness.

Checklist

• Use a controlled request form linked to an internal ticket or case ID.
• Verify staff training completion and role authorization before granting export rights.
• Record dataset components to be sent (CT, RTSTRUCT, RTPLAN, RTDOSE) and why each is needed.
• Capture reviewer sign-off for de-identification settings and QC plan prior to export.
• Store SOP and tool configuration versions with the export record.

DICOM Metadata Removal Procedures

Implement a consistent de-identification profile aligned with DICOM PS3.15 concepts, ensuring that downstream physics tasks remain valid. When pseudonymization is used, maintain a secure re-identification key accessible only to privacy-authorized personnel.

Remove or replace direct identifiers (e.g., PatientName [0010,0010], PatientID [0010,0020], PatientBirthDate [0010,0030], PatientAddress [0010,1040]) and purge free-text fields likely to contain PHI (e.g., StudyDescription, SeriesDescription, ProtocolName). Retain technical attributes essential to dose geometry and registration (e.g., FrameOfReferenceUID, ImageOrientationPatient, ImagePositionPatient, PixelSpacing, SliceThickness). For RT objects, ensure referenced UIDs remain internally consistent after any remapping.

Set Patient Identity Removed (0012,0062) to “YES” when applicable and document the De-identification Method and Code Sequence to enable traceability. Date handling should follow a documented policy (e.g., consistent date shifting) that preserves relative timing needed for physics analysis without exposing actual dates.

Checklist

• Apply a validated de-identification profile with version control and change logs.
• Strip direct identifiers; redact free-text fields; preserve essential geometric/dose attributes.
• Regenerate UIDs as needed while maintaining referential integrity across RT objects.
• Record Patient Identity Removed and De-identification Method in each instance.
• Validate outputs with automated DICOM checks and manual spot reviews before delivery.

Pixel Data and Overlay Management

Even after metadata scrubbing, PHI can exist in pixel data as burned-in text or overlays. Inspect CT series for corner annotations, scouts, dose screens, and any acquired or post-processed graphics. If Burned In Annotation (0028,0301) is “YES” or unknown, perform pixel redaction.

Remove DICOM overlays (60xx group) and presentation states that include text labels or graphics revealing PHI. When redacting pixels, use consistent masks that do not alter image dimensions or spacing, preserving dose calculation integrity and RTSTRUCT alignment.

Checklist

• Automate detection with OCR on image corners; verify with human QC for random slices.
• Delete overlays and presentation states containing identifiers; keep original geometry intact.
• Set Burned In Annotation appropriately and re-run QC after redaction.
• Document redaction coordinates/policy and store before/after thumbnails for audit evidence.

Access Control and User Authentication

Enforce Role-Based Access Control (RBAC) so only authorized roles can stage, approve, or transmit exports. Assign unique user IDs, require Multi-Factor Authentication (MFA) for systems that handle ePHI (TPS, PACS/VNA, DICOM router, secure file transfer), and implement session timeouts and automatic lockouts.

Restrict export destinations to whitelisted endpoints. For break-glass scenarios, require documented justification and immediate post-event review. Offboard users promptly and review role assignments at least quarterly.

Checklist

• Define RBAC roles (requestor, preparer, reviewer, approver, transmitter) with least privilege.
• Enable MFA on all portals and remote access paths touching ePHI.
• Whitelist destination AETitles, IPs, and secure file endpoints; block ad hoc sharing.
• Review access rights quarterly and audit recent exports for appropriateness.

Encryption and Data Protection Practices

Encrypt ePHI at rest and in transit. Use Encryption Standards (AES-256, TLS 1.2+) or stronger. For file transfer, prefer mutually authenticated DICOM TLS, SFTP/SSH, or HTTPS with certificate validation; avoid email unless using approved, end-to-end encrypted methods with enforced policy controls.

When using removable media, use hardware-encrypted drives (AES‑256), apply tamper-evident seals, and transmit passphrases out-of-band. Protect keys in a centralized KMS, rotate them per policy, and log all key operations. Verify integrity with checksums and compare on receipt before import.

Checklist

• Ensure TLS 1.2+ for network transport and AES-256 for storage, backups, and media.
• Implement certificate pinning or mutual TLS for recurring endpoints where feasible.
• Generate and verify checksums (e.g., SHA-256) at send and receive.
• Prohibit unencrypted email and consumer sync tools for PHI-bearing data.

Audit Controls and Incident Response Planning

Enable comprehensive Audit Trail Logging across TPS, PACS/VNA, DICOM routers, file transfer gateways, and operating systems. Log who exported, which dataset (by pseudonym), what objects, when, where sent, method, checksum, and approval chain. Forward logs to an immutable or tamper-evident repository with time synchronization and retention that meets policy.

Establish alerts for anomalous volumes, off-hours exports, new destinations, or failed de-identification checks. Review dashboards daily and perform formal monthly audits with documented outcomes. Test restore and chain-of-custody reconstruction at least annually.

Your incident response plan should define triage, containment, forensics, notification workflows, and corrective actions. Practice tabletop exercises, document lessons learned, and update SOPs, RBAC, and tooling based on findings.

Checklist

• Centralize export and access logs; protect them with immutability and strict access.
• Alert on abnormal export patterns and policy violations in near real time.
• Run monthly audits; track metrics (false positives, time-to-review, incidents per quarter).
• Maintain a tested incident response playbook with clear roles and escalation paths.

Conclusion

A disciplined HIPAA audit checklist for the CT simulation export workflow ensures you share only what is necessary, strip PHI from both metadata and pixels, secure access with RBAC and MFA, protect data using AES‑256 and TLS 1.2+, and prove compliance with robust audit trails and practiced incident response. Document each step, review regularly, and refine controls as systems and risks evolve.

FAQs.

What is the minimum necessary standard for exporting DICOM-RT files?

Export only the objects and attributes required to meet the stated physics purpose. For example, if dose recalculation is not needed, omit RTDOSE; if contour review alone is needed, send CT and RTSTRUCT only. Remove direct identifiers, restrict free-text, and document why each exported component is necessary.

How should de-identification of DICOM metadata be performed?

Apply a validated de-identification profile that strips direct identifiers, redacts free-text fields, and preserves geometry-critical attributes. Use consistent pseudonyms and, if needed, maintain a secured re-identification key. Set the appropriate de-identification flags and record the method used for traceability.

What access controls are required for medical physics workflow?

Implement Role-Based Access Control (RBAC) so only trained, authorized users can stage, approve, and transmit exports. Require Multi-Factor Authentication (MFA), unique user IDs, session controls, destination whitelisting, quarterly access reviews, and prompt offboarding for departing users.

How is audit logging implemented for HIPAA compliance?

Capture end-to-end Audit Trail Logging: user identity, time, patient pseudonym, objects exported, destination, transport method, checksum, and approvals. Centralize logs in an immutable repository, set alerts for anomalies, review routinely, and retain records per policy to support investigations and audits.