EpicCare Link: Complete Guide

What is EpicCare Link?

EpicCare Link is Epic's web application for community users: physicians, practice staff and other approved parties outside the health system who need to see records for patients they share. Users sign in through a browser, and the host health system controls the accounts, the chart views, the order types and the notifications each user group receives.

Epic's own interoperability page describes this offering as Epic Community Link, with chart access, orders, referrals and notifications on updates to a patient's care. Most health systems still publish their portal pages under the EpicCare Link name, so both names appear in enrollment forms and training material.

Who can a health system give an account to?

A host usually gives accounts to physicians who refer patients in and to the staff who work for them. Some hosts go further and list insurers, regulators and other authorized third parties among their users.

• Referring physicians and providers: The University of Kansas Health System says any physician or provider who refers a patient to it can use the portal, at no cost.
• Practice staff: Clinical and nonclinical staff and office administrators can request accounts, and each enrollee signs the terms and conditions electronically before access starts.
• Other authorized parties: The same host lists certain insurance providers, regulators and other authorized third parties as possible users.
• Practices already on Epic: At least one academic health system tells outside organizations that already use Epic to look at Care Everywhere rather than the portal.

Access to a given patient is narrower than access to the portal. Hoag Health System keeps chart access for a patient's listed primary care provider while that relationship stands, and limits consulting and referring physicians, their staff and community facility providers to 90 days after first login.

What can a referring practice do in the portal?

The portal's core job is read access to the shared patient's record, with a set of actions on top that varies by host. Check the host's own feature list before you design a workflow that depends on one of them.

• Chart review: The University of Kansas Health System lists progress notes, lab results, discharge instructions, consult notes and imaging reports.
• Event alerts: The same host sends notifications about outpatient visits, admissions and discharges for the practice's patients.
• Orders and referrals: Kansas lets clinical staff enter referral orders and place imaging orders; Hoag allows radiology orders only, and only for providers or a designated practice liaison.
• Business functions: Hoag adds claims status and remittance advice, document attachment, secure two-way messages with its providers and online release of information requests.
• Read-only hosts: Other health systems describe their portal as view-only, with notifications and no ordering.

EpicCare Link, Care Everywhere and Community Connect

Epic gives outside organizations several ways to reach a patient's record, and they solve different problems. Picking the wrong one is a common reason a referral project stalls after the first meeting.

• EpicCare Link: A browser view into the host's Epic record for users who keep their own, separate EHR. Data stays in the host system unless someone exports or attaches it.
• Care Everywhere: Record exchange between organizations' systems. Epic states that organizations use it to exchange over 30 million patient records daily, including with organizations on other EHRs.
• Community Connect: The host extends its own Epic instance to independent providers, who then chart in that shared record as their EHR.
• Share Everywhere: A patient-driven, one-time web view of the record that the patient grants to someone outside the health system.
• Patient-directed exchange: FHIR-based APIs that let a patient send their record to a third-party app they choose.

For a practice that only needs to look up a shared patient a few times a week, the portal is often enough. For a practice that needs results in its own EHR, or a health system that wants structured referrals from many outside clinics, an interface or Care Everywhere usually does more.

Community Connect is a larger commitment than the other options. The independent practice uses the host's Epic as its own EHR, so it follows the host's build decisions, upgrade calendar and support model rather than its own.

How does outside software connect to EpicCare Link?

Outside software connects to the portal through sign-on, and connects to the data through Epic's documented interfaces. open.epic lists a single sign-on interface into EpicCare Link that passes the user and, optionally, the patient context from another system.

• Single sign-on: A practice portal or referral tool opens EpicCare Link for the signed-in user, already on the right patient, so staff do not log in twice.
• Referral data by FHIR: Epic on FHIR lists ServiceRequest read for referrals, and Community Resource ServiceRequest, Task and Communication resources for referral loops with community organizations.
• Messages by HL7 v2: Epic's Incoming Provider Communications Interface routes letters written in other systems to the recipient by preference, such as In Basket, fax or mail.
• Documents by HL7 v2: Outgoing Documentation sends notes as HL7 MDM messages, which can carry a consult note back to the referring practice's own system.

What a vendor should not do is automate the portal's screens. Hosts such as Hoag make each user responsible for all activity under their login and forbid sharing credentials, so a bot that signs in as a user breaks the user agreement and leaves an audit trail that names the wrong person.

Single sign-on is worth scoping early, because it needs the host's identity team as well as its Epic analysts. Agree which system is the identity source, how a user is matched to their portal account, and what happens when the patient context passed in is a patient the user is not allowed to see.

What does a host need to run a portal program?

A host needs an owner for enrollment, a site administrator model, signed agreements and a review cycle. The software is the smaller part; the account lifecycle is what keeps the program safe.

• 1. Agreements: Hoag requires each organization to sign a data sharing agreement and each user to sign a user agreement submitted by their site administrator.
• 2. Site administrators: The University of Kansas Health System asks every practice to name 2 site administrators who verify users and reset passwords.
• 3. Authentication: Kansas requires 2-factor authentication for user accounts.
• 4. Account review: Hoag's site administrators verify accounts quarterly and deactivate the ones no longer needed.
• 5. Feature scope: Decide per user group which chart sections, order types and notifications are on, and publish that list.
• 6. Support path: Give practices one contact for access problems and one for clinical questions about the shared patient.

Rules that apply to community access

• Treatment disclosures: Under 45 CFR 164.502(b)(2)(i), the HIPAA minimum necessary standard does not apply to disclosures to a health care provider for treatment, which is why referring physicians can see a broad chart.
• Not a business associate: A provider that receives PHI to treat the patient is not the host's business associate under HHS rules, so a referring practice signs a portal agreement, not a BAA.
• Security Rule controls: 45 CFR 164.312 makes unique user identification, audit controls and person or entity authentication required safeguards for the host's system, portal accounts included.
• Information blocking: For health care providers, blocking or delaying an outside clinician's access to EHI can be information blocking under 45 CFR Part 171 unless an exception applies.

These rules pull in two directions. The treatment exemption allows a broad chart view, while the Security Rule pushes the host to tie every view to one authenticated person, which is why hosts pair wide chart access with strict account controls.

Where portal programs break down

• Stale accounts: Staff who left a practice keep active logins because nobody owns the quarterly review.
• Shared logins: A front desk uses one account for everyone, which defeats unique user identification and makes audit logs useless.
• Double entry: Staff read a result in the portal and retype it into their own EHR, which adds transcription errors and delay.
• Feature assumptions: A workflow built for one host's ordering rights fails at a second host that runs a read-only portal.
• No loop closure: The referral is placed, but the consult note never reaches the practice's own record.
• Screen automation: A vendor scrapes the portal instead of using an interface, and the host disables the account.

Several of these failures are operational rather than technical. A named enrollment owner and a quarterly access review prevent the first two, and an interface for results and consult notes removes the retyping and the missing loop.

How Agnotic can help

A referral network rarely runs on the portal alone. Agnotic Technologies builds the software around it: single sign-on from a practice or referral tool into EpicCare Link, referral intake that reads Epic's referral resources, HL7 v2 feeds that carry consult notes back to the referring practice, and enrollment tooling that tracks site administrators and access reviews.

Agnotic works with the host's Epic analysts on what is enabled, builds against the customer's test environment, and designs the access model around the HIPAA Security Rule safeguards the host already enforces.

Sources

• Epic: Interoperability, including Epic Community Link, Care Everywhere and Community Connect
• open.epic: Single Sign-On into EpicCare Link and other clinical interfaces
• open.epic: Incoming Provider Communications and Outgoing Documentation interfaces
• The University of Kansas Health System: EpicCare Link users, features and security
• Hoag: EpicCare Link features, access periods and site administrators
• UI Health: EpicCare Link for referring providers
• 45 CFR 164.502: Uses and disclosures, minimum necessary and business associates
• 45 CFR 164.312: Technical safeguards