Want to interoperate?
First, tell us a bit about yourself. Who are you?
Available resources
Epic supports a wide variety of data exchange technologies. If you’re not sure how best to enable your app to exchange data with Epic, this guide provides an overview of the different ways to work with Epic, the various types of data exchange technologies, and the processes for developing and testing your app.
What Does It Mean to Exchange Data with Epic?
Epic strives to provide patients with the best care through optimization of our EHR, including through connections to other systems, such as other EHRs, government entities, and third-party consumer applications.
These connections are used to facilitate data exchange that can provide benefits such as:
- Granting patients access to their own medical records
- Allowing patients to share their data with additional applications of their choice
- Ensuring that users of other EHRs have access to a patient’s data to support continuity of care
- Sending data to patient registries
- Enabling clinical decision support for providers
How Do I Exchange Data with Epic?
There are five main phases to prepare for and ultimately exchange data with Epic. These phases consist of designing, developing, testing, and connecting your app with Epic, which ultimately facilitates data exchange between your system and Epic.
What Should I Consider When Designing My Data Exchange?
Due to the vast breadth of standards and types of integrations a developer may wish to pursue, there are many factors to consider when determining the best way for you to exchange data with Epic. The sections below cover the most common considerations when designing an integration, while the Case Studies section toward the end of this document provides examples for applying these considerations to some sample scenarios.
Types of Data to Exchange
Before you begin designing your integration, you must first understand what data you plan to exchange with Epic. Start by defining the discrete types of data your app will work with, and define a scope for the level of detail required within that data set. For example, you may need to exchange medication information. You should then more specifically define data elements you need within that data type, such as dosage information, RxNorm codes, etc.
Direction of Data Exchange
After you have defined the data you need to exchange, determine the direction of that exchange. For example, an integration that transfers data from Epic to clinical registries may only need to read data from Epic. Meanwhile, an integration that results lab orders will need to write data back to Epic. Make sure you understand which data types need to be read out of Epic and which need to be written into Epic.
When writing data to Epic, additional caution should be taken to ensure that the data written is accurate, complete, and documented on the correct patient. Improper use of these technologies may result in patient safety and data integrity concerns.
Workflows Using Data Exchange
Next, determine when and how this data exchange should occur. Does data exchange occur based on a specific event, such as a clinician placing an order or a patient being discharged? Does data exchange occur on a schedule, such as a nightly data extract? Does data exchange occur when a user decides to launch your app? Some methods of data exchange might only be applicable in specific workflows or when specific events occur. Before determining your appropriate data exchange method, you must first define the workflows in which you plan to exchange data with Epic.
Data Exchange Method
Epic recommends using industry standards for data exchange whenever possible. The most appropriate standard for your use case may vary. For example, NCPDP standards may be the most appropriate method to exchange of pharmaceutical data, while Digital Imaging and Communications (DICOM) standards may be the most appropriate method to exchange medical images.
Once a data set, direction of data exchange, and workflows in which that exchange should occur are defined, you need to determine which standards or specific technologies are the most applicable.
You can find information about the standards-based interfaces, APIs, and other data exchange methods that Epic currently supports by browsing the Explore pages of open.epic.
In some cases, industry standards may not fully meet your needs. Epic has developed Epic-specific data exchange methods that extend the capabilities of industry standards for some use cases. For example, some Epic-specific web services are described on the Web Services page of open.epic. Other options may be available through our Vendor Services offering.
Security Mechanisms
Due to the sensitive nature of healthcare data, data exchange technologies generally require various forms of authentication, authorization, and security. Some integrations may use an SSO solution, such as SMART on FHIR, for authentication using the OAuth 2.0 framework for authorization while others rely on security mechanisms like client certificates or TCP/IP connections. Consider what authentication mechanisms are supported by the data exchange methods you have selected for your use case. Applications with some form of user interface generally require an authentication mechanism to authenticate the specific user gaining access to that data, while system-to-system connections are less likely to require user-based authentication.
OAuth 2.0 is the preferred method of security for apps in which Epic users interact with data. TCP/IP connections and TLS/SSL certificates are common security mechanisms for system-to-system connections.
What Support Is Available to Me?
Epic provides two services paths for supporting other vendors: open.epic and Vendor Services. Open.epic focuses on enabling others to learn about and engage in data exchange with Epic through self-service documentation and tools. Vendor Services adds human technical support services as well as expanded online documentation, tutorials, and testing tools.
open.epic
Open.epic helps you learn about and engage in data exchange with Epic. We provide technical specifications for our standards-based interfaces and APIs, self-service testing sandbox and client registration for FHIR clients , and general information (like this!) to help you locate the right Epic tools or services to support you in your endeavor.
The most successful open.epic integrations tend to be those created by developers knowledgeable in the integration technologies they plan to use to produce integrations that meet the workflow needs of Epic community members.
Vendor Services
Vendor Services provides vendors the option to engage with an Epic representative to obtain support services such as integration design feedback, direct troubleshooting assistance, install documentation and assistance, and more.
For more information on what Vendor Services offers, check out the Vendor Services website.
Summary
Select the path you plan to use while designing your app, as its affects the services and data exchange technologies available to you.
| Details/Features | open.epic | Vendor Services |
|---|---|---|
| Available to... | Anyone | Vendors that meet the basic enrollment criteria |
| App Vetting Process | None | Vendors may choose to provide additional information for potential customers and to attest to best-practices |
| Membership Fees | None | Yes, visit the Vendor Services website for details |
| Design and Technical Support for Developer | Online resources | Additional online resources, Epic representative support, user forums |
| Training for Developer | Online resources | Additional online resources, webinars, newsletters |
| App Testing Resources | Launchpad | Additional testing tools/harnesses, Testing in Epic environment with Epic representative |
| Single Sign-On / Web Launch | Available | Available |
| Industry-Standard & Epic Public APIs | Available | Available |
| Additional APIs | Not available | Available for specific use cases |
| Kit | Not available | Available for specific use cases |
| Content Imports | Not available | Available for specific use cases |
| Install Support for Developer | Online resources | Online resources, Epic representative support, user forums, implementation guides, downloadable build |
Where Do I Go from Here?
Now that we’ve gone through the basics of which technologies to use for your data exchange with Epic, the following sections provide high-level guidance for turning those recommendations into a working connection. For a brief overview of how to work with an Epic Community Member to develop your product's connection to Epic, see our Strategies to Effectively Collaborate page.
Developing Your Connection
Once you have determined the technologies you need for data exchange, the next step is to develop a connection to Epic!
During this stage of the process, you reference specifications for the data exchange technologies against which you are developing. Some standards have open-source code libraries you can use for your development.
Obtaining a Client ID
Many interoperability technologies require a client ID to exchange data with Epic. Vendors using those interoperability technologies will need to register for client ID. A client ID identifies an associated application requesting access to an organization’s Epic environment and tells the system the scope of data that the application is authorized to access.
Client IDs are commonly provisioned using self-service tools on open.epic and Vendor Services. This step generates a production client ID for use in organizations’ Epic production environments, and non-production client ID for use in sandboxes and in organizations’ Epic non-production environments.
Testing Your Connection with the Sandbox
The method for testing your connection may vary depending on the technologies you’re using, but at their base, both the open.epic and Vendor Services websites offer a sandbox environment – a non-production instance of Epic with which you can test your connections using certain interoperability technologies.
A more comprehensive list of the available testing tools in each website can be found on the Testing Sandbox page .
Distributing Client IDs to Organizations’ Epic Environments
If your connection requires a client ID, you must distribute your client ID to the relevant organization’s environments before you can start testing your connection to that organization’s non-production environment.
Client IDs are distributed to community member environments in a few different ways. That distribution method may be determined by some app-specific criteria:
- Client IDs for apps that that access USCDI v1 or CCDS data elements on behalf of patients (or their proxies) using certain FHIR APIs automatically download to most organizations' Epic environments.
- Client IDs for other apps (those that do not meet the auto-download criteria) must be manually downloaded to organizations’ Epic environments when they choose to use such apps. The full download process can be found on our App Creation & Request Process page.
Installing Your App with Community Members
Prior to connecting your application to an organization’s Epic production environment, you and the customer should first test your application and connection against the organization’s non-production Epic environments. Each organization customizes their Epic environments to meet their specific needs. As a result, each organization’s Epic environments vary from one another, sometimes in ways that impact your data exchange methods. Testing enables organizations to validate that connections to their system access and write data in a safe, secure, and reliable way.
Depending on the various data exchange technologies your connection uses and the workflows it integrates with, this testing may also be necessary for the organization’s analysts to validate Epic environment configuration and network configuration needed to connect their Epic environments to your application.
If you would like assistance with the installation process, consider Vendor Services, which offers pre-configured Epic configuration for your application to reduce manual effort.
Case Studies
Now that we’ve talked about the process, you may be wondering how to apply that logic to your own proposed method of data exchange. This section provides some example scenarios for how you might apply this document's logic to your own decision-making process.
Case Study A: Scheduling
This example was last reviewed on December 15, 2022.
In this scenario, your organization works with patients who would like to schedule appointments at Epic clinics and facilities. You’d like to be able to view a patient’s upcoming appointments, schedule new appointments, and cancel existing appointments.
Types of Data to Exchange
Your organization is only interested in basic patient information and appointment related data. This can help you determine potentially applicable technologies. Now we can look at the different data exchange technologies that support your desired use.
- FHIR APIs
- HL7v2 Interfaces
-
Additional API technologies
- If you have use cases that do not seem to be covered with the technologies above, reach out to Vendor Services to determine if there are additional technologies available that fit your use case.
In this step, you’ll also want to consider individual data elements that your integration relies on. For appointments this may be information about the patient, provider, visit type, department, date and time. Some data exchange technologies may only support certain data fields, or only provide limited details about the field. Making a comprehensive list of all data elements your integration requires can help you determine whether or not a specific data exchange technology meets your needs.
Direction of Data Exchange
For this integration, your organization would like to read a patient’s current appointments from Epic, and write new appointments, cancelations and reschedules into Epic, so the direction of data exchange varies. In this step, you may also want to consider whether this reading and writing of data is initiated by your system or by Epic.
For retrieving a patient’s upcoming appointments, you have to decide if you want to retrieve a schedule from Epic, or be notified of schedule changes so that you can create your own schedule. A related question is: do you want to store upcoming appointments? Or do you want to retrieve upcoming appointments only when a patient asks? If you want to create the schedule, and only be notified of changes to the schedule, HL7v2 interfaces are a good choice for proactive notifications. If you want to retrieve a complete picture, or appointments only when a patient asks, then querying data through APIs allows for this flexibility. You look at the FHIR APIs and don’t see an appointment.search option to retrieve an upcoming appointment for which you don’t know the FHIR ID. You contact Vendor Services, who investigates whether there are additional APIs that can retrieve upcoming appointment information for a patient.
You are looking to schedule and cancel appointments in Epic. However, you may need to query information from Epic first. APIs allow for querying of existing information like available slots and existing appointments if they aren’t stored in your system. You see that appointment $find may be helpful for this use.
Workflows Using Data Exchange
For your integration there will be patients interacting with your web page to manage their appointments. You are most interested in allowing patients to view upcoming appointments and cancel appointments that are no longer needed. Your app provides a convenient way for patients new to an organization to schedule appointments. With the patient as the user, and desiring the ability to search for available slots, you would like to use APIs. Looking closer into Appointment $find you see that it is intended for a non-patient user and requires the customer to do significant build. You also do not see an API to cancel appointments, so you contact Vendor Services to help investigate whether additional APIs are available.
Security Method
Different integration methods have different security capabilities. In this scenario your app is controlled by the patient but any API calls or HL7 messages are secured on the backend.
A patient using your website may not have an Epic patient portal (MyChart) account, so they may not have any Epic credentials to facilitate single sign-on with your website. With APIs, you will support an OAuth 2.0 Client Credentials flow or basic authentication with a generic user for your app. This grants you an access token that can be used to authorize subsequent API calls.
For HL7 you use a TCP/IP connection rather than HL7v2 over HTTPS. Data transferred with HL7v2 won’t rely on authentication, but rather relies on other security mechanisms to secure your data exchange.
Data Exchange Method
Now that you’ve analyzed the above sections, we can pull that information together.
You want to store your own schedule of appointments so you can send appointment reminders whether or not a patient logs into your portal. You opt to receive HL7v2 messages for appointment booking, cancellation, modification and for no shows so you can store this data in your own database. For scheduling new appointments, you decide to use additional API technologies available through Vendor Services. When a patient decides to book an appointment, you don’t know what slots are available to book, so you decide to use APIs to query for appointment availability. Then, to book the appointment for the patient you decide to use APIs because the data fields returned by the availability API and required by the scheduling API match. You also decide to cancel appointments through APIs.
Case Study B: Lab Integration
This example was last reviewed on December 5, 2022.
In this scenario, your organization results labs for hospitals, some of which use Epic, and you’d like to be able to send lab orders and results back and forth between the two systems. What will this integration look like?
Types of Data to Exchange
The main groups of data types your organization is interested in are lab orders and lab results. This can help you limit down potential technologies. Now you can look at the different data exchange technologies that support these mechanisms:
-
FHIR APIs
- ServiceRequest (Order Procedure) for lab orders
- Observation (Labs) for lab results
- DiagnosticReport for lab results
-
HL7v2 Interfaces
- Outgoing Ancillary Orders interface for lab orders
- Incoming Ancillary Results interface for lab results
-
Additional APIs
- Lab APIs which may be available through Vendor Services
In this step, you’ll also want to consider individual data elements that your integration relies on. For labs, this may be information about the specimen, how it was collected, when it was received, etc. Say your lab also supports microbiology labs, where your integration also needs to record sensitivity and isolate information. Some data exchange technologies only support certain data fields, so making a comprehensive list of all data elements your integration requires can help you determine whether or not a specific data exchange technology meets your needs.
Direction of Data Exchange
For this integration, your organization would like to read lab orders from Epic and write lab results into Epic. This means that the direction of data exchange varies depending on the type of data you’re exchanging. In this step, you may also want to consider whether this reading and writing of data is initiated by your system or by Epic.
Looking at the lab order portion of the integration, you aren’t sure when a lab order will be placed in Epic. Rather than continually querying Epic for lab orders, you would prefer that Epic send you the lab order each time one of these orders is placed. In that case, you want Epic to push this lab order data into your system. HL7v2 interfaces are great for this type of proactive messaging so you’ll want to keep that in mind as you design the integration.
Looking at the lab result portion of the integration, you do know when a lab is resulted in your system, so you should control when you send lab results back to Epic. This means that you’ll push lab result back into Epic from your system. Many different technologies exchange lab results. However, you’re looking to write this data, not read it. You see that Observation (Labs) does not support a Create interaction that would allow you to create this lab result in Epic. You contact Vendor Services, who informs you that there are no additional APIs that would allow you to write lab results back to Epic either. You do note that the HL7v2 Incoming Ancillary Results would allow you to write this data into Epic.
Workflows Using Data Exchange
This section is simple for your integration: you’d like to integrate with lab ordering and resulting workflows. For your integration, you’re most interested in ordering workflow after the order has been signed and the resulting workflow before the lab has been resulted in Epic. Your app supplements these workflows my automating the delivery of orders and the receipt of lab results. This could replace an old workflow such as sending orders and results manually by fax.
Data Exchange Method
Now that you have analyzed the above sections, you can pull that information together.
For your integration, it makes the most sense to use the Outgoing Ancillary Orders and Incoming Ancillary Results HL7v2 interfaces for your integration.
Security Method
Now that you’ve generally determined the data exchange technologies needed for your app, you’ll also want to think about what, if any, authentication method is needed. Since this app is entirely system-to-system using HL7v2 interfaces and you use a TCP/IP connection rather than HL7v2 over HTTPS, your integration won’t rely on authentication, but rather relies on other security mechanisms to secure your data exchange.
Interfaces
Each month more than 13 billion messages are sent between Epic and non-Epic systems. Across the Epic community, we have over 30,000 active interfaces with more than 1,000 vendors. We offer interfaces that are compliant with HL7, X12, DICOM, NCPDP, and other standards and can support interfaces that are either real-time or batch, one-way or bidirectional, point-to-point or mediated by an interface engine.
To learn more about each standard and any requirements that the standards body may have to use their interfaces, visit the standards body’s website. Explore and download documentation about Epic’s implementation of standards-based interfaces.
FHIR
Epic is a strong supporter of HL7® FHIR® (Fast Healthcare Interoperability Resources) as the future of REST-based interoperability. In addition to participating in the standards development process with HL7, Epic is also a member of the Argonaut Project and the Da Vinci Project, each aimed at accelerating the adoption of FHIR.
Check out the variety of resources we offer to support your FHIR development needs.
Vendor Services
Vendor Services provides developers various support services, including:
- Testing tools, simulators, and sandboxes for multiple versions of the Epic system to enable robust, cross-version testing
- Online tutorials and webinars, newsletters, and a developer community forum
- Design, testing, and troubleshooting support services to build an effective integration
- Install tools, documentation, and support services
Care Everywhere
Traditionally thought of as "interoperability", Care Everywhere processes requests to and from other health systems that care for patients, sending standardized summaries (C-CDA), and incorporating the new data into patient records. With hundreds of millions of record exchanges per month, Care Everywhere has helped millions of patients and providers with care coordination and transitions of care.
Organizations using Care Everywhere are able to connect using the protocols outlined on open.epic.
Carequality
Like the framework and agreements that enable roaming across cellular networks and providers, Carequality enables nationwide coordination of care. Carequality's common framework includes trust policies, implementation-level functionality, standards-based technical and testing requirements, and operational practices for faster connectivity with other network members.
Nearly all Epic customers are members of the Carequality network, providing access to coordinated care for millions of patients across hundreds of Epic organizations.
To get started, contact Carequality to become a member.
The Trusted Exchange Framework and Common Agreement™
The Trusted Exchange Framework and Common Agreement (TEFCA™) is a federally backed interoperability network intended to improve the exchange of patients’ health records while protecting privacy. The Epic community is in the process of getting connected to TEFCA. You can see the organizations that are live (or planning to go live) here. You can learn more about connecting to Epic organizations for TEFCA’s supported use cases here.
Direct Messaging
Direct messaging allows users to push patient charts to community members using a network of HISPs (Health Information Service Providers), and works similar to email. The organization that is currently seeing the patient can send a standardized C-CDA summary to another organization for referrals and other transitions of care, and provider to provider communications between organizations.
Epic organizations have also used Direct Messaging to improve social care outcomes with groups like United Way, and to share information with Health Information Exchanges (HIEs), government repositories, and public health reporting databases.
Check out more details about how to set this up on open.epic.
Couldn't find it?
Trying to interoperate and didn't find what you were looking for? Use this form to tell us more about what you're seeking.
You can work directly with Epic customers to implement interoperability between your application and healthcare organizations' Epic systems. Learn more about available interoperability technologies. If you're interested in working directly with Epic to design an integration, or would like other support services, check out Vendor Services.
Vendor Services
Vendor Services provides developers various support services, including:
- Testing tools, simulators, and sandboxes for multiple versions of the Epic system to enable robust, cross-version testing
- Online tutorials and webinars, newsletters, and a developer community forum
- Design, testing, and troubleshooting support services to build an effective integration
- Install tools, documentation, and support services
Our software exchanges over 5 million patient records daily via standards-based exchange of CCD/C-CDA documents to other vendor EHRs, government organizations, and Epic EHRs.
EpicCare Link
With EpicCare Link, community users like non-Epic referring and ordering providers, post-discharge facility staff, and release of information requesters can access the patient chart via a web portal. They can follow the patient's care across the health system, schedule appointments, place orders, send notes, and more.
To use EpicCare Link to partner with an Epic organization, sign up with that organization directly.
Care Everywhere
Traditionally thought of as "interoperability", Care Everywhere processes requests to and from other health systems that care for patients, sending standardized summaries (C-CDA), and incorporating the new data into patient records. With hundreds of millions of record exchanges per month, Care Everywhere has helped millions of patients and providers with care coordination and transitions of care.
Organizations using Care Everywhere are able to connect using the protocols outlined on open.epic.
Carequality
Like the framework and agreements that enable roaming across cellular networks and providers, Carequality enables nationwide coordination of care. Carequality's common framework includes trust policies, implementation-level functionality, standards-based technical and testing requirements, and operational practices for faster connectivity with other network members.
Nearly all Epic customers are members of the Carequality network, providing access to coordinated care for millions of patients across hundreds of Epic organizations.
To get started, contact Carequality to become a member.
Share Everywhere
Share Everywhere enables patients to quickly share their health information with the people taking care of them. Patients can choose to share a temporary web view of their health record summary with anyone in the world who has an internet connection, even if that person don’t have access to an EHR.
From MyChart, patients can generate a share code and provide it to the person they want to share their health data with. This might be a doctor, chiropractor, physical therapist, dentist, or school nurse, for example. The share code recipient enters that code and the patient’s date of birth on the Share Everywhere website to receive one-time, temporary access to the patient’s health information. The person who views this information can also write a note back to the patient’s health system to help keep them informed of the care they provided.
The Trusted Exchange Framework and Common Agreement™
The Trusted Exchange Framework and Common Agreement (TEFCA™) is a federally backed interoperability network intended to improve the exchange of patients’ health records while protecting privacy. The Epic community is in the process of getting connected to TEFCA. You can see the organizations that are live (or planning to go live) here. If you’re an Epic customer, contact your BFF to get started. If you’re not an Epic customer, you can learn more about connecting to Epic organizations for TEFCA’s supported use cases here.
Direct Messaging
Direct messaging allows users to push patient charts to community members using a network of HISPs (Health Information Service Providers), and works similar to email. The organization that is currently seeing the patient can send a standardized C-CDA summary to another organization for referrals and other transitions of care, and provider to provider communications between organizations.
Epic organizations have also used Direct Messaging to improve social care outcomes with groups like United Way, and to share information with Health Information Exchanges (HIEs), government repositories, and public health reporting databases.
Check out more details about how to set this up on open.epic.
Exports
Epic software gives users the ability to export electronic health information in multiple electronic formats depending on the use case. Exports can be formatted to be human-readable or computable (machine-readable). Exports that are formatted to be computable can be provided in industry standard formats (suitable for most scenarios where information will be exchanged with other systems) or Epic-native formats (suitable when all available information is needed).
A few examples of available electronic formats include:
- Human-readable documents, such as PDFs, for subsets of clinical electronic health information.
- FHIR-formatted files for a subset of electronic health information in FHIR.
- C-CDA-formatted XML documents for subsets of electronic health information that can be expressed in C-CDA templates.
- EHI Tables for all Epic electronic health information, in a computable, tab-separated value (TSV) file format native to Epic.
Couldn't find it?
Trying to interoperate and didn't find what you were looking for? Use this form to tell us more about what you're seeking.
Access to Epic Applications and Documentation
If you are a consultant providing support for an Epic customer and need access to Epic applications and documentation, we are here to help. Our team will work with your consulting firm to ensure you have an appropriate agreement in place with us. To get started, please submit this application for access.
Submit one application per customer, even if you have multiple consultants working with that customer. If your firm’s Epic access needs to be updated for a customer, please submit a new application. We will review each application and either send your firm an agreement to sign or contact you to help with next steps.
As one of our customers, you should give us a call at (608) 271-9000. We'll work with you to figure out how to get you where you want to go.
MyChart
If your healthcare provider uses Epic, they likely offer you secure, online access to MyChart, Epic’s patient portal, to help you manage and participate in your healthcare. Note that your healthcare provider might call its patient portal by another name, usually similar to its organization name.
MyChart enables you to interact with your healthcare provider and health information electronically from your smartphone, tablet, or internet browser. You can view and schedule appointments, review test results, communicate with your care team, and much more.
Connecting Other Apps
Most Epic customers enable you to connect your favorite fitness wearables and health apps to your electronic health record. You can connect your Fitbit or Withings devices directly in MyChart. Developers of apps like Apple Health have designed their apps to connect to your electronic health record with your permission. When these apps attempt to access your health record, you should be redirected to your healthcare provider's MyChart page to log in with your credentials (you shouldn't share your credentials directly with the 3rd party). Learn more about how to authorize an app to access your records and how to revoke authorization later.
Your Health Records and Privacy
Epic provides doctors and healthcare organizations with electronic health record software that lets them securely document and store your health information. For questions about privacy, data sharing, and your rights as a patient, contact your healthcare organization’s medical records department or privacy officer. Most healthcare organizations have a patient privacy document, patient rights document, or a page on their website with specific privacy policies and contact information.
Depending on where you live, your health record may be protected by regulations such as HIPAA and state laws in the U.S., the General Data Protection Regulation (GDPR) in the European Economic Area, or Australia’s Privacy Act of 1988. Your healthcare provider will have more details on which regulations or other protections apply to your health record.
Your health record contains your clinical data, like test results, medications, and surgical history, along with demographic information like your address and date of birth. To request a copy of your health record or ask questions about what’s in it, contact your healthcare provider's medical records department.
Happy Together
If you have more than one MyChart account, Happy Together shows your information from those accounts in a single view. You can review your recent and upcoming visits, test results, medications, allergies, and health issues from multiple healthcare providers, all in one place.
Some organizations haven’t activated Happy Together yet. Check out our Happy Together organization list to see which organizations are already using Happy Together and which ones will be joining soon.
Share Everywhere
Share Everywhere enables you to quickly share your health information with people taking care of you. You can choose to share a temporary web view of your health record summary with anyone in the world who has an internet connection, even if that person doesn’t have access to an electronic health record.
From MyChart, you can generate a share code and provide it to the person you want to share your health data with. This might be a doctor, chiropractor, physical therapist, dentist, or school nurse, for example. The share code recipient enters that code and your date of birth on the Share Everywhere website to receive one-time, temporary access to the your health information. The person who views this information can also write a note back to the your healthcare provider to help keep them informed of the care you received.
Care Everywhere
Care Everywhere lets your healthcare providers securely exchange your health information with other organizations that care for you, whether they use Epic or another electronic health record.
Sharing information helps your care team provide you with the best care. For example, in an emergency, it's critical for doctors to know about your allergies and medications. Electronic exchange of your record can also help improve your experience as a patient by reducing how much of your medical history you need to remember, bring with you, or have mailed or faxed to your healthcare providers.
Only healthcare organizations that identify you as one of their patients can request your record from your healthcare provider. If you'd like to know more about your healthcare organization's policies and practices for sharing your records, contact their medical records department.
The Trusted Exchange Framework and Common Agreement™
The Trusted Exchange Framework and Common Agreement (TEFCA™) is a federally backed program intended to support the exchange of health records while protecting privacy. One of the connection pathways TEFCA supports is the ability for patients to use apps of their choice to retrieve copies of their medical records from participants in the framework. In TEFCA, this is referred to as Individual Access Services (IAS). The idea is that individuals can use TEFCA-connected IAS apps as an alternative to using a patient portal app offered by their healthcare providers. Patients might then use the app to self-report or track their health data, which can also provide valuable information to their doctor.
TEFCA also raises the bar for privacy and security. Before an IAS app can connect to the framework, it must voluntarily agree to comply with privacy and security requirements from HIPAA. Apps must also explicitly ask for permission before they can sell your data. Health apps for patients outside of TEFCA often don’t otherwise have to abide by HIPAA’s privacy and security rules.
To get your records through TEFCA, first you’ll need to find an app that you want to use that participates in TEFCA. Then, you’ll follow the steps described in the Connecting Other Apps section above to give access to your information. If you’re an app developer, you can learn more about TEFCA IAS with Epic here.
Lucy
Lucy is Epic's freestanding personal health record. You can direct a summary of your information from the Epic electronic health record (EHR), other EHRs, and non-EHR sources (PDFs, JPEGs, etc.) to Lucy, where it can be downloaded to your computer, saved to a flash drive, or securely stored in the cloud.
Couldn't find it?
Trying to interoperate and didn't find what you were looking for? Use this form to tell us more about what you're seeking.
Not trying to interoperate and need some help? Visit Epic.com to get in touch with us.
open.epic
Here on open.epic we offer a full instance of Epic you can build configuration to test your FHIR apps. We also offer a launchpad tool for testing a web application from inside an Epic user session. In addition, we offer tutorials to help you set up an integration with Epic. The OAuth 2.0 Tutorial includes step by step guidance for the supported workflows. The FHIR tutorial describes Epic's FHIR framework and how to best navigate the data structure. The Client ID tutorial discusses when and how client IDs are used, and how to obtain them.
Vendor Services
Vendor Services provides developers various support services, including:
- Testing tools, simulators, and sandboxes for multiple versions of the Epic system to enable robust, cross-version testing
- Online tutorials and webinars, newsletters, and a developer community forum
- Design, testing, and troubleshooting support services to build an effective integration
- Install tools, documentation, and support services
Payer Platform: Bidirectional Data Exchange for Health Plans
Payer Platform is a software system that connects health plans with providers who use Epic and enables bidirectional data exchange to help improve quality of care, and reduce cost and administrative burden. For example, receive clinical summaries, images, supplementary documentation, and event notifications for your members from providers. Send paid claims, diagnoses, care gaps, and other insights so providers can embed your insights into their workflows.
Payers who choose Payer Platform become part of the Epic community. We establish a long-term relationship and offer in-depth, personalized services to facilitate connections, implement and support the technology, collect input to help shape future development, and define a vision for enabling payer and provider collaboration. Some of the largest, leading payer organizations have chosen this strategic relationship with Epic to better support their transformative, value-based goals.
If you are interested in Payer Platform, please reach out for more information.
Payer Gateway: Automated Receipt of Clinical Data from Providers
Payer Gateway is an Epic service that lets you request clinical summaries directly from providers who use Epic to reduce administrative burden. Providers who participate in Payer Gateway can release patient records automatically as visits occur, or upon request.
To use Payer Gateway, your system must support the IHE XCPD and XCA Query-Response Profiles and/or the Direct protocol. The clinical summaries are provided as HL7 CDA XML documents.
If you are interested in Payer Gateway, please reach out for more information.
Real Time Prescription Benefits
Epic supports real-time prescription benefits checking (RTPB) during the prescriber ordering process. Prescribers can see expected out-of-pocket costs, lower-cost medication suggestions, and whether additional approvals are needed from the insurance company before the prescription can be filled. Providers can share this information with patients before sending the order to the pharmacy, saving time and money for patients, and helping improve medication adherence.
If you are interested in joining the RTPB network, please reach out for more information.
Chart Gateway: Patient-Initiated Insurance Requests
Life and disability insurance companies can use Chart Gateway to electronically request and retrieve patient information from providers who use Epic and have opted to release records through Chart Gateway. When you connect to Chart Gateway, you connect with all Epic providers who have opted in, increasing efficiency for your requests, improving the applicant’s experience by reducing unnecessary physical examinations, and enhancing the security of record requests. You can use Chart Gateway to request records for life insurance, critical illness insurance, disability income insurance, and life annuity applications.
If you are interested in Chart Gateway, please reach out for more information.
Development of Secure Code
Our software development life cycle includes security code review and testing throughout development from design to release. Our review includes white-box code review and testing, black-box testing, and both static and dynamic testing of the software. Because all Epic’s applications are developed in-house on a common code base, they share a common security and authentication architecture. This helps prevent security flaws that may result from inconsistencies between the security architectures of a disparate product suite.
Security Tools and Network Configuration
Our system works with standard security mechanisms that organizations use to secure their systems. We play well with tools such as firewalls, reverse proxies, VPNs, SIEM tools, and anti-virus software. Additionally, Epic customers own their data, providing the underlying architectures to protect that data such as servers, firewalls, certificates, and load balancers. They're able to independently perform penetration testing of their own infrastructures to ensure their implementation is secure.
Encryption
We’re a big fan of the wheel. When something’s got that kind of track record, why come up with something new? We think the same thing about cryptography where we use industry standard algorithms and implementations where possible in our software and we encourage you to do the same.
Standards-Based Authentication
Epic uses industry standards for API authentication and authorization to launch third-party applications from our software, or invoke clinical decision support systems. We use the SMART App Launch Framework with SMART on FHIR to connect authorized third-party applications to EHR data, allowing apps to launch from within or outside of our software. This framework supports reliable and secure authorization of app used by clinicians and patients with our software. The CDS Hooks framework enables external clinical decision support services to provide clinicians information or prompt to launch SMART apps within the workflow at the point of care.
Reporting Security Issues
Found a potential security issue? Please report the vulnerability so we can address it quickly.