FHIR Resources
For a full list of Epic FHIR resources, visit fhir.epic.com.
| Resource | Description |
|---|---|
| AllergyIntolerance.Read | Returns data about an allergy or intolerance to a specific substance associated with one patient. You can also search by ID and by patient, allowing it to return a list of allergies |
| AllergyIntolerance.Search |
The AllergyIntolerance resource defines clinical information about a patient’s allergic response to a substance. It defines the substance that elicited the response, as well as when the reaction occurred, the severity, and the type of reaction noted. The AllergyIntolerance resource can also accommodate search by ID and by patient, allowing it to return a list of allergies. If a patient has no active allergies, an AllergyIntolerance resource will be returned indicating whether the patient’s allergies have never been reviewed (are not on file), or if they have been reviewed and it has been determined that they have no known allergies. This resource can also return unconfirmed AllergyIntolerance resources in the “holding tank” that drives the EpicCare Reconcile Outside Data Activity. Note – once a clinician reconciles an allergy, a new AllergyIntolerance resource associated with the reconciled allergy will be available in the normal AllergyIntolerance.Search results, and the unconfirmed AllergyIntolerance in the “holding tank” will no longer appear in the AllergyIntolerance.Search results. |
| CarePlan.Read (Inpatient) |
The FHIR CarePlan resource is a broad container for summarizing the plan of treatment for a patient. It includes links to the Condition Resource (the patient’s long term problem list) and the Goal Resource (the patient’s longitudinal goals) as well as in-line detail about upcoming appointments and upcoming orders. This resource is designed for inpatient-related care plan data. This read interaction enables the lookup of a specific inpatient CarePlan resource by FHIR ID. |
| CarePlan.Search (Inpatient) |
The FHIR CarePlan resource is a broad container for summarizing the plan of treatment for a patient. It includes links to the Condition Resource (the patient’s long term problem list) and the Goal Resource (the patient’s longitudinal goals) as well as in-line detail about upcoming appointments and upcoming orders. This resource is designed for inpatient-related care plan data. The search interaction enables the lookup of one or more CarePlan resources, filtered by the specified parameters. |
| Care Team (Read) | Returns information about a patient’s care team and care team members. The patient’s care team includes longitudinal care team assignments. The patient’s inpatient treatment team is not included in this resource. Inpatient treatment team members are instead included as participants in the relevant Encounter resource. |
| Care Team (Search) | Returns information about a patient’s care team and care team members. The patient’s care team includes longitudinal care team assignments. The patient’s inpatient treatment team is not included in this resource. Inpatient treatment team members are instead included as participants in the relevant Encounter resource. |
| Patient.Read |
The FHIR Patient resource defines demographics, care providers, and other administrative information about a person receiving care at a health organization. A user or staff member accessing this FHIR resource must have appropriate security to have search details, demographic details, and/or PCP details included in the Patient resource. A MyChart user accessing this FHIR resource must be authorized to view patient information in MyChart. Additionally, this FHIR resource returns patient identifiers only to MyChart users with security to see patient IDs. Additionally, if an Epic organization has configured service area restrictions, the user accessing this FHIR resource must be authorized to view patients in the target service area. When two patient records are merged, a Patient.Read on the target patient will work normally. The source patient will return a 404 error, as we consider the source patient FHIR ID to be invalid after the merge. |
| Patient.Search |
Patient.$match Alternative:: If you need to identify a single patient record, strongly consider using Patient.$match instead. This is especially useful for backend integrations where sufficient patient demographics are available. Patient.Search should be used to get a list of patients matching a subset of parameters rather than matching a single patient record. Improper use of Patient.Search could lead to writing data on the wrong patient record and even patient safety concerns. This web service allows filtering or searching for patients based on a number of parameters, and retrieves patient demographic information from a patient’s chart for each matching patient record. This service also does not respect the same filtering as MyChart, with the exception of the careProvider parameter. A user or staff member accessing this FHIR resource must have appropriate security to have search details, demographic details, and/or PCP details included in the Patient resource. A MyChart user accessing this FHIR resource must be authorized to view patient information in MyChart. Additionally, this FHIR resource returns patient identifiers only to MyChart users with security to see patient IDs. If an Epic organization has configured service area restrictions, the user accessing this FHIR resource must also be authorized to view patients in the target service area. When two patient records are merged, a Patient.Search on the target patient will work normally. The source patient will return a 404 error, as we consider the source patient FHIR ID to be invalid after the merge. |
| Observation (Read) | The Observation (Labs) resource returns component level data for lab results. Observation is not normally used on its own to access lab results, because it is limited to reading microbiology sensitivities (method level, isolate level, and sensitivity level), textual (narrative and impression) Observations, and certain imaging Observations (such as Midmark EKG results). Instead, a system queries the DiagnosticReport resource to identify all lab procedures performed for a patient. The DiagnosticReport results contain pointers to one or more Observation resources that contain the component results. If you are familiar with HL7v2, DiagnosticReport is analogous to an OBR segment, where Observation is like an OBX segment. For example, consider a CBC (Complete Blood Count) test. The overall CBC test would be represented as a DiagnosticReport resource. The component results (white blood cell count, red blood cell count, hemoglobin, platelet count, etc.) would each be returned in independent Observation resources. |
| Observation (Search) | The Observation (Labs) resource returns component level data for lab results. Observation is not normally used on its own to access lab results, because it is limited to reading microbiology sensitivities (method level, isolate level, and sensitivity level) and textual (narrative and impression) Observations. Instead, a system queries the DiagnosticReport resource to identify all lab procedures performed for a patient. The DiagnosticReport results will contain pointers to one or more Observation resources that contain the component results. If you are familiar with HL7v2, DiagnosticReport is analogous to an OBR segment, where Observation is like an OBX segment. |
| Observation (Search) | The Observation (Labs) resource returns component level data for lab results. Observation is not normally used on its own to access lab results, because it is limited to reading microbiology sensitivities (method level, isolate level, and sensitivity level) and textual (narrative and impression) Observations. Instead, a system queries the DiagnosticReport resource to identify all lab procedures performed for a patient. The DiagnosticReport results will contain pointers to one or more Observation resources that contain the component results. If you are familiar with HL7v2, DiagnosticReport is analogous to an OBR segment, where Observation is like an OBX segment. |
| Condition (Read) | This web service retrieves a single problem from a patient’s chart. This includes any data found in the patient’s problem list across all encounters. This resource can be queried by a combination of patient ID and status. A user or staff member accessing this FHIR resource must have |
| Condition (Search) | This web service retrieves problems from a patient’s chart. This includes any data found in the patient’s problem list across all encounters. This resource can be queried by a combination of patient ID and status. Note that this resource retrieves only data stored in problem list records. As a result, medical history data documented outside of a patient’s problem list isn’t available to applications using this service unless that data is retrieved using another method. This resource does not return unconfirmed Condition resources in the “holding tank” that drives the EpicCare Reconcile Outside Data Activity. Note – once a clinician reconciles a problem, a new Condition resource associated with the reconciled problem will be available in the normal Condition.Search results. |
| Procedure.Read (Surgeries) |
The FHIR Procedure resource defines an activity performed on or with a patient as part of the provision of care. It corresponds with surgeries and procedures performed, including endoscopies and biopsies, as well as less invasive actions like counseling and physiotherapy. Because terminology codes for procedures are often billing related, some procedures might not have a terminology code, especially when billing activities are not performed within Epic. The Procedure (Surgeries) API is designed to summarize any performed surgical procedures for a patient. Other types of procedures may be returned in other APIs, such as the Procedure (Orders) API for procedures created from orders. This resource is designed for a high-level summarization around the occurrence of a procedure, and not for specific procedure log documentation – a concept that does not yet have a defined FHIR Resource. The read interaction enables the lookup of a Procedure resource by a constant server ID. Read interactions begin with a client having previously established a relationship, typically when following a reference to this resource from another resource or through querying for procedures through the search interaction. |
| Procedure.Search(Surgeries) |
The FHIR Procedure resource defines an activity performed on or with a patient as part of the provision of care. It corresponds with surgeries and procedures performed, including endoscopies and biopsies, as well as less invasive actions like counseling and physiotherapy. The Procedure (Surgeries) API is designed to summarize any performed surgical procedures for a patient. Other types of procedures may be returned in other APIs, such as the Procedure (Orders) API for procedures created from orders. Organizations can have differences when determining which performable activities are classified as procedures, so the types of activities included in FHIR Procedure search can vary between organizations. Because terminology codes for procedures are often billing related, some procedures might not have a standard code (for example, CPT), especially when billing activities are not performed within Epic. For organizations that do perform billing activities within Epic, procedures might not have a CPT code until the charges are generated for the procedure. This resource is designed for a high-level summarization around the occurrence of a procedure, and not for specific procedure log documentation – a concept that does not yet have a defined FHIR Resource. When searching, only completed procedures are returned. To gather a complete list of surgical procedure information for a patient , three different Procedure APIs must be consulted. While a surgical procedure may be documented in multiple places in Epic, it will be returned only by one Procedure FHIR API, in the following order of precedence: Procedure (Orders): Includes any procedure that is ordered by a clinician and completed during an encounter. If a procedure is returned by this API, it won’t be returned by the Procedure (Surgeries) or Procedure (Surgical History) APIs. |
| Immunization.Read |
The FHIR Immunization resource provides a patient’s immunizations, including vaccine and vaccine administration details. The read interaction allows a client to retrieve an Immunization resource by a constant server ID, typically retrieved from a different resource. |
| Immunization.Search |
The FHIR Immunization resource provides a patient’s immunizations, including vaccine and vaccine administration details. The search interaction allows the client to query for a patient’s immunizations. The Immunization Search endpoint allows a client to retrieve an identifier for an immunization. |
| DiagnosticReport.Read (Results) |
The DiagnosticReport resource represents a resulted, patient-related, non-medication order and data associated with the order and the patient. This resource returns textual results and discrete result components. It can return lab, imaging, cardiology and endoscopy results. It can also return pathology results that are not a scan. Scans filed into Epic are not returned by this resource. Starting in February 2024, DiagnosticReport can return EKG data using the Midmark third-party integration. If the EKG order collected heart rate and blood pressure data as well, this data is returned as Observations contained within the response. Starting in May 2024, DiagnosticReport can return audiology exam finding data. Data within the audiology exam is returned as observations contained within the response. The read interaction enables the look up of a DiagnosticReport resource by a constant server ID. The read interaction allows clients to store only the server ID, and with a single request, retrieve the most up-to-date result data on a patient. Read interactions typically begin with a client having previously established a relationship, often through querying for DiagnosticReports through the search interaction. |
| DiagnosticReport.Search (Results) |
The DiagnosticReport FHIR resource represents resulted diagnostic orders and relevant data associated with the order and the patient. Supported diagnostic services include laboratory, radiology, and cardiology, audiology, and endoscopy. Within DiagnosticReport, the Observation FHIR resource returns individual components from laboratory tests and text-based content, such as narratives or impressions, from radiology and cardiology results. This resource returns textual results and discrete result components. It can return lab, imaging, and cardiology results. It can also return pathology results that are not a scan. Scans filed into Epic are not returned by this resource. Starting in February 2024, DiagnosticReport can return EKG data using the Midmark third-party integration. If the EKG order collected heart rate and blood pressure data as well, this data is returned as Observations contained within the report. Starting in May 2024, DiagnosticReport can return audiology exam finding data. Data within the audiology exam is returned as observations contained within the response. The DiagnosticReport resource corresponds to the following Common Clinical Data Set (CCDS) Elements: Laboratory Tests. The search interaction for DiagnosticReport enables the client to query for diagnostic reports based on a patient and additional optional parameters, such as date, LOINC code/Identity ID, or order ID/accession number. Client may use the Patient Identifier Web Service to establish an identifier for a patient. |
| Device (Read) | The FHIR Device resource describes information about a specific patient’s durable, manufactured medical items. The below documentation describes only medical devices implanted in a patient. The Device resource corresponds to the following Common Clinical Data Set (CCDS) Elements: Unique Device Identifiers (UDI). The read interaction enables the lookup of a Device resource by a constant server ID. The read interaction allows clients to store only the server ID, and with a single request, retrieve the most up-to-date information about a device. Read interactions typically begin with a client having previously established a relationship, often through querying for Devices through the search interaction. |
| Device (Search) | The FHIR Device resource describes information about durable, manufactured medical items; specifically – implantable medical devices. The search interaction enables the client to query for implantable devices based on a specified set of information. The Device Search endpoint allows clients to establish an identifier for an implantable device without previously receiving unique identification from the server for the device. When testing integrations, you must use a UDI in a valid format for this service to return a response. |
| Encounter (Read) | The Encounter (Patient Chart) resource defines the setting where patient care takes place. This includes ambulatory, inpatient, emergency, home health, and virtual encounters. |
| Encounter (Search) | The Encounter (Patient Chart) resource defines the setting where patient care takes place. This includes ambulatory, inpatient, emergency, home health, and virtual encounters. This web service will return all inpatient encounters in the specified time period, but will only return outpatient encounters once they have been checked in. You can’t use the Encounter (Patient Chart) resource to find upcoming appointments. Instead, use the Appointment resource to retrieve information on upcoming appointments. |
| Medication (Read) | The FHIR Medication resource defines detailed information about a medication order’s product or package. The Medication resource is not specific to any patient. |
| Medication (Search) | The FHIR Medication resource defines detailed information about a medication order’s product or package. The Medication resource is not specific to any patient. The R4 Medication.Search interaction currently supports only the _id search parameter, making it similar to a Medication.Read request. |
| Medication Statement (Read) | The MedicationStatement resource represents all medications a patient is taking, be it those ordered in the EMR or reported externally by either another organization or the patient themselves. The MedicationStatement resource information reflects the details about how the patient is actually taking the medication even if it differs from what was ordered. Starting in February 2022 or November 2021 by special update, organizations in the Netherlands can use this resource to satisfy the requirements of the MedicationUse profile. |
| Medication Statement (Search) | The MedicationStatement resource represents all medications a patient is taking, be it those ordered in the EMR or reported externally by either another organization or the patient themselves. The medicationStatement resource information reflects the details about how the patient is actually taking the medication even if it differs from what was ordered. The search interaction enables you to query for medication orders based on a patient and optionally status or category. You can use the Patient Search endpoint to establish an identifier for a patient without previously receiving unique identification from the server for the patient. Only active medications are returned by default. Starting in February 2023, medications of all statuses are returned for organizations in the Netherlands by default. |
| Practitioner Role (Read) | The PractitionerRole resource defines location and types of services (roles) that a practitioner provides for an organization. It references the Practitioner resource, and there can be multiple PractitionerRoles per practitioner. |
| Practitioner Role (Search) | The FHIR PractitionerRole resource consists of a location and types of services that practitioners can provide for an organization. When using the Search operation, an identifier, practitioner, organization, location, or specialty parameter is required. This resource accepts multiple comma-delimited values for practitioner, location, or organization. |
| Practitioner (Read) | You can use the read interaction to look up a Practitioner resource by a constant server ID. The read interaction allows you to store only the server ID, and with a single request, retrieve the most up-to-date role information on a Practitioner. Read interactions typically begin with a client having previously established a relationship. |
| Practitioner (Search) | The FHIR Practitioner resource is defined as a person who is directly or indirectly involved in the provisioning of healthcare. The Practitioner resource can provide information about a healthcare provider, such as activities, responsibilities, demographics, and other administrative information. |
| Organization (Read) | The read interaction of the Organization resource allows you to look up an organization using a constant server ID. The read interaction allows clients to store only the server ID, and with a single request, retrieve the most up-to-date information about an organization. Read interactions typically begin with a client having previously established a relationship, often through querying for a resource through the search interaction. |
| Organization (Search) | The search interaction of the Organization resource allows you to look up organization resources based on the specified search parameters. Currently, the search interaction supports only the _id search parameter. As a result, it functions similarly to an Organization.Read request. |
| Location (Read) | The FHIR Location resource defines details and position information for a physical place where resources and participants can be found. The Location resource is referenced by the Practitioner and Appointment resources and references the Organization resource in an effort to provide a more complete context in associating a patient or supply with a physical location. |
| Location (Search) | The FHIR Location resource defines details and position information for a physical place where resources and participants can be found. The Location resource is referenced by the Practitioner and Appointment resources and references the Organization resource in an effort to provide a more complete context in associating a patient or supply with a physical location. This search interaction currently supports only the _id search parameter. As a result, it functions similarly to Location.Read. |
| Document Reference (Read) | The FHIR DocumentReference resource is a generic resource that can be used to communicate many different types of documents. This implementation of DocumentReference is used to communicate clinical notes in accordance with the US Core Implementation Guide. The read interaction enables the look up of a DocumentReference resource by a constant server ID. The read interaction allows clients to store only the server ID, and with a single request, retrieve the most up-to-date result data on a patient. Read interactions typically begin with a client having previously established a relationship, often through querying for DocumentReference through the search interaction. |
| Document Reference (Search) | The FHIR DocumentReference resource is a generic resource that can be used to communicate many different types of documents. This implementation of DocumentReference is used to communicate clinical notes in accordance with the US Core Implementation Guide. The search interaction enables the client to query for clinical note (HNO) records based on a patient and optionally document type, status, encounter ID, note creation time, or associated encounter period. |
| Goal.Search (Patient) | The FHIR Goal resource defines objectives for a patient based on a current condition or recent procedure. The goal can be long-term, such as targeting a specific HgbA1c level after a diabetes diagnosis, or shorter term such as changing wound dressings routinely following a procedure. The search interaction enables the client to query for goals based on status or goal category. The search endpoint requires a patient ID. Goals are not filterable by active date. A user or staff member accessing this FHIR resource must have security to access care plans. Additionally, a provider must have security to see problems/conditions related to a goal. A MyChart user accessing this FHIR resource must have security to access goals. |
| Goal.Read (Patient) | The FHIR Goal resource defines desired health outcomes to be achieved by a patient over a period of time such as “lower blood pressure in the next three months” or “Lose 10 lbs by X date”. |
| MedicationRequest.Write (Signed Medication Order) | You can use the search interaction to query for medication orders based on a patient and optionally status or category. This resource can return various types of medications, including inpatient-ordered medications, clinic-administered medications (CAMS), patient-reported medications, and reconciled medications from Care Everywhere and other external sources. The R4 version of this resource also returns patient-reported medications. Previously, patient-reported medications were not returned by the STU3 version of MedicationRequest and needed to be queried using the STU3 MedicationStatement resource. This is no longer the case. The R4 version of this resource returns patient-reported medications with the reportedBoolean element set to True. If the informant is known, it is also specified in the reportedReference element.A user or staff member accessing this FHIR resource must have security to view medications. A MyChart user accessing this FHIR resource must be authorized to view medications in MyChart. |
| MedicationRequest.Read (Signed Medication Order) | The read interaction enables the look up of a MedicationRequest resource by a constant server ID. The read interaction is typically used to: Retrieve specific MedicationRequest data that was referenced in another resource. Initiate a contextual launch where the runtime context is a specific MedicationRequest. This resource can return various types of medications, including inpatient-ordered medications, clinic-administered medications (CAMS), patient-reported medications, and reconciled medications from Care Everywhere and other external sources. The R4 version of this resource also returns patient-reported medications. Previously, patient-reported medications were not returned by the STU3 version of MedicationRequest and needed to be queried using the STU3 MedicationStatement resource. This is no longer the case. The R4 version of this resource returns patient-reported medications with the reportedBoolean element set to True. If the informant is known, it is also specified in the reportedReference element. A user or staff member accessing this FHIR resource must have security to view medications. A MyChart user accessing this FHIR resource must be authorized to view medications in MyChart. |
| Coverage.Read | Retrieves a Coverage resource by its FHIR ID. Coverage resources correspond to coverage records in Epic. In Epic, coverage records exhibit the following characteristics: The patient-level coverage list represents all possible insurances that could be billed for services. A patient might have a long list of possible coverages that are applicable only for specific services. Examples include third party liability, worker’s comp, black lung insurance, Medicaid for ESRD, Medicare, commercial, etc. For any specific visit, an account record will indicate which coverages will be used for that visit. A single visit-level account may have multiple coverages attached. Coverage filing order indicates which is billed first. Coverages are specific to service area. For this reason, if you are searching across multiple service areas, a patient might have what appears to be duplicate coverages. This resource typically should not be used to determine which coverages are relevant for recent or upcoming visits and services. Instead, it returns all coverages that are potentially applicable to a patient. This resource respects patient-level break-the-glass checks as configured in Epic. Audit events are logged to the patient audit trail when a coverage is accessed by this resource. |
| Coverage.Search |
Searches for Coverage resources. Coverage resources correspond to coverage records in Epic. In Epic, coverage records exhibit the following characteristics: The patient-level coverage list represents all possible insurances that could be billed for services. A patient might have a long list of possible coverages that are applicable only for specific services. Examples include third party liability, workers’ comp, black lung insurance, Medicaid for ESRD, Medicare, commercial, and others. This resource respects patient-level break-the-glass checks as configured in Epic. Audit events are logged to the patient audit trail when a coverage is accessed by this resource. |
| MedicationDispense.Read (Fill Status) |
The read interaction enables the look up of a MedicationDispense resource by a constant server ID. This resource returns a medication’s fill status, as well as other information about the medication, such as the dose, route, and dispense quantity. This resource can return various types of medications, including prescriptions, inpatient-ordered medications, To Take Out (TTO) orders, and clinic-administered medications (CAMS) dispensed through Epic. |
| MedicationDispense.Search (Fill Status) |
You can use the MedicationDispense search interaction to query for a medication’s fill status, as well as other information about the medication, such as the dose, route, and dispense quantity. This resource can return various types of medications, including prescriptions, inpatient-mode medications, To Take Out (TTO) orders, and clinic-administered medications (CAMS) dispensed through Epic. |
| List.Read (Patient List) | The FHIR List resource defines a collection of records that can be used within many places. Epic supports direct reading of the List resource to give access to Patient Lists, which includes My Lists and System Lists. |
| List.Search (Patient List) | The FHIR List resource defines a collection of records that can be used within many places. Epic supports direct reading of the List resource to give access to Patient Lists, which includes My Lists and System Lists. To pull a My List, it must be the My List of the user whom the API call is made on behalf of or shared with that user. |
| ExplanationOfBenefit.Read (Claim) |
This web service retrieves a specific ExplanationOfBenefit resource, which represents claims data received and processed by health plans, including services rendered to a patient and the cost information associated with those services. This API can only be used with organizations licensed for Epic Tapestry |
| ExplanationOfBenefit.Search (Claim) | This web service searches for ExplanationOfBenefit resources that meet the specified criteria. ExplanationOfBenefit resources represent claims data received and processed by health plans, including services rendered to a patient and the cost information associated with those services. |