Health information exchange and HIPAA

Choose a platform for sharing PHI with another provider around the actual exchange: what must leave your system, who receives it, and how the receiving team will use it. Then compare contractual coverage, connections, data quality, implementation, support, and total cost. There is no evidence-supported universal best choice for every clinic or health system.

What is health information exchange?

Health information exchange is the electronic sharing of patient health information. The exchange activity is distinct from an organization or network that facilitates it and from the software that connects participating systems.

Start with the clinical handoff, not a product category. These hypothetical clinic examples describe different needs:

• A referral coordinator sends a specialist a referral letter and supporting records.
• A clinic receives an outside laboratory result that staff need to review in the patient’s chart.
• A primary care team obtains a discharge summary from another provider before a follow-up appointment.

For each, ask what counts as success. Does someone need to open a document, or must information appear in particular fields in the receiving system?

Delivering a readable document is not the same as exchanging structured information that receiving software can interpret and use. Delivery alone does not demonstrate clinical-system integration, and structured content still requires compatible implementations.

The appropriate platform depends on that answer, the participating systems, contractual scope, and implementation requirements.

Choose the exchange approach that fits your clinic's workflow

Use a workflow record before requesting demonstrations. Every scenario below is hypothetical; turnaround entries are proposed clinic requirements, not vendor performance claims.

Hypothetical workflow	Sender → recipient	Information	Required turnaround	Approach to investigate
Referral documents	Clinic referral system → specialist’s office	Referral letter and supporting records	Before the specialist reviews the referral	Secure document delivery; staff-managed delivery or an automated connection
Outside lab result	Laboratory system → ordering clinic’s EHR	Result and associated patient/order details	Within the clinic’s agreed review window	An automated interface or interoperability service
Cross-system record lookup	Outside provider’s records → treating clinic	Relevant history or discharge summary	During visit preparation or care	EHR-connected exchange network
Application-to-application exchange	Source application → receiving application	Defined data fields or resources	According to the receiving workflow	Integration engine or interoperability API

Secure document delivery transports content; EHR-connected exchange networks facilitate exchange among participants; integration engines route and transform messages between systems; and interoperability APIs expose defined application interactions. These categories can overlap, and suitability depends on the specific endpoints and workflow.

Do not treat these categories as interchangeable. Ask the receiving organization which connection it can actually accept and whether staff must intervene.

An everyday messaging or file-sharing tool should not be assumed to supply patient matching, structured clinical exchange, or EHR integration. Request evidence for each capability rather than extending a general file-delivery claim to the whole workflow.

Check HIPAA responsibilities and contractual coverage before sharing PHI

Keep the disclosure decision separate from the vendor-contract decision.

A provider's disclosure to another provider for an individual's treatment does not itself require a business associate agreement. A separate organization handling PHI on a covered entity's behalf generally requires a BAA when it acts as a business associate, subject to applicable exceptions.

A service’s contractual scope also needs separate review. A BAA defines permitted activities for a particular business associate relationship. It cannot authorize disclosures prohibited by the Privacy Rule, and its coverage should not be assumed to extend to every connected service.

For background, see what HIPAA compliant means and the guide to business associate agreements.

Before approval, check a vendor BAA's covered services and exclusions. Request:

• The eligible plan, contract, and contracting entity.
• The exact products and services covered.
• Excluded connectors, optional features, and external destinations.
• Subprocessor information and support-access arrangements.
• Retention settings and return or deletion terms.
• Incident notification and cooperation obligations.

Required BAA provisions under 45 CFR 164.504(e) address permitted uses and disclosures, safeguards, reporting, individual-rights assistance, HHS access, subcontractor obligations, return or destruction where feasible, and termination rights. Pricing, connector coverage, deployment milestones, and support service levels are additional procurement criteria, not required BAA provisions.

Use these directory verdicts narrowly:

Verdict	Meaning for the evaluated service and workflow
Yes	A vendor-owned BAA or trust source establishes availability and scope matching the evaluated use.
Conditional	Documented availability depends on specified plans, contracts, features, or other conditions.
No	A qualifying vendor source establishes that the evaluated service or plan is unavailable for the proposed use.
Unknown	No qualifying source establishes the answer, or material scope questions remain unresolved.

These are evidence labels, not certification or organization-wide approval. Record the source and verification date in comparison metadata.

Obtain qualified legal review of each workflow's consent and disclosure requirements, including applicable state privacy laws, 42 CFR Part 2 restrictions on covered substance use disorder records, and HIPAA's special protections for psychotherapy notes. HIPAA is not the only potentially applicable rule.

Compare exchange vendors by supported workflow and BAA scope

Use the same evidence requirements for every candidate. Do not infer coverage from encryption, a healthcare webpage, network participation, or another product sold by the same company.

The comparison below leaves unsupported details unknown rather than inventing an exchange-vendor shortlist.

Vendor and product	Intended workflow	BAA availability by plan or contract	Covered services	Exclusions	Supported connections or standards	Verdict	Sources and verification date
		Unknown —	Unknown —	Unknown —	Unknown —	Unknown

For each candidate, require a specific assessment:

• Consider when: official documentation and the applicable contract establish support for the required workflow, and equivalent-scope quotes or published terms support the commercial comparison.
• Less suitable when: documented limitations conflict with a required connection, operating model, support commitment, or budget constraint.

Unknown does not mean a vendor refuses to sign a BAA. It means the available qualifying evidence does not establish the answer.

Use vendor BAA and service-scope checks alongside technical documentation and the proposed contract.

Ownership and independence: Chanty, Inc. owns and publishes HIPAA Compliant Wiki. Vendor inclusion, ordering, and verdicts are independent of payment and publisher interests. The directory reports published terms; it does not audit vendors, certify compliance, or provide legal advice.

Evaluate integration breadth, standards, and data quality

“Integration breadth” needs a connection inventory, not a logo collection. Ask each candidate:

• Which exact sending and receiving systems are supported?
• Is the connection ready, configurable, or custom-built?
• Which versions and deployment environments are included?
• Who maintains the interface when either endpoint changes?
• What requires an additional product, contract, or implementation project?

Standards matter only in the context of the required exchange:

Standard to investigate	Workflow question
HL7 v2 clinical messaging; specify the interface version, message types, fields, and implementation guide. Documented versions include v2.5.1 and v2.9.1.	Can the proposed message interface deliver the required result fields into the receiving workflow?
FHIR (Fast Healthcare Interoperability Resources), a resource-based healthcare information exchange standard; specify the release, supported resources, operations, profiles, and access arrangements. Releases include R4 (4.0.1), R4B (4.3.0), and R5 (5.0.0).	Which resources, operations, profiles, and access arrangements does each endpoint support?
C-CDA (Consolidated Clinical Document Architecture), a US-realm library of templates for CDA Release 2 clinical documents; specify the C-CDA version, document type, templates, and receiving-system behavior.	Can the recipient receive and use the proposed clinical document?
Direct secure messaging, a certificate-based push transport used for workflows such as referrals and care transitions; it transports content but does not itself establish clinical-field integration.	Does the proposed delivery method match the recipient’s operational needs?

Support for the same named standard does not establish universal compatibility. Verify matching versions, profiles or templates, content requirements, security arrangements, and tested endpoint behavior.

Test data quality separately from transport. In a hypothetical outside-lab workflow, a delivery receipt would answer a different question from whether staff can locate the result in the intended chart.

Set acceptance checks for patient identity handling, field completeness, terminology mapping, duplicate handling, provenance, and visible errors. Treat these as workflow-specific acceptance criteria, not a universal HIPAA checklist, and require each candidate to demonstrate them through documented testing.

Use representative exchanges with the actual counterparties before making a data-quality or standards recommendation.

Compare total cost, deployment effort, and customer support

Ask vendors to quote the same workflow and operating assumptions. Treat the following as items to request—not charges every vendor necessarily imposes.

Cost item	What to request
Subscription or platform	Included services, minimum commitments, and optional modules
Connection setup	Cost per required endpoint and responsibility for setup
Interface development	Included mapping, custom work, and change requests
Usage	Metered activity, allowances, overages, and growth assumptions
Migration and testing	Historical-data work, validation, and acceptance testing
Monitoring and maintenance	Ongoing interface oversight, upgrades, and remediation
Support	Included assistance and separately priced coverage
Internal staff time	Clinic, IT, security, legal, and training effort

Compare quotes or published terms only after aligning scope, quantities, contract term, exclusions, and usage assumptions. Identify costs or obligations omitted from each offer.

For deployment speed, request a dependency list: what already exists, what must be built, who owns each task, and what acceptance testing is included. Compare commitments for your connection—not an unrelated implementation example.

For customer support, request documented service hours, onboarding scope, escalation paths, incident ownership, and contractual response commitments. Ask separately about acknowledgment, investigation, workarounds, and resolution.

Obtain each vendor's written deployment and support commitments. Distinguish an acknowledgment or response deadline from a restoration or resolution deadline, and identify applicable exclusions and contractual remedies.

Record candidate-specific trade-offs only where evidence supports them:

• Total cost: compare equivalent-scope quotes that identify excluded work, usage assumptions, recurring charges, and maintenance obligations.
• Deployment: require written evidence of ready connections, custom dependencies, customer responsibilities, and contractual milestones.
• Support: confirm coverage hours, escalation ownership, response and resolution commitments, exclusions, and contractual remedies in the applicable support agreement.

Otherwise, mark the comparison quote or contract review needed. Do not rank vendors as cheapest, fastest, or best-supported without equivalent scope, dated evidence, and an explicit comparison method.

Test the complete PHI exchange path before approval

Map the proposed route, including less visible handling points.

A hypothetical referral workflow might be:

Source application → connector → transformation service → delivery service → specialist’s receiving system

Add temporary storage, error queues, logs, backups, support access, and any external destination to the review. Map where ePHI is created, received, maintained, or transmitted, including these components wherever they handle ePHI; the actual architecture must be documented rather than assumed.

For every component, identify its operator, proposed access, retention, contractual coverage, and failure owner. Do not extend the core platform’s coverage to a connector or destination without checking its scope.

Use this as a recommended procurement acceptance checklist, not a statement of universal legal requirements:

• The intended recipient can access the correct information.
• Access controls match the approved users and roles.
• Transmission protection is documented.
• Logs provide the evidence needed to investigate an exchange.
• Failed or partial deliveries become visible to an accountable team.
• Retries and duplicate handling are tested.
• Retention and deletion behavior match the approved design.

HIPAA's technical safeguard standards in 45 CFR 164.312 address access control, audit controls, integrity, authentication, and transmission security. Distinguish required from addressable implementation specifications; addressable does not mean optional. Document vendor capabilities separately from legal obligations and recommended purchasing criteria.

Request testing with synthetic data where appropriate. Document pass/fail criteria, unresolved defects, counterparties, and the evidence needed before approving production PHI. Use a controlled test environment and verify the test data's origin, disclosure risk, and suitability; calling data synthetic does not establish that it is free of PHI. If relying on HIPAA de-identification, use Expert Determination or Safe Harbor.

Use patient data security basics to broaden the review beyond successful delivery.

Questions to answer before choosing an exchange platform

Follow this sequence: define the workflow, confirm the recipient connection, establish applicable contractual coverage, test usability, and compare full operating costs.

Ask every candidate:

• What exactly is covered by the proposed agreement?
• What leaves that scope?
• Which connections are ready for our endpoints?
• What must our team build or maintain?
• Who investigates and fixes failures across organizational boundaries?
• What costs are excluded from the quote?

Compare the vendor’s current terms with the proposed data flow and record unresolved questions before procurement.

Related reading: HIPAA guides.

Frequently asked questions

What is health information exchange, and how does it relate to HIPAA?

Health information exchange is the electronic sharing of patient health information. Applicable HIPAA duties depend on the parties' roles, the purpose and legal basis for disclosure, and how PHI is handled—not simply on use of the HIE label. Evaluate the activity, the participating organizations, and the connecting services separately.

What kind of platform can share PHI with another healthcare provider?

Start with the recipient’s requirements. Investigate document delivery for a document handoff, an exchange network for supported record access, or an integration service for application-level exchange. These are overlapping starting points, not guarantees of suitability: directed exchange sends information, query-based exchange supports record discovery and access, and integration engines connect applications and message formats. Confirm contractual scope for the selected route.

Does every provider-to-provider exchange require a BAA?

Not every exchange between providers requires a BAA. A disclosure to another provider for an individual's treatment does not itself require one; a separate service handling PHI on a covered entity's behalf generally does when it acts as a business associate, subject to applicable exceptions.

Is a signed BAA enough to approve a data exchange platform?

A signed BAA is not blanket authorization for disclosures, proof that every connected service is covered, or a substitute for the customer's own HIPAA responsibilities, including applicable risk analysis and safeguards. Also evaluate the proposed workflow, configuration, access, and exclusions.

What is the difference between secure file sharing and healthcare interoperability?

Secure file sharing can deliver a readable document without populating usable fields in another clinical system. Interoperability includes both exchanging information and using the information received; successful delivery alone does not demonstrate that capability. Test document access and receiving-system usability separately.

How should we compare exchange vendors on total cost and customer support?

Request equivalent-scope quotes covering setup, interfaces, usage, maintenance, support, and internal work. Compare documented support hours, escalation ownership, and response commitments. Treat missing commercial terms as unresolved—not as evidence of lower cost or better service.

How can we test data quality and integration compatibility before deployment?

Define representative scenarios with the actual counterparties. Check identity handling, completeness, mapping, duplicates, provenance, errors, and receiving-workflow usability. Test both sides of each interface in a controlled environment, including realistic end-to-end workflows. Agree on workflow-specific acceptance thresholds; standards validation alone does not establish clinical usability. Record results against agreed pass/fail criteria.

Which interoperability standards should an exchange platform support?

Require the standards, versions, and implementation details needed by your actual endpoints—not the longest standards list. HL7 v2 addresses clinical messages, FHIR resource-based exchange, C-CDA clinical documents, and Direct secure push transport. Select the applicable combination using endpoint and workflow requirements; these standards are not interchangeable. Ask for evidence that the specific connection works.