Documentation - Epic on FHIR

Primary User Type	User Has Epic Access	User Context
Patient	Yes	Patient
Patient	No	Backend System
Provider	Yes	Clinicians, Staff, or Administrative Users
Provider	No	Backend System
Background Process with No User Interaction	N/A	Backend System

Header	Description
`alg`	The JWT authentication algorithm. Currently only RSA 256 is supported in id_token JWTs so this will always be `RS256`.
`typ`	This is always set to `JWT`.
`kid`	The base64 encoded SHA-256 hash of the public key.

Claim	Description	Remarks
`iss`	Issuer of the JWT. This is set to the token endpoint that should be used by the client.	Starting in the May 2020 version of Epic, the `iss` will be set to the OAuth 2.0 server endpoint, e.g. https://<Interconnect Server URL>/oauth2. For Epic versions prior to May 2020, it is set to the OAuth 2.0 token endpoint, e.g. https://<Interconnect Server URL>/oauth2/token.
`sub`	STU3+ FHIR ID for the resource representing the user launching the app.	For Epic integrations, the `sub` and `fhirUser` claims reference one of the following resources depending on the type of workflow: Provider/user workflows: Practitioner resource MyChart self access workflows: Patient resource MyChart proxy access workflows: RelatedPerson resource Note apps with a SMART on FHIR version of DSTU2 will still get a STU3+ FHIR FHIR ID for the user. The STU3+ Practitioner.Read or RelatedPerson.Read APIs would be required to read the Practitioner or RelatedPerson FHIR IDs. Patient FHIR IDs can be used across FHIR versions in Epic's implementation.
`fhirUser`	Absolute reference to the FHIR resource representing the user launching the app. See the HL7 documentation for more details.	The fhirUser claim will only be present if app has the R4 (or greater) SMART on FHIR version selected, and requests both the openid and fhirUser scopes in the request to the authorize endpoint. See the remark for the `sub` claim above for more information about what the resource returned in these claims represents.
`aud`	Audiences that the ID token is intended for. This will be set to the client ID for the application that was just authorized during the SMART on FHIR launch.
`iat`	Time integer for when the JWT was created, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC).
`exp`	Expiration time integer for this authentication JWT, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC).	This is set to the current time plus 5 minutes.
`preferred_username`	The user's LDAP/AD down-level logon name.	This claim is supported in Epic version February 2021 and later. The preferred_username claim will be present only if the app requests both the openid and profile scopes in the request to the authorize endpoint.
`nonce`	The nonce for this client session.	The nonce claim will be present only if it was specified in the authorization request. This is an identifier for the client session. For more information about the nonce, refer to the Authentication Request section of the OpenID specification.

Header	Description
`alg`	The JWT authentication algorithm. Epic supports the following RSA signing algorithms for all confidential clients: RS256, RS384, and RS512. For clients that register a JSON Web Key Set URL, Epic also supports the following Elliptic Curve algorithms: ES256, ES384. Epic does not support manual upload of Elliptic Curve public keys, and we recommend new apps use a JWK Set URL and Elliptic Curve keys.
`typ`	If provided, this should always be set to `JWT`.
`kid`	For apps using JSON Web Key Sets (including dynamically registed clients), set this value to the `kid` of the target public key from your key set
`jku`	For apps using JSON Web Key Set URLs, optionally set this value to the URL you registered on your application

Claim	Description	Remarks
`iss`	Issuer of the JWT. This is the app's `client_id`, as determined during registration on the Epic on FHIR website, or the `client_id` returned during a dynamic registration	This is the same as the value for the `sub` claim.
`sub`	Issuer of the JWT. This is the app's `client_id`, as determined during registration on the Epic on FHIR website, or the `client_id` returned during a dynamic registration	This is the same as the value for the `iss` claim.
`aud`	The FHIR authorization server's token endpoint URL. This is the same URL to which this authentication JWT will be posted. See below for an example POST.	It's possible that Epic community member systems will route web service traffic through a proxy server, in which case the URL the JWT is posted to is not known to the authorization server, and the JWT will be rejected. For such cases, Epic community member administrators can add additional audience URLs to the allowlist, in addition to the FHIR server token URL if needed.
`jti`	A unique identifier for the JWT.	The `jti` must be no longer than 151 characters and cannot be reused during the JWT's validity period, i.e., before the `exp` time is reached. In the November 2024 version of Epic and later, this value must be a string.
`exp`	Expiration time integer for this authentication JWT, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC).	The `exp` value must be in the future and can be no more than 5 minutes in the future at the time the access token request is received.
`nbf`	Time integer before which the JWT must not be accepted for processing, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC).	The `nbf` value cannot be in the future, cannot be more recent than the `exp` value, and the `exp` - `nbf` difference cannot be greater than 5 minutes.
`iat`	Time integer for when the JWT was created, expressed in seconds since the "Epoch" (1970-01-01T00:00:00Z UTC).	The `iat` value cannot be in the future, and the `exp` - `iat` difference cannot be greater than 5 minutes.

JWT Scenario	Audience (aud)	Issuer (iss)
Launch Token	Authorization server	Authorization server
Authorization Code	Authorization server	Authorization server
Access Token	Authorization server	Authorization server
Openid Connect ID Token	The app's client_id	Authorization server
Client Assertion	Authorization server	The app's client_id

JWT Scenario	Audience (aud)	Issuer (iss)
Launch Token	Authorization server	Authorization server
Authorization Code	Authorization server	Authorization server
Access Token	Authorization server	Authorization server
Openid Connect ID Token	The app's client_id	Authorization server
Client Assertion	Authorization server	The app's client_id

Prefix	Prefix Meaning	Example Search	Example Comparisons
eq	equal	=eq2013-01-14	2013-01-14T00:00 matches
2013-01-14T10:00 matches
2013-01-15T00:00 does not match - it's not in the range
lt	less than	=lt2013-01-14T10:00	2013-01-14 matches, because it includes the part of 14-Jan 2013 before 10am
le	less than or equal to	=le2013-03-14	"from 21-Jan 2013 onwards" is included because that period may include times before 14-Mar 2013
gt	greater than	=gt2013-01-14T10:00	2013-01-14 matches, because it includes the part of 14-Jan 2013 after 10am
ge	greater than or equal to	=ge2013-03-14	"from 21-Jan 2013 onwards" is included because that period may include times after 14-Mar 2013
sa	starts after	=sa2013-03-14	"from 15-Mar 2013 onwards" is included because that period starts after 14-Mar 2013
"from 21-Jan 2013 onwards" is not included because that period starts before 14-Mar 2013
"before and including 21-Jan 2013" is not included because that period starts (and ends) before 14-Mar 2013
eb	ends before	=eb2013-03-14	"from 15-Mar 2013 onwards" is not included because that period starts after 14-Mar 2013
"from 21-Jan 2013 onwards" is not included because that period starts before 14-Mar 2013, but does not end before it
"before and including 21-Jan 2013" is included because that period ends before 14-Mar 2013

Name	User Login	User Password	Description
FHIR, USER	FHIR	EpicFhir11!	User account without linked provider record. This user will not have a PractitionerRole resource.
FHIRTWO, USER	FHIRTWO	EpicFhir11!	User account with linked provider record. This user will have a PractitionerRole resource.

Patient	Identifiers and Credentials	Applicable Resources
Camila Lopez	FHIR: erXuFYUfucBZaryVksYEcMg3 External: Z6129 MRN: 203713 MyChart Login Username: fhircamila MyChart Login Password: epicepic1	DiagnosticReport Goal Medication MedicationOrder MedicationRequest MedicationStatement Observation (Labs) Patient Procedure
Derrick Lin	FHIR: eq081-VQEgP8drUUqCWzHfw3 External: Z6127 MRN: 203711 MyChart Login Username: fhirderrick MyChart Login Password: epicepic1	CarePlan Condition Goal Medication MedicationOrder MedicationRequest MedicationStatement Observation (Smoking History) Patient
Desiree Powell	FHIR: eAB3mDIBBcyUKviyzrxsnAw3 External: Z6130 MRN: 203714 MyChart Login Username: fhirdesiree MyChart Login Password: epicepic1	Immunization Observation (Vitals) Patient
Elijah Davis	FHIR: egqBHVfQlt4Bw3XGXoxVxHg3 External: Z6125 MRN: 203709	AllergyIntolerance Binary Condition DocumentReference Medication MedicationOrder MedicationRequest MedicationStatement Observation (Smoking History) Patient
Linda Ross	FHIR: eIXesllypH3M9tAA5WdJftQ3 External: Z6128 MRN: 203712	Condition Medication MedicationOrder MedicationRequest MedicationStatement Observation (Vitals) Patient
Olivia Roberts	FHIR: eh2xYHuzl9nkSFVvV3osUHg3 External: Z6131 MRN: 203715	Binary Condition Device DocumentReference Patient
Warren McGinnis	FHIR: e0w0LEDCYtfckT6N.CkJKCw3 External: Z6126 MRN: 203710	AllergyIntolerance Binary Condition DiagnosticReport DocumentReference Observation (Labs) Observation (Vitals) Patient Procedure

Bulk FHIR Group	FHIR Group ID
Group consists of test patients in table above.	e3iabhmS8rsueyz7vaimuiaSmfGvi.QwjVXJANlPOgR83

FHIR Bulk Data Access Tutorial

Contents

Background
Important Considerations for Using Bulk Data
Epic's Implementation of the Bulk Data Standard
Using the Bulk Data APIs

Background

The FHIR Bulk Data Access specification, also known as Flat FHIR, gives healthcare organizations the ability to provide external clients with large amounts of data for a population of patients formatted as FHIR resources. This functionality is available starting in the August 2021 version of Epic.

Important Considerations for Using Bulk Data

The bulk data API is powerful, and because it uses the FHIR standard, you might find it easier to export and process data from bulk data if you are already familiar with that standard. However, there are important things to take into consideration before deciding to use bulk data. As always, carefully consider your use case to determine whether bulk data is the best solution.

Technical Constraints

Bulk data runs on an organization's operational database, so it is important to consider performance. Bulk data exports large amounts of data for large groups of patients, which takes more time to complete the larger the data set or patient population. Responses are not instantaneous, so use cases of bulk data should not rely on immediate responses. Later in this tutorial, we will cover how to set up requests to help minimize this wait time.

Also, bulk data requests are not incremental. The API collects all data for the requested patients and resources before it starts returning any data. You cannot retrieve any results until all results are ready.

When to Use Bulk Data

As with any data exchange, form should follow function. While having all of this data formatted as FHIR resources might be exciting or sound easier to work with, the data won't be useful if bulk data's technical capabilities don't align with your use case. Consider your exchange paradigm and workflow needs first, then see if bulk data meets those requirements. If it does - great! If it doesn't, explore other options to interoperate with Epic on open.epic. Below are examples of use cases that fit bulk data and some that don't.

Good Use Cases for Bulk Data

A one-time load of data in preparation for continuous data exchange using other methods
Monthly loads of a targeted set of data (for example, _type=Patient,Condition)
Weekly export of a dynamic group of patients (for example, all patients discharged in the last week with a certain diagnosis)
Weekly loads of small patient populations (less than one hundred), such as for registry submissions

Poor Use Cases for Bulk Data

Data synchronization with data warehouses or other databases
Periodic loads of large amounts of clinical data
Incremental data loads
Data exports for groups of over one thousand patients

Best Practices

Epic has several recommendations that can help you have the best experience with bulk data APIs.

Limit group sizes to around a thousand patients or fewer.
Use the _type parameter whenever possible to improve response time and minimize storage requirements.
For groups of under one hundred patients, check the request status every ten minutes, or use exponential backoff. For groups of over one hundred patients, check the status every thirty minutes, or use exponential backoff. More information on exponential backoff can be found in the bulk data export specification.
After retrieving all of the resource file content, use the FHIR Bulk Data Delete Request API to allow the server to clean up the data from your request.

Epic's Implementation of the Bulk Data Standard

The implementation guide for Bulk Data Access is on HL7's website. Starting in the August 2021 version, Epic supports the 1.0.1 version of the specification for R4 FHIR resources. We have also incorporated some features from the 1.1.0 version to provide additional functionality. Epic supports only the Group Export operation. We do not support _since or other bulk data operations at this time.

Using the Bulk Data APIs

Now that you have determined that bulk data is an appropriate solution for your use case, let’s go through how to use the APIs. This diagram shows the typical flow of the bulk data APIs.

Client Configuration and Authorization

External clients must be authorized to use the bulk data APIs: Bulk Data Kick-off, Bulk Data Status Request, Bulk Data File Request, and Bulk Data Delete Request. Additionally, they must be authorized for the R4 search API for each resource they want to request, for example, AllergyIntolerance.Search (R4). The healthcare organization you're integrating with also needs to authorize your client to access the specific groups of patients. Work with that organization to enable a group that is appropriate for your use case.

This tutorial assumes you are passing a form of authorization covered in one of our authentication guides. It is generally assumed that in production environments FHIR APIs will use OAuth 2.0; however, it's important to note FHIR APIs do support HTTP Basic Authentication.

Kicking Off the Bulk Data Request

To begin, you need the base URL of the organization you want to integrate with, as previously described in the FHIR Tutorial. Let's say this is our base URL:

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4

Bulk data uses the Group resource for the export operation. Contact the organization you are integrating with to discuss what group of patients to use for your integration and to get the FHIR ID for that group.

Use the Group FHIR ID to call the group export operation:

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export

The request above returns results for a default set of R4 resources in the ndjson format. The default set includes the resources in the U.S. Core Data for Interoperability (USCDI) data classes, resources from the patient compartment of the bulk data access specification, and additional supporting resources outside of the patient compartment. Starting in the November 2021 version of Epic (and in the August 2021 version with a special update), Provenance is also in the default set of resources.

Epic also supports the following parameters for the group export operation:

_type
includeAssociatedData
_typeFilter (starting in the November 2023 version of Epic)

_type Parameter

The _type parameter accepts a comma-delimited list of FHIR resource types. When used, bulk data returns only the resource types specified in the parameter. Epic recommends using this parameter whenever possible because limiting the scope of the request to only the resources you need decreases both response times and the amount of data stored.

The _type parameter is also the only way to retrieve Binary resources. Binary files can become very large in this workflow, so Binary resources are not returned by default. Certain very large Binary files cannot be retrieved by bulk data operations at all. If a Binary file is not returned, you can still get the ID from the resource that it's associated with, for example, from the DocumentReference.content.attachment.url element, and perform a separate Binary.Read request for the content. Starting in the November 2021 version of Epic and in August 2021 by special update, an OperationOutcome with the resource type and FHIR ID is included in the response file.

For resources where Epic doesn't support a search by Patient ID (for example, Medication), a resource that has search by Patient ID and references the resource of interest (for example, MedicationRequest) should be included. For example, you could use the _type parameter to limit the request to include only Patient, MedicationRequest, and Medication resources as follows:

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export?_type=patient,medicationrequest,medication

includeAssociatedData Parameter

The includeAssociatedData parameter can be set to "LatestProvenanceResources" to include the Provenance resource associated with each resource instance included in the bulk data files.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export?includeAssociatedData=LatestProvenanceResources

_typeFilter Parameter

The _typeFilter parameter accepts a comma-delimited list of FHIR resource search queries. This is used to filter the results of the bulk data export so you can retrieve only the data you need. To use _typeFilter for a specific resource type, that resource must be included in the _type parameter. You cannot use _typeFilter without also using _type. Query strings for multiple resources can be included in _typeFilter.

Query strings in the _typeFilter parameter use the same search parameters as the R4 search APIs, and are formatted in much the same way. The general format is “_typeFilter=Resource%3Fparameter%3Dvalue\,value%26parameter%3Dvalue.” The standard query string reserved characters (question mark, equals sign, and ampersand) must be URL encoded within _typeFilter and commas must be backslash escaped.

Here is an example of a simple query string in _typeFilter. This would limit the MedicationRequest resources returned in the bulk data export to those with a category of “inpatient.”

https://vendorservices.epic.com/interconnect-amcurprd-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export?_type=MedicationRequest&_typeFilter=MedicationRequest%3Fcategory%3Dinpatient

This is an example of a more complex use of _typeFilter. This would limit the Observation resources returned to vital signs from 2023 and laboratory results from 2022 onwards, and the Condition resources returned to active problems on the problem list.

https://vendorservices.epic.com/interconnect-amcurprd-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export?_type=Observation,Condition&_typeFilter=Observation%3Fcategory%3Dvital-signs%26date%3D2023,Observation%3Fcategory%3Dlaboratory%26date%3Dge2022,Condition%3Fcategory%3Dproblem-list-item%26clinical-status%3Factive

When you use _typeFilter, we recommend following these best practices:

Avoid using multiple query strings that would have overlapping results. For example, including “Observation%3Fcategory%3Dlaboratory” and “Observation%3Fcategory%3Dlaboratory\,vital-signs” in the same request.
When possible, simplify _typeFilter values into a single query string. For example, rather than “_typeFilter=MedicationRequest%3Fstatus%3Dactive,MedicationRequest%3Fstatus%3Don-hold” use “_typeFilter=MedicationRequest%3Fstatus%3Dactive\,on-hold”
Test your query strings with the respective resources in a search request to ensure they return the results you expect before using the query strings in _typeFilter.

Note that the following are not supported by _typeFilter:

Searching by patient, subject, or _id
Query strings with search result parameters, such as _count, _include, or _revInclude
Query strings for the Patient resource
Query strings for resources that don't contain patient information
Applying the search query strings to resources included by reference

Requirements and Restrictions

When you have compiled all components of the request URL, you can submit the GET request to kick-off the bulk data workflow. Note that by default, a client can request a specific group of patients only once in a twenty-four-hour period. If you need to request bulk data more frequently, work with the Epic organization you're integrating with to configure an appropriate request window.

Your request must include the following headers:

Accept: application/fhir+json
Prefer: respond-async

Checking the Status of the Request

After kicking off the bulk data request, use the status API to track the progress of the request. Note that the same client and user that made the kickoff request must make the status request. In the response headers of the kick-off request, the value of the “Content-Location” header is the status URL for this bulk data request. Each bulk data request has a unique identifier used to request the status of a specific bulk data request.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/B0F84FB8D37411EB92726C04221B350C

If the bulk data request has not finished processing, the response body is empty. An approximate measure of progress is available in the "X-Progress" response header. The value of this header is "Searched X of Y patients" where "Y" is the number of patients in the group and "X" is the number of patients processed so far. This is only an approximate measure of progress because there is additional processing required after all patients have been searched, so it's possible for the header to be set to "Searched 100 of 100 patients" with no response body returned.

Epic recommends pinging for the request status every ten minutes for groups with a hundred or fewer patients, every thirty minutes for groups over a hundred, or using exponential backoff as described in the bulk data export specification.

After the request is completed, the status API returns the URLs for the resource files. For more information on the structure of the response, reference the API details.

{
    "transactionTime": "2021-06-23T16:39:52Z",
    "request": "https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/R4/Group/eIscQb2HmqkT.aPxBKDR1mIj3721CpVk1suC7rlu3yX83/$export?_type=patient,encounter,condition",
    "requiresAccessToken": "true",
    "output": [
        {
            "type": "Patient",
            "url": "https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/9ED3042CD44111EB84F2D2068206269D/e19upATM-PTKGZuHsy04IUQ3"
        },
        {
            "type": "Condition",
            "url": "https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/9ED3042CD44111EB84F2D2068206269D/e8D8N1JwB3qCiHJkmeV.98w3"
        }
    ],
    "error": [
        {
            "type": "OperationOutcome",
            "url": "https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/9ED3042CD44111EB84F2D2068206269D/eKbGgVw9pUn6xIiB8kZ756w3"
        }
    ]
}

Viewing Resource Files

Bulk data generates a separate file for each resource type. The "output" elements in the status API response lists each resource type and the corresponding file request URL. If a single resource has a very large number of results, the data is split into multiple files, all linked in the response. There is a maximum of three thousand resource instances per file, but the actual number of resource instances in a given file varies based on the size of the resource instances included in the file. To view a file, you'll use the file request API. The file URLs for this API are found in the file manifest from the status API. Note that the same client and user that made the kickoff request must make the file request.

https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/9ED3042CD44111EB84F2D2068206269D/e19upATM-PTKGZuHsy04IUQ3

The format of the bulk data files is ndjson. The ndjson format is similar to JSON, but is newline-sensitive. Resource instances are included in the bulk data file through a search by Patient ID or through a reference in a previously gathered resource instance. The files do not differentiate by patient, so results for all patients are included in each resource file.

Viewing Request Errors

In addition to the resource files, if there are any request-level errors, the "error" element in the status API response includes the URL for the OperationOutcome file. This file includes only request-level errors. Bulk data does not return resource-level errors.

Error Code	Error Text	Notes
59130	"Some information was not or may not have been returned due to business rules, consent or privacy rules, or access permission constraints."	This error is logged when a resource is requested that the client is not authorized for. OperationOutcome.issue.diagnostics lists the resource.
59100	"Content invalid against the specification or a profile."	This error is logged when a parameter is included in the request that Epic doesn't support in bulk data. OperationOutcome.issue.diagnostics lists the parameter.
59136	"The resource or profile is not supported."	This error is logged when a resource is requested that Epic doesn't support in bulk data. OperationOutcome.issue.diagnostics lists the resource.
59176	"Error Converting FHIR Resource to ndjson. Resource: <resource type> FHIR ID: <resource FHIR ID>"	This error is logged when a resource instance cannot be included in the resource file because of its size. The resource instance can be requested separately using the resource's read interaction. This error is logged starting in the November 2021 version of Epic and in August 2021 by special update.

Deleting Requests

If you no longer want to run a request after starting it, or no longer need the data stored, the bulk data delete API is available. This API uses the same URL as the status API, but uses the DELETE HTTP method rather than GET.

DELETE https://fhir.epic.com/interconnect-fhir-oauth/api/FHIR/BulkRequest/B0F84FB8D37411EB92726C04221B350C

If you delete a request before it is completed (the status API hasn’t returned any content), the request does not finish processing and is marked as deleted in the receiving system. The deleted request does not count towards your request per group per client per time period limit.

If you delete a request after it is completed (the status API returns file URLs), the request remains marked as completed in the system, but the data generated by the request is deleted. Deleting the generated data after you've retrieved it can help prevent excessive storage requirements for the server. In this case, the request does count towards the client's request limit. Epic recommends running the delete API after you finish retrieving the data files.

Category Name	Category Definition
Acute Virtual Care	Acute Virtual Care products are in-room cameras used to monitor admitted patients virtually, enabling and supporting virtual nursing, continuous remote monitoring, and teleconsult workflows for admitted patients. The clinician-facing video feed from these cameras can be viewed via an external web application or embedded within Epic Monitor. The patient-facing video feed can be viewed via an external web application or embedded within MyChart Bedside TV. These products may use computer vision-based detection on the in-room video feed to monitor patients for fall risk or other adverse events.
Alert Manager	Alert Communicator is included in EpicCare Inpatient and requires a third-party Alert Manager. Alert Managers ingest alerts from a variety of devices, such as inpatient vitals monitors, and determine who should get notified for each alert. They then send Epic’s Alert Communicator a standardized PCD-06 message indicating the alert recipient, and the relevant alert details. We then display it to the appropriate user(s) as a toast notification in Hyperspace or a push notification in Haiku and Rover. They also handle escalation in scenarios where the original recipient does not respond in an appropriate amount of time.
Ambient Voice Recognition: Notes	Ambient Voice Recognition (AVR): Notes apps integrate with Epic’s Ambient Voice Recognition Module for notes in ambulatory, emergency, and inpatient encounters. Clinicians record their clinical encounters from beginning to end in Haiku, verbalizing their evaluative process throughout. When they finish recording, the audio is processed by a third-party ambient listening vendor. The vendor processes the conversation and converts it into a note. The documentation is then sent to Hyperspace for the clinician to review and sign. With integration in this area, clinicians can expect to spend less time writing notes, provide more attention to patients during visits, and have reduced after-hours time.
Anesthesia Infusion Injectable Hardware	Anesthesia infusion injectable hardware integrations support a hardware device that manages manual IV bolus injections by identifying medication and concentration, performing allergy checks, measuring doses, and automatically documenting the process in real-time in Epic's Anesthesia application. This integration enhances workflow efficiency and accuracy, increasing clinician focus on patient care and reducing manual documentation.
Automated Dispensing System	Automated Dispensing Systems (ADS) manage and include computerized devices that store, dispense, and track medications at the place of service. ADS commonly receive patient and order information to determine what medications are available for dispensing and send dispense information back to Epic when medications are removed from the ADS.
Bayesian Medication Dosing Decision Support	A third-party decision support system used to provide personalized medication dosing recommendations. These products launch from Hyperspace using SMART on FHIR, pull patient and medication information, and provide the end user with optimized medication dosing recommendations. Bayesian analysis is commonly used for medications with narrow therapeutic windows or medications requiring precise dosing based on patient factors.
Bedside Dining	Bedside Dining applications present patients dining menus and options to place dining orders within MyChart Bedside.
Bedside TV Hardware	To provide a TV-centric experience in hospitals, vendors need to support hardware-level features such as deploying and app/OS updating, making Bedside TV the main screen, and facilitating seamless video calls using in-room cameras.
Clinical Knowledge Set	The Clinical Knowledge Set integration is based on the HL7 Infobutton standard, which allows clinicians to retrieve targeted information provided by third parties, specific to the context of the patient or clinical workflow. Rather than searching third party knowledge base, searches are performed automatically based off elements of the patient's chart like diagnoses or orders.
Community Resource Network (CRN)	Community Resource Network integrations support closed loop referrals from Epic community members to other organizations on the health grid, like post-acute facilities, community resources, DME suppliers, and more. Case Managers can find availability for their patients nearing discharge, and send information via vendors to post-acute facilities who can accept or decline placement based on the patients’ needs and history, as well as capacity and provider availability. Similarly, clinicians who identify Social Drivers of Health impacting patients can refer them to community organizations who can help address patients’ needs, all without leaving their workflows within Epic.
Computer Telephony Integration (CTI)	Computer telephony integration (CTI) apps allow Epic users to make and receive telephone calls in Hyperspace. Incoming calls bring the user to the activity in Epic that matches the purpose of the call and with the caller identified. Outgoing calls allow the user to initiate a call in the phone system to a selected phone number with a single click.
Digital Pathology	Digital Pathology is an integration between Beaker (Epic's laboratory application) and a 3rd party Image Management System (IMS) to allow pathologists to gain access via a hyperlink to high-resolution, digitized images of case slides for examination and interpretation. The hyperlink can be set up as one link for the overall case with all the associated slide images (Case-level) and/or as multiple links to the individual slide images (Slide-level).
Embedded Payment Processor	The embedded payment processor integration (often referred to as the external payment page or EPP) allows MyChart websites, Welcome kiosks and tablets, and/or Hyperspace users to collect credit card and bank account payments in real time, while helping comply with standards to safely handle payment information. This is done by embedding a gateway’s URL as a payment page in Epic. The gateway’s website handles the collection of the payment directly and posts non-sensitive transaction information back to Epic.
Encoder	Encoder integrations involve using a third-party system to determine and file diagnosis, procedure, and DRG codes based on clinical documentation. Coders or CDS users launch from Epic into the encoder, which interfaces with Epic to ensure accurate coding and data storage. Encoders can integrate for facility coding workflows and/or for Clinical Documentation Improvement (CDI) workflows.
Endoscope Data Capture	Endoscope data capture integrations allow vendors to gather data from a scope, format it, and then send it downstream. Currently, Epic is focused on image data, though that will expand to video, event, and other data in the future. This data is used throughout Lumens workflows, e.g., documenting findings or writing a procedure note.
Fully Autonomous Coding	Fully Autonomous Coding applications utilize AI and machine learning to assign billing codes to patient charges or accounts. Fully Autonomous Coding apps receive patient information, clinical documentation, result and charge details from various outgoing interfaces and APIs. Without user intervention, the Fully Autonomous Coding app processes this information, updated charges are sent back to the EHR via an incoming financial transactions (DFT) interface and filed to Professional Billing or Hospital Billing. If the flow cannot be completed autonomously, feedback should be sent to Epic allowing the coder to complete the review in Epic.
Hemodynamics System	Hemodynamic Monitoring Systems are used in Cardiac Cath Labs, Cardiac EP Labs, and some Interventional Radiology Labs to monitor patients during invasive procedures. These systems monitor the patient’s vitals and pressures associated with specific cardiac structures. Epic’s procedure log is used in conjunction with the existing hemodynamic monitoring system, and the hemodynamic system writes relevant data into Epic’s procedure log to keep all the data integrated with the patient’s chart in Epic.
Home Dialysis	Home dialysis machines are used by patients to administer hemodialysis and peritoneal dialysis at home. These machines also collect clinical data such as vitals that are written to device-entered or patient-entered flowsheets in Epic, maintaining continuity of the patient’s chart throughout treatment.
Hospital Utilization Review Creation	Hospital Utilization Review Creation apps provide guidelines for treatment of various medical conditions and the associated reimbursement. Apps in this category integrate with the Utilization Review activity (Clinical Case Management). Utilization managers launch the application and document a patient’s symptoms, events, and treatments to see if the patient meets sufficient criteria for admission or discharge and what level of care is needed in the hospital. Afterwards, the app will send the criteria and notes added by the case manager into the Utilization Review activity in Epic.
Identity Verification for EpicCare Link	This Toolbox category definition is Under Construction with expected future renovations. Identity Verification for EpicCare Link involves connecting reusable identity platforms to streamline the EpicCare Link New Account Request process and secure account recovery. For identity platforms who offer this functionality to Epic organizations, the goal is for users to assert their identity as part of the New Account Request submission instead of requiring manual review of individual applicants. Additionally, this category enables third parties to help with account recovery when EpicCare Link users cannot recover their account via traditional methods.
Identity Verification for MyChart	This Toolbox category definition is Under Construction with expected future renovations. An Identity Verification for MyChart application uses the specification in MyChart self-signup workflows to integrate with reusable identity platforms. This functionality aims to allow users to assert their identity and complete MyChart signup, regardless of their MyChart account status or existing patient record. Additionally, this integration will be used during account recovery to help patients who cannot complete recovery through traditional 2FA methods.
Imaging Appropriate Use Criteria	Imaging Appropriate Use Criteria (AUC) apps provide decision support for appropriateness of imaging procedures given clinical indications. When imaging orders are placed in Epic, AUC apps are notified and given some clinical context to determine the appropriateness of the order. The decision support outcome may file directly in an Epic OurPractice (OPA, formerly BPA) response, while other times, the app’s UI is shown to request additional information.
Infusion Pumps	Bi-directional infusion pump integration allows clinicians to send order details from Epic to auto-program the pump, and then receive documentation information from the pump, such as rate changes and volumes, to file into the patient’s chart.
Employee Identity Management - Login and Session Management	Login and Session Management applications provide secure and efficient mechanisms for users to access Epic’s applications such as Hyperspace, Haiku, Canto, or Rover..
Medication Ordering Decision Support	A third-party decision support system used to suggest medication changes. These products launch from Hyperspace using CDS Hooks to pull medication order information and provide the end user with medication ordering recommendations. The ordering decision support provided should augment the customer's existing medication warning configuration by evaluating patient-specific information to provide a more tailored warning.
MyChart Care Companion Care Plan Content	Apps that create signed XML documents used to import MyChart Care Companion care plans into customer environments. These care plans deliver notifications, analyze data provided by patients and connected devices, and orchestrate changes to the plan and escalations as needed to help patients, their caregivers, and care managers stay on top of a patient's care. A care plan comprises modules of patient-assigned tasks, which are delivered to patients as periodic reminders. These tasks could be reading education materials, responding to questionnaires, performing periodic symptom check-ins, or measuring weight, height, or blood pressure for example.
NoteReader CDI	NoteReader CDI is a tool used to help clinicians write complete, accurate, and specific clinical documentation. It works with a third-party Computer-Assisted Physician Documentation (CAPD) engine to suggest documentation improvements, called queries or nudges, to clinicians when they are writing a note. These nudges prompt clinicians to address potential issues in their documentation, which can help reduce denied claims and ensure accurate reimbursement for the care provided.
Oncology Clinical Pathways Decision Support	A third-party decision support system used to suggest oncology treatment protocols. These products launch from Beacon’s Treatment Plan navigator, embedded within Hyperspace, and post the user’s selected oncology protocol back to Epic.
Outbound Emergency Medical Services Transportation Ordering	Emergency Medical Services (EMS) Transportation Ordering applications enable hospital staff to order EMS-based transportation services for patients requiring additional medical care during transportation, commonly between medical facilities, by integrating Epic with Computer Aided Dispatch (CAD) systems. These integrations center around outbound transportation from the ordering location. Companies offering these applications may provide transportation services themselves or facilitate integration with transportation services employed directly by the hospital system.
Outpatient CDI (Risk Adjustment)	This Toolbox category definition is Under Construction with expected future renovations. This functionality integrates risk adjustment recommendations from third-party systems directly into Epic's pre-visit and point-of-care workflows, facilitating comprehensive HCC reviews in a singular decision support tool. CDI staff can review suggestions during pre-visit workflows and tee them up for providers to review during point-of-care workflows, without needing to navigate to other systems or disparate decision support advisories. Supplemental data explaining the suggestions and evidence will be displayed to end users, and providers' actions will be sent back to the third-party systems, creating a feedback loop with vendors that was not previously available.
Outpatient Pharmacy Patient Locker	The Patient Locker integration for Outpatient Pharmacy is for third-party systems that store pre-filled prescriptions in a locker for patient pick-up. Pharmacists/technicians complete their usual workflow to fill prescribed medications, but rather than waiting for patients to come to the pharmacy and pick up the prescription in person the medication is stored in a patient locker. Once patients know their prescription is ready to be picked up they travel to the locker and the system is able to collect necessary patient identification, dispense the correct medication, and offer counseling services if required.
Outpatient Pharmacy Will-Call	The Will-Call integration for Outpatient Pharmacy is for third-party systems that improve the organization of prescribed fills waiting to be picked up. When the prescriptions are filled, they are stored in bags, bins, etc. such that an indicator (e.g., a light) can call attention to the prescription location. This system allows pharmacists, technicians, or other users to easily find the prescription a patient at the counter has come to pick up.
Payer Medical Necessity Guideline Creation	Payer Medical Necessity Guideline Creation apps provide care guidelines for treatment of various medical conditions for authorization review. Apps in this category integrate with the Guideline Review activity (Tapestry Utilization Management).
Payment Device Integrations	The Payment Device Integration allows payments to be collected in real time. This is handled by outgoing requests sent to your endpoint during a payment workflow. The first request checks whether the device is initialized while the second request is needed for a payment transaction response. The payment is processed outside of Epic and through the payment processor.
Point-of-care Middleware Integrations	Point-of-care Middleware Integrations are middleware that connect lab hardware to Epic to facilitate receiving results from point-of-care devices into Beaker.
Printing Output Management Integrations	Output Management applications integrate with Epic Print Services (EPS) to collect the jobs exiting from the service that are bound for physical printer devices, which would normally be done through Windows print queues
Procedural Consent Content Import	This Toolbox category definition is Under Construction with expected future renovations. A clinical consents content vendor provides consent content such as procedure-specific risks, benefits and alternatives that is imported into customer environments. The content can then be pulled into consents created in Epic by clinical staff, spanning many clinical workflows and specialties.
Real Time Location Systems	A Real-Time Location System (RTLS) is used within the healthcare industry to provide real-time visibility into where patients, staff, and assets are located within their facilities. RTLS uses a tag that gets assigned to the entity (patient/staff/asset) they want to locate and a sensory network that’s deployed within the facility to determine location of the tag. Epic integrates with RTLS leveraging an HL7v3 interface to communicate incoming patient, staff, and medical device locations, and tag associations. In Epic, the RTLS data is used to provide visibility and automate workflows.
Real Time Prescription Benefit	An integrated real time prescription benefit (RTPB) application uses the native RTPB interface to provide accurate patient-level cost estimates and alternatives to providers at the point of ordering. Using information provided by the interface, RTPB applications offer: more accurate prior authorization information and automatic prior authorization status adjustments, out of pocket costs for the patient before signing orders, potential medication alternatives and their costs, and up front coverage alerts such as step therapy requirements.
Employee Identity Management - Reauthentication	Reauthentication applications verify the identity of end-users before performing certain actions within Epic’s applications such as Hyperspace, Haiku, Canto, or Rover.
Remote Patient Monitoring with Devices	RPM with devices allows providers to monitor and manage their patients’ chronic conditions. Devices that are distributed to a patient gather patient-generated health data such as blood pressure, heart rate, or weight. Data is sent back to Epic from the device. These products require patients to be explicitly enrolled in an RPM episode in Epic. Clinicians review the data in Hyperspace and take appropriate follow-up actions.
Remote Interpretation over Telehealth Invitations	Clinicians or staff members can send an invitation to a remote audio or video interpreter for a specified language from within their standard workspace for a telehealth visit. The remote interpreter will join on-demand via the health system’s video visit platform to conduct audio or video remote interpretation between the patient and the treatment team. A detailed log of events will be audited in the customer’s environment.
Shipping Management System	This Toolbox category definition is Under Construction with expected future renovations. A Shipping Management System vendor provides software that integrates with Epic to manage package shipments. The system receives data such as prescription or supply shipment details from Epic, and returns information including tracking numbers, expected delivery dates, and shipping labels. This integration streamlines the shipping process by embedding package management directly within Epic workflows.
Staff Duress	This Toolbox category definition is Under Construction with expected future renovations. This integration will enhance staff safety by enabling third-party panic button devices to send location-aware staff duress alerts into Epic using FHIR-based APIs. When triggered, the integration with Epic will identify the user and their location which will then be used within Epic to notify designated security response and informational groups through Epic’s push notification framework. Critical and informational push notifications will support timely response and coordination, with responders able to acknowledge or decline alerts from within Epic.
Standard Lab Middleware Integrations	Standard Lab Middleware Integrations are middleware that connect lab hardware to Epic to facilitate receiving results from lab instruments into Beaker.
Total Parenteral Nutrition Compounding	Total Parenteral Nutrition (TPN) Compounding is the process of preparing sterile solutions for patients to receive intravenously. This process is conducted via TPN compounding machines (compounders), which are computerized medical devices that receive ingredient level information and compound precise amounts of each component. TPNs can be compounded in-house or offsite by a third-party compounding service.
Vitals Gateway and Middleware Device Integration	Vendors in this category receive vitals data from devices like bedside monitors or anesthesia carts. Vendors support either a Spot Check Vitals integration, a Continuous Vitals integration, or both. Spot Check Vitals devices receive discrete data that is validated on the device and then sent to EpicCare Inpatient Clinical Documentation. Continuous Vitals devices receive a constant stream of data which is then sent to EpicCare Inpatient Clinical Documentation or Epic’s Anesthesia application.
Waveform Visualization	Waveform visualization apps display waveform data in near real time via a web and/or mobile app that launches from Epic.
Wayfinding	Wayfinding applications using a patient’s appointment information, such as encounter department, to help users navigate healthcare organizations.

Epic Version	Epic Sandbox JKU Support	Epic Customer JKU Support
February 2025 and prior	Optional	Optional - Each customer can choose to enforce JKU support for backend OAuth apps. This enforcement is off by default.
August 2025	Vendor Services and Epic on FHIR no longer allow new static key uploads for use in the sandbox.
November 2025	Static keys no longer supported in the sandbox for backend OAuth.	Vendor Services and Epic on FHIR websites no longer allow static key uploads for new apps. Both sites still support rotating keys for live apps.
February 2026		Static keys are no longer supported in customer environments for backend OAuth.

OID Segment	Meaning
1.2.840.114350	Epic’s root OID
.1	Indicates that this is an application-type ID
.13	The application ID. Some common application IDs include: 13: EDI 72: Care Everywhere
.<CID>	The unique Epic organization ID
.<EnvType>	The environment type. 1-Epic refers to Epic environments, such as the open.epic sandboxes. 2-Production and 3-Non-production refer to instances of Epic deployed at healthcare organizations. 1: Epic 2: Production 3: Non-production
.7	Indicates that this OID is intend for use in an HL7-type message
.<Value>	The value. This varies greatly depending on the concept we are generating an OID for. It might include multiple additional sub-nodes.

Element	Type	Cardinality	Description
target	Reference (resource)	1..*	The resource this provenance supports
recorded	Instant	1..1	Timestamp that the activity was recorded/updated
agent	Backbone Element	1..*	Actor involved
agent.type	CodeableConcept	0..1	How the agent participated
agent.who	Reference (Practitioner \| Patient \| Organization)	1..1	Who participated
agent.onBehalfOf	Reference (Organization)	0..1	Who the agent is representing.

Element	Type	Cardinality	Description
type	Coding	1..1	Type or identifier of the event
recorded	Instant	1..1	Time when the event was recorded
agent	BackboneElement	1..*	Actors involved in the event
agent.role	CodeableConcept	0..*	Agent role in the event
agent.who	Reference (PractitionerRole \| Practitioner \| Organization \| Device \| Patient \| RelatedPerson)	0..1	Identifier of who participated
agent.requestor	Boolean	1..1	Whether the user is the initiator
source	BackboneElement	1..1	The audit event reporter
source.observer	Reference (PractitionerRole \| Practitioner \| Organization \| Device \| Patient \| RelatedPerson)	1..1	The identity of the source detecting the event
entity	BackboneElement	0..*	Data or objects used
entity.what	Reference (Any)	0..1	Specific instance of the resource
entity.detail	BackboneElement	0..*	Additional information about the entity
entity.detail.type	String	1..1	Name of the property that changed
	String	1..1	Property value
entity.detail extension (audit-event-detail-state)	Extension	0..1	Indicates whether the value in entity.detail.valueString is the value before or after the audited event

Parameter	Supported in DSTU2?	Supported in STU3?	Supported in R4?
_id	Yes	Yes	Yes
_count	Yes, for the Observation resource only	Yes	Yes
_include	No	Yes	Yes
_revInclude	No	No	Yes
_lastUpdated	No	No	No

Prefetch Property Name	FHIR Query
patient	Patient/{{context.patientId}}
medications	MedicationRequest?patient={{context.patientId}}&status=active
encounterDx	Condition?patient={{context.patientId}}&encounter={{context.encounterId}}&category=encounter-diagnosis
user	{{context.userId}}

Field	Description
hook	Epic supports the following hooks: order-select order-sign patient-view
hookInstance	A universally unique identifier (UUID) for each hook call.
fhirServer	The base FHIR URL for the health system. Epic will always provide this. Reach out to the Client Systems Web and Server Systems team or EDI TS for the organization to obtain this.
fhirAuthorization	A structure holding an OAuth 2.0 bearer access token, which can be used to authenticate to Epic APIs for a short period of time.
context	The CDS Hooks specification (for example, patient-view) defines the context elements associated with each hook. Epic always sends patientId and userId. If the hook is initiated from an encounter context, encounterId is sent. For the order-select and order-sign hooks, draftOrders is always sent. Specific to order-select, the selections array identifies which orders are newly selected.
prefetch	Resources sent in the prefetch are configured by the health system and can include FHIR resources that are already supported by Epic.

Extension	Description
com.epic.cdshooks.request.bpa-trigger-action	The specific trigger action in Epic that is mapped to the hook. Common values include, but are not limited to: 5 (General OPA section) 6 (Enter problem) 7 (Enter diagnosis) 18 (Enter order) 23 (Sign orders) 26 (IP Admission OPA section) 27 (IP Discharge OPA section) 29 (IP Transfer OPA section) 60 (Open patient chart)
com.epic.cdshooks.request.cds-hooks-specification-version	The CDS hooks specification version used by Epic.
com.epic.cdshooks.request.fhir-version	The primary FHIR version of the CDS service as specified during OAuth registration.
com.epic.cdshooks.request.criteria-id	The ID of the OPA criteria record in Epic. This value can be helpful during troubleshooting.
com.epic.cdshooks.request.epic-version	The version of Epic that the health system is currently using.
com.epic.cdshooks.request.cds-hooks-implementation-version	The internal version Epic assigns to CDS Hooks implementations. Can be used to determine what features are supported.

Field	Description
cards	An array of cards that provide any of the following: Information Text to be shown to the user, optionally formatted as GitHub-flavored markdown, or with html markup if also providing an Epic-specific extension defining the content type. Suggestions Work with the health system to map the problem list items, encounter diagnoses, medications, procedures and/or multi-order sets. Containing CREATE actions for Condition resources, specifically Problems, or Encounter Diagnosis. Medication single order follow-up suggestions with CREATE actions using MedicationRequest resources Medication single order follow-up suggestions with DELETE actions using MedicationRequest resources Procedure single order follow-up suggestions with CREATE actions using ProcedureRequest (STU3) or ServiceRequest (R4) resources Procedure single order follow-up suggestions with DELETE actions using ProcedureRequest (STU3) or ServiceRequest (R4) resources Order Set, SmartSet, Pathway or Express Lane multiple order follow-up suggestions with CREATE actions using ProcedureRequest (STU3) or ServiceRequest (R4) resources Links Reference links do not require any additional configuration SMART App links need to be added to the allowlist in Epic
systemActions	Beginning in Feb 24, Epic supports system actions to annotate orders via the ServiceRequest.Update (Unsigned Order) (R4) API.

Field	Description
indicator	The info, warning, and critical values can be mapped to Epic-specific values by the Epic application team for display.
uuid	Unique identifier, used for auditing and logging suggestions. This field is optional. However, it is required if you intend to receive feedback.
selectionBehavior	Only the value "any" is currently supported.
detail	A CDS Service may return content as mere plain text, as GitHub flavored markdown, or, with an Epic-specific extension, as html. (See "com.epic.cdshooks.card.detail.content-type" extension, below).
source.topic.code	Epic only supports alpha-numeric strings as the code of source.topic, for example: "Card123" or "869e7c5587e04d0da96a60a84b5b8eac". The value returned in source.topic.code is used for logging and auditing, and is returned to the CDS Service in the feedback request. Maximum Length: 100 Characters Source.topic.code should be a static identifier representing the particular topic of a card. When an end user overrides a given card, their acknowledgment is associated with this identifier. If you want the end user's override to be respected on subsequent requests to your CDS service, the topic identifier should remain static if sending the same card content.
links	Allows your service to suggest a link to a user for additional information or a SMART app. Allowed links are allow-listed by the health system.

Field	Description
label	This field is not used, but is required.
uuid	Unique identifier, used for auditing and logging suggestions. This field is optional. However, it is required if you intend to receive feedback.
isRecommended	Boolean. When there are multiple suggestions, allows a service to indicate that a specific suggestion is recommended from all the available suggestions on the card. In Epic, this is used to control whether the suggested action is pre-selected or not.
actions	Epic only supports a single action per suggestion.
actions.type	For a given resource, confirm the action types supported in the API Library.
actions.description	This value is the primary content of the OPA. A CDS Service may return content as plain text.
actions.resource	The FHIR resource provided by the CDS Service representing the action to be suggested to the user. Check the API Library to see what resources (and action types) are supported.

System	Description	Resource(s)
urn:com.epic.cdshooks.action.code.system.preference-list-item	Used to order a specific preference list item.	MedicationRequest.Create ServiceRequest.Create ProcedureRequest.Create
urn:com.epic.cdshooks.action.code.system.orderset-item	Used to order a specific SmartSet, OrderSet, or Pathway.	ServiceRequest.Create ProcedureRequest.Create
urn:com.epic.cdshooks.action.code.system.cms-hcc	Used to suggest a Visit Diagnosis through a CMS-HCC model.	Condition.Create
urn:com.epic.cdshooks.action.code.system.hhs-hcc	Used to suggest a Visit Diagnosis through a HHS-HCC model.	Condition.Create
urn:oid:2.16.840.1.113883.6.90	Used to suggest ICD-10 codes.	Condition.Create
urn:oid:2.16.840.1.113883.6.69	Used to suggest NDC codes.	MedicationRequest.Create
urn:oid:2.16.840.1.113883.6.88	Used to suggest by RxNorm code.	MedicationRequest.Create

Attribute	Description
label	This field is not used, but is required.
url	The URL to load.
type	This field is required, and may either be absolute or smart.
appContext	This field is optional, and will share information from the CDS card with the subsequently launched SMART app.
autolaunchable	Supported by Epic beginning in Aug 23, this will autolaunch the SMART app if only one OPA requests an autolaunch at a given time.

Extension	Description
com.epic.cdshooks.card.detail.content-type	If this is not set, or set to "text/markdown" or "text/markdown; variant=GitHub", Epic will treat it as GitHub Flavored Markdown Other options are "text/plain", "text/html", and "text/markdown; variant=CommonMark".

Field	Description
alg	The cryptographic string used to sign this JWT. The default is RSA SHA-384.
jku	The URL to the JWK Set containing the public key(s).
kid	The identifier of the key-pair used to sign this JWT.
typ	Fixed value: "JWT".
aud	Your CDS service’s endpoint. This must be manually configured by the health system.
exp	The expiration timer for the authentication JWT.
iat	The issue time of the JWT.
iss	The URI of the JWT issuer, the FHIR endpoint of the organization. This must be manually configured.
jti	A string value that uniquely identifies the JWT.
nbf	Typically set to 5 minutes prior to the issue time of the JWT.
sub	CDS hooks client ID. This must be manually configured.

Element Name	Definition	Why it matters	API	HL7v2
Preferred Name	Name used by patient in day-to-day life	Note that using preferred name is something that can be important for more than just transgender patients. For example, a dementia patient who goes by Tessie might not remember or respond to her legal name of Theresa. It can be important to providing a better experience at the healthcare organization if everyone sees her name as Tessie in the chart and in ancillary systems so that everyone can use that name to address her. Preferred name might also be referred to as a chosen name, nickname, name in use, or lived name.	FHIR Patient resource (all versions): name.use = ‘usual’	PID-5
Legal Sex	Legal sex of the patient	Legal sex might be required for patient identification, matching, or integration with government registries.	FHIR Patient resource (all versions): gender	PID-8
Coverage Sex	Sex documented on the patient’s coverage	Health plans track a patient’s demographics and compare against those submitted by a provider during administrative processes (for example, authorization or claims). Coverage Sex tracks the patient sex the health plan has on file, and can be different than the patient's legal sex.	Not supported	IN1-43 (subscriber sex)
Gender Identity	How the patient identifies their gender	Helps to assist users in the other system to address the patient respectfully. Might be required for reporting and registries.	FHIR Patient resource (STU3+): Patient.extension (gender-identity)	ZPD-20 or OBX value
Sex assigned at Birth	Sex assessed at birth	Helps to assist users in the other system with background information.	FHIR Patient resource (STU3+): Patient.extension (birth sex)	ZPD-22 or OBX value
Menarche Flag	Whether the patient can get pregnant	Useful for systems that deal with pregnancy and delivery, most commonly OB systems. This is intentionally not a gender/sex value and should not be used to determine if a patient is female.	Not supported	ZPD-23
Sex for Clinical Use	Patient proxy sex for clinical decisions	Sex for Clinical Use is useful for systems that make clinical decisions based on patient sex and can help prevent harmful assumptions about a patient's body and health.	FHIR Patient resource (STU3+): Patient.extension (sex-for-clinical-use)	ZPD-24
Individual Pronouns	Patient’s pronouns	Referring to a patient using the wrong pronouns can lead to them feeling disrespected and excluded.	FHIR Patient resource (R4+): individual-pronouns	Patient Pronouns: ZPD-36 Pronoun Comment: ZPD-37
Sexual Orientation	Sexual Orientation	This information can be used for continuity of care during conversions or for reporting purposes.	FHIR Patient resource (STU3+)	ZPD-21

Document not found

open.epic Terms of Use

open.epic Terms of Use

Introduction

For Epic Community Members

For Developers

For Everyone

Definitions

JWT Authentication Troubleshooting

Issues with the App Listing

Issues with the Request Body

Issues with the Token Request Formatting

Issues with the JWT

Issues with the Signature

App Developer Guidelines

1 Guidelines for Well-Behaved Apps

1.1 Safety Guidelines

1.2 Security Guidelines

1.3 Privacy and Data Use Guidelines

1.4 Reliability and Scalability Guidelines

1.5 Data and System Integrity Guidelines

2 Intellectual Property

3 Transparency and Honesty

Footnotes

App Creation & Request Process Overview

Table of Contents

Overview

Creating, Activating, and Licensing an App

Registering an App / Provisioning Client IDs

Facilitating Epic Community Member Downloads

Provisioning Client Secrets

Requesting an App

Before Starting the Request Process

Obtaining the open.epic API Subscription Agreement

Downloading Client Records

Confirm the Client ID was Downloaded

Deactivate an App

App Creation & Request Process Step-by-Step

Table of Contents

Overview

Creating, Activating, and Licensing an App

Registering an App / Provisioning Client IDs

Recommendations for Creating your App Listing

Application Name

Public Documentation URL

Summary

Description

Data Use Questionnaire

Thumbnail

Screenshots

Facilitating Epic Community Member Downloads

Provisioning Client Secrets

Customer-specific Endpoint URIs

Requesting An App

Before Starting the Request Process

Obtaining the open.epic API Subscription Agreement

Downloading Client Records

Confirm the Client ID was Downloaded

User Context

Application User Context

Choosing a User Context

Multi-Context Applications

Limit APIs to the Required Application

Limit Use of Backend Apps

Use Cases for Backend Apps

Creating a Multi-Context App with Epic on FHIR

Epic Community Member Downloads

API Supported User Types

Overview

User Type Validation

When Does an API Support a Given User Type?

API and User Type in Your Application

Should I Edit My App's User Context?

Additional User Security Validation

Requesting a Listing in Showroom

Connection Hub

Toolbox

Request a Blueprint and Evaluation

Toolbox Categories

Workshop