Want to interoperate?

Epic's comprehensive health record software supports a broad set of interoperability technologies.

First, tell us a bit about yourself. Who are you?

Ah, the crafty type. Whether you're a software developer, researcher, data scientist, or another kind of techie, perhaps we have something you'll find useful.
We see our customers as heroes. Thank you for helping, good citizen.
Working together to improve a member’s experience — now that’s what I call benefits.
Our hero! Helping heroes get the information they need makes our day. :-)
You're at the heart of everything we build.
Whether you're a soup kitchen, social worker, legal office, clinical support staff, or a community hospital, we understand you need access to the patient's chart to meet their needs.
We have no doubt that every time you've been "defeated" that we're all playing into your diabolical plan.

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, HL7v2 Validator 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.

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.

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:

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.

hanging open sign

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

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
To learn more or enroll, go to the Vendor Services website.

care everywhere logo

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 nearly 150 million 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 logo

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.

email envelope

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.

question mark

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

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
To learn more or enroll, go to the Vendor Services website.

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 logo

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 logo

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 nearly 150 million 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 logo

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 logo

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.

email envelope

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.

EHI Export icon

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.
question mark

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 logo

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.

interconnected rings

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.

medical record folder with person's face

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 logo

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 logo

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 logo

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.

lucy logo

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.

question mark

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.

hanging open sign

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, and an HL7v2 Validator for device or result HL7v2 messages. 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

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
To learn more or enroll, go to the Vendor Services website.

payer platform logo

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 logo

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.

medication pills

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 logo

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.

code symbols with arrow denoting deployment

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.

wrench with web icon

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.

lock and key

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.

shield with lock

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.

report

Reporting Security Issues

Found a potential security issue? Please report the vulnerability so we can address it quickly.