Epic Open API Specifications

Health Level 7 standardizes data interchanges within and across organizations. It's one of the most widely implemented standards for health-related data. You can learn more about this standard from HL7 .

• Incoming Materials Management

  Used to automate synchronization of supply definitions from an external materials management system. The interface can add or modify properties of these items such as the supplier they are purchased from and the physical location where they are stored.

• Incoming External Encounters

  Receives data about encounters that happen at an outside entity. These encounters can then be used by care managers to follow up with the patient or by Epic population health tools for analytics. This interface is for use with Payer Platform or Healthy Planet.

• Outgoing Fills to Automated Fill System from Willow Ambulatory

  Transmits verified pharmacy fills to automated prescription fill systems.

• Incoming Fill Status Updates and Load/Unload from Automated Fill System

  Updates the status of the prescription fill in Willow Ambulatory Pharmacy when an automated prescription fill system fills, dispenses, or cancels a prescription.

• Outgoing Patient Waiting Time from Patient Administration System

  Organizations in Ontario can collect information in diagnostic imaging and surgical workflows to report to Cancer Care Ontario's Wait Time Information System (WTIS) requirements.

• Outgoing Inventory Depletion

  Informs an external materials management system of supplies that have been using during a procedure. It indicates which supply was used, from where the user picked the supply, and the number by which the external system should decrement the balance of the supply. These messages are triggered from within Epic's surgical, radiology, and cardiology software applications.

• Outgoing Blood Transfusion Status Notification

  Sends transfusion notifications to external Blood Bank systems so that blood banks can update their records when a given blood unit is transfused. To use this interface, an organization must document the unit number and product code for blood transfusions using the Blood Product Administration Module.

• Incoming External Outpatient Medication Orders Interface

  Receives outpatient medication orders from outside sources such as other EHR systems. They are not filed directly to the chart, but instead are filed as a medication waiting to be reconciled in the Reconcile Outside Information activity. This interface is generally used for conversion purposes, and is recommended in place of the Incoming Medication Orders to EpicCare Ambulatory interface.

• Incoming Asynchronous Acknowledgement

  Receives asynchronous application acknowledgements in response to any outgoing HL7v2 message sent using Bridges, Epic's core messaging infrastructure.

• Outgoing Documentation

  Notifies external systems of documentation recorded in Epic. Sends MDM messages with notes and transcriptions as they are saved and modified, and can send a document summary upon close of an encounter in EpicCare Ambulatory EHR. Documents are sent in either RTF or PDF format.

• Outgoing Provider Communications Interface

  Notifies external systems of provider communications written in the Communication Management activity in Epic. The interface sends letter attachments as PDF documents to recipients.

• Outgoing Medication Verification Queue Update Notification from Willow Inpatient Interface

  Informs external systems when an inpatient medication order is added or removed from the pharmacist verification queue.

• Outgoing External Encounters

  Sends HL7v2 ADT messages using data filed as external encounters in Received Documents records and using message data filed on the Incoming External Encounters interface. This is intended for use with Payer Platform.

• Incoming Provider Communications Interface

  Notifies Epic users of provider communications written in other systems.   Communications can have attached letters or documents and are routed to the recipient (Provider, Department, etc) based on preferences (In Basket, Fax, Mail, etc) the same as if the communication was written in Epic and routed with the Communication Management activity.

• Outgoing Asynchronous Acknowledgement Interface

  Sends asynchronous application acknowledgements in response to any incoming HL7v2 message received in Bridges, Epic's core messaging infrastructure.

• Incoming External Appointments Interface

  Receives HL7v2 scheduling messages about appointments that happen at an outside entity. These encounters can then be used by care managers to follow up with the patient or by Epic population health tools for analytics. This interface is different from the Incoming Appointment Scheduling interface in that it does not make appointments that can be acted upon (checked in, canceled, etc) or accessed from the clinical schedule to be charted in.

• Outgoing External Appointments Interface

  Sends HL7v2 scheduling messages using data filed as external appointments and using message data filed on the Incoming External Appointments interface. This is intended for use with Payer Platform.

• Incoming Provider Information

  Receives messages that can create, update, inactivate, or delete records in the provider master file, typically from an external credentialing system. While this interface can build the shell of a provider record, for example, address and contact information, this interface can't completely automate the addition of new providers to an organization because Epic has many settings and features that are built by association to provider records. These settings cannot by nature be controlled by an external system. There are also use cases requiring provider records to be built that will not be tracked in a credentialing system.

• Incoming Medication Stock Reservation to Willow Inventory

  Reserves medication stock for use at a specific inventory location.

• Outgoing Provider Information

  Sends provider information to an external system whenever a provider record is created, updated, inactivated, or deleted.

• Outgoing Device Association Interface

  IHE PCD Profile standard to associate device record to patient.

• Incoming Drug Supply Receipt to Willow Inventory

  Files drug supply items on stock that are received and invoiced on a purchase order in central pharamcy management.

• Outgoing Birth Registry Reporting - Canada

  Sends messages to the BORN Birth Registry Ontario.

• Incoming Financial Transactions

  Receives financial transactions. It can receive charge and credit transactions for hospital accounts for Epic's Hospital Billing application, and post or void charges on guarantor accounts for Epic's Professional Billing application. These charges are subject to charge entry checks.

• Incoming Procedural Supply Usage

  Updates supply or implant usage information in OpTime (Epic's OR module) or Cupid (Epic's CVIS) procedural logs.

• Outgoing Results and Orders

  You can configure each copy of this interface one of the following ways: This interface can send result messages in the LRI format. LRI format results follow the HL7 version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1. It can send both order status and result messages from Beaker to external systems, when Beaker is the reference lab for another LIS or clinical system. This interface can send result messages in the ELR format. ELR format results follow the HL7 version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1. This format is often used to notify public health agencies of tests which must be reported for disease tracking, and meet Meaningful Use (MU) or Promoting Interoperability (PI) measures in the U.S. This interface can send messages for pathology reports that contain electronic cancer checklists. These messages conform to the North American Association of Central Cancer Registries (NAACCR) Standards for Cancer Registries Volume V rules for constructing HL7 messages for CAP electronic cancer checklist synoptic reporting. Use the LRI format unless you have a specific need to use the ELR or NAACCR formatted results.

• Incoming Surgical Cart Tracking

  After a surgical case is created, this interface files the identifier, current location, and transport status of the surgical carts that have been prepared for or assigned to the surgical case.

• Outgoing Infusion Orders

  Sends infusion order details to infusion pump gateways for the purposes of prepopulating infusion parameters on associated infusion pumps. When an infusion order message is sent on the Outgoing Infusion Orders interface, an immediate response is expected back from the infusion pump gateway via the Incoming Verification interface. These are advanced interfaces with a particular set of pre-requisites for successful implementation.

• Incoming External Push Notifications

  Used for receiving alerts that are appropriate for one-way informational notifications that do not need to be acknowledged by the receiving user. See also Incoming Alerts from Alert Manager or Incoming Alerts from Patient Care Devices for other workflows.

• Incoming Patient Education Interface

  Integrates Epic's Patient Education activity with a third-party education content management or content delivery system. The interface is used to record whether the patient has completed an educational assignment, and it can also be used to record ad hoc educational activities that were not assigned by the clinician.

• Outgoing Patient Education Interface

  Integrates the Patient Education Activity with a third-party education content management or delivery system. This interface is used to send clinician-initiated education assignments to a third-party system so that the content can be viewed and acted upon there.

• Incoming Deficiency Tracking

  An HIM deficiency represents incomplete work by a provider. Receives and processes messages that can create or delete deficiencies, and update deficiency status and assigned providers. The interface adds external deficiency information in HIM when a deficiency is not automatically created by standard application functionality. This interface is useful if transcriptions are stored in an external system (obviating the need for an Incoming Transcription interface, which can also update deficiency statuses). The deficiency created by the interface can be configured to follow the rules defined in HIM for aging and delinquency or they can be controlled by an external system in a direct fashion. This interface also plays a key role if integrating with an external web-based deficiency system, receiving messages that allow a URL to be launched from the Chart Completion module.

• Incoming Patient Administration

  Receives messages for new or changed demographic information, visits (ADT), registration (guarantors and insurance coverage), allergies, and bed status updates.

• Incoming Problem List

  Used to add, modify, or remove problems from the patient-level problem list. This interface works specifically with the longitudinal problem list, not problems specific to a particular hospitalization. This integration has been implemented only for conversions.

• Outgoing Problem List

  Sends notification of added, modified, or deleted problems from the patient-level problem list in the EHR to an external system. This interface works specifically with the longitudinal problem list, not problems specific to a particular hospitalization.

• Incoming Clinical Observations

  Receives and processes clinical observations (past medical history, smoking history, and so on), that do not fit into other tools. This interface is typically used for filing clinical data for the purposes of a conversion. The Incoming Clinical Documentation Flowsheet interface is recommended if the data will be filed only to a documentation flowsheet.

• Outgoing Ancillary Orders

  Sends orders placed by a clinical user in EpicCare to external ancillary systems - including messages for new orders, order cancellations, and number assignment responses to externally-initiated orders. Use cases include: Send physician placed orders to external laboratory, radiology or cardiology systems, when not using Epic equivalent product. Send orders from Beaker, Epic's LIS, to an external LIS if test needs to be performed at another lab. Send orders to blood bank system from Beaker. To send orders to both an external lab system (not to Beaker) and an external radiology system (not Radiant, Epic's RIS), two copies of the interface are needed, one for each purpose.

• Outgoing Medication Administration Notification

  Sends medication administration notification when a clinician marks a medication as administered on the MAR. This interface also sends updates regarding prior administrations, and change of status notifications for medications previously marked as administered. It does not send due times for medications that need to be administered in the future. The interface does not send messages when clinicians document the administration of blood products on the MAR or patient-controlled analgesia (PCA) medications on a documentation flowsheet.

• Outgoing Diet Orders

  Sends information about new or canceled diet orders to an external nutrition system. Messages are triggered when diet orders are created or canceled in EpicCare Inpatient EHR.

• Outgoing Imaging Results and Orders

  Sends orders and results from Radiant (Epic's RIS) or Cupid (Epic's CVIS) to PACS, radiology transcription systems, or other external systems. This is the only interface that sends orders or results from Radiant or Cupid. Messages are triggered for new orders when an order reaches a status of scheduled or arrived, changes to the status of an order, for results, and when the appointment associated with an order is canceled.

• Incoming Blood Product Matching to BPAM

  This interface is included with the Blood Product Administration Module and facilitates matching (positive patient identification with blood) of blood products received from an external blood bank system.

• Incoming Medication Orders to EpicCare Ambulatory

  Receives medication order information from an external ambulatory pharmacy system other than Willow Ambulatory. In the past, this interface was used only by an organization that maintained its own ambulatory pharmacy system and interfaced it with EpicCare Ambulatory EHR. In its original implementation mode, this interface encodes and cancels orders, tracks and cancels dispenses, and requests the originator of a refill order. However, since external pharmacy systems have now moved to NCPDP/e-prescribing workflows, this interface is no longer implemented in real time, and is sparingly used for certain types of electronic conversions (see Patient Abstractor for preferred method of converting at home medications). Note that this interface cannot be used to receive medications from an external Hospital Information System and file them for use with Willow Inpatient, nor can it file medication administration information discretely to the electronic MAR.

• Outgoing Medication Orders from EpicCare Ambulatory

  Sends ambulatory medication orders that are placed in Order Entry to an external pharmacy system internal to the organization other than Willow Ambulatory Pharmacy. Messages are triggered as a user orders, discontinues, or reorders a medication.

• Outgoing Scanned Document Link Maintenance

  Sends updated document link keywords to an external document management system (DMS) when key information about where the content is located changes, for example, if a scan that originated in the DMS is moved from one encounter to another by HIM Chart Correction processes.

• Incoming Results from Lab Instruments

  Receives test results from instruments into Beaker, Epic's LIS. This is also the interface to use to receive point of care testing results, such as from docked glucometer systems, into Beaker.

• Outgoing Orders to Lab Instruments

  Sends information about new or canceled laboratory orders from Beaker, Epic's LIS, to an instrument. This is also the interface to use for Point of Care testing with Beaker, for example, docked glucometer systems. It can trigger messages when a new specimen is received, a test is reordered, an add-on test is ordered for a specimen that has already been received, or a test is canceled.

• Incoming Orders from CPOE Systems

  Receives orders from external ordering systems. The interface can create, update, or cancel orders. Common use cases are routing lab orders to Beaker (Epic's LIS), radiology orders to Radiant (Epic's RIS), or cardiology orders to Cupid (Epic's CVIS). Some integrations may additionally require either an Incoming Patient Administration interface to create or update patient records or an incoming query to look up patient information before sending the order message.

• Incoming Medication Dispenses and Load/Unload from ADS to Willow Inpatient

  Processes dispense, return, and waste information from medication cabinet systems (automated dispense systems), dispensing workflow engines, and robots. Also processes "load/unload" messages received when a drawer, pocket, or bin is emptied or stocked.

• Outgoing Verified Medication Orders from Willow Inpatient

  Sends verified pharmacy orders. This interface is typically used with cabinet, robotic, TPN, or carousel dispensing systems. It is sometimes used to transmit medication orders to an external medical record or surgery system. Messages are triggered from Willow Inpatinet Pharmacy when a user verifies, re-verifies, discontinues, or modifies an order, reverses a discharge, changes a patient's location such that the dispense location changes, or loads a medication into a station that did not previously contain that medication. We recommend one interface for cabinets and a separate interface for robotic dispensing systems, since the requirements for message content varies between systems, as the robot is dispensing multiple doses of a given medication for a cart, whereas the cabinet order will be dispensed by a user.

• Outgoing Patient Administration

  Informs external systems of new patient creation, changes to patient demographic information, visits (ADT), registration (guarantors and insurance coverage), allergies, and bed status updates. These messages are triggered from many of Epic's applications. The ability to send allergy updates is only available from the Allergy activity. This interface does not send final coded diagnoses, procedures, or DRGs after a hospital account is coded.

• Outgoing Formulary Information to ADS from Willow Inpatient Interface

  Also known as ADS Console Management. The interface can be used to populate the master medication list of an automated dispense system when a medication is added or removed from the Willow Inpatient Pharmacy formulary.

• Incoming EOB Scanning

  Receives messages that notify the billing applications (Resolute Hospital, Professional, Home Health (Dorothy), or Enterprise Billing) that a scanned explanation of benefits document exists. Receiving a message opens a new payment batch in the appropriate billing application based on scan type.

• Incoming Device Data

  Receives discrete measurements from patient monitoring and documentation devices. The messages file to the application, where the data can be validated by the user and added to the chart, or in the case of surgical procedures, can be set to automatically validate and file to the chart. This type of integration is usually done with device aggregators to file samples from continuous physiological monitoring. It is not used for consumer-initiated monitoring or home monitoring.

• Incoming MPI and Demographics Query

  Receives and responds to queries for demographic data from an external system when Epic is the EMPI. Does not modify patient data.

• Incoming Personnel Management

  Receives messages from an external user management system to create, update, or delete user records in Epic. While this interface can build the shell of a user record and associate role based information, this interface can't completely automate the addition of new users to an organization, because Epic has settings and features built by association to a user record. These settings cannot be controlled by an external system. We recommend you use the Personnel Management web services rather than this HL7v2 interface as it offers significantly greater capabilities.

• Incoming Location and Department Information

  Used to automate synchronization of the facility structure (locations and departments). To this point, this integration has been completed only with custom in-house systems previously developed by our organizations.

• Outgoing MPI and Demographics Query

  Queries an external EMPI during a patient search after a local search is performed. The correct patient is then selected by a user from a list of candidates returned in the response message.

• Outgoing Claim Scrubber Query

  Claim Scrubbing functionality integrated into various workflows in Resolute, Epic's billing system.

• Outgoing Address Verification Query

  Queries a third-party system to verify and validate patient-level and guarantor-level demographic data the time of registration. This interface works with Prelude, Epic's registration system.

• Outgoing Clinical Documentation Flowsheet Data

  Sends discrete documentation flowsheet data to another system.

• Incoming Appointment Scheduling

  Receives scheduling information from external systems to show that information in Epic or provide clinical access to the patient's appointments. It can receive messages for new, rescheduled, updated, or canceled appointments, as well as notifications that a patient did not show for an appointment.

• Incoming Schedule Query

  Receives patient information queries and returns information regarding scheduled appointments.

• Incoming Clinical Documentation Flowsheet Data

  Receives discrete patient data from an external system (where a user has previously validated the data), and files directly to the documentation flowsheet. This interface can also be used with clinically regulated home monitoring device vendors for post discharge monitoring programs, home care, home hospice, or other types of patient monitoring episodes.

• Incoming Procedure Log Data

  Receives information about cardiac catheterization, electrophysiology and interventional radiology procedures when using the Cupid (CVIS) procedure log for intra-procedure documentation. This information is sent from a hemodynamic product that collects vitals and pressures during the procedure. This interface can file information to flowsheets and free text events such that it appears on the Cupid procedure log. This interface is typically not used if Cupid's procedure log is not in use and the procedure log is being completed in the hemodynamic system.

• Outgoing Financial Transactions

  Sends financial transactions. Typically, the relevant situation for the use of this interface is when clinical services are provided at an organization that is not responsible for the associated revenue.

• Outgoing Syndromic Data

  Follows the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data. Used to meet Meaningful Use Objectives to send Syndromic Surveillance data to Public Health agencies.

• Outgoing Results Query to Ontario Lab Information System

  Sends a patient-level query to the Ontario Laboratories Information System (OLIS) when a patient checks in for an appointment, and receives results OLIS returns in response to the query. The query can also be initiated on demand by a user at any time. Follows eHealthOntario OLIS Interface Specification R01.20. www.ehealthontario.on.ca.

• Outgoing Registration to Home Device Data Concentrator

  Sends registration information to a device data concentrator system to register patients and devices. This interface would be used instead of the standard Patient Administration interface when collecting data from patient home monitoring devices using an external system.

• Outgoing Appointment Scheduling

  Sends appointment information to external systems. Users can trigger messages for new, rescheduled, updated, no showed, and canceled appointments. To send surgical case schedules, the Outgoing Surgical Case Scheduling interface is required.

• Coding - Incoming Query and Response

  The incoming coding interface supports workflows in which coders are working entirely in your system. Coders in your system send messages to providers using Epic asking for more information to support their documentation (CDI or Coding Query). Responses are sent in return.

• Incoming Surgical Case Tracking

  Receives surgical case event information in real time to populate the event and the event timestamp in a surgical case log.

• Outgoing Medication Stock Transfer Request and Response

  Initiates a fill in a dispensing system-such as robotic arm or carousel-to assist in sending medications from the pharmacy to a hospital floor. This interface also receives acknowledgments from the dispensing system, which updates stock counts in Willow Inventory Management accordingly. For example, if a user requests five bottles of a certain medicine, but only four exist in stock, the interface updates the stock count being sent to the floor to four. Note that the purpose of messages sent by the interface is to request stock for a hospital floor. For that reason, the messages aren't patient-specific.

• Outgoing Surgical Case Scheduling

  Sends case scheduling information to external systems. Messages are sent for new, rescheduled, updated, and canceled cases.

• Outgoing OCIO Medication Orders from EpicCare Ambulatory

  Sends outpatient and discharge medication orders to a pharmacy information system. This interface supports a subset of HL7 version 2.4 according to the specifications defined in the Clinical System Medication Management Interface Specification version 10.1 published by the Office of Chief Information (OCIO) of Victoria in Australia.

• Incoming Medication Inventory Management

  Updates medication stocks in Willow Inventory, Epic's medication inventory management system, with changes for an externally managed inventory location.

• Outgoing Medication Inventory Depletion

  Communicates changes in medication stock in Willow Inventory medication inventory management for an external inventory location.

• Incoming Surgical Resource Data

  Used to automate synchronization of surgical instrument records, implant groups, or trays from an external system.

• Incoming Infusion Documentation

  Receives discrete measurements from an infusion pump gateway associated with the administration of an infusion order. This is an advanced interface with a particular set of prerequisites for successful implementation.

• Incoming Alerts from Alert Manager and Alert Reporting from Patient Care Devices

  This collection of interfaces receives alert messages to send push notifications to end users. Upon receiving, reading, or responding to an alert, response messages are sent back to the alert manager. They can also store technical and physiological alert data from patient care devices such as physiological monitors and infusion pumps.

• Incoming Medication Administration Notification

  Files administration information to a medication order created and acted on in an external system. The read-only orders appear on the MAR for reference.

• Incoming Prescriptions from Legacy Pharmacy to Willow Ambulatory

  Receives medication orders from legacy pharmacy systems and files the medications orders to Willow Ambulatory Pharmacy. This interface is used only for conversions.

• Incoming Ancillary Results

  Receives test results from a laboratory, cardiology, or similar information system These results include general lab, microbiology, pathology, and blood bank results, results with a narrative/impression, and hyperlinks to results that are stored elsewhere. These results can include LIS data, RIS data, pacemaker data, ECG records, and hemodynamic data. The interface can accept incoming order messages that request order numbers, replace procedures, or cancel existing orders. This HL7v2 interface is specific to a clinical order and uses TCP/IP to exchange messages.

• Discrete Genomic Results

  Discrete genomic results file to Epic via the Incoming Ancillary Results interface . To include discrete genomic data as a part of the test's result, specifically formatted OBX segments must be included on the result (ORU^R01) message. These OBX segments follow the representation for discrete genomic data published in the HL7 Version 2.5.1 Implementation Guide: Lab Results Interface (LRI), Release 1 and the supported data elements are outlined in the specification document.

• Incoming Ancillary Results - Imaging

  Epic's radiology and cardiology software receives results from a imaging, cardiology, or transcription system for use in Epic. These results include results with a narrative/impression, and image availability or hyperlinks to results that are stored elsewhere, such as a PACS. This HL7v2 interface is specific to a clinical order and uses TCP/IP to exchange messages.

• Digital Pathology

  The integration between Beaker, Epic's lab software, and an image-management system for the digital pathology workflow utilizes the Outgoing Lab Instrument Orders and the Incoming Lab Instrument Results interfaces. Beaker sends patient, case, and slide information and receives image availability notifications to enable whole slide imaging workflows.

• Incoming Transcriptions

  In this scenario, an external system has findings in a text or image format. These findings are either observations from a given contact with a patient (such as a visit or a hospitalization) or observations specific to a clinical order. Traditionally, this interface was used to match dictations with their eventual transcription (hence the name), but it can be used for a broader range of clinical findings. The EHR receives and files documents from a transcription system, scanned documents from an external document management system, or notes generated in another clinical system. This interface is often used for clinical findings that don't neatly fit into more specific data elements. Notes created or updated by the transcription interface can trigger deficiency updates.

• Incoming Scanned Document Link

  Receives and files scan pointers from an external document management system. This interface can also receive base64 encoded documents and store them to an Epic server. This interface does not file textual data intended for use in Radiant or Cupid; those documents must be processed by the Incoming Ancillary Results and Orders interface set up as an Incoming Ancillary Results and Orders - Imaging interface. Messages must be in HL7 MDM format. Documents processed by this interface can satisfy deficiencies in the Health Information Module.

• Smoking Cessation Integration

  This is a group of three interfaces that together can be used to integrate with quit line vendors to communicate an order for cessation counseling, and receive in response the followup documented by the quit line and any medications, such as nicotine gum, given to the patient as part of the protocol.

• Electronic Fetal Monitoring

  Epic integrates electronic fetal monitoring systems more tightly with inpatient workflows in the Epic EHR. The interfaces control establishing a shared identity with the EFM system, transmitting monitor vitals information from the fetal monitor to Epic, and associated documentation done in Epic with the fetal strip.

• Event Notifications via Direct

  Epic sends CMS Event Notifications that conform to DirectTrust’s Event Notifications via the Direct Standard™ implementation guide. The goal of these notifications is to improve care coordination across healthcare settings, reduce readmissions, and improve transitions. The provided specification contains details regarding the HL7v2 attachments.

• Coding - Bidirectional

  The bidirectional interface is used to integrate with encoders and computer-assisted coding systems to exchange information for Hospital Coding workflows. Epic offers front-end integrations through web services as well as back-end integration methods. Separately, the outgoing interface can be used to send the final coded information to downstream systems such as care management products.

• Electronic Laboratory Reporting

  This Outgoing Results and Orders interface sends results in the ELR format. ELR format results follow the HL7 version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1. This format is often used to notify public health agencies of tests which must be reported for disease tracking, and meet Meaningful Use (MU) or Promoting Interoperability (PI) measures in the U.S.

• NAACCR Pathology Reporting

  This Outgoing Results and Orders Interface sends messages for pathology reports that contain electronic cancer checklists. These messages conform to the North American Association of Central Cancer Registries (NAACCR) Standards for Cancer Registries Volume V rules for constructing HL7 messages for CAP electronic cancer checklist synoptic reporting.

• Incoming Vaccination Administration

  Receives unsolicited vaccination administration updates from either an immunization registry or an external clinical system that is not a registry. If integrating with a registry that supports the query interface, the query is the preferred integration.

• Outgoing Vaccination Query

  Initiates a query to and receive a response from an immunization registry system. Each query requests data for a given patient. Generally, registries provide historical immunization data. Some registries additionally supply immunization recommendation data. The incoming portion of the interface does not directly update immunizations in the chart; the provider sees the response from the registry and decides what should be added to the patient record. HL7 2.5.1 specification conforms to the Center for Disease Control HL7 2.5.1 Implementation Guide for Immunization Messaging .

• Outgoing Vaccination Administration

  Sends information about vaccination administrations to either an immunization registry or a clinical system or receiving system that is not a registry. An incoming response interface receives and files the response/acknowledgement returned from an immunization registry. The specification conforms to HTI-1 regulations, using the Center for Disease Control Implementation Guide for Immunization Messaging.

• Incoming Patient Administration from Population Register

  The Finnish Population Information System (formerly known as the National Population Register or VRK), is a computerized national register that contains demographic information about Finnish citizens and foreign citizens residing in Finland. The population register sends data to this interface in a batch.

• Incoming Referral Notification

  The recommended workflow, for a full closed loop referral is a 360 Exchange Closed Loop integration. 360X Closed Loop Referral . This HL7v2 interface receives referral information from an external system, and is only able to create, update, and cancel a request for a referral in the receiving Epic system.

• Outgoing Referral Notification

  The recommended workflow, for a full closed loop referral is a 360 Exchange Closed Loop integration. 360X Closed Loop Referrals This HL7v2 interface only sends new or updated request for referral information.

"The Version 3 Normative Edition represents a new approach to clinical information exchange based on a model driven methodology that produces messages and electronic documents expressed in XML syntax. The V3 specification is built around subject domains that provide storyboard descriptions, trigger events, interaction designs, domain object models derived from the RIM, hierarchical message descriptors (HMDs) and a prose description of each element." - HL7.org

• Outgoing Child Protection Information Sharing NHS Query

  This interface sends queries to the Spine for the NHS Digital Child Protection - Information Sharing project (CP-IS) in the United Kingdom. The Spine responds whether a child is in Child Protection, a child who is a Looked After Child, or an expectant mother of an unborn child who will be under Child Protection.

• Outgoing Infection Reporting to NHSN Interface

  Sends documents in clinical document architecture (CDA) format, supporting the January 2021 Patient Safety Component Manual developed and maintained by the National Healthcare Safety Network (NHSN). Each CDA document represents either a single patient infection, a surgical procedure, an antimicrobial resistance event, or a month of department-level or facility-level antimicrobial usage, device utilization, or patient census summary data. This covers all US nationally mandated reporting elements for inpatient infection prevention.

• Outgoing Risk Assessment Query

  Supports comprehensive breast cancer risk assessment following the HL7 Version 3 Implementation Guide for Family History/Pedigree Interoperability, Release 1 - US Realm April 2013.

• Data Exchange with DBC Onderhoud Grouper

  Sends Diagnosis Behandeling Combinatie (DBC) and charge information from Epic to the VECOZO Declaratie Grouper (Netherlands). The Grouper retrieves a billable product and billing code (DBC-zorgproduct).

• Real-Time Location System (RTLS) Interface

  Tracks the location of patients, staff, and medical devices within a facility. This automates and enhances many workflows. For example, it can automatically document operating room wheels in and out times, or make it easier for staff to associate medical devices with specific patients.

• Outgoing BSN Verification Query

  BSN or Burgerservicenummer verification is required in the Netherlands. There are two types of BSN queries: BSN request, and BSN verification. Using provided demographic data, a BSN request will retrieve and store the BSN for a patient, whereas the BSN verification serves to validate that the BSN a user has stored to the patient record is correct.

• Incoming QRDA Documents Interface

  Imports QRDA document information used to report on quality measures for regulatory programs. This interface supports ONC 2015 Edition Certification (for Meaningful Use).

• Outgoing National Healthcare Survey Interface

  Reports National Healthcare Survey data to the Centers for Disease Control and Prevention (CDC).

• Clinical Document Architecture (CDA)

  When exchanging patient summary documents, we use Clinical Document Architecture (CDA) as the content standard. CDA is an XML-based markup standard defined by Health Level Seven (HL7), intended to specify encoding, structure and semantics of clinical documents for the purpose of exchange. Care Everywhere supports the exchange of document defined in the Consolidated CDA (C-CDA) framework, which is required for ONC 2015 Edition certification for Meaningful Use. Epic's EHR can consume any valid C-CDA or CDA document. Epic's EHR can create the following documents: HL7/ASTM CCD (HITSP C32 Implementation) HL7/IHE Consolidated CDA (CCD and Progress Notes Template) Contact us if you have questions about our CDAs.

IHE, or Integrating the Healthcare Enterprise, coordinates the use of many different standards by layering on the context of healthcare delivery. You can learn more from IHE . Epic maintains a set of IHE Integration statements for these profiles. If you are looking to see which technical options in each profile that Epic supports, see Epic's integration statements .

• Outgoing Cancer Reporting

  Allows organizations using Epic's oncology software, Beacon, to meet the Meaningful Use objective to send cancer case information to cancer registries.

• Research Study Management and Enrollment

  These interfaces integrate with an external Clinical Research Management system to facilitate research workflows. They can create or update research study records, associate patients to a study, update the patient's enrollment status in the study, and receive study billing grid information. These interfaces follow the IHE - Retrieve Protocol for Execution (RPE) implementation, IHE - Clinical Research Process Content Profile (CRPC), HL7 Study Participation, and HL7 Study Design.

• Incoming Patient Discovery

  In this scenario, an external system has a patient that it is attempting to match in an Epic system. The external system sends a subset of patient demographics and if Epic can find a unique high-confidence match, it returns the matching patient. Epic implements all transactions required in the IHE Technical Framework to support the IHE Cross-Community Patient Discovery Profile as a Responding Gateway.

• Outgoing Patient Discovery

  In this scenario, a patient presents to an Epic system, and a user needs to match the patient in an external system. Epic sends a subset of patient demographics to the external system, which responds with the patient who matches the query. Epic confirms the match, usually through the user, and then report back the user's actions. Epic implements all transactions required in the IHE Technical Framework to support the IHE Cross-Community Patient Discovery Profile as an Initiating Gateway.

• Implantable Device - Cardiac

  Epic's cardiology software implements IHE's Implantable Device - Cardiac - Observation Profile as an Implantable Device - Cardiac - Consumer. It supports the OBX - Encapsulated PDF or Ref Pointer option and the PV1 - Patient Visit option.

• Medical Device Waveform Display

  The Epic Monitor can receive streaming waveform data from device and middleware vendors for displaying in the Waveform widget in the Epic Monitor.

• Cross-Community Access (XCA) and Cross-Enterprise Document Sharing (XDS.b)

  The process of exchanging clinical documents is handled through a series of messages exchanged via standards-based SOAP Web services. Because organizations that use Epic software are often the size of regional HIEs themselves, interoperability with the Epic EHR requires no centralized infrastructure. Instead, the EHR acts as a document repository itself for point-to-point queries. Specifically, the EHR supports IHE XCA and IHE XDS.b Query-Response.

• Sending Clinical Documents (Direct)

  Epic's EHR supports document exchange via the Direct protocol. Documents sent from an Epic EHR via Direct follow the XDR/XDM option, in which structured documents are sent in the message with structured metadata. Similarly, Epic receives structured documents to file to the appropriate chart. External provider directories containing Direct addresses can be imported into the Epic EHR using a standard format . While Epic software supports the full SMTP+S/MIME stack, organizations using Epic can alternatively choose to delegate duties to an external HISP. Providers use the EHR to push data using Direct, and patients can use their portal to send structured clinical summaries to any arbitrary Direct endpoint with which the organization has established trust.

• Closing Referral Loop

  To facilitate closing the loop on referrals so referring providers can be kept up to date on the treatment received by their patients, Epic supports additional elements within Direct messaging using the XDR transport method. These additional elements indicate Direct messages which include a specialist report generated during the care of a patient who has been referred to an organization outside their primary care organization.

• FHIR Launch Sequence

  Epic can utilize the HL7 SMART on FHIR launch sequence to enable context exchange for FHIR resources with an external application. When used from an EHR-based launch, the interaction follows the IHE Mobile Retrieve Form for Data Capture (mRFD) profile.

• Device Enterprise Communication

  Epic supports the IHE Device Enterprise Communication (DEC) profile for receiving vendor independent, multi-modality patient care device data. This supports a wide variety of devices from vital signs monitors to point of care systems.

• Device Alarm Communication

  Epic supports the IHE Alarm Communication Management (ACM) profile for receiving device initiated alerts. This standard helps facilitate communication of alarm information to caregivers.

• Infusion Documentation

  Epic supports the IHE Point-of-Care Infusion Verification (PIV) standard for electronic transmission of infusion information as part of medication administration. This decreases the need for manual pump programming and may leverage additional decision support internal to the pump.

• Newborn Notification

  Epic supports the IHE Newborn Admission Notification Information (NANI) profile for transmitting newborn information to Public Health systems. This standard can be used to send ADT messages after a baby is born to provide public health with an initial notification of a new child.

• 360X Closed Loop Referrals

  360 Exchange Closed Loop Referrals (360X) is an industry and government supported standard specification for referrals that allows the exchange of patient referral data between different EHR environments. Epic and non-Epic organizations whose EHR systems meet the specification’s requirements can exchange 360X referrals.

FHIR, or Fast Healthcare Interoperability Resources, provides a lightweight REST-based access layer for standard HL7-defined data models. If you're looking for more than specs, check out FHIR development sandbox for how you can get client IDs and testing support.

• $submit-attachment (Prior Auth) (R4)

  This web service is used by providers to submit additional information to facilitate the payer's prior authorization review process. The current types of additional information that are supported include QuestionnaireResponse Bundles and DocumentReference in the form of PDFs. This is generally used in conjunction with Claim.$submit (Prior Auth) (R4) as a way to add details to a specific submission. This incoming web service enables submission of additional information to the payer's UM system using FHIR. Refer to Operation Definition of $submit-attachment v2.1.0 and CDex Parameters Submit Attachment Profile v2.1.0 for more information.

• Account

  The Account resource acts as a central record against which charges, payments, and adjustments are applied. It contains information about which parties are responsible for payment of the account. Technical Specifications: Account.Read (Premium Billing) (R4) Account.Search (Premium Billing) (R4)

• AdverseEvent

  The AdverseEvent resource returns data about an event that caused unintended physical injury resulting from or contributed to by medical care, a research study, or other healthcare setting factors. These events might require additional monitoring, treatment, or hospitalization, or might result in the death of a patient. Technical Specifications: AdverseEvent.Read (R4) AdverseEvent.Search (R4)

• AGL ScanViewing Action

• AGL ScanViewing Closing

• AGL ScanViewing DocumentDisplay

• AGL ScanViewing Handshake

• AGL TelephoneAlert

• AllergyIntolerance

  The AllergyIntolerance data models describe a patient's intolerance to a foreign substance and an associated reaction that occurs from exposure. Technical Specifications: AllergyIntolerance.Read (DSTU2) AllergyIntolerance.Search (DSTU2) AllergyIntolerance.Create (STU3) AllergyIntolerance.Read (STU3) AllergyIntolerance.Search (STU3) AllergyIntolerance.Create (Patient Chart) (R4) AllergyIntolerance.Read (Patient Chart) (R4) AllergyIntolerance.Search (Patient Chart) (R4) AllergyIntolerance.Read (Outside Record) (R4) AllergyIntolerance.Search (Outside Record) (R4)

• Appointment, Schedule, Slot

  Appointment describes a patient's scheduled visit with a health care provider. The slot resource provides time-slots that can be booked using an appointment. They do not provide any information about appointments that are available, just the time, and optionally what the time can be used for. The Schedule resource is the link from a slot to a practitioner and location for an appointment. Technical Specifications: Appointment.Read (Appointments) (STU3) Schedule.Read (STU3) Appointment.$book (STU3) Appointment.$find (STU3) Slot.Read (STU3) Appointment.Search (Appointments) (STU3) Appointment.Read (Appointments) (R4) Appointment.Search (Appointments) (R4) Appointment.Read (Scheduled Surgeries) (R4) Appointment.Search (Scheduled Surgeries) (R4) Appointment.Read (Prior Auth) (R4) Appointment.Search (Prior Auth) (R4)

• Authentication and Single Sign-On (SSO)

  Epic recommends and supports the HL7 SMART on FHIR profile of OAuth 2.0, including the EHR launch and standalone launch for both patients and providers, as well as backend services. Epic also supports basic authentication. See Tutorial

• Binary

  Binary provides the ability to retreive a particular document. Technical Specifications: Binary.Read (Generated CCDA) (DSTU2) Binary.Read (Clinical Notes) (STU3) Binary.Read (Provider Photo) (R4) Binary.Read (Clinical Notes) (R4) Binary.Read (Document Information) (R4) Binary.Read (OASIS) (R4) Binary.Read (HIS) (R4) Binary.Read (Handoff) (R4) Binary.Read (Labs) (R4) Binary.Read (External CCDA) (R4) Binary.Read (Radiology Results) (R4) Binary.Read (Correspondences) (R4) Binary.Read (Radiology Results) (STU3) Binary.Read (Correspondences) (STU3) Binary.Read (IRF-PAI) (R4) Binary.Read (Minimum Data Set) (R4) Binary.Read (Clinical References) (R4) Binary.Read (Patient-Entered Questionnaires) (STU3) Binary.Read (Patient-Entered Questionnaires) (R4) Binary.Read (Generated CDAs) (R4) Binary.Search (Clinical Notes) (R4) Binary.Search (Handoff) (R4) Binary.Search (Clinical References) (R4) Binary.Search (HIS) (R4) Binary.Search (IRF-PAI) (R4) Binary.Search (Labs) (R4) Binary.Search (Provider Photo) (R4) Binary.Search (Correspondences) (R4) Binary.Search (Generated CDAs) (R4) Binary.Search (External CCDA) (R4) Binary.Search (Document Information) (R4) Binary.Search (Minimum Data Set) (R4) Binary.Search (OASIS) (R4) Binary.Search (Radiology Results) (R4) Binary.Search (Patient-Entered Questionnaires) (R4) Binary.Read (Practitioner Photo) (STU3) Binary.Read (Outside Record - Clinical Notes) (R4) Binary.Search (Outside Record - Clinical Notes) (R4) Binary.Read (Study) (R4) Binary.Read (Prior Auth Supporting Info) (R4)

• BodyStructure

  BodyStructure describes anatomical details about a specimen or body part, including patient information, descriptions, and images. For example, this resource can return tooth information from the patient record. Technical Specifications: BodyStructure.Read (Tooth) (R4) BodyStructure.Search (Tooth) (R4) BodyStructure.Read (Organ) (R4) BodyStructure.Search (Organ) (R4) Bodystructure.Create (Radiotherapy Volume) (R4) Bodystructure.Read (Radiotherapy Volume) (R4) Bodystructure.Search (Radiotherapy Volume) (R4) Bodystructure.Update (Radiotherapy Volume) (R4)

• Bulk Data Access

  FHIR Bulk Data Access, also known as Flat FHIR, is a framework for efficiently accessing large volumes of information about a group of individuals. For more information, refer to the HL7 specification , or Epic's FHIR Bulk Data Access Tutorial . Technical Specifications: Bulk Data Kick-off Bulk Data Status Request Bulk Data File Request Bulk Data Delete Request

• CarePlan, Goal

  Careplan describes the assessment and treatment plan for a particular patient. Goal describes provider-documented targeted outcomes for a patient to achieve. Technical Specifications: CarePlan.Read (Encounter-Level) (DSTU2) CarePlan.Search (Encounter-Level) (DSTU2) Goal.Read (Patient) (DSTU2) Goal.Search (Patient) (DSTU2) Goal.Read (Patient) (STU3) Goal.Create (Patient) (STU3) Goal.Search (Patient) (STU3) Goal.Read (Patient) (R4) Goal.Search (Patient) (R4) CarePlan.Read (Longitudinal) (R4) CarePlan.Search (Longitudinal) (R4) CarePlan.Read (Encounter) (R4) CarePlan.Search (Encounter) (R4) CarePlan.Read (Dental) (R4) CarePlan.Search (Dental) (R4) CarePlan.Read (Questionnaires Due) (R4) CarePlan.Search (Questionnaires Due) (R4) CarePlan.Read (Inpatient) (R4) CarePlan.Search (Inpatient) (R4) CarePlan.Read (Outpatient) (R4) CarePlan.Search (Outpatient) (R4) Goal.Read (Care Plan Goal) (R4) Goal.Search (Care Plan Goal) (R4) CarePlan.Read (Oncology) (R4) CarePlan.Search (Oncology) (R4) Goal.Read (Pathway Step) (R4) Goal.Search (Pathway Step) (R4) CarePlan.Read (Inpatient Pathway) (R4) CarePlan.Search (Inpatient Pathway) (R4) CarePlan.Read (Care Path) (R4) CarePlan.Search (Care Path) (R4) Goal.Read (Care Path) (R4) Goal.Search (Care Path) (R4) CarePlan.Read (Patient Education) (R4) CarePlan.Search (Patient Education) (R4) Goal.Search (Care Plan) (STU3) Goal.Read (Care Plan) (STU3) CarePlan.Read (Longitudinal) (DSTU2) CarePlan.Search (Longitudinal) (DSTU2) Goal.Read (Outside Record) (R4) Goal.Search (Outside Record) (R4) CarePlan.Search (Outside Record) (R4) CarePlan.Read (Outside Record) (R4)

• CareTeam

  The CareTeam resource returns information about a patient’s care team and care team members. The care team includes longitudinal care team assignments as well as providers who have had recent visits with the patient. 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. Technical Specifications: CareTeam.Read (Longitudinal CareTeam) (R4) CareTeam.Search (Longitudinal CareTeam) (R4) CareTeam.Read (Episode) (R4) CareTeam.Search (Episode) (R4) CareTeam.Read (Outside Record) (R4) CareTeam.Search (Outside Record) (R4)

• CDS Hooks

  CDS Hooks is an HL7 standard for in-workflow, real-time, provider-facing decision support integration between Electronic Health Record systems and external Decision Support Services. A summary understanding of the specification is necessary for the discussion of state of Epic support for CDS Hooks, so check out the HL7 published specification and current draft specification . Epic recommends against using this feature for other purposes; if you need only a notification, we instead recommend using an event based interface.

• Claim.$inquire (Prior Auth) (R4)

  This web service enables providers to inquire about the status of existing prior authorization requests in the utilization management system using FHIR technology. It is an alternative to the traditional ANSI X12 278 transaction, which is the EDI standard historically used by payers and providers to exchange prior authorization requests and inquiries electronically. Providers can use this service to check the current review status, retrieve pended authorization details, or confirm approved/denied outcomes for previously submitted prior authorization requests. This API functions similarly to the incoming 278 inquiry API but, instead, uses the FHIR specification defined in the Da Vinci Prior Authorization Support implementation guide .

• Claim.$submit (Prior Auth) (R4)

  This web service enables providers to submit prior authorization requests to the utilization management system using FHIR technology. It is an alternative to an ANSI X12 278 Health Care Services Request For Review message, which is the EDI standard historically used by payers and providers to exchange prior authorization requests electronically. Providers can use this service as standalone, following Coverage Requirements Discovery (CRD) when prior authorization is determined necessary, or after Documentation Templates and Rules (DTR) interactions to submit QuestionnaireResponse resources alongside the initial authorization request. This API functions similarly to the incoming 278 request API but, instead, uses the FHIR specification defined in Da Vinci Prior Authorization Support (PAS) implementation guide v2.1.0 for PAS Claim .

• Communication

  The Communication resource represents a record of communication. This resource can convey details about messages between health systems and community-based organizations about referral requests made through continued care and services workflows in Epic, such as a post-discharge service request for durable medical equipment (DME) or social services. Technical Specifications: Communication.Read (Community Resource Communication) (R4) Communication.Search (Community Resource Communication) (R4) Communication.Create (Community Resource Communication) (R4) Communication.Read (Patient Education) (R4) Communication.Search (Patient Education) (R4) Communication.Read (Customer Relationship Management) (R4)

• Computer-Telephony Integration (Incoming)

  Epic integrates with your organization’s phone system to automatically open the appropriate chart or another activity in Epic when calls are received.

• Computer-Telephony Integration (Outgoing)

  Epic integrates with your organization’s phone system so users can place or end a call directly from a patient chart or another activity in Epic, and details about the call are logged. Your phone system can also update Epic with the call identifier after the call.

• Condition

  Conditions can encompass acute and chronic problems and conditions, as well as encounter diagnoses. Technical Specifications: Condition.Read (Problems) (DSTU2) Condition.Search (Problems) (DSTU2) Condition.Create (Problems) (STU3) Condition.Read (Encounter Diagnosis, Problems) (STU3) Condition.Search (Encounter Diagnosis, Problems) (STU3) Condition.Create (Problems) (R4) Condition.Read (Encounter Diagnosis) (R4) Condition.Read (Problems) (R4) Condition.Search (Encounter Diagnosis) (R4) Condition.Search (Problems) (R4) Condition.Read (Health Concerns) (R4) Condition.Search (Health Concerns) (R4) CDS Hooks Condition.Create (Problems) (R4) CDS Hooks Condition.Create (Encounter Diagnosis) (R4) CDS Hooks Condition.Create (Encounter Diagnosis, Problems) (STU3) Condition.Read (Genomics) (R4) Condition.Search (Genomics) (R4) Condition.Read (Care Plan Problem) (R4) Condition.Search (Care Plan Problem) (R4) Condition.Read (Dental Finding) (R4) Condition.Search (Dental Finding) (R4) Condition.Read (Infection) (R4) Condition.Search (Infection) (R4) Condition.Read (Reason for Visit) (R4) Condition.Search (Reason for Visit) (R4) Condition.Read (Medical History) (R4) Condition.Search (Medical History) (R4) Condition.Read (Outside Record Health Concern) (R4) Condition.Read (Outside Record Problems) (R4) Condition.Search (Outside Record Health Concern) (R4) Condition.Search (Outside Record Problems) (R4) Condition.Read (Outside Record Encounter Diagnosis) (R4) Condition.Search (Outside Record Encounter Diagnosis) (R4)

• Consent

  The FHIR Consent resource defines a concept around collected consent for some action. Consent resources correspond to Documents in Epic. The Consent.Search interaction returns only metadata about the patient consent document(s) on file, such as the type of consent and the effective period. This resource does not return the consent document itself. Typically this resource is used to check whether a consent document is on file for a particular patient. The Consent resource is intended only for provider-facing applications. Patient-facing applications cannot use this resource. Technical Specifications: Consent.Read (Document) (R4) Consent.Search (Document) (R4) Consent.Read (Code Status) (STU3) Consent.Search (Code Status) (STU3) Consent.Read (Code Status) (R4) Consent.Search (Code Status) (R4) Consent.Read (Document) (STU3) Consent.Search (Document) (STU3)

• Contract

  The Contract resource is primarily used for read interactions and can be used as a reference when calling the DocumentReference.Create interaction. Technical Specifications: Contract.Read (Healthcare Services Reimbursement) (R4) Contract.Search (Healthcare Services Reimbursement) (R4)

• Coverage

  Coverage resources represent an insurance coverage associated with the patient. A patient might have a long list of possible coverages, some of which are applicable only for specific services. Examples include third party liability, worker's comp, black lung insurance, Medicaid for ESRD, Medicare, commercial, etc. Technical Specifications: Coverage.Read (Patient Insurance Information) (R4) Coverage.Read (Patient Insurance Information) (STU3) Coverage.Search (Patient Insurance Information) (R4) Coverage.Search (Patient Insurance Information) (STU3) Coverage.Read (Outside Record) (R4) Coverage.Search (Outside Record) (R4)

• Coverage Requirements Discovery (R4)

  This web service is available as part of Epic's utilization management module for clients to integrate with Epic health plans and payers. This web service is based on the implementation guide published by the HL7® FHIR® Da Vinci Project for Coverage Requirements Discovery (STU 2.1) , acting as a payer-side CRD server. The purpose of CRD is to communicate coverage information about a requested service for a covered member, including whether the service is a covered benefit, whether the service requires a prior authorization, and whether additional documentation is needed through the Documentation Templates and Rules web service (DTR). Epic's CRD payer web service supports responding to requests by two mechanisms: directly by using authorization requirements created inside Epic's utilization management module; and by forwarding the CRD request to another system. This guide describes the requirements and invariants of Epic's implementation of CRD for its utilization management module. Coordinate with each payer you integrate with to understand any additional features or limitations of other CRD systems that might be involved in final responses over this web service. At the time of writing, CRD is a constantly evolving specification and is still receiving corrections and enhancements, as is our server implementation, so this content will change over time.

• Coverage Requirements Discovery Endpoint Discovery (R4)

  This web service is only for use alongside the Coverage Requirements Discovery (CRD) service available with Epic's utilization management module for health plans and payers. The Coverage Requirements Discovery Endpoint Discovery API allows a client to discover endpoints and prefetch queries to be used for the CRD service with a health plan or payer using Epic's utilization management module. CRD is based on the CDS Hooks standard . Refer to the documentation for that standard for more information about the CDS Hooks Discovery endpoint this web service implements. For more information about CRD, refer to the implementation guide published by the HL7® FHIR® Da Vinci Project for Coverage Requirements Discovery (STU 2.1) .

• COVID SMART Scheduling Links

  Provides an Epic implementation of the SMART Scheduling Links standard , a lightweight appointment availability publishing API designed to make it easy for organizations to publish COVID vaccine appointment slot availability in cooperation with outside websites, vendors, or government programs. Technical Specifications: COVID SMART Scheduling Links

• Da Vinci Plan Net Provider Directory

  The Da Vinci Plan Net Provider Directory API enables public access to provider directory information, including health insurer's insurance plans, their associated networks, and the organizations and providers that participate in these networks.

• Device, DeviceRequest, DeviceUseStatement

  The Device, DeviceRequest, and DeviceUseStatement resources define data about a patient's implanted and external devices, requests for devices, and information about how those devices are used. Technical Specifications: Device.Read (Implants) (DSTU2) Device.Search (Implants) (DSTU2) Device.Read (Implants and External Devices) (STU3) Device.Search (Implants and External Devices) (STU3) Device.Read (Implants) (R4) Device.Search (Implants) (R4) DeviceRequest.Read (STU3) DeviceRequest.Search (STU3) DeviceRequest.Search (R4) DeviceUseStatement.Read (Implants and External Devices) (STU3) DeviceUseStatement.Search (Implants and External Devices) (STU3) DeviceUseStatement.Read (Implants) (R4) DeviceUseStatement.Search (Implants) (R4) Device.Read (External Devices) (R4) Device.Search (External Devices) (R4) DeviceUseStatement.Read (External Devices) (R4) DeviceUseStatement.Search (External Devices) (R4) DeviceUseStatement.Search (Lines, Drains, Airways) (R4) DeviceUseStatement.Search (LDAs) (STU3) DeviceUseStatement.Read (LDAs) (STU3) DeviceUseStatement.Read (Lines, Drains, Airways) (R4) Device.Search (Lines, Drains, Airways) (R4) Device.Search (LDA) (STU3) Device.Read (Lines, Drains, Airways) (R4) Device.Read (LDA) (STU3) Device.Read (Outside Record) (R4) Device.Search (Outside Record) (R4)

• Device.$auxiliary-function (Auxiliary Function Notification) (R4)

  This web service generates a push notification that represents a task triggered from an auxiliary function. This is currently exclusive to staff duress push notifications, which are created when a user presses a panic button on a Real-Time Location System (RTLS) device and are sent to configured groups of users. The notification tracks who has received or responded to the notification. Staff duress push notifications require third-party RTLS Badges integration with Epic.

• DiagnosticReport

  DiagnosticReport describes the findings associated with a diagnostic laboratory procedure. Technical Specifications: DiagnosticReport.Read (Results) (DSTU2) DiagnosticReport.Search (Results) (DSTU2) DiagnosticReport.Read (Results) (STU3) DiagnosticReport.Search (Results) (STU3) DiagnosticReport.Read (Results) (R4) DiagnosticReport.Search (Results) (R4) DiagnosticReport.Read (Care Plan Goal) (R4) DiagnosticReport.Search (Care Plan Goal) (R4) DiagnosticReport.Read (Care Plan Goal) (STU3) DiagnosticReport.Search (Care Plan Goal) (STU3) DiagnosticReport.Read (Outside Record Results) (R4) DiagnosticReport.Search (Outside Record Results) (R4)

• Document & Image Management

  Manage the ability to retrieve and view images and documents that are stored in a third-party Document Management System (DMS). Through these integrations, users can more easily view documents from Epic without separately opening the DMS.

• DocumentReference

  DocumentReference provides a list of available documents for a patient. CDA documents and clinical notes are examples of documents that this resource may return. Technical Specifications: DocumentReference.Read (Generated CCDA) (DSTU2) DocumentReference.Search (Generated CCDA) (DSTU2) DocumentReference.Read (Clinical Notes) (STU3) DocumentReference.Create (Clinical Notes) (STU3) DocumentReference.Search (Clinical Notes) (STU3) DocumentReference.Create (Clinical Notes) (R4) DocumentReference.Read (Clinical Notes) (R4) DocumentReference.Search (Clinical Notes) (R4) DocumentReference.Read (Document Information) (R4) DocumentReference.Create (Document Information) (R4) DocumentReference.Update (Document Information) (R4) DocumentReference.Read (OASIS) (R4) DocumentReference.Search (OASIS) (R4) DocumentReference.Read (HIS) (R4) DocumentReference.Search (HIS) (R4) DocumentReference.Read (Handoff) (R4) DocumentReference.Search (Handoff) (R4) DocumentReference.Read (Labs) (R4) DocumentReference.Search (Labs) (R4) DocumentReference.Read (External CCDA) (R4) DocumentReference.Search (External CCDA) (R4) DocumentReference.Read (Radiology Results) (R4) DocumentReference.Search (Radiology Results) (R4) DeviceRequest.Read (R4) DocumentReference.Read (Radiology Results) (STU3) DocumentReference.Read (Correspondences) (R4) DocumentReference.Read (Correspondences) (STU3) DocumentReference.Search (Correspondences) (STU3) DocumentReference.Search (Correspondences) (R4) DocumentReference.Search (Radiology Results) (STU3) DocumentReference.Read (Minimum Data Set) (R4) DocumentReference.Search (Minimum Data Set) (R4) DocumentReference.Read (IRF-PAI) (R4) DocumentReference.Search (IRF-PAI) (R4) DocumentReference.Read (Non-Patient Document Information) (R4) DocumentReference.Create (Non-Patient Document Information) (R4) DocumentReference.Search (Document Information) (R4) DocumentReference.Read (Clinical References) (R4) DocumentReference.Search (Clinical References) (R4) DocumentReference.Read (Patient-Entered Questionnaires) (STU3) DocumentReference.Search (Patient-Entered Questionnaires) (STU3) DocumentReference.Read (Patient-Entered Questionnaires) (R4) DocumentReference.Search (Patient-Entered Questionnaires) (R4) DocumentReference.Read (Generated CDAs) (R4) DocumentReference.Search (Non-Patient Document Information) (R4) DocumentReference.Search (Generated CDAs) (R4) Communication.Search (Non-Patient Customer Relationship Management) (R4) Communication.Search (Customer Relationship Management) (R4) DocumentReference.Search (Outside Record - Clinical Notes) (R4) DocumentReference.Read (Outside Record - Clinical Notes) (R4) DocumentReference.Read (Prior Auth Supporting Info) (R4)

• Encoder Interface API

  The GetEncoderMessage and SetEncoderMessage APIs are used to integrate with encoders and computer-assisted coding systems to exchange information for Hospital Coding workflows. Epic offers front-end integrations through web services as well as back-end integration methods. To see the HL7 payload, check out the HL7v2 - Coding-Bidirectional spec .

• Encounter

  The Encounter resource defines the setting where patient care takes place. This includes ambulatory, inpatient, emergency, home health, and virtual encounters. If you want to store upcoming appointment information, use the Appointment resource instead of Encounter. Technical Specifications: Encounter.Read (Patient Chart) (STU3) Encounter.Search (Patient Chart) (STU3) Encounter.Read (Patient Chart) (R4) Encounter.Search (Patient Chart) (R4) Encounter.Search (Outside Record) (R4) Encounter.Read (Outside Record) (R4)

• Endpoint

  The FHIR Endpoint resource describes the technical details of a location that can be connected for the delivery or retrieval of information. The resource contains information on how to connect and for what purposes. This endpoint does not need to be the current system, it can describe locally hosted services, regional services, or national services. Talk to the target organization for their supported protocols when using this resource. Technical Specifications: Endpoint.Read (STU3) Endpoint.Read (R4)

• EpisodeOfCare

  The EpisodeOfCare resource returns information about a patient's episode of care, including the episode type, care team members, diagnoses, and start and end dates. Technical Specifications: EpisodeOfCare.Read (R4) EpisodeOfCare.Search (R4)

• ExplanationOfBenefit

  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. Technical Specifications: ExplanationOfBenefit.Read (Claim) (R4) ExplanationOfBenefit.Search (Claim) (R4)

• ExplanationOfBenefit.Read (Prior Auth) (R4)

  Use this API to retrieve a specific ExplanationOfBenefit (Prior Auth) resource. This resource represents medical benefit prior authorization information, including requests for services or bed day authorizations submitted for a patient. The data returned includes prior authorization requests processed directly by the organization as well as prior authorizations received from external payers through payer data exchange workflows. Data loaded from other FHIR servers is returned in the format the organization received it. Because of this, the documentation below does not apply to these loaded resources. These resources can include any elements from the FHIR specification and can be distinguished from other resources by the presence of meta.tag set to external-bulk-data . When used as part of the CMS Payer-to-Payer API, only approved prior authorizations are returned. In other interoperability scenarios, both approved and denied prior authorizations can be returned.

• ExplanationOfBenefit.Search (Prior Auth) (R4)

  Use this API to search for ExplanationOfBenefit (Prior Auth) resources for a patient. This resource represents medical benefit prior authorization requests and determinations, including both service-based and bed day authorizations. The API can retrieve prior authorizations processed directly by the organization as well as prior authorizations received from external payers through payer data exchange workflows. Data loaded from other FHIR servers is returned in the format the organization received it. Because of this, the documentation below does not apply to these loaded resources. These resources can include any elements from the FHIR specification and can be distinguished from other resources by the presence of meta.tag set to external-bulk-data . When used as part of the CMS Payer-to-Payer API, only approved prior authorizations are returned. In other interoperability scenarios, both approved and denied prior authorizations can be returned.

• FamilyMemberHistory

  FamilyMemberHistory describes the conditions, history, and relationship information of a patient's family members. Technical Specifications: FamilyMemberHistory.Search (DSTU2) FamilyMemberHistory.Read (R4) FamilyMemberHistory.Search (R4)

• Flag

  The Flag resource retrieves patient FYI flags from the patient chart. Patient FYIs are short, free-text notes associated with a patient or with a specific encounter for that patient. Technical Specifications: Flag.Read (Patient FYI) (R4) Flag.Search (Patient FYI) (R4) Flag.Read (Patient FYI) (STU3) Flag.Search (Patient FYI) (STU3) Flag.Search (Isolation) (R4) Flag.Read (Isolation) (R4) Flag.Read (Health Concerns) (R4) Flag.Search (Health Concerns) (R4) Flag.Read (Infection) (R4) Flag.Search (Infection) (R4) Flag.Read (Infection) (STU3) Flag.Search (Infection) (STU3) Flag.Read (Health Concern) (STU3) Flag.Search (Health Concern) (STU3)

• GetDepartmentWaitTimes

• GetProviderWaitTimes

• GetScanSignatureContext

  See Scan Signature Deficiencies on open.epic for further documentation on this resource. This web service returns the complete list of patient encounters that are related to the given encounter for scan signature purposes. This service can also be used to find all the documents a provider has to sign in each encounter so the provider can work on them all at once. Vendors should call this service to get the full list of patient CSNs for which to display documents and signature requirements. This service will search for patient encounters linked to the episode of the CSN and documents with outstanding signature requirements. Outstanding in this case means a provider hasn't completed the document’s signature requirement.

• GetWaitTimes

• Group

  The Group resource represents information about a collection of people or other entities. In Epic workflows, for example, this resource is used to represent an employer group that is part of a health plan. Technical Specifications: Group.Read (Employer Group) (R4) Group.Search (Employer Group) (R4)

• Group.$bulk-member-match File Request

• Group.$bulk-member-match Kickoff

• Group.$bulk-member-match Status Request

• ImagingStudy

  The ImagingStudy resource returns information related to a DICOM imaging study. Technical Specifications: Media.Read (Study) (R4) Binary.Search (Study) (R4) Media.Search (Study) (R4)

• Immunization, ImmunizationRecommendation

  Immunization describes the details of a vaccine administered to a patient. ImmunizationRecommendation is available only to organizations in the Netherlands, and describes which immunizations are recommended for a patient. Technical Specifications: Immunization.Read (DSTU2) Immunization.Search (DSTU2) Immunization.Read (STU3) Immunization.Search (STU3) Immunization.Read (Patient Chart) (R4) Immunization.Search (Patient Chart) (R4) ImmunizationRecommendation.Read (R4) ImmunizationRecommendation.Search (R4) ImmunizationRecommendation.Read (STU3) ImmunizationRecommendation.Search (STU3) Immunization.Read (Outside Record) (R4) Immunization.Search (Outside Record) (R4)

• Incoming FHIR Message Acknowledgement - Denmark

  Receives asynchronous acknowledgement messages in response to any MedCom FHIR messages sent from Epic.

• InitializeDeviceResponse

• International Patient Summary (IPS)

  The International Patient Summary (IPS) is a FHIR document that contains an essential set of healthcare information for a single patient, making it easy for healthcare organizations to exchange clinical data for patient care across borders and jurisdictions. For more information, refer to Epic's International Patient Summary overview and the HL7 specification . Technical Specifications: Patient.$summary (International Patient Summary) (R4)

• Introspect

  The Introspect web service allows an application using OAuth2 secured services to get data associated with an OAuth2 token. One useful function of this service is to allow the client application to determine the user associated with the OAuth2 token. Technical Specifications: Introspect

• List

  The FHIR List resource defines a collection of records that can be used within many places. We support direct reading of the List resource to give access to Patient Lists. Reading is supported for those types of lists and system lists. Technical Specifications: List.Read (Patient List) (STU3) List.Search (Patient List) (STU3) List.Search (Medication List) (R4) List.Read (Medication List) (R4) List.Read (Problems) (R4) List.Search (Problems) (R4) List.Read (Allergies) (R4) List.Search (Allergies) (R4) List.Read (Hospital Problems) (R4) List.Search (Hospital Problems) (R4) List.Read (Family History) (R4) List.Search (Family History) (R4) List.Read (Immunizations) (R4) List.Search (Immunizations) (R4) List.Search (Patient List) (R4) List.Read (Patient List) (R4)

• Location

  The FHIR Location resource defines details and position information for a physical place where resources and participants can be found. Technical Specifications: Location.Read (STU3) Location.Read (Organizational Directory) (R4) Location.Search (Organizational Directory) (R4) Location.Read (Outside Record) (R4) Location.Search (Outside Record) (R4)

• Medication, MedicationOrder, MedicationRequest, MedicationStatement, MedicationDispense

  The Medication, MedicationOrder, MedicationRequest and MedicationStatement data models combine to model a patient's reported and prescribed medication orders and instructions. Medication provides information about each medication, independent of a patient. The MedicationOrder and MedicationRequest resources give a summary of the medication orders placed for the patient along with their status. The MedicationStatement resource gives a full-picture summary of all medications a patient may be taking, whether they are prescriptions or patient-reported medications. The MedicationDispense resource is available only to organizations in the Netherlands, and indicates how a medication product is to be or has been dispensed for a patient. Technical Specifications: Medication.Read (DSTU2) MedicationOrder.Read (DSTU2) MedicationOrder.Search (DSTU2) MedicationStatement.Read (DSTU2) MedicationStatement.Search (DSTU2) Medication.Read (STU3) MedicationRequest.Read (Signed Medication Order) (STU3) MedicationRequest.Search (Signed Medication Order) (STU3) MedicationStatement.Read (STU3) MedicationStatement.Search (STU3) Medication.Search (DSTU2) Medication.Read (Organization Med List) (R4) MedicationRequest.Read (Signed Medication Order) (R4) MedicationRequest.Search (Signed Medication Order) (R4) CDS Hooks MedicationRequest.Create (Unsigned Order) (R4) CDS Hooks MedicationRequest.Create (Unsigned Order) (STU3) CDS Hooks MedicationRequest.Read (Unsigned Order) (R4) Medication.Search (Organization Med List) (R4) MedicationRequest.Read (Order Template Medication) (R4) MedicationRequest.Search (Order Template Medication) (R4) CDS Hooks MedicationRequest.Delete (Unsigned Order) (R4) CDS Hooks MedicationRequest.Delete (Unsigned Order) (STU3) MedicationDispense.Read (Verified Orders) (R4) MedicationDispense.Read (Verified Orders) (STU3) MedicationDispense.Search (Verified Orders) (STU3) MedicationDispense.Search (Verified Orders) (R4) MedicationAdministration.Search (LDAs) (R4) MedicationAdministration.Search (LDAs) (STU3) MedicationAdministration.Read (LDAs) (R4) MedicationAdministration.Read (LDAs) (STU3) MedicationDispense.Search (Fill Status) (R4) MedicationDispense.Read (Fill Status) (R4) MedicationRequest.Update (Prior Auth) (R4) MedicationRequest.Read (Prior Auth) (R4) MedicationRequest.Search (Prior Auth) (R4) MedicationDispense.Read (Outside Record) (R4) MedicationDispense.Search (Outside Record) (R4) MedicationRequest.Read (Outside Record) (R4) MedicationRequest.Search (Outside Record) (R4) Medication.Read (Outside Record) (R4) Medication.Search (Outside Record) (R4)

• NutritionOrder

  NutritionOrder describes diet order data including oral diets, oral nutrition supplements, enteral nutrition (tube feedings), and infant formula. It can also include details about a patient's food allergies, intolerances, and personal/cultural requirements or preferences. Technical Specifications: NutritionOrder.Read (R4) NutritionOrder.Search (R4) NutritionOrder.Read (STU3) NutritionOrder.Search (STU3)

• Observation

  This implementation of the Observation resource supports querying for vital signs, lab results, lines drains and airways (LDA-W), obstetric details, core characteristics, and smoking history. Technical Specifications: Observation.Read (Labs) (DSTU2) Observation.Search (Labs) (DSTU2) Observation.Read (Social History) (DSTU2) Observation.Search (Social History) (DSTU2) Observation.Read (Vitals) (DSTU2) Observation.Search (Vitals) (DSTU2) Observation.Read (Labs) (STU3) Observation.Search (Labs) (STU3) Observation.Create (Vitals) (STU3) Observation.Read (Vitals) (STU3) Observation.Search (Vitals) (STU3) Observation.Read (Core Characteristics) (STU3) Observation.Search (Core Characteristics) (STU3) Observation.Read (Social History) (STU3) Observation.Search (Social History) (STU3) Observation.Create (LDA-W) (STU3) Observation.Read (LDA-W) (STU3) Observation.Search (LDA-W) (STU3) Observation.Update (LDA-W) (STU3) Observation.Create (Lines, Drains, Airways) (R4) Observation.Create (Vital Signs) (R4) Observation.Read (Core Characteristics) (R4) Observation.Read (Lines, Drains, Airways) (R4) Observation.Read (Social History) (R4) Observation.Read (Vital Signs) (R4) Observation.Search (Core Characteristics) (R4) Observation.Search (Lines, Drains, Airways) (R4) Observation.Search (Social History) (R4) Observation.Search (Vital Signs) (R4) Observation.Update (Lines, Drains, Airways) (R4) Observation.Read (Labs) (R4) Observation.Search (Labs) (R4) Observation.Read (Periodontal) (R4) Observation.Search (Periodontal) (R4) Observation.Read (SmartData Elements) (R4) Observation.Search (SmartData Elements) (R4) Observation.Read (Activities of Daily Living) (R4) Observation.Search (Activities of Daily Living) (R4) Observation.Read (Activities of Daily Living) (STU3) Observation.Search (Activities of Daily Living) (STU3) Observation.$lastn (Labs) (STU3) Observation.$lastn (Social History) (STU3) Observation.$lastn (Activities of Daily Living) (STU3) Observation.Read (Study Finding) (R4) Observation.Read (Obstetrics and Gynecology) (R4) Observation.Search (Obstetrics and Gynecology) (R4) Observation.Search (Study Finding) (R4) Observation.Search (Genomics) (R4) Observation.Read (Labor and Delivery) (R4) Observation.Search (Labor and Delivery) (R4) Observation.Read (Genomics) (R4) Observation.Read (Newborn Delivery) (R4) Observation.Search (Newborn Delivery) (R4) Observation.Read (Family Situation) (STU3) Observation.Read (Family Situation) (R4) Observation.Search (Family Situation) (R4) Observation.Search (Family Situation) (STU3) Observation.$lastn (Vitals) (STU3) Observation.Search (Assessments) (R4) Observation.Read (Assessments) (R4) Observation.Search (SDOH Assessments) (R4) Observation.Read (SDOH Assessments) (R4) Observation.Create (DICOM Image Characteristics) (R4) Observation.Update (DICOM Image Characteristics) (R4) Observation.Search (DICOM Image Characteristics) (R4) Observation.Read (DICOM Image Characteristics) (R4) Observation.Search (Phenotype) (R4) Observation.Read (Phenotype) (R4) Observation.Read (Outside Record Sexual Orientation) (R4) Observation.Read (Outside Record Smoking Status) (R4) Observation.Search (Outside Record Results) (R4) Observation.Search (Outside Record Smoking Status) (R4) Observation.Search (Outside Record Sexual Orientation) (R4) Observation.Read (Outside Record Screening Assessment) (R4) Observation.Search (Outside Record Screening Assessment) (R4) Observation.Read (Outside Record Pregnancy Status) (R4) Observation.Search (Outside Record Pregnancy Status) (R4) Observation.Read (Outside Record Vital Signs) (R4) Observation.Search (Outside Record Vital Signs) (R4) Observation.Read (Outside Record Activities of Daily Living) (R4) Observation.Search (Outside Record Activities of Daily Living) (R4) Observation.Read (Outside Record Occupation) (R4) Observation.Search (Outside Record Occupation) (R4) Observation.Read (Outside Record SDOH Assessment) (R4) Observation.Search (Outside Record SDOH Assessment) (R4)

• Organization

  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 Organization or PractitionerRoles through the search interaction. Technical Specifications: Organization.Read (STU3) Organization.Read (Organizational Directory) (R4) Organization.Search (Organizational Directory) (R4) Organization.Read (Outside Record) (R4) Organization.Search (Outside Record) (R4)

• Outgoing Hospital Notification

  Sends hospital notification messages to Danish municipalities. This interface can send ED arrival, admission, discharge, leave of absence, and death notifications. The messages follow the MedComHospitalNotificationMessage profile specifications.

• Outgoing Vital Records Death Reporting

  Automates the death certification process by sending the required medical certifier information for a patient death to state or jurisdictional Vital Records Reporting systems. The interface follows the HL7 Vital Records Death Reporting (VRDR) FHIR Implementation Guide, VRDR 3.0.0, FHIR STU3.

• PAS Incoming Claim Response Notification

  The HL7 FHIR Da Vinci Prior Authorization Support (PAS) STU 2.1 ( https://hl7.org/fhir/us/davinci-pas/STU2.1/ ) functionality is intended to streamline the prior authorization process using a FHIR-based data exchange rather than the previous ANSI X12-based electronic messaging specification as well as to encourage automation throughout the process. Complex prior authorization requests can take some time to adjudicate. When a health plan finishes their adjudication or modifies the request, they shall use the $notify operation to inform the health system. This operation is essentially an asynchronous response to an authorization request using a bundled ClaimResponse resource ( https://hl7.org/fhir/us/davinci-pas/STU2.1/StructureDefinition-profile-pas-response-bundle.html ). While the HL7 specification suggests that a subscription ( https://hl7.org/fhir/us/davinci-pas/STU2.1/specification.html#subscription ) request should first be submitted to initiate this notification process, Epic recommends that health plans should always assume that a subscription is desired when an authorization request has been submitted to improve automation.

• Patient

  This basic FHIR service covers data about persons receiving care or other health-related services. It focuses on the demographic information necessary to support administrative, financial, or logistic purposes. Technical Specifications: Patient.Read (DSTU2) Patient.Search (DSTU2) Patient.Create (STU3) Patient.Read (STU3) Patient.Search (STU3) Patient.Create (Demographics) (R4) Patient.Read (Demographics) (R4) Patient.Search (Demographics) (R4) Patient.$match (Patient Match) (R4)

• Patient Lookup and Identifiers

  Search for patients and obtain or assign identifiers. If no patient can be found for the given criteria, a patient record can be created.

• Personnel Management

  Create, update, and delete user records in Epic. With this suite of services, you can also view and update user groups, pager IDs, user login departments, and departments the user has access to.

• Practitioner, PractitionerRole

  The Practicioner service covers data about providers of care or other health-related services. Technical Specifications: Practitioner.Read (DSTU2) Practitioner.Read (STU3) Practitioner.Search (DSTU2) Practitioner.Search (STU3) PractitionerRole.Read (STU3) PractitionerRole.Search (STU3) Practitioner.Read (Organizational Directory) (R4) Practitioner.Search (Organizational Directory) (R4) PractitionerRole.Read (Organizational Directory) (R4) PractitionerRole.Search (Organizational Directory) (R4) PractitionerRole.Read (Outside Record) (R4) PractitionerRole.Search (Outside Record) (R4) Practitioner.Read (Outside Record) (R4) Practitioner.Search (Outside Record) (R4)

• Print Job Status

  Use the UpdatePrintJobStatus API to send back information about the status of the print job that you received from Epic through Epic Print Service (EPS).

• PrintTestPage

• PrintTestPageToTray

• Procedure, ProcedureRequest, ServiceRequest

  Procedure describes performed surgical, dental, and diagnostic procedures on a patient. ProcedureRequest and ServiceRequest define a request for a procedure to be planned, proposed, or performed. The results of ProcedureRequest and ServiceRequest are available in the Procedure resource or the DiagnosticReport resource. Technical Specifications: Procedure.Read (Orders) (DSTU2) Procedure.Search (Orders) (DSTU2) ProcedureRequest.Read (Orders) (STU3) ProcedureRequest.Search (Orders) (STU3) Procedure.Read (Orders, Surgeries) (STU3) Procedure.Search (Orders, Surgeries) (STU3) Procedure.Read (Orders) (R4) Procedure.Search (Orders) (R4) ServiceRequest.Read (Orders) (R4) ServiceRequest.Search (Orders) (R4) CDS Hooks ServiceRequest.Create (Unsigned Order) (R4) CDS Hooks ProcedureRequest.Create (Unsigned Order) (STU3) ServiceRequest.Read (Dental Procedure) (R4) ServiceRequest.Search (Dental Procedure) (R4) Procedure.Read (Patient-Reported Surgical History) (R4) Procedure.Search (Patient-Reported Surgical History) (R4) CDS Hooks ServiceRequest.Read (Unsigned Order) (R4) Procedure.Read (Surgeries) (R4) Procedure.Search (Surgeries) (R4) ServiceRequest.Read (Community Resource ServiceRequest) (R4) ServiceRequest.Search (Community Resource ServiceRequest) (R4) ServiceRequest.Read (Order Template Procedure) (R4) ServiceRequest.Search (Order Template Procedure) (R4) CDS Hooks ServiceRequest.Delete (Unsigned Order) (R4) CDS Hooks ProcedureRequest.Delete (Unsigned Order) (STU3) ServiceRequest.Read (Referral) (R4) ServiceRequest.Read (Pregnancy Plans) (R4) ServiceRequest.Search (Pregnancy Plans) (R4) Procedure.Read (Surgical History) (STU3) Procedure.Search (Surgical History) (STU3) Procedure.Read (Nursing Intervention) (R4) Procedure.Search (Restricting Intervention) (R4) Procedure.Search (Restricting Intervention) (STU3) Procedure.Read (Restricting Intervention) (R4) Procedure.Read (Restricting Intervention) (STU3) Procedure.Read (Nursing Intervention) (STU3) Procedure.Search (Nursing Intervention) (R4) Procedure.Search (Nursing Intervention) (STU3) CDS Hooks ServiceRequest.Update (Unsigned Order) (R4) CDS Hooks ProcedureRequest.Update (Unsigned Order) (STU3) Procedure.Search (SDOH Intervention) (R4) ServiceRequest.Create (External Radiotherapy Summary) (R4) ServiceRequest.Read (External Radiotherapy Summary) (R4) ServiceRequest.Search (External Radiotherapy Summary) (R4) ServiceRequest.Update (External Radiotherapy Summary) (R4) Procedure.Create (External Radiotherapy Summary) (R4) Procedure.Read (External Radiotherapy Summary) (R4) Procedure.Search (External Radiotherapy Summary) (R4) Procedure.Update (External Radiotherapy Summary) (R4) Procedure.Read (SDOH Intervention) (R4) ServiceRequest.Read (Prior Auth) (R4) ServiceRequest.Search (Prior Auth) (R4) ServiceRequest.Update (Prior Auth) (R4) Procedure.Read (Outside Record) (R4) Procedure.Search (Outside Record) (R4) ServiceRequest.Read (Outside Record) (R4) ServiceRequest.Search (Outside Record) (R4)

• ProcessTransactionResponse

• Provenance

  Provenance returns contextual metadata about the origin of a different resource, such as who authored the data for the target resource, who transmitted it, or which organization such actions were performed on behalf of. Technical Specifications: Provenance.Read (R4)

• Questionnaire, QuestionnaireResponse

  The Questionnaire resource is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. The QuestionnaireResponse resource provides a complete or partial list of answers to a set of questions filled when responding to a questionnaire. Technical Specifications: QuestionnaireResponse.Create (Patient-Entered Questionnaires) (R4) QuestionnaireResponse.Read (Patient-Entered Questionnaires) (R4) Questionnaire.Read (Patient-Entered Questionnaires) (R4) Questionnaire.Search (Patient-Entered Questionnaires) (R4) QuestionnaireResponse.Read (Code Status Questionnaire) (R4) QuestionnaireResponse.Read (Prior Auth) (R4) QuestionnaireResponse.Read (Outside Record) (R4) QuestionnaireResponse.Search (Outside Record) (R4)

• Questionnaire.$log-questionnaire-errors (R4)

  The Questionnaire.$log-questionnaire-errors operation allows a client to report errors encountered while rendering or processing a DTR questionnaire. The request identifies the questionnaire using its canonical URL. The server validates the canonical, resolves the appropriate downstream endpoint based on that canonical, and forwards the request to that endpoint for processing. This implementation does not interpret or process the reported error details locally. Any additional parameters (such as an operationOutcome describing the errors) are forwarded to the resolved downstream endpoint without modification. If the questionnaire canonical cannot be validated or resolved to a downstream endpoint, the operation returns an OperationOutcome describing the failure. On successful resolution, the downstream endpoint’s response is returned unchanged. Refer to Operation Definition of $log-questionnaire-errors v2.1.0 and Structure Definition of dtr-log-errors-input-parameters v2.1.0 for more information.

• Questionnaire.$next-question (R4)

  The Questionnaire.$next-question operation supports adaptive (dynamic) questionnaires by enabling a client to request the next set of questions based on the answers collected so far. The client sends a FHIR Parameters resource containing a single input parameter named "in", whose value is a QuestionnaireResponse representing the current questionnaire state. The QuestionnaireResponse includes the Questionnaire definition as a contained resource and any answers gathered up to that point. The server evaluates the adaptive logic and returns a FHIR Parameters resource containing a single output parameter named "out", whose value is an updated QuestionnaireResponse. The returned QuestionnaireResponse preserves previously provided answers and updates the contained Questionnaire to include the next question(s) the client should present. This operation is typically called repeatedly in a loop: The client submits the current QuestionnaireResponse. The server returns the next question(s). The client collects answers and resubmits. This cycle repeats until the server returns a QuestionnaireResponse with status = complete. If the input is invalid or incomplete, the server returns an OperationOutcome describing the issue. Refer to Operation Definition of DTR Questionnaire $next-question v2.1.0 , Structure Definition of dtr-next-question-input-parameters v2.1.0 , and Structure Definition of dtr-next-question-output-parameters v2.1.0 for more information.

• Questionnaire.$questionnaire-package (R4)

  The HL7 FHIR Da Vinci Documentation Templates and Rules (DTR) STU 2.1 ( https://hl7.org/fhir/us/davinci-dtr/STU2.1/ ) enables health plans to express their documentation requirements for prior authorizations and to allow health systems to gather and submit that information in a streamlined manner.  When a health plan responds to a CRD ( https://hl7.org/fhir/us/davinci-crd/STU2.1/ ) or PAS ( https://hl7.org/fhir/us/davinci-pas/STU2.1/ ) message indicating that clinical or administrative data is required, and optionally includes a canonical questionnaire, the health system performs a $questionnaire-package operation ( https://hl7.org/fhir/us/davinci-dtr/STU2.1/OperationDefinition-questionnaire-package.html ).  Health systems use the $questionnaire-package operation ( https://hl7.org/fhir/us/davinci-dtr/STU2.1/StructureDefinition-dtr-qpackage-input-parameters.html ) to retrieve a DTR Standard Questionnaire resource ( https://hl7.org/fhir/us/davinci-dtr/STU2.1/StructureDefinition-dtr-std-questionnaire.html ) from the output ( https://hl7.org/fhir/us/davinci-dtr/STU2.1/StructureDefinition-dtr-qpackage-output-parameters.html ), which is shown to an appropriate user.  The health system then builds a QuestionnaireResponse resource from the answered questionnaire and sends it to the health plan as part of the PAS request process.

• RelatedPerson

  The FHIR RelatedPerson resource is typically an entity with a personal or professional relationship to the patient. RelatedPersons are often a source of information about the patient. For integrations with Epic, the RelatedPerson is represented by a MyChart account record ID and their link to a Patient record ID. Typically the RelatedPerson represents a MyChart proxy for the patient. Technical Specifications: RelatedPerson.Read (Proxy) (R4) RelatedPerson.Read (Friends and Family) (R4) RelatedPerson.Search (Proxy) (R4) RelatedPerson.Search (Friends and Family) (R4) RelatedPerson.Read (Outside Record) (R4) RelatedPerson.Search (Outside Record) (R4)

• Release of Information

  Create and update release of information (ROI) requests.

• RequestGroup

  A RequestGroup represents a group of related requests, such as MedicationRequest or ServiceRequest resources, that can be used to capture intended activities that have inter-dependencies such as "give this medication after that one". Technical Specifications: RequestGroup.Read (Dental Visit) (R4) RequestGroup.Read (Oncology Plan Day) (R4) RequestGroup.Search (Oncology Plan Day) (R4) RequestGroup.Search (Dental Visit) (R4) QuestionnaireResponse.Search (Patient-Entered Questionnaires) (R4)

• ResearchStudy

  The ResearchStudy resource includes general information about the research studies tracked in Epic, including the title, status, identifier, and principal investigator. These studies focus on the safety, efficacy, comparative effectiveness, and other information about medications, devices, therapies, and other intervention and investigative techniques intended to increase the field of healthcare-related knowledge. Technical Specifications: ResearchStudy.Read (R4) ResearchStudy.Search (R4)

• ResearchSubject

  The ResearchSubject resource includes general information about a research subject tracked in Epic, including the study, study arm, consent status, and other key items. Epic tracks human beings only for research associations. Technical Specifications: ResearchSubject.Read (R4) ResearchSubject.Search (R4)

• Scan Signature Deficiencies

  When using a document management system (DMS) to manage scans on a patient's chart, it's also possible to track signature requirements for those scans in Epic. DMS applications can use these web services to create and update signature deficiencies in Epic. These signature deficiencies will notify the signing users and let them launch directly into the DMS's signing application.

• Security Information and Event Management (SIEM)

  Receive event and access information from Epic to detect security incidents.

• Specimen

  The specimen resource covers substances used for diagnostic and environmental testing. The specimen resource focuses on the process for gathering, maintaining and processing the specimen as well as where the specimen originated. Technical Specifications: Specimen.Read (Patient Chart) (R4) Specimen.Search (Patient Chart) (R4) Specimen.Read (STU3) Specimen.Search (STU3) Specimen.Read (Outside Record) (R4) Specimen.Search (Outside Record) (R4)

• Substance

  Substance returns basic information about a substance, such as the code or set of codes that identify the substance. For example, this resource can describe an electrolyte ion component of a total parenteral nutrition (TPN) medication. Technical Specifications: Substance.Read (R4) Substance.Search (R4)

• Task

  The Task resource describes activities and tracks the completion state of those activities. It includes details such as the description of the task, the patient to whom it applies, who is expected to perform the task, and the task’s status. This resource can be used to track tasks associated with referral requests made through continued care and services workflows in Epic, such as a post-discharge service request for durable medical equipment (DME) or social services. Technical Specifications: Task.Read (Community Resource) (R4) Task.Search (Community Resource) (R4) Task.Update (Community Resource) (R4) Task.Read (Episode Checklist) (R4) Task.Search (Episode Checklist) (R4) Task.Search (Auxiliary Function Notification) (R4) Task.Read (Auxiliary Function Notification) (R4)

• UpdateUserDemographics

• Utilization Management

  The CriteriaReview web service retrieves data from a criteria review record. A ReviewCollection groups together CriteriaReview resources that have been created for a patient previously.

• ValueSet

  The ValueSet resource represents a subset of the codes in a code system that is supported by a given server. The $expand operation of the ValueSet resource can be used by a FHIR API consumer to determine what values to expect back from the server as a result of a Read or Search operation and what values they can pass in to the server when performing a Create or Update operation. Technical Specifications: ValueSet.$expand (Supported Codes) (R4)

• ValueSet.$expand (DTR Payer Guidelines) (R4)

  The ValueSet resource represents a subset of the codes in a code system that is supported by a given server. The DTR (Documentation Templates and Rules) $expand operation of the ValueSet resource can be used to dynamically expand value sets referenced in DTR questionnaires, providing a simple collection of codes suitable for use for data entry or validation within documentation requirement workflows. It is important that this is the endpoint used to fetch ValueSets from references that come through during CRD/DTR/PAS related workflows. The DTR $expand operation response represents a single ValueSet resource, or an OperationOutcome with an error message. DTR value set expansion only supports querying the ValueSet.$expand operation at the resource type level.

In some cases, we've found that standards didn't exist, weren't sufficient, or were too complicated technically for our customers' use cases. In those cases, we've developed purpose-built Epic-specific web services to serve those needs. All web services require a client ID to identify the calling application as part of the Epic authorization framework. When you are ready to use the web services listed below with an Epic customer, review Creating, Activating, and Licensing an App to create a new client ID. Then submit an email request to have these web services added to your app. You may apply to Vendor Services for access to a sandbox or to receive Epic support for these Web Services.

• Encoder Interface API

  The GetEncoderMessage and SetEncoderMessage APIs are used to integrate with encoders and computer-assisted coding systems to exchange information for Hospital Coding workflows. Epic offers front-end integrations through web services as well as back-end integration methods. To see the HL7 payload, check out the HL7v2 - Coding-Bidirectional spec .

• Patient Lookup and Identifiers

  Search for patients and obtain or assign identifiers. If no patient can be found for the given criteria, a patient record can be created.

• Personnel Management

  Create, update, and delete user records in Epic. With this suite of services, you can also view and update user groups, pager IDs, user login departments, and departments the user has access to.

• Phone System Pause/Resume

  When collecting credit card payments over the phone, you may not want the credit card number (as read by the patient) to be contained in the customer service recording files. This web service can be setup to send a request to the phone system to pause the recording when the staff's credit card entry form opens, and send another request to the phone system to resume the recording when the credit card form closes.

• Print Job Status

  Use the UpdatePrintJobStatus API to send back information about the status of the print job that you received from Epic through Epic Print Service (EPS).

• Release of Information

  Create and update release of information (ROI) requests.

• Utilization Management

  The CriteriaReview web service retrieves data from a criteria review record. A ReviewCollection groups together CriteriaReview resources that have been created for a patient previously.

• Scan Signature Deficiencies

  When using a document management system (DMS) to manage scans on a patient's chart, it's also possible to track signature requirements for those scans in Epic. DMS applications can use these web services to create and update signature deficiencies in Epic. These signature deficiencies will notify the signing users and let them launch directly into the DMS's signing application.

• Outgoing SMS

  You may want to send text messages to patients or proxies for a variety of reasons, such as to remind them of upcoming appointments or surgeries, send notifications about their MyChart account, or update visitors about a patient’s surgery. Epic’s SMS (Short Message Service) web service enables you to pass a phone number and simple message data to a SMS web service vendor, which will send a text message directly to a patient’s mobile phone over a cellular network.

• MyChart Bedside MDM Patient Data Wipe

  Epic sends requests to Mobile Device Management (MDM) vendors so they can wipe data corresponding to discharge and/or transfer workflows. The requests include an MDM-managed device's identifier to the MDM vendor's endpoint so that the MDM vendor can then clear data from the device remotely.

• Embedded Context-Aware Linking for Epic Monitor

  Epic's Remote Sitter solution allows organizations to engage in continuous video surveillance of multiple patients (typically 12 a time), be it for COVID, fall risk, or behavioral disorders. It’s a grid of videos embedded in our Epic Monitor platform and surrounded with contextual information from the EMR. Our plan is to embed web browser controls, each containing a CAL video feed, so that customers can engage with any video vendor on Vendor Services. We call it ECAL (Embedded CAL).

• Enterprise Image Access

  This web integration API provides the ability to generate dynamic, secure, contextual links used to launch the appropriate context in an enterprise image viewer. You can use our simple testing harness to help you validate that your web application can be successfully embedded.

• Content Linking

  The patient portal provides patients with a view into the medical chart maintained by their healthcare organization. This information can be supplemented by educational materials that are specific to a patient's problems, medications, and other information. This functionality is called Content Linking. While many approaches have been used to achieve this integration in the past, Epic recommends that new organizations use the Infobutton APIs as they are implemented through the National Library of Medicine and MedlinePlus .

• E-Signature

  Epic's kiosk software can be used to collect signatures for consent or other purposes. These signatures can then be sent to an external document management system. The kiosk sends an image of the signature to the document management system, which in turn creates a reference to the signature document within the EHR.

• Credit Card and Bank Account Integration

  Epic provides support for credit cards to be used with the Epic system to pay copays, hospital and outpatient bills, and for medications. This integration is handled through credit card gateway systems, which send payment data to processing services that verify the payments with appropriate banks. The gateway then sends the verified payment information back to the Epic system to post the payment. This integration is handled through the patient portal and patient kiosk software as well as in over-the-phone and billing-office use cases. Epic software for credit card processing follows the PA-DSS requirements in its development.

• Tapestry Document Linker DMS Integration

  This web service allows third-party DMS vendors to launch activities within a pre-existing Hyperspace instance to link documents to records in Epic such as claims or coverages. Information about the document in the third-party database will be populated in the activity launched, and users can complete the linking workflow from the Hyperspace session. The web service can also launch a new Hyperspace instance if one is not open when the web service is called.

• Credit Card and Check Scanning Device Integration

  In addition to the Credit Card and Bank Account Integration specification, Epic provides separate and additional support for non-keyboard emulation credit card devices. This integration is handled through an interface between Epic and your gateway software. The gateway software integrates with the device and provides Epic with transaction results for the credit card payment. This integration is handled through the patient kiosk and by front desk personnel during check-in or check-out. This interface is supplemental to the generic credit card interface described above and should be implemented in addition to that interface if you want to provide support for EMV devices.

• Incoming Computer-Telephony Integration

  Epic integrates with your organization’s phone system to automatically open the appropriate chart or another activity in Epic when calls are received.

• Outgoing Computer-Telephony Integration

  Epic integrates with your organization’s phone system so users can place or end a call directly from a patient chart or another activity in Epic, and details about the call are logged. Your phone system can also update Epic with the call identifier after the call.

• Outbound Fax Services with Epic Print Service

  Epic integrates with fax management systems using the outbound faxing web service. This web service allows Epic community members to fax documents generated by various applications from their instance of Epic, and receive back information about whether the transmission was successful.

• SAML 2.0 Reauthentication for Haiku and Canto EPCS

  Haiku and Canto, Epic's mobile apps for physicians on iOS and Android devices, support launching a web portal during e-prescribing controlled substances (EPCS) to verify the physician's identity with an EPCS-qualified identity provider (IdP). The IdP returns a valid SAML assertion to Haiku or Canto, which allows the physician to continue placing orders. This process follows the SP-initiated Web Browser SSO profile defined in the OASIS SAML 2.0 specification. The workflow is also supported in Rover, Epic's mobile app for nurses, on iOS devices only.

• Binary Data Retrieval

  This web integration enables Epic to request image and document files from an external system. Epic will then display these images inline within the user's workflow.

• Outgoing MDS Data for MDS Scrubbers

  The Minimum Data Set (MDS) scrubber interface allows MDS coordinators to send in-progress and completed MDS assessments electronically to a 3rd-party MDS scrubbing vendor and receive real-time feedback.

• EPS Document Retrieval Web Service

  This web service integration enables Epic print services (EPS) to query a document management system (DMS) for images or documents to insert into a print job. This is useful when you want a scan to be stored in your DMS, but want to include that scan in something you print.

• Wait Time APIs

  This set of APIs returns estimated wait time information. Select the appropriate API to retrieve wait time information for a given emergency department, urgent care clinic, ambulatory clinic, or outpatient provider.

• Print Test Page

  Use the PrintTestPage API to trigger test print jobs from a specified printer device.

• Output Management Web Service

  Epic integrates with third-party output management systems using the outbound print job web services. These web services allow Epic community members to send print requests to a third-party output management server and receive back information about whether the print job was successful.

• Encryption Guide

  PACS integrations use encryption to protect confidential information sent between systems. This guide describes the technical details of Epic’s supported encryption algorithms, including step-by-step instructions and sample encrypted payloads.

• Tapestry Generic Code Editor

  Bi-directional claim code editing integration with Tapestry

• Disassociate Mobile Device

  Use the DisassociateMobileDevice API to disassociate a mobile device from the server using its Install ID. After disassociation, the device no longer receives push notifications or VoIP calls, and users on shared devices no longer receive notifications from previously logged-in users.

Standards developed by Digital Imaging and Communications are used internationally for communicating medical images and related information. You can learn more from DICOM .

• Imaging Integration

  Epic has APIs available for PACS integration that include single sign-on, patient context synchronization, study context synchronization, and real-time measurement exchange. These APIs have been implemented to varying degrees across PACS and CPACS vendors. Check out our DICOM conformance statement as well. We additionally have an encryption utility for use with our XML integration (identical to URL encryption).

• MWL (Modality Work List)

  This DICOM interface enables a piece of imaging equipment to obtain details of patients and scheduled examinations electronically, avoiding the need to type such information multiple times.

• MPPS (Modality Performed Procedure Step)

  This DICOM interface provides a mechanism for modalities to send the procedure start and procedure complete notification.

• SR (Structured Reporting)

  This DICOM interface provides a mechanism for modalities to send structured information from the performed exam to Epic. Each modality or exam can send different measurements.

• SC (Secondary Capture)

  This DICOM interface provides a mechanism for modalities or a PACS to forward a copy of the DICOM SC images flagged by the technologist to Epic. We can process this message and file the image to be used when reviewing the patient's chart.

• WADO (Web Access to DICOM Objects) Import of Key Objects

  This DICOM interface pulls key objects from the PACS via WADO to support streamlined workflows throughout the EHR.

The National Council for Prescription Drug Programs develops standards related to the real-time exchange of information about pharmacy services. You can learn more from NCPDP .

• Outgoing Medication History for Populations Request and Response

  Performs queries to get the medication dispense history for registries of patients to assist in tracking patients' medication adherence.

• Incoming External Paid Pharmacy Claims Interface

  Loads external paid pharmacy claims messages into Epic Payer Platform or Tapestry, Epic's managed care application, using flag files in the NCPDP Post-Adjudication format.

• Outgoing Prescription Prior Authorization Request and Reponse

  Supports message events necessary for a prescribing provider to request an electronic prior authorization for a medication order and receive either approval or denial from a Pharmacy Benefits Manager, and supports messages to cancel requests. These interfaces for electronic prior authorization support a subset of the NCPDP standard.

• Outgoing Prescription Information from Prescriber to Pharmacies

  Used for e-prescribing when the organization is the prescriber. Uses NCPDP SCRIPT 10.6,2017071,2023011 to send new prescriptions, renewal responses, cancel requests, and change responses with an external pharmacy. Previously known as Outgong Medication Orders to Retail Pharmacies.

• Incoming Prescription Information from Pharmacies to Prescriber

  Uses NCPDP SCRIPT 10.6 or 2017071 to receive renewal requests, cancel responses, and change requests from external pharmacies.

• Outgoing Medication Dispense History Query

  E-prescribing functionality when Epic is the prescriber. Uses NCPDP SCRIPT 10.6, 2017071,2023011 to receive medication history information from external sources.

• Incoming Prescription Information from Prescribers to Pharmacy

  Uses NCPDP SCRIPT to receive new prescriptions, renewal responses, and cancel requests from external providers into Epic's ambulatory pharmacy product.

• Outgoing Prescription Information from Pharmacy to Prescribers

  E-prescribing functionality when Epic is the Pharmacy. Uses NCPDP SCRIPT 10.6,2017071,2023011 to send renewal requests and cancel responses to external providers from Willow Ambulatory.

• Outgoing Pharmacy Update from Willow Ambulatory to E-Prescribing System Interface

  Sends messages to an e-prescribing system to change e-prescribing related settings of an ambulatory pharmacy, such as service levels or operating mode.

• Outgoing Provider Download to E-Prescribing System Interface

  Queries an external e-prescribing system for current and updated e-prescribing provider data.

• Outgoing Organization Download to E-Prescribing System

  Queries an external e-prescribing system for current and updated e-prescribing pharmacy data.

• Outgoing Provider Update to E-Prescribing System Interface

  Sends messages to an e-prescribing system when changes to e-prescribing related settings are made to provider's record, such as service levels or contact information.

• Outgoing Formulary Query to e-Prescribing System

  Downloads NCPDP Formulary & Benefit files from an external source to provide formulary information to the provider during order entry.

• Outgoing Pharmacy Benefit Claims Adjudication Query

  This real-time interface is used to determine what portion of a prescription's cost will be paid by the patient's insurance so that the patient can be charged appropriately for the prescription fill. Claim Adjudication uses NCPDP Telecommunication version D.0.

ASC X12 standards are used for facilitating electronic interchange relating to business processes, in both healthcare and other industries. You can learn more from ASC X12 .

• Incoming Healthcare Claim Repricing Request (X12 837)

  Tapestry receives incoming claim repricing requests through ANSI ASC X12 837 transactions.

• Incoming External Paid Medical Claims (X12 837)

  Loads external paid medical claims messages into Epic Payer Platform, using flat files in the 837 format.

• Incoming Pharmacy Price Sales Catalog to Willow Inventory Interface

  Updates purchase contract records with up-to-date pricing and supplier item ID information.

• Outgoing Additional Information to Support a Health Care Services Authorization

  Used in conjunction with an Outgoing Authorization Request for Review - 278R, provides supporting clinical documentation for the request. Follows ANSI X12 specification 005010X211, ANSI X12 275 for Authorization, Additional Information to Support a Health Care Services Review (275)

• Incoming Claim File Acknowledgment Interface – 999

  This incoming interface loads claim file acknowledgment responses using industry standard ANSI ASC X12N 999 transactions.

• Outgoing Authorization Request as Notification (X12 278R)

  Sends authorization decisions for covered patient referrals to third-party AP claims systems using the 278R format rather than 278N. Required by Texas Medicaid.

• Tapestry Incoming Marketplace Benefit Enrollment and Maintenance

  Receives eligibility information to create, term, and update Marketplace coverage information.

• Tapestry Incoming Marketplace Premium Payment Information

  Receives and processes premium payments associated with Marketplace coverages in Epic

• Tapestry Outgoing Marketplace Benefit Enrollment and Maintenance

  Sends marketplace coverage enrollment information government agencies or other entities.

• Tapestry Incoming Referral Transfer Attachment (X12 275)

  Receives electronic attachments and links them to Tapestry claims.

• Incoming Additional Information to Support a Health Care Services Review - 275

  Used in conjunction with an Incoming Referral Request for Review - 278R, provides supporting documents for the referral request. Follows ANSI X12 Specification 005010X211, ANSI X12 275 for Authorization, Additional Information to Support a Health Care Services Review.

• Outgoing Additional Information for Health Care Claim (X12 275)

  Sends additional information to support a Healthcare Claim from Epic's billing module, Resolute

• Tapestry Outgoing Healthcare Claim: Dental (X12 837)

  Sends dental claim information to payers. The 837 transmits claim information either for the purpose of payment, such as a provider sending a bill to a payer, or for the purpose of reporting, such as a delegated risk payer sending payment information to a health plan or the government.

• Outgoing Pharmacy Purchase Order from Willow Inventory

  Sends medication purchase order requests to a supplier. The interface uses the ANSI X12 850 transaction set or GS1 for the request.

• Incoming Pharmacy Purchase Order Invoice to Willow Inventory

  Receives invoices from a supplier for purchase orders placed in Willow Inventory, Epic's medication inventory management system. The interface uses the ANSI X12 810 transaction set for the response.

• Outgoing Healthcare Claim: Professional (X12 837 Batch)

  Sends professional claim information to payers. The 837 transmits claim information either for the purpose of payment, such as a provider sending a bill to a payer, or for the purpose of reporting, such as a delegated risk payer sending payment information to a health plan or the government.

• Incoming Healthcare Claim: Professional (X12 837)

  Tapestry receives incoming professional, institutional, or dental claims through ANSI ASC X12 837 transactions. Standard version is batch with a real time option in upcoming version.

• Outgoing Healthcare Claim Payment/Advice (X12 835)

  Sends claim payment and remittance information to health care providers. The 835 lets providers know which claims are paid and whether there is any difference between the payment amount and the billed amount. This is a batch interface, with a real time option available in an upcoming version.

• Incoming Benefit Enrollment and Maintenance (X12 834)

  Receives enrollment information from employers or other sponsors of coverage. Health plans and employers send 834s to inform a payer about members who are being enrolled in the payer's insurance plan or for whom the payer is otherwise taking on risk.

• Incoming Claim Status Inquiry (X12 276/277)

  Receives requests from health care providers for status information about claims, including whether the claim was paid or unpaid and why. Tapestry supports the batch interface by default, with a real-time interface available. Returns response (X12 277).

• Incoming Payment Order/Remittance Advice (X12 820 Batch)

  Receives payment and remittance information. Tapestry supports an incoming 820 for the purpose of posting payment information against premium billing accounts.

• Outgoing Benefit Enrollment and Maintenance (X12 834)

  Sends enrollment information to health plans, government agencies, or other entities. Payers send 834s for reporting purposes to list all members for whom they have taken on risk.

• Incoming Eligibility Verification Query (X12 270/271)

  Receives requests from health care providers for member eligibility and benefits information in the form of a 270, and sends a response in the form of a 271. This is a real-time interface.

• Incoming Referral Request for Review (X12 278R)

  Receives a referral request from a provider or provider group so that Epic's managed care system can perform utilization management and approve or deny the service request. A response message is sent to inform the provider of the authorization decision.

• Outgoing Unsolcited Healthcare Claim Pending Status Notification (X12 277P)

  Sends information to a health care provider about the status of all non-finalized claims received from that provider. The 277P is an unsolicited message that is similar to the 277 response to the 276. It is sent so that the provider doesn't have to continually send 276 requests to the payer.

• Incoming Authorization Notification (X12 278N)

  Receives unsolicited, completed referral information (usually with authorization numbers) from an external utilization management system so that Epic' Managed Care system can pay Accounts Payable (AP) claims. Sends an acknowledgment of the receipt of the information (or errors if any occur during message processing).

• Tapestry Incoming Referral Transfer Attachment (X12 275)

  Receives electronic attachments and links them to claims in Epic's managed care product, Tapestry.

• Outgoing Eligibility Verification Query (X12 270/271)

  Used to verify eligibility with clearinghouses and payers. Uses ANSI X12 270/271 transactions.

• Outgoing Claims Status Request (X12 276/277)

  Sends requests and receives responses from payers and intermediary systems about claim statuses using industry standard ANSI ASC X12N 276/277 transactions. Epic uses web services to send and receive the X12 messages.

• Outgoing Authorization Request for Review and Response (X12 278R)

  Transmits patient referral or authorization information to a third-party system. The referral/authorization information is sent in order to obtain authorization for health care services (such as specialty referrals and procedures) with clearing houses and payers. It uses ANSI X12 278 transactions.

• Outgoing Pharmacy Benefit Eligibility Query - 270/271

  E-Prescribing functionality when Epic is the Prescriber. Initiates pharmacy benefit eligibility queries.

• Outgoing Admission Notification (X12 278)

  Used to notify a payer or health plan about an admission for one of their covered a patients. The ANSI X12 278 transaction is used for both the original notification of the admission and the payer response that might follow. Such a response might contain the reference/authorization number to be sent later on the claim.

• Outgoing Authorization Notification (X12 278N)

  Sends authorization decisions for covered patient referrals to third-party AP claims systems. The response from the third-party AP claims system is the acknowledgement of the information received.

• Incoming Purchase Order Acknowledgement to Willow Inventory

  Receives acknowledgements from a supplier for purchase orders placed in Willow Inventory. The interface uses the ANSI X12 855 transaction set for the response.

• Incoming Shipment Notification to Willow Inventory

  Receives information about items sent by a supplier to fill a purchase order from Willow Inventory medication inventory management. This interface uses the ANSI X12 856 transaction set or European GS1.

• Outgoing Health Care Claims for Institutional, Professional, and Dental Services

  This outgoing batch interface sends insurance claim information to payers and intermediary systems using industry standard ANSI ASC X12N 837 transactions (institutional, professional and dental).

• Outgoing Health Care Data Reporting Claims

  This outgoing batch interface sends insurance claim information to government and intermediary systems using the industry standard ANSI ASC X12N 837 data reporting transaction.

• Rapid Retest

  This bi-directional interface builds upon the use of standard Claim Reconciliation and sends individual claims to intermediary systems using industry standard ANSI ASC X12N 837 transactions (institutional, professional, and dental) and loads information about claim status back using industry standard ANSI ASC X12N 277CA transactions. This interface updates the status of errored claims in the system.

• Incoming Health Care Claim Payment/Advice

  This incoming batch interface posts insurance claim payment information received directly from payers and content aggregators, such as claims clearinghouses and banks, using standard ANSI ASC X12N 835 transactions.

• Outgoing Health Care Claim Acknowledgement

  This outgoing batch interface sends claim acknowledgement responses to incoming ANSI 837 files using ANSI ASC X12N 277CA transactions.

• Tapestry Outgoing X12 Acknowledgment (X12 999)

  This message is sent in response to incoming healthcare services messages. It acknowledges the receipt of the message and, if necessary, reports any formatting errors in the file. It is an ANSI ASC X12N 999 transaction.

• Tapestry Outgoing Front-End Claim Status Acknowledgment (X12 277CA)

  Tapestry Outgoing Front-End Claim Status Acknowledgment (X12 277CA).

• Incoming Marketplace Benefit Enrollment and Maintenance (HIX 834)

  Standard X12 format for loading marketplace information.

• Incoming X12 HIX 820

  Incoming Standard X12 format for loading Marketplace Premium Payment Information.

• Tapestry Outgoing Marketplace Benefit Enrollment (X12 834)

  Standard X12 format for sending out marketplace coverage information

• Outgoing Authorization Inquiry (X12 278I)

  Provides the ability to inquire about the status of an existing authorization request. It uses ANSI X12 278 transactions and is used in conjunction with an Outgoing Authorization Request for Review - Outgoing Request (X12 278R) interface.

• Incoming Claim Status Batch (X12 277)

  This incoming batch interface loads information about claim acknowledgments using industry standard ANSI ASC X12N 277CA transactions. This interface can update the status of claims in the system and is able to load claim error information from payer and intermediary systems.

• X12 278 Endpoint Specifications

  Describes JSON Wrapped RESTful endpoint for sending and receiving X12 278 interface messages.

• Payer Platform Outgoing Claims Status Request (X12 276/277)

  Sends requests and receives responses from payers and intermediary systems about claim statuses using industry standard ANSI ASC X12N 276/277 transactions. Epic uses web services to send and receive the X12 messages.

But wait! There's more! We've also created custom integrations using the following approaches.

• Outgoing Real Time Prescription Benefit Inquiry and Response

  Supports real-time prescription benefits checking (RTPB) during the prescriber ordering process. This feature lets prescribers see expected out-of-pocket costs, lower-cost medication suggestions, and whether additional approvals from the insurance company are needed before the prescription can be filled. Providers can share this information with patients before sending the order to the pharmacy, saving time and money for patients, and help improve medication adherence. Payers and vendors interested in joining the RTPB network can request more information by submitting an Interoperability Request .

• Outgoing Newborn Personal Identity Code Request and Response

  The Outgoing Newborn Personal Identity Code Request interface sends notifications of patient birth to the Population Register Centre (VRK) in Finland. The Incoming Newborn Personal Identity Code Response interface receives the response message from VRK that contains the HETU for the newborn and assigns the HETU to the patient in Epic.

• Outgoing Death Notification and Response

  Sends notifications of patient death to the Population Register Centre in Finland.

• Outgoing Provider Query

  This XML interface queries the Terhikki provider database to determine whether a provider has specific rights and restrictions. The rights and restrictions associated with a provider are used to determine which features in Epic the provider has access to.

• Outgoing eArchive Documents and Query

  Queries the Kanta eArchive system for document metadata and content and sends new and updated documents to Kanta eArchive. Licensing for this interface includes the Outgoing eArchive Document Query interface.

• Outgoing Demographics Query

  Queries the Population Register Centre (VRK) in Finland for a patient's demographics or the patient's HETU.

• Outgoing QRDA Documents

  Users can create QRDA Idocuments from data in their Epic EHR. Each QRDA I document is specific to one patient and contains data pertinent to quality measure reporting. Each QRDA III document includes aggregated quality measurement data for a provider or group of providers, including the quality measures they are reporting on and their performance rate. QRDA III documents are typically used by providers for quality measure submission. Many regulatory programs, including Meaningful Use, Core Measures, Inpatient Quality Reporting, ORYX Performance Measurement Reporting, and PQRS, accept QRDA documents to satisfy their quality reporting requirements.

• Bidirectional Referrals

  This pair of interfaces sends and receives referral and consultation requests, along with triage details and care summaries regarding those referrals. These messages are structured according to the HL7-Finland PikaXML standard.

• Outgoing Document Notification Interface - Finland

  Sends document metadata to Navitas when Navitas queries Epic for a document ID.

• Outgoing Social Care Document Query

  This XML interface queries the Kanta Social Care system for document metadata and content.

• Outgoing Dental Summary Interface - Singapore

  Sends a PDF report summarizing the patient's dental health. Requires Wisdom, Epic's dental product.

• Outgoing Referral and Provider Communication Notification Interface - Singapore

  Sends a notification to the National Electronic Health Record (NEHR) when referrals are entered in Epic or provider communications are written in the Communication Management activity in Epic.

• Outgoing Demographics Query Interface - Singapore

  Queries the National Electronic Health Record (NEHR) system in Singapore for a patient's demographics information.

• Outgoing Transaction Notification Interface - Belgium

  Sends metadata for notes, letters, results, and scans to the Belgian National Hub. This process allows the Hub to index references to the source content for external providers to request.

• Outgoing Transaction Query Interface - Belgium

  Interface for Belgium. A collection of web services invoked from the Chart Review activity that retrieve a list of documents for a patient from the National Hub and request the contents of specific documentation.

• Outgoing Birth Notification and Medical Form Interface - Belgium

  Sends birth notifications and birth-related medical forms to Belgium's eBirth registry according to the specifications in the eBirth Hospital Web Services Technical User Guide - Final version - 1.6 – 12/05/2016.

• Outgoing Medication Orders Request and Response Interface - Belgium

  Interface for Belgium. Sends e-prescribing messages to, and receives acknowledgements from, Recip-e. These interfaces can be used to create new prescriptions, cancel prescriptions, and query for a list of prescriptions that a pharmacy can dispense.

• Outgoing Social Care Need Query Interface - Finland

  Queries the eTotu Social Services system for patient referrals and documents.

• Outgoing Financial Transactions Query Interface - Belgium

  Sends charges to and receives charge verifications from an external system. Billing-related errors logged by this interface are routed to an activity in Epic where users can correct errors and resubmit affected messages in real time.

• Outgoing Imaging Document and Response Interface - Finland

  Sends reference links for R2CDA imaging documents to Navitas and receives acknowledgements in return.

• Outgoing Vaccination History Query Interface - Norway

  Queries the SYSVAK vaccination registry, per Norwegian SYSVAK specification . Each query requests historical immunization data for a given patient. This registry does not provide immunization recommendation data. The incoming portion of the interface does not directly update immunizations in the chart; the provider sees the response from the registry and decides what should be added to the patient record.

• Outgoing Vaccination Administration Request and Response Interface - Norway

  Sends information about vaccination administrations, per the Norwegian SYSVAK specification .

• Outgoing Sick Leave Interface - Norway

  Sends information regarding a patient's ability to perform work in Norway, as specified by the Norwegian Labour and Welfare administration (NAV). Relevant information includes duration of impairment, cause of impairment, and other supporting information provided by the patient's provider.

• Outgoing External Repricing Request Query (X12 837)

  Epic's managed care system supports pricing claims in real-time by sending the 837 and receiving a response of a repriced 837 with HCP Segments.

• Incoming Health Care Services Authorization Interface - Netherlands

  Receives notifications from VECOZO when the status of an authorization request has changed. The incoming interface can update authorization records (RFL or AUT) in Epic, which drive referral workqueue and scheduling workflows.

• Outgoing Birth Notification Interface - Norway

  Sends notification of birth and receives back national identifier from the Norwegian citizen registry.

• Outgoing Vaccination Codeset Update Request and Response Interface - Norway

  Queries the Norwegian SYSVAK registry and returns an import file to update the immunization build for Norwegian customers.

• Outgoing Financial Information Query Interface - Norway

  Retrieves income, expense, and asset information for patients and their contacts from Financial Assistance.

• Outgoing Birth Registry Interface - Norway

  Sends clinical information regarding a birth event to the MFR registry.

• Outgoing GP Patient List Subscription and Response

  In Norway, a regional service (NAV) maintains a list of physicians (GPs) and the patients to whom they provide care. This supports integration for providers to interact with NAVs service; notably, subscribing to their list (signing up for an updated list of patients to be sent monthly), ending their subscription to the monthly list, and checking the status of their subscription.

• Outgoing ePrescribing Service Request and Response Interface - Norway

  ePrescribing services with the national medication directory service (SFM)

• Incoming ePrescribing Service Notification Interface - Norway

  ePrescribing services with the national medication directory service.

• Incoming MDS CMS Validation Report

  Takes the CMS MDS Validation Final Report flat file, parses the result of all of the MDS assessments in the report, and files the results of the validation back to Epic The MDS Validation Final Report flat file is generated by CMS QIES and the specification for the report can be found in the CASPER Reporting User's Guide For MDS Providers. A full list of CMS error and warning codes (edits) can be found in section 5 of the MDS 3.0 Provider User's Guide.

• Outgoing Vaccination Administration Request and Response - Australia

  Sends information about vaccination administrations to the Australian Immunisation Register (AIR). In an upcoming version, will also query AIR for immunization history.

• Incoming Provider Communications Interface - Finland

  Receives incoming summary of care if patient receives care out of home municipality.

• Outgoing Provider Communications - Finland

  Sends outgoing communication and summary of care for patients receiving care outside of home municipality.

• Tapestry Incoming Bank Reconciliation

  Receives status updates for check records to match the status assigned by the bank responsible for distributing the check.

• Tapestry Incoming Benefit Accumulations

  Receives external benefit bucket information so that member cost responsibility can be calculated correctly when processing claims.

• Tapestry Outgoing Positive Pay Files

  Sends check information for processed claims to banks as part of the claims payment cycle.

• Incoming Drug Supply Chain Event Notification to Willow Inventory

  Enables supply chain partners to capture event information about supply chain events and to share that information with their trading partners securely.  Uses the Electronic Product Code Information Service (EPCIS) GS1 standard and complies with the Drug Supply Change Security Act (DSCSA) regulation that requires organizations exchange package-level tracing information.

• Outgoing Dialysis Updates to CMS

  Sends Dialysis Data to CMS (by way of a Renal Healthcare HIE) from the Dialysis Module, per HIE specifications. Requires Nephrology license. Specifications are found https://qnetconfluence.cms.gov/display/ELDF/Documentation+Repository

• Outgoing eMultidose Patient Medication List Change Query

  eMultidose Patient Medication List Change Query

• Outgoing eMultidose Responsibility Update

  Outgoign eMultidose Responsibilty Update

• Outgoing Social Care Disclosure Notification - Finland

  Notifies the national log register storage service (Kanta) that patient social care information has been shared, per Sosiaalihuolto-r4.

• Incoming Scheduling Slot Availability Query

  Receives requests from the United Kingdom's NHS e-Referral Service (also known as Choose and Book) to request appointment slots from Cadence, Epic's scheduling system.

• Outgoing PDS Tracing Query

  Outgoing PDS Tracing interface sends queries to the Personal Demographics Services (PDS) master index for National Health Service (NHS) patient records in the United Kingdom. PDS Trace Response messages are processed by the Incoming PDS Tracing interface. Message interactions follow HSCIC's Message Implementation Manual (MIM) version 7.2.02 and External Interface Specification 11.6. This interface uses messages expressed in XML encoding syntax.

• Outgoing PDS Demographics Synchronisation Query

  Outgoing PDS Synchronisation interface sends queries for demographics and demographic updates to the Personal Demographics Services (PDS) master index for National Health Service (NHS) patient records in the United Kingdom. PDS Synchronisation Response messages are processed by the Incoming PDS Synchronisation interface. Message interactions follow HSCIC's Message Implementation Manual (MIM) version 7.2.02 and External Interface Specification 11.6. This interface uses messages expressed in XML encoding syntax.

• Outgoing PDS NHS Number Allocation Request for Acute Care

  Sends requests to the Personal Demographics Services (PDS) to generate a new National Health Service (NHS) number for an adult patient in an acute care setting in the United Kingdom. PDS NHS Number Response messages are processed by the Incoming PDS NHS Number Allocation interface. Message interactions follow HSCIC's Message Implementation Manual (MIM) version 6.3.01 and External Interface Specification 11.6. This interface uses messages expressed in XML encoding syntax.

• Outgoing PDS Newborn Notification

  Sends requests to the Personal Demographics Services (PDS) to generate a new National Health Service (NHS) number for a newborn delivery documented in Stork within the United Kingdom. PDS Create Initial Record Response messages are processed by the Incoming PDS Create Initial Record Response interface. Message interactions follow HSCIC's Message Implementation Manual (MIM) version 7.2.02 and External Interface Specification 11.6. This interface uses messages expressed in XML encoding syntax.

• Outgoing Medication Orders

  Sends outgoing e-prescribed medication orders, following Dutch HL7 v3 Standards (MP6).

• Outgoing Medication Dispense History Query

  Queries the Landelijk SchakelPunt (LSP) to retrieve patient medication data. Certified with VZVZ. This interface follows the Dutch HL7 v3 standards implemented within AORTA.

• Outgoing Medication Orders

  Sends ambulatory medication orders that are placed in Order Entry to the National Electronic Health Record (NEHR) in the format required by the NEHR putOrderedMedications service. This interface uses the XML message format.

• Outgoing Medication Dispenses

  Sends outpatient medication dispenses to the National Electronic Health Record (NEHR) in the format required by the NEHR putDispensedMedications service. Messages are sent whenever an outpatient medication dispense is received from an internal pharmacy system through an Incoming Medication Orders to EpicCare Ambulatory interface. This interface uses the XML message format.

• Outgoing Laboratory Results

  Sends laboratory results to the National Electronic Health Record (NEHR) in the format required by the NEHR putLabResults service. This interface uses the XML message format.

• Outgoing Radiology Results

  Sends radiology results to the National Electronic Health Record (NEHR) in the format required by the NEHR putRadiologyResults service. This interface uses the XML message format.

• Outgoing Discharge Summaries

  Sends a clinical summary to the National Electronic Health Record (NEHR) in the format required by the NEHR putDischargeSummary service. The summary is generated upon discharge of a patient.

• Outgoing ED Summaries

  Sends a clinical summary to the National Electronic Health Record (NEHR) in the format required by the NEHR putEDNotes service. The summary is generated when the patient is discharged or dismissed from the emergency department.

• Outgoing Surgical Summaries

  Sends a surgical summary to the National Electronic Health Record (NEHR) in the format required by the NEHR putOTNotes service at the time that a surgical log is posted or addended. This interface uses the XML message format.

• Outgoing Health Care Claim Grouper and Pricer

  Bidirectional interface that analyzes claims to determine which codes and prices are appropriate, and can work with various external systems.

• Outgoing Municipality Integrations

  Manages communication with external municipal systems according to established MedCom protocols to coordinate the delivery of home care after discharge. The outgoing interface supports: automatic admission and discharge notifications to alert municipalities when their citizens have been admitted to and discharged from the hospital, clinical reports by nursing staff to convey updated clinical information and home care needs to the home care system so they can prepare to assume responsibility for the patient, and administrative notifications to coordinate and document the extension of admissions if the municipality is not yet prepared to accept responsibility for patient care. This integration also includes an incoming interface for filing admission reports sent by municipality home care systems when they receive an admission notification from the hospital. Clinical staff can use these admission reports to review the current status of home care patients. This interface uses the Medcom XML/EDIFACT standard.

• Bidirectional Correspondence

  Sends and receives patient-centric clinical correspondence messages to external parties, including other hospitals, general practitioners, and municipal systems. These messages are used for ad hoc communication to convey additional information beyond what is included in other specifications.

• Outgoing Newborn CPR Assignment Request and Response

  Registers newborns in the Danish civil registration system (CPR) and reserves a corresponding CPR identifier (national ID). This interface uses the Medcom Web Service standard.

• Outgoing Order Requisitions

  Sends orders placed by a clinical user to either an external LIS or Danish laboratory outside the organization. This interface supports general chemistry, blood bank, microbiology, and pathology laboratory procedures placed by users in EpicCare Inpatient and EpicCare Ambulatory, and pathology procedures placed by clinical users in OpTime. This interface uses the Medcom XML standard.

• Incoming Pathology Results

  Receives pathology test results from a LIS for use in Epic. Results can be received for orders placed in Epic or placed elsewhere. Additionally, this interface can update the status of the results to In Process, Preliminary, Final, or Final-Edited. This interface uses the Medcom XML standard.

• Incoming Lab Results Interface

  Receives general chemistry, blood bank, and microbiology test results from LIS for use in Epic. Results can be received for orders placed in Epic or placed elsewhere. Additionally, this interface can update the status of the result to In Process, Preliminary, Final, or Final- Edited. This interface uses the Medcom XML standard.

• Outgoing Referrals and Booking Confirmation

  Manages outgoing referrals communication with external systems according to established MedCom protocols. The interface facilitates sending new referrals composed in Epic and forwarding copies of previously received referral messages. The interface can also send booking confirmations to inform a patient's referring and primary care physicians when a referral is being acted on in Epic. These notifications can be sent automatically when an appointment has been scheduled, or when a patient is preadmitted or arrived in the ED for an issue relating to the referral. This interface uses the Medcom XML/EDIFACT standard.

• Incoming Referrals and Booking Confirmation

  Manages incoming referrals communications with external systems according to established MedCom protocols. This interface can both create incoming hospital referrals and file booking confirmation messages for referrals originating in Epic.

• Outgoing Binary Documents

  Sends binary attachment documents associated with a MedCom message. This interface must work in conjunction with one of the following MedCom interfaces: Outgoing Summary of Care, Outgoing Referrals and Booking Confirmation, Bidirectional Correspondence, and Outgoing Order Requisitions.

• Incoming Binary Documents

  Files the binary attachment documents associated with an incoming MedCom message to the Epic WebBLOB server. This interface must work in conjunction with one of the following MedCom interfaces: Incoming Summary of Care, Incoming Referrals and Booking Confirmation, Bidirectional Correspondence, Outgoing Municipality Integrations - Incoming Response, Incoming Rehabilitation Plan Summary, Incoming Lab Results, and Incoming Pathology Results.

• Outgoing Procedure Log Data

  Sends data for configured case tracking events from a Cupid procedure log case for the purpose of submitting data to external registries. Submissions to the NCDR CathPCI & NCDR ICD registries can be sent directly from Cupid, Epic's CVIS. The messages contain data on the case including panels, staff, timeouts, implants, equipment, radiation, verifications, flowsheets, events, medications, and labs.

• Incoming Referral Scheduling Request Query

  Receives requests from the United Kingdom's NHS e-Referral Service (also known as Choose and Book) to book an appointment in Cadence, Epic's scheduling system.

• Incoming Summary of Care Interface

  Files a summary of care document (Epikrise) from an external hospital or specialist as a note to the patient's chart. These notes describe the care that the patient received from the external hospital or specialist and can be used as reference when providing care in Epic.

• Outgoing Summary of Care Interface

  Sends a summary of care document (Epikrise) to the patient's referring provider and primary care physician to report the outcome of an ED visit, admission, or ambulatory encounter using a combination of discrete and free-text information. Summary of care messages are automatically sent for the patient whenever a designated Epikrise note has been signed and the patient's encounter is closed. This interface uses the Medcom XML/EDIFACT standard.

• Outgoing PAS Data and Response Interface

  Sends patient, referral, administrative pathway, and encounter data grouped by patient episode to the Victorian Integrated Non-Admitted Health (VINAH) database, which is run by the State of Victoria Department of Health & Human Services in Australia. Additionally, this interface receives asynchronous acknowledgments and error information from VINAH. This interface uses messages expressed in XML encoding syntax.

• Data Exchange with 3M Core Grouping Software or Grouper Plus Content Services

  This is a proprietary specification to/from 3M's Core Grouping Software or Grouper Plus Content Services. Medicare OP claims data is sent to the 3M Module. CSG/GPCS performs APC/APG grouping, reimbursement calculations, OCE and proprietary claims scrubbing; the results are loaded back into Epic where errors can drive claim edits.

• Outgoing FMK Medication Card Services Request and Response

  Manages the following interactions between Epic and the Danish medication database Falles Medicinkort (FMK): Filing medication lists for patients into Epic; pushing medication changes from Epic to the national database; and setting the reviewed status of the medication list by a clinician.

• Outgoing Medication Orders to Prescription Exchange Service

  Sends medication orders and receives acknowledgements from a prescription exchange service (the currently supported service is eRx). When clinicians create, cancel, or amend medication orders, this XML interface relays the ePrescription information to eRx, which forwards the medication information to the appropriate dispensing facility. This interface uses the XML message format.

• Outgoing Birth Notification Interface

  Sends a report to register newborns in the municipal child care system and begin coordination of home visits by municipal pediatric nursing after discharge.

• Outgoing ECPR Assignment Request and Response

  Requests ECPR identifiers for request a new official ECPR from the Denmark national ECPR registry for non-Danish residents, anonymous, trauma, and unknown patients.

• Outgoing Rehabilitation Plan Summary

  Sends a summary of the physical therapy/rehabilitation (GGOP) provided for a patient and needs for ongoing therapy/rehab. Frequently used as a way for physical therapists to document ongoing care for a patient, provide progress updates to external parties such as their primary care physician, and transition responsibility for therapy to other entities such as other hospitals or municipality rehabilitation systems. This interface uses the XML (DGOP), GGOP (MedCom XML) standard.

• Incoming Rehabilitation Plan Summary

  Receives incoming summaries of physical therapy/rehabilitation (GGOP) from physical therapists. This interface can be configured to create scheduling orders, which users can use to plan future appointments for the patient's care. This interface uses the XML (DGOP) GGOP (MedCom XML) standard.

• Outgoing Prescription Prior Authorization Request and Response

  Submits prior authorization requests to the DHPO and HAAD post office. This interface uses the HAAD XML standard.

• Outgoing Claim Submission from Willow Ambulatory

  Submits claims to the DHPO and HAAD post office. This interface uses the HAAD XML standard.

• Incoming Remittance Advice Download to Willow Ambulatory

  Downloads remittance advices that are stored in HAAD post office using a batch job. This interface uses the HAAD XML standard.

• Outgoing COV Verification Query

  The interface queries Vecozo and uses the VZ37/VZ38 standard to retrieve and store insurance information for a patient. This interface uses the VZ37 / VZ38 standard.

• Outgoing IHI Verification Query

  Queries the Australian Healthcare Identifiers (HI) Service to retrieve and validate a patient's Individual Healthcare Identifier (IHI) Number. The main goal of this query is to allow modules such as Care Everywhere to interact with My Health Record, which requires valid IHI Numbers for patients when uploading documents.

• Outgoing Perinatal Data

  Submits summary reports at the end of each pregnancy to Perined, a national registry in the Netherlands that records obstetric data. This interface uses the XML HL7 NL standard.

• Outgoing Initial Public Health Case Report (eICR)

  Satisfies the Meaningful Use objective to send Electronic Case Reports to public health agencies using the HL7 Clinical Document - Electronic Initial Case Report (CDA-eICR) format.

• Outgoing FMK Ordered Refill Request and Response

  Sends refill requests to the Danish medication database Fælles Medicinkort (FMK) for a patient or an entire facility.

• Outgoing eRx Services Request and Response

  Communicates with the prescription center of Finland any time a user makes changes to a patient's prescriptions, as well as when a user needs to reconcile a patient's existing prescriptions into Epic.

• Outgoing Prescription Upload Request and Response

  Submits a prescription to the UAE Post Office hub for authorization.

• Outgoing Prescription Download Request and Response

  Downloads a patient's prescriptions from the UAE Post Office hub.

• HL7 InfoButton

  The Active Guidelines (AGL) activity in the Epic EHR uses the HL7 InfoButton standard to allow 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.

• Mobile App Integration

  Epic's mobile applications - Haiku, Canto, and Rover - can communicate with specialized clinical review applications like document or image viewers. This framework allows our applications to launch your app with context, making for a a smooth and seamless clinical experience for the user.

• Clinical Context Manager Integration

  CCOW (formerly known as Clinical Context Object Workgroup) is a vendor-independent HL7 standard protocol designed to allow disparate clinical applications to synchronize data in real-time at the point of care. Epic can integrate as a participant with a third-party clinical context manager.

• Patient Portal Links

  Epic's patient portal can link to other patient-specific websites through functionality known as Dynamic Links. Dynamic Links are used to launch external websites from within the portal. The link can be configured to pass context about the patient through query string parameters, optionally encrypted using AES.

• Cash Management

  This incoming batch interface creates a record of deposits for cash reconciliation using a configurable flat file format. The flat file is configurable and the preferred format is in the linked specification, however Epic can also support industry standard formats such as CCD+.

• Incoming Claim Status Batch (Flat File)

  This incoming batch interface loads information about claim status through a configurable flat file. This interface can update the status of claims in the system and is able to load claim error information from payer and intermediary systems. The flat file format is configurable, but the common specification is pre-configured in the Foundation System for Epic customers and widely used with success.

• Incoming Self-pay Payments

  This incoming batch interface posts self-pay and bad debt payments in a configurable flat file format. The flat file format is configurable, but the above common specification is pre-configured in the Foundation System for Epic customers and widely used with success.

• Monthly Premium Withholding Report (MPWR)

  Transmits premium information to Medicare Advantage plans.

• Outgoing 1095-B (Simple)

  The 1095-B is a flat file for tax information.

• Outgoing 1099-MISC

  The 1099-MISC tax form is used to report miscellaneous income for Vendors from an AP Cycle processing.

• Batch Eligibility Query (BEQ)

  Outbound BEQ request and Incoming BEQ response. BEQ is a way for plans to submit batches of individuals for verification of various eligibilities.

• Outbound Medicare Advantage and Prescription Drug System (MARx) files

  File for reporting drug information between a health plan and CMS.

• Tapestry Document Linker DMS Integration

  We recommend using the Hyperdrive Document Linker instead of this technology. This VB integration enables users in an external document management system to launch the Tapestry Document Linker activity in an active Hyperspace session and pass necessary document information to link a document to records in Epic. Additionally the integration can allow for users in the DMS to create new claim and CRM records in Hyperspace with links to the desired document.

• Collections Extract and Import

  Epic can generate a flat file extract to collections agencies containing information about charges assigned to the agency. Epic can also receive flat file imports with updates to those charges to support tracking of payments and changes to charges in Resolute.

• SAML 2.0 Idp-initiated Single Sign-On (SSO)

  Epic supports launching an external app with SAML 2.0. The SAML 2.0 Identity Provider initiated workflow initiates from Epic, playing the SAML role of Identity Provider. Implementation requires the exchange of an x509 certificate, which is used to sign the SAML claims. This process follows the OASIS SAML 2.0 specification. Epic recommends the use of SMART on FHIR over SAML if possible.

• Single Sign-On (SSO) into MyChart

  We moved the MyChart SSO specification from open.epic.com to vendorservices.epic.com . This will give developers and our customers access to Epic guidance on preventing cybersecurity vulnerabilities. If you are interested in developing to the specification, please fill out an interoperability request for assistance.

• Single Sign-On (SSO) into EpicCare Link

  Other systems can provide SSO integration into Epic's web application, EpicCare Link, by passing user and optionally patient context.

• Appointment Notifications

  Interactive Voice Response systems can be used to deliver appointment reminders to patients prior to their visits, asking them to confirm. Once the appointment is confirmed, the IVR system sends this information back to the Epic EHR so clinic staff can estimate no-show probabilities.

• Recall Notifications

  Interactive Voice Response systems can be used to remind patients to schedule appointments for upcoming recalls. Once the communication happens, the IVR system sends this information back to the Epic EHR to finish the documentation.

• Request Notifications

  Interactive Voice Response systems can be used to remind patients to schedule appointments for upcoming appointment requests. Once the communication happens, the IVR system sends this information back to the Epic EHR to finish the documentation.

• Incoming Receipts

  Receives receipts for messages sent to the VANS network in relation to the Medcom message sent.

• Outgoing Receipts

  Sends positive or negative receipt messages for Medcom messages received from the VANS network using the Medcom XML/EDIFACT standard.

• eMediplan APIs

  These APIs enable queries into Epic for the full medication list for a patient and can generate a push notification when a user in Switzerland requests an eMediplan in Epic. An interface engine can use the notification to call into these APIs and standard FHIR APIs to gather the necessary information to request an eMediplan document from the HCI eMediplan system. This document can be filed into Epic with an Incoming Scanned Document Link interface or shared with other healthcare organizations. The document includes a QR code that healthcare providers can use to retrieve the patient's medications from eMediplan.

• Incoming External Clinical Data

  As organizations extend Epic to affiliated practices in their communities, there has been an increasing need to convert historical patient-level data from other vendors' systems into Epic. We recommend and very strongly prefer converting data using any of our other standards based integration options, such as from a CCDA. This is a limited import tool that allows organizations to load patient-level data from organizations that do not otherwise support standards-based data exchange.

• Paid Claims Import

  Paid claim data can be imported into Epic to support population health and care management workflows by reconciling the data with the rest of the comprehensive medical record. These formats are recommended when the data can be manipulated or the extract is flexible, to simplify the process of importing into Epic.

• EDManager

  This set of APIs allow external applications that are running alongside Epic Hyperspace to programmatically take certain actions, such as logging in/out and launching activities. They also provide the ability to query Epic Hyperspace for information, as well as to be notified when key events occur. These APIs are commonly used for automating external-driven workflows, most notably logins.

• Desktop Generic Authentication

  This interface allows external authentication software to implement authentication devices for use in Epic. The external authentication software can write installable devices that can be configured for use as devices to authenticate a user for login into Epic, to re-authenticate the user after login (for example, to sign off on medications), or to identify a patient (for example, to check into an appointment).

• Scan Acquisition

  This COM integration enables users to seamlessly launch an external scan acquisition interface from Epic. Epic can pass the user's active context information, such as the patient, encounter, or order.

• Scan Viewing

  This COM integration enables Epic to display an ActiveX scan viewing control in a modeless floating window. The user can interact with both the viewer and Epic, and Epic will manage closing the window if the user's patient context changes.

• EPS Document Retrieval Plugin

  This .NET integration enables Epic print services (EPS) to query a document management system (DMS) for images or documents to insert into a print job. This is useful when you want a scan to be stored in your DMS, but want to include that scan in something you print. We recommend new implementations use the EPS Document Retrieval Web Service instead of this.

• SIEM Feed

  Epic can feed certain security and privacy relevant events to a security information and event management (SIEM) system in near real-time.  Messages coming from Epic can be formatted using Common Event Framework (CEF), Log Event Extended Format (LEEF), or RFC 5424 syslog.

• Epic Access Logging

  The Epic Access Logging extract script extracts key Epic event logging data, including patient, user, and encounter information, from the Epic organization’s Clarity database into a pipe delimited flat file.

• Speech Recognition (Classic VB Client)

  This set of APIs allow speech recognition systems to integrate with Epic Hyperspace (Classic VB Client).  The speech recognition system can receive information about and make changes to the content of a control. 99% of customers are no longer using this client. For current specifications, see Hyperdrive Speech Recognition .

• Computable Exports

  Epic software gives users the ability to export electronic health information in multiple formats depending on the use case. The following computable formats are available: FHIR-formatted files for a subset of electronic health information in FHIR. C-CDA-formatted XML documents for the subsets of electronic health information that can be expressed in C-CDA templates. EHI Tables for complete electronic health information, in a tab-separated value (TSV) file format native to Epic. Refer to the EHI Tables technical specification for detailed information about what’s included in this export by default. A copy of the specification might also be included in the Full EHI Export package you receive. The TSV files might also come packaged with non-computable files that are referenced in a patient record, such as media files and rich text format notes.

• Welcome Accessibility for Vendors

  Welcome is Epic’s application for patient self-service arrivals using kiosk enclosures or free-roaming tablets. This guide is intended for vendors supplying Welcome hardware and software solutions and provides an overview of some considerations associated with supporting an accessible patient workflow on those form factors

• Welcome Hardware Guide For Vendors

  Welcome is Epic’s application for patient self-service arrivals using kiosk enclosures or free-roaming tablets. This guide is intended for vendors supplying Welcome hardware solutions and provides an in-depth guide to the integration considerations soliciting organizations may have when requesting hardware.

• PB Statement Form 807

  Epic can generate a delimited plain text file of information that can be shared with a statement vendor. This file includes information about the patient and their Professional Billing balances in Epic. File format subject to change - fields and segments may be added or removed with future development. Programming should accept or ignore additional fields and segments when they occur gracefully.

• SBO Statement Form 808

  Epic can generate a delimited plain text file of information that can be shared with a statement vendor. This file includes information about the patient and their Enterprise billing balances in Epic. File format subject to change - fields and segments may be added or removed with future development. Programming should accept or ignore additional fields and segments when they occur gracefully.

• Active Guidelines

  The Active Guidelines (AGL) activity gives clinicians a convenient way to access web applications without leaving the Epic application. A web app can either be launched as the result of a user interacting with a response from a decision support web service or, depending upon health system configuration, by a user specifically choosing to navigate to the application from various activities or items. The web application is embedded within a sandboxed iframe in the Epic Hyperspace desktop application and can communicate with the EHR through cross-domain web messaging.

• Kiosk Generic Authentication

  Allows external authentication software to implement authentication devices for use in Epic’s self-arrival kiosk software. The external authentication software can write installable devices that can be configured to identify a patient or to enroll a patient for future identifications.

• OpenID Connect

  Epic’s Hyperspace application now supports the OpenID Connect (OIDC) authorization code flow as a means of authenticating users for logging in to Hyperspace as well as authentication within Hyperspace workflows.

• Translation of Patient-Facing Content

  Outlines the file format expectations for translation of patient-facing content which can show up in MyChart and other areas of our patient-facing software. Not all workflows that are patient-facing are currently included in this file format.

• Care Gaps Import

  Care gaps data can be imported into Epic to support population health and care management workflows. Imported quality measure outcomes can be used to drive patient outreach, enhance during-encounter decision support, and summarize measure performance for your patient populations. This format is recommended when the data can be manipulated, or the extract is flexible, to simplify the process of importing into Epic.

• Bluetooth® Generic Health Sensor Device Integration with MyChart

  The Generic Health Sensor (GHS) Profile is a Bluetooth® standard for communicating health-related observations from personal health devices. This specification describes how devices that support the GHS Profile can integrate with MyChart to file patient data.

• Risk Adjustment Import

  Risk Adjustment data can be imported into Epic to support population health and care management workflows by providing condition categories and suspected conditions. This format is recommended when the data can be manipulated or the extract is flexible, to simplify the process of importing into Epic.

• Supplemental Data Import

  Supplemental data can be imported into Epic to support population health and care management workflows by providing additional clinical data to include in HEDIS™ quality reporting. This format is recommended when the data can be manipulated or the extract is flexible, to simplify the process of importing into Epic.

• Verified Safety Checks

  Documentation to assist BLE wristband vendors in supporting Epic Verified Safety Checks for inpatient behavioral health units.

• Bluetooth Wayfinding

  Enables a web-based application embedded within MyChart Mobile to request and receive Bluetooth signals, data, and beacon information from the containing app to support indoor blue-dot wayfinding experiences.

• Prospective Patient Import

  Prospective Patient data can be imported into or exported out of Epic to support maintaining a unified view of prospective and current patients, enabling more effective outreach, patient matching, and reporting. This is a spreadsheet-based import/export tool that allows organizations to load prospective patient data from third-party systems.