Radiology image sharing policy maps HIPAA to PACS

Vendor agnostic policy for hospital admins: map HIPAA and BAA to PACS/DICOM controls, verify DICOM TLS, and use 5 step onboarding checklist.

Published 6 October 2026
HIPAA PACS policy title card

A compliant radiology image sharing policy rests on three pillars: a HIPAA-compliant business associate agreement, enforced technical controls including DICOM TLS, at-rest encryption, role-based access, and audit logging, and documented QA and credentialing for every remote reader touching your studies. Regulators point to HIPAA cloud computing guidance, the ACR-AAPM-SIIM technical standard, and NIST SP 1800-24 as the baseline references. Teleradiology providers are one route to meeting these requirements without building the infrastructure yourself.


TL;DR:

  • Verifying technical controls requires vendor demonstration of DICOM TLS handshake, approved at-rest encryption standards, and network segmentation for compliance.
  • Contracts must assign Security Rule responsibilities clearly, with audit log review scheduled regularly and breach notification procedures explicitly defined.
  • Role-based access should differentiate permissions for radiologists, technologists, and administrators, with data retention periods and data portability requirements documented in the policy.
  • Vendors must be able to produce live audit logs from DICOM TLS handshakes during proof-of-concept testing to demonstrate readiness for secure image transfer.
  • Operational governance requires ongoing credentialing, peer review, risk analysis, and scheduled testing of downtime procedures to maintain compliance and system integrity.

Table of Contents

Core policy elements every document needs

Your policy document is only as useful as the clauses it forces into existence. Start with the business associate agreement language, because every other control depends on it. Under HHS guidance, a cloud service provider that creates, receives, maintains, or transmits electronic protected health information is a business associate and needs a BAA, even if that provider never holds a decryption key. That single rule eliminates the common assumption that "no-view" storage sidesteps HIPAA obligations.

From there, your policy should spell out who can do what. Role-based access control sounds simple until you try to define every role: radiologist, technologist, PACS administrator, billing staff, and the vendor's own support team each need a distinct permission set, with administrative functions walled off from routine viewing.

Retention terms deserve their own clause rather than a vague reference to "applicable law." Specify how long DICOM originals, compressed previews, and derived reports are kept, and who owns the data if you terminate the relationship.

  • Define BAA scope: permitted uses, disclosures, and subcontractor flow-down obligations.
  • Assign RBAC tiers for radiologists, technologists, administrators, and vendor support staff.
  • Set retention and disposition periods for native DICOM, previews, and reports, plus a data portability clause.
  • Require audit log generation with a stated review frequency, not just "logs exist."
  • Document breach notification timing and the testing that proves the plan works before you need it.

Each of these items should map to a line in your vendor contract, not just an internal memo, because an unenforced policy element is not a control.

How do you verify the technical controls actually work?

Policy language means little without technical proof behind it. For transport, require DICOM TLS, ideally mutual TLS, between PACS endpoints, and HTTPS for any DICOMweb access using WADO-RS or WADO-URI. NIST SP 1800-24 demonstrated these exact controls in a reference PACS environment and recommended network segmentation and system hardening alongside them.

At-rest encryption needs the same specificity: state the encryption standard, who holds the keys, and how often they rotate. If a vendor manages key rotation, your contract should say so explicitly rather than leaving it implied.

Authentication choices matter just as much as encryption. Mutual TLS, OAuth2, and SAML are all viable, but your policy should name which one applies to which integration point, along with any AE title restrictions that limit which systems can initiate a DICOM association.

  • Require DICOM TLS or mutual TLS for PACS-to-PACS and PACS-to-vendor connections.
  • Mandate HTTPS for all WADO-RS and WADO-URI retrieval endpoints.
  • Specify at-rest encryption standards, key ownership, and rotation cadence in writing.
  • Name approved authentication methods (mutual TLS, OAuth2, SAML) per integration point.
  • Segment networks and restrict firewall rules so only authorized AE titles can connect.
  • Retain audit logs with integrity checks and secure the endpoints that render images for viewing.

Pro Tip: Ask a prospective vendor to run a live DICOM TLS handshake during the proof-of-concept and export the resulting audit log; a vendor that cannot produce that evidence quickly is not ready for your environment.

BAA and SLA language to demand from vendors

Procurement and legal teams need a checklist, not a feeling, when reviewing a cloud or teleradiology contract. The BAA itself should state which Security Rule tasks belong to your organization and which belong to the vendor: encryption management, access logging, and incident response all need a named owner. HHS guidance on cloud computing confirms covered entities may use cloud services once a compliant BAA is signed and a configuration-specific risk analysis is complete.

Your service-level agreement should go beyond uptime percentages. Include access speed thresholds, turnaround reporting cadence, and a firm breach notification window measured in hours, not business days.

  • Define Security Rule task ownership explicitly inside the BAA, not by inference.
  • Set SLA metrics for uptime, retrieval speed, turnaround reporting, and breach notification timing.
  • Require a documented exit plan covering data portability and verification of access control removal.
  • Reserve audit rights and request evidence such as SOC or HITRUST reports alongside routine logs.
  • For no-view cloud services, confirm in writing how Security Rule responsibilities are allocated since the provider remains a business associate regardless of decryption access.

Operational governance beyond the contract

A signed contract does not run itself. Credentialing and privileging for remote radiologists need the same rigor the Joint Commission expects for any telehealth practitioner, including primary source verification and ongoing license monitoring.

  1. Verify credentialing and privileging for every remote reader, including license status by state.
  2. Track quality through peer review, turnaround metrics, and ongoing SLA monitoring against contract terms.
  3. Tie access provisioning and deprovisioning to HR workflows and license renewal checks.
  4. Schedule recurring risk analysis, penetration testing, and audit log review at a fixed cadence.
  5. Validate downtime procedures through acceptance testing before you depend on them in a real outage.

Treat this list as a living operating rhythm. A policy that only gets reviewed at contract renewal has already fallen behind the risks it was written to manage.

A short checklist for onboarding a new vendor

Turning policy into practice works best as a sequence rather than a single sign-off.

  1. Run a pre-contract risk assessment scoping exactly which ePHI and imaging data will be shared.
  2. Negotiate the BAA, SLA, audit rights, and exit or portability terms before any data moves.
  3. Test the proof-of-concept: DICOM TLS handshake, WADO retrieval, image rendering, and authentication.
  4. Confirm operational acceptance with log verification, role-based access tests, and a downtime drill.
  5. Go live, then schedule formal QA checks at 30, 90, and 180 days to confirm the controls still hold.

Pro Tip: Build the 30/90/180-day checks into your calendar before go-live, not after; policies that rely on someone remembering to schedule a review rarely get reviewed.

Where AstraRad fits against this checklist

This checklist reflects what imaging leaders actually ask for during vendor review. Reports should come from qualified specialists, integration should connect directly to your existing PACS, and SLA commitments must be documented rather than implied. Whatever vendor you evaluate, request the same proof points we provide as standard practice.

  • Ask for a BAA template that names Security Rule task ownership before you sign anything.
  • Request SLA performance reports, not just a promised turnaround number.
  • Review an integration diagram showing exactly how DICOM and WADO traffic will flow.
  • Ask for a current licensing roster covering every state where readers will interpret your studies.

Perspective: strict controls versus urgent clinical needs

Locking down every key and access path sounds safest until a STAT stroke case needs a read in minutes, not hours. The fix is not looser security; it is pre-built exceptions. Escrowed keys for genuine emergencies and pre-authorized rapid-auth flows for STAT workflows let you keep strict controls everywhere else while still protecting the image integrity and system availability that urgent cases actually depend on.

Rafael Vieira

How AstraRad can help you put this policy into practice

AstraRad teleradiology homepage with a chest X-ray open in the reading viewer

We designed our workflow to satisfy this checklist directly: board-certified subspecialists on every study, PACS integration that avoids a second portal, and SLA reporting you can hand straight to your compliance file. If you are evaluating vendors against the controls above, request our BAA template and run an integration proof-of-concept walkthrough before committing to a contract.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

How AstraRad can help you put this policy into practice: overview diagram

FAQ

What must a HIPAA-compliant BAA include for imaging vendors?

A compliant BAA must name the vendor as a business associate, assign specific Security Rule responsibilities, and spell out breach notification timing. This applies even to no-view cloud storage providers that never hold a decryption key.

Is DICOM TLS required for sharing radiology images?

DICOM TLS is not a flat legal mandate, but it is the control that NIST's PACS security guidance and the ACR-AAPM-SIIM technical standard both point to for protecting image transport. Most credible teleradiology and PACS vendors treat it as a baseline requirement for any production connection.

How often should audit logs be reviewed?

Your policy should state a fixed review cadence rather than leaving logs unexamined until an incident forces the question. A recurring schedule, paired with periodic risk analysis as described in HHS cloud computing guidance, keeps the control active instead of theoretical.

Do remote radiologists need separate credentialing?

Yes. Remote and on-site radiologists are held to the same professional and technical standards, and credentialing by proxy is specifically addressed in Joint Commission telehealth guidance. Your policy should require license verification and privileging checks before any remote reader touches a study.

What should an exit plan cover if we switch vendors?

An exit plan should cover data portability for native DICOM files, verification that the outgoing vendor's access has been fully removed, and confirmation of retention or disposition of any remaining copies. Building this into the original contract, rather than negotiating it after a termination notice, avoids leaving ePHI in an ambiguous state.

Sources

Put a radiologist's name on your next read.

Tell us your modalities and monthly volume. A complete per-report rate card, with turnaround tiers and SLA terms in writing, lands in your inbox within one business day.