Skip to content
Start my free trial
HIPAA-focused secure file exchange

HIPAA compliant file sharing for protected ePHI handoffs

My MX Data gives healthcare organizations and their partners a controlled route for exchanging sensitive health files. Named-recipient access, permissions, multi-factor authentication, protected storage and detailed activity records can support the technical and operational safeguards around ePHI.

Start my 7-day free trial

No credit card required. Up to 5 users.

Discuss your HIPAA workflow

Technology can support a HIPAA program, but no file-sharing product makes an organization compliant by itself. Coverage, permitted uses, minimum-necessary decisions, policies, risk analysis, contracts and breach obligations remain with the regulated organization.

Named recipientsClear access ownership
Configurable controlsPermissions and MFA
Protected filesASR security methodology
Activity recordsMore accountable handoffs
The wider HIPAA framework

Secure file exchange sits inside a much larger compliance system

HIPAA is not a single encryption requirement. Covered entities and business associates need to consider privacy, security, permitted disclosures, contracts, incident response and the evidence that shows how safeguards operate in practice.

The HIPAA Privacy Rule establishes standards for protected health information, while the Security Rule focuses on administrative, physical and technical safeguards for ePHI.

When sensitive files move outside the source system, the handoff should still reflect the organization’s policies: an approved purpose, the correct data set, the right recipient, suitable access controls and a record that can support oversight.

Privacy Rule

Sets standards for uses and disclosures of PHI and gives individuals rights over their information.

purpose and disclosure

Security Rule

Requires reasonable and appropriate safeguards for the confidentiality, integrity and availability of ePHI.

administrative • physical • technical

Breach Notification Rule

Creates notification duties following breaches of unsecured PHI, with different responsibilities for covered entities and business associates.

detect • assess • notify

Business associate obligations

Contracts and direct regulatory duties matter when another organization creates, receives, maintains or transmits PHI on a covered entity’s behalf.

contract and accountability
Security Rule safeguard layers

Three layers shape the way ePHI should be protected

A file-sharing control is most effective when it supports the policies, workforce practices, physical environment and technical architecture around it.

01

Administrative safeguards

Governance turns security from a product setting into a repeatable operating practice.

  • Risk analysis and risk management
  • Workforce authorization and training
  • Security incident procedures
  • Contingency planning and evaluation
02

Physical safeguards

Facilities, workstations and devices still affect who can reach systems and health information.

  • Facility access controls
  • Workstation use and security
  • Device and media controls
  • Disposal and reuse procedures
03

Technical safeguards

System controls help manage access, integrity, authentication and transmission security.

  • Unique user identification and access control
  • Audit controls and activity review
  • Integrity and authentication measures
  • Protection for ePHI in transit

My MX Data primarily supports the controlled-exchange and evidence layer. It does not replace the risk analysis, policy, training, device, facility or broader system controls required across the organization.

An accountable exchange path

Five decisions before an ePHI file leaves your control

A secure platform can make the handoff clearer, but the organization still needs a repeatable approval process before the file is released.

Confirm purpose

Identify the permitted use, disclosure or operational basis for sharing the information.

Reduce the data

Prepare the information reasonably needed for the purpose and exclude unnecessary content.

Verify the recipient

Confirm the person, organization and authority behind the destination account.

Apply safeguards

Set permissions, authentication and file-protection controls for the exchange.

Retain the record

Keep the activity history with the wider approval, contract and compliance evidence.

Secure delivery does not validate the disclosure itself

The file route can enforce recipient and access settings, while the covered entity or business associate remains responsible for deciding whether the disclosure is permitted, appropriately limited and correctly documented.

Minimum necessary in practice

Give each recipient the information and access their role actually needs

A controlled exchange can help translate internal access decisions into a more precise external handoff. The legal standard and any exceptions must still be assessed by the organization.

Limit the file set

Prepare a purpose-specific package rather than exporting a complete record by default.

Limit the audience

Use named accounts and recipient verification instead of open or reusable public links.

Review exceptional access

Escalate unusual, urgent or broad disclosures through the appropriate privacy and security process.

illustrative disclosure matrixrole based
information set
referring clinician
billing partner
external auditor
Clinical referral summary
ALLOW
NO
REVIEW
Billing and coding record
REVIEW
ALLOW
REVIEW
Complete longitudinal record
REVIEW
NO
NO
Security audit evidence
NO
NO
ALLOW

Illustrative only. Actual permissions depend on the purpose, relationship, applicable HIPAA provision, organizational policy and any other legal restriction.

Covered entities and business associates

A secure channel cannot replace the agreement around it

Where a vendor or partner performs functions involving PHI on behalf of a covered entity, the parties need to determine their roles and put the required written assurances in place.

Covered entity

Define the permitted relationship

  • Determine why the partner needs PHI and what services it performs.
  • Complete due diligence and address required business associate contract terms.
  • Set approved users, information categories, retention and incident routes.
  • Oversee the relationship and respond when controls or circumstances change.
Business associate

Safeguard the information received

  • Use and disclose PHI only as permitted by the contract and applicable law.
  • Apply Security Rule safeguards to ePHI and manage subcontractor obligations.
  • Report security incidents and breaches through the agreed route and timeline.
  • Support access, amendment, accounting or return and destruction duties where required.

Confirm contractual requirements before transferring PHI

HHS explains that covered entities generally need written satisfactory assurances from business associates that PHI will be appropriately safeguarded. Confirm whether a BAA is required and what contractual arrangements are available during procurement; a secure product interface is not a substitute for the contract.

Incident and breach readiness

A stronger activity record gives investigators a better place to start

When a disclosure or access event is questioned, teams need facts: which file moved, who initiated it, which recipient was named, what controls were applied and what activity followed.

Those facts can support the security-incident and breach-assessment process, but they do not decide whether an event meets the legal definition of a breach or who must be notified.

HHS breach guidance Building a file audit trail
exchange event reconstructionREVIEW OPEN
File submitted

Authorized workforce member selected a referral package for external delivery.

Recipient policy applied

Named account, permissions and authentication requirements attached to the exchange.

Recipient verified

Destination user completed the required sign-in and verification step.

File accessed

Access event recorded for review alongside the organization’s wider logs and evidence.

Case evidence preserved

Exchange history exported to the incident file for legal and security assessment.

Supporting exchange controls

File-sharing features that can support a HIPAA program

Use technology to make approved exchanges more deliberate, more restricted and easier to reconstruct.

Named-recipient access

Direct sensitive files to identified accounts rather than broadly reusable links or unmanaged attachments.

Explore the features

Permission-based control

Configure how approved recipients interact with a file and keep the exchange within a defined route.

View platform controls

Multi-factor authentication

Add an extra verification step before the recipient can access protected information.

See encrypted file sharing

ASR file protection

Use My MX Data’s patented anonymize, shard and restore methodology within the protected exchange.

Understand the protection model

Detailed activity history

Retain a clearer account of sender, recipient and file events for oversight and incident review.

Read about audit trails

Administrative oversight

Give designated administrators a clearer way to manage users, exchanges and operational policy.

View the product walkthrough
Healthcare file-sharing scenarios

Practical workflows involving sensitive health files

Different teams can use the same controlled-exchange principles while applying their own approval, minimum-necessary and retention rules.

care coordination

Provider-to-provider referrals

Deliver referral records, imaging or supporting documents to the identified receiving team without relying on ordinary attachment chains.

named destination • documented handoff
patient access

Approved record disclosures

Provide an approved access-response package through a restricted route after identity, scope and redaction work is complete.

verified recipient • protected delivery
partner exchange

Business associate collaboration

Exchange approved files with billing, legal, analytics or operational partners under the applicable contract and access policy.

role clarity • permission controls
assurance

Audit and incident evidence

Share logs, investigation records or compliance evidence with authorized reviewers through a controlled channel.

evidence integrity • activity history
A supporting control, not a certification

Where My MX Data fits in a HIPAA program

My MX Data can support secure file handoffs and the activity evidence around them. Compliance still depends on how the organization scopes, configures, contracts for and operates the service within its wider environment.

HIPAAHITECHNIST 800-171CCPAITARState health privacy laws

Important: My MX Data should not be described as certified, approved or endorsed by HHS or OCR, or as making a customer HIPAA compliant automatically. Any HIPAA role, contractual requirement and permitted use must be determined from the actual service arrangement.

MX can control the file handoff

Named accounts, permissions, MFA, protected storage and activity records can reduce uncertainty around an approved exchange.

Your organization decides what may be shared

Privacy, clinical, legal and security teams determine the purpose, recipient, information set and applicable exception.

Risk analysis remains broader than one tool

The assessment must consider all ePHI created, received, maintained or transmitted across the regulated environment.

Contracts and BAAs are separate controls

Required written assurances, allocation of duties and incident-notification terms must be handled through the appropriate agreement.

Proposed rules are not the current rule

HHS has proposed significant Security Rule changes. Organizations should monitor the rulemaking while continuing to comply with requirements currently in force.

HIPAA file-sharing questions

What healthcare, privacy and security teams usually ask

These answers explain the operational role of controlled file exchange. They are general information and not legal advice.

Visit all FAQs
01What is HIPAA, and which organizations does it regulate?

HIPAA is a federal framework that includes privacy, security, breach-notification and enforcement requirements for protected health information. The core regulated groups are covered entities, including health plans, health care clearinghouses and certain health care providers that conduct covered electronic transactions, together with their business associates.

Business associates are organizations or people that perform particular functions or services involving PHI on behalf of a covered entity. Some subcontractors of business associates can also fall within the regulated chain. The label depends on the actual function and data relationship, not simply whether an organization works somewhere in healthcare.

  • Confirm whether the information is PHI and whether it is held or transmitted by a regulated entity.
  • Identify whether the organization is acting as a covered entity, business associate or in another capacity.
  • Document the permitted purpose, contract structure and safeguards around the processing.

The official HHS covered entities and business associates guidance is the appropriate starting point for role analysis.

02Does using My MX Data make an organization HIPAA compliant?

No single product makes an organization HIPAA compliant. My MX Data can support selected technical and operational controls around the transfer of sensitive files, but HIPAA compliance extends across governance, risk analysis, policies, workforce behavior, facilities, devices, systems, contracts and incident response.

The platform can make an approved handoff more controlled through named-recipient access, configurable permissions, multi-factor authentication, file protection and detailed activity records. Those capabilities may reduce risks associated with ordinary attachments, uncontrolled public links and unclear recipient access.

  • The organization still decides whether the disclosure is permitted and appropriately limited.
  • Administrators must configure the service consistently with policy and assign access correctly.
  • Required contracts, including BAAs where applicable, must be addressed separately.
  • The service must sit inside the organization’s ongoing risk-management and review process.

My MX Data should therefore be described as supporting a HIPAA-aligned secure file-exchange workflow, not as replacing the wider compliance program.

03Does HIPAA require every PHI file to be encrypted?

The HIPAA Security Rule uses a framework of required and addressable implementation specifications. Encryption is an important safeguard, but an addressable specification is not the same as an optional control that can simply be ignored. A regulated entity must assess whether the safeguard is reasonable and appropriate and, if it is not implemented, document the reasoning and any equivalent alternative where appropriate.

That analysis should be based on the organization’s risk analysis, environment and the way ePHI is created, received, maintained or transmitted. For external file exchange, encryption alone also leaves other questions unanswered:

  • Who is the recipient? A protected file can still be sent to the wrong person.
  • What can the recipient do? Access and permission decisions still matter.
  • What evidence remains? Teams need records that support oversight and incident review.

A controlled exchange combines file protection with identity, permissions and activity evidence rather than treating encryption as the entire compliance answer.

04When is a business associate agreement required?

A covered entity generally needs written satisfactory assurances when a business associate creates, receives, maintains or transmits PHI on its behalf. These assurances are normally documented in a contract or other arrangement commonly called a business associate agreement or BAA.

The agreement addresses how PHI may be used and disclosed, the safeguards that must be applied, incident and breach reporting, subcontractors and what happens to PHI when the relationship ends. The required terms depend on HIPAA and the actual services, while state law and ordinary commercial provisions may add further requirements.

  • Determine the parties’ roles from the real processing activity.
  • Confirm whether an exception applies rather than assuming every healthcare vendor is a business associate.
  • Complete the required agreement before allowing PHI into the service.
  • Align the contract with the configured workflow, authorized users and incident route.

HHS publishes sample business associate agreement provisions, but organizations should obtain legal review for their own arrangement.

05How can secure file sharing support the minimum-necessary standard?

The minimum-necessary standard generally asks regulated entities to make reasonable efforts to limit certain uses, disclosures and requests for PHI to what is needed for the intended purpose. It does not apply identically in every situation, and there are important exceptions, so the privacy team must determine the correct legal treatment.

A secure exchange can support the operational side of that decision by creating a purpose-specific package and directing it to a defined recipient rather than distributing a broad export to an open group.

  • Separate clinical, billing, audit and administrative records instead of combining them automatically.
  • Use named accounts and permissions aligned with the recipient’s role.
  • Require review for unusually broad or sensitive data sets.
  • Record which approved package was actually transferred.

The platform cannot decide what is legally necessary. It helps enforce the delivery decision after the organization has made and documented it.

06Can an activity log prove that no HIPAA breach occurred?

No. An activity log is evidence, not a legal conclusion. It may show when a file was submitted, which account was named, what access event occurred and which settings were applied. Those facts can materially improve the investigation, but the organization must assess the full circumstances under the applicable breach framework.

A breach analysis may consider the nature and extent of the PHI, the unauthorized person, whether the information was actually acquired or viewed and the extent to which risk was mitigated. Evidence may also be needed from identity systems, endpoints, email, applications, interviews and third parties.

  • Preserve logs promptly so relevant information is not overwritten.
  • Correlate sources rather than relying on a single platform record.
  • Document the assessment, decisions, notifications and mitigation steps.

The HHS Breach Notification Rule guidance explains the federal notification framework.

07What is the role of HIPAA risk analysis?

Risk analysis is foundational to the Security Rule. HHS describes it as the first step in identifying risks and vulnerabilities affecting the confidentiality, integrity and availability of ePHI. The scope must cover all ePHI the regulated entity creates, receives, maintains or transmits, rather than only the files held in one transfer product.

For a file-exchange service, the assessment may examine user provisioning, authentication, recipient errors, configuration, device access, integrations, retention, incident response, subcontractors and the way exports are prepared before upload.

  • Document where ePHI enters, moves through and leaves the workflow.
  • Identify reasonably anticipated threats and vulnerabilities.
  • Assess likelihood and impact using a consistent method.
  • Implement and monitor reasonable and appropriate risk-management measures.

Use the current HHS risk-analysis guidance and NIST SP 800-66 Revision 2 as authoritative implementation resources.

08Has the proposed HIPAA Security Rule update already taken effect?

HHS published a notice of proposed rulemaking in December 2024 that would significantly strengthen and make more specific a range of Security Rule requirements. A proposal is not the same as a final rule. Organizations should distinguish the requirements currently in force from measures that may become mandatory after rulemaking is completed.

The proposal includes subjects such as more specific risk-analysis documentation, technology asset inventories, network maps, stronger authentication and encryption expectations, testing, incident planning and enhanced business-associate duties. These themes can still be useful indicators of regulatory direction, but they should not be presented as final legal requirements unless and until HHS finalizes them.

  • Continue complying with the current Security Rule.
  • Monitor the official HHS rulemaking page for status and implementation dates.
  • Consider whether planned security improvements are sensible now based on current risk, even before a legal mandate changes.

Check the official HIPAA Security Rule NPRM page for current information rather than relying on an undated summary.

Give ePHI a more controlled route

See how My MX Data can support your HIPAA file-sharing workflow

Bring healthcare, privacy, security and external partners into a more accountable exchange, with clearer controls around recipient access and a more useful activity history.

Start my 7-day free trial

No credit card required. Up to 5 users.

Talk through the workflow
Named-recipient accessConfigurable permissionsMFADetailed activity records
Customer perspectives

Trusted for sensitive, accountable file exchange.

★★★★★

The audit history gives us a reliable answer when a client asks who accessed something. It feels secure, well judged and easy enough for the whole team to use.

Hannah BrooksOperations Director
★★★★★

It isn’t bloated with features we’ll never use, yet the security is strong enough for serious compliance checks. Staff began using it straight away without training.

Helen C.Operations Manager, Manufacturing
★★★★★

The version control and audit trail tools were quite helpful for project management, making it easy to monitor changes and retrieve past data.

Amir Z.Marketing Director
Common questions

Frequently asked questions

Clear answers about HIPAA Compliance.

What is HIPAA-compliant file sharing?

HIPAA-compliant file sharing generally means a controlled approach to healthcare-related files that may contain electronic protected health information that keeps recipient, access and activity controls around the exchange.

For hipaa compliance, the practical focus is on healthcare-related files that may contain electronic protected health information rather than treating every file as an open link or an unmanaged attachment. The practical test is whether the process gives the team enough control for the sensitivity of the file without creating workarounds that people are likely to bypass.

For more detail on the related MX workflow, see MX security and administration features. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. Where the workflow is business-critical, the organization should document who owns the process and who is responsible for reviewing exceptions or incomplete exchanges.

Does My MX Data automatically make an organization HIPAA compliant?

No. Using My MX Data does not automatically make an organization compliant with HIPAA. The organization still needs to decide matters such as lawful use, data classification, retention, supplier due diligence, training and incident response where those duties apply.

Technology can support specific controls, but compliance also depends on the organization's policies, contracts, configuration, staff practices, risk decisions and wider governance. For higher-risk workflows, legal, compliance and security stakeholders should review the intended recipients, data type, access period and evidence requirements before rollout.

MX should be assessed as one part of that wider control environment rather than as a substitute for the organization's own compliance program. For more detail on the related MX workflow, see MX feature set. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information.

How can named-recipient access and multi-factor authentication help protect sensitive healthcare files?

Protection in MX relies on several controls working together rather than a single security feature. That gives the team a more defensible record of the handoff.

AES-256 encryption forms part of the model alongside named-recipient access, permissions, multi-factor authentication, expiry controls and detailed activity records. Different transactions can carry different conditions, so routine material does not need to be handled exactly like highly sensitive information.

For more detail on the related MX workflow, see file-exchange controls. Security still depends on the wider environment, including endpoint protection, account management, recipient behavior and the organization's own operating procedures.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

How does encryption help protect healthcare information during file exchange?

Protection in MX relies on several controls working together rather than a single security feature. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

AES-256 encryption forms part of the model alongside named-recipient access, permissions, multi-factor authentication, expiry controls and detailed activity records. The sender retains a clearer connection between the file, the intended recipient and the access window applied to that exchange.

For more detail on the related MX workflow, see encryption-led file sharing. Layered controls are useful because identity, confidentiality and evidence solve different parts of the file-exchange problem.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. Different transactions can carry different conditions, so routine material does not need to be handled exactly like highly sensitive information.

What audit records can organizations retain for healthcare-related file transfers?

MX records activity associated with file exchanges, giving relevant senders and administrators a clearer history after information has been shared. A transaction record is most useful when it answers practical questions such as who accessed the file, when they did it and whether the current version was downloaded.

Records may include uploads, access, downloads, comments, recipient activity, timestamps, transaction history and relevant user or IP details. That history can help a team follow up on incomplete exchanges, investigate unexpected activity and prepare evidence for internal review.

For more detail on the related MX workflow, see MX feature set. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information.

Can access to sensitive healthcare files expire or be restricted after they are sent?

My MX Data can restrict an exchange to named or authorized recipients rather than relying on an unrestricted public link. The sender retains a clearer connection between the file, the intended recipient and the access window applied to that exchange.

Recipient selection, permissions, multi-factor authentication and expiry settings can then be combined to shape who can reach the information and for how long. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

For more detail on the related MX workflow, see file-exchange controls. Different transactions can carry different conditions, so routine material does not need to be handled exactly like highly sensitive information.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. Administrative oversight matters because access can change during a project as people join, leave or move between responsibilities.

Can MX support the exchange of very large healthcare files and document sets?

Yes. MX is designed to support very large files and complete datasets without arbitrary file-size restrictions. This is useful for engineering, media, software and project teams that need to move complete working packages without breaking the process apart.

That can include patient information, clinical documents and administrative records, reducing the need to split an exchange across multiple uploads or move it to another tool simply because the file is large.

For more detail on the related MX workflow, see controlled large-file exchange. The same recipient, authentication, permission and activity controls can remain around the transfer even when the payload is technically large.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. HIPAA responsibilities extend beyond the transfer mechanism and may involve risk analysis, access management, workforce procedures, contracts and safeguards across the wider environment.

What wider policies and security controls should an organization consider alongside a secure file-sharing platform?

Protection in MX relies on several controls working together rather than a single security feature. For particularly sensitive information, MX can also use ASR (Anonymize, Shard and Restore) as an additional protection method that is distinct from conventional encryption.

AES-256 encryption forms part of the model alongside named-recipient access, permissions, multi-factor authentication, expiry controls and detailed activity records. Layered controls are useful because identity, confidentiality and evidence solve different parts of the file-exchange problem.

For more detail on the related MX workflow, see MX feature set. Administrative oversight matters because access can change during a project as people join, leave or move between responsibilities.

The HHS HIPAA Security Rule guidance explains the administrative, physical and technical safeguards expected for electronic protected health information. Security still depends on the wider environment, including endpoint protection, account management, recipient behavior and the organization's own operating procedures.