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.

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.

The AllergyIntolerance data models describe a patient's intolerance to a foreign substance and an associated reaction that occurs from exposure.

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.

Binary provides the ability to retreive a particular document.

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.

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.

Careplan describes the assessment and treatment plan for a particular patient. Goal describes provider-documented targeted outcomes for a patient to achieve.

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.

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.

Conditions can encompass acute and chronic problems and conditions, as well as encounter diagnoses.

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.

The Contract resource is primarily used for read interactions and can be used as a reference when calling the DocumentReference.Create interaction.

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.

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.

CRD Endpoint Discovery

High Level Description

Endpoint: GET api/epic/2024/HL7DaVinciCRD/CoverageRequirementsDiscovery/cds-services/

Available: February 2026

Purpose: The CRD endpoint discovery API allows a CRD client to discover endpoints and prefetch queries to be used with the Coverage Requirements Discovery API.

Key Capabilities

See the CDS Hooks Discovery specification for a detailed description of this API's behavior: https://cds-hooks.hl7.org/2.0/#discovery.

Make an empty GET request to receive CDS service information.

The response includes two service definitions, one for order-sign and one for appointment-book. The service ID is the same, and requests for both hooks should go to the same URL.

Coverage Requirements Discovery

Purpose: This is an overview covering Epic's payer-side support for a subset of Da Vinci Coverage Requirements Discovery (CRD) STU 2.1 (https://hl7.org/fhir/us/davinci-crd/STU2.1/) as a CRD server, focused on the ability to return whether prior auth is required for outpatient procedures.

The main value of this functionality is to inform providers when prior authorization is not needed, reducing administrative burden submitting and reviewing unnecessary prior authorizations.

Key Capabilities

Request requirements: The supported CDS Hooks are order-sign (https://cds-hooks.org/hooks/order-sign/) and appointment-book (https://cds-hooks.org/hooks/appointment-book/).

The request resources supported are ServiceRequest and MedicationRequest; these can be present in either the draftOrders bundle in an order-sign hook or referenced by the basedOn element of an Appointment in an appointment-book hook. MedicationRequests in an Appointment are a deviation from the STU 2.1 specification, which allows only ServiceRequests to be used in the basedOn element. Appointments that do not reference a ServiceRequest or MedicationRequest are not supported.

The request must include resources prefetched using the queries determined from CDS Discovery (https://cds-hooks.hl7.org/2.0/#discovery); the URL of this endpoint is "https://<payer server API base>/epic/2024/HL7DaVinciCRD/CoverageRequirementsDiscovery/cds-services". The server will not utilize any FHIR authorization information to query for referenced FHIR resources after receiving a CRD request.

If referenced resources are not included, the request might not be processed, or complete guidance might not be available. The request will also not be processed if the patient, coverage, or procedure cannot be matched to information available in Tapestry UM.

Some information, such as performing provider, is technically optional in a CRD request, but there might not be available guidance without this information present. Make sure to discuss with each payer you integrate with to ensure information they require will be available in your request.

When determining the service date to use when evaluating coverage requirements, the following elements are used. Other elements are not used.

• ServiceRequest.occurrencePeriod.start, MedicationRequest.dosageInstruction.timing.repeat.boundsPeriod.start
• ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start
• Appointment.start
• Appointment.requestedPeriod.start

Work with payers you integrate to understand what code systems they will provide guidance for.

Response info:

For each service where a decision is made, the response will contain an update System Action (https://cds-hooks.hl7.org/2.0/#system-action) for the ServiceRequest or MedicationRequest to update it with a Coverage Information extension (https://hl7.org/fhir/us/davinci-crd/STU2.1/StructureDefinition-ext-coverage-information.html) containing the decision. This includes ServiceRequest or MedicationRequest resources referenced by an Appointment; Appointments will not be updated with coverage information.

The ServiceRequest or MedicationRequest resource will be included in the system action with a limited subset of information from the original request.

The coverage-information extension is built of multiple inner extensions; we support the extensions listed below. Other extensions on the Coverage Information are not currently supported.

• covered
• pa-needed
• info-needed
• doc-needed
• doc-purpose
• reason
• detail
• coverage-assertion-id
• coverage
• date
• expiry-date

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.

DiagnosticReport describes the findings associated with a diagnostic laboratory procedure.

DocumentReference provides a list of available documents for a patient. CDA documents and clinical notes are examples of documents that this resource may return.

Epic Payer Support for DTR

High Level Description

Epic supports compliance with the HL7 Da Vinci Documentation Templates and Rules (DTR) implementation guide version 2.1.0. This service enables payers to provide structured documentation requirements and questionnaires to requesting systems using FHIR.

Endpoint & Availability

Epic DTR Base URL (separate from generic FHIR server base URL): https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations

Available: February 2026

Purpose

The DTR services support collection of clinical documentation needed to satisfy payer requirements. DTR may be invoked standalone or as part of CRD or PAS workflows.

Key Capabilities

• Provide standard and adaptive questionnaires
• Support standalone, CRD-initiated, and PAS-initiated DTR workflows
• Adaptive question progression using $next-question
• Optional logging of questionnaire errors
• ValueSet expansion support

Requirements

Required request properties

• Patient
• Coverage
• ServiceRequest(s) AND/OR Context identifier
  • CRD-initiated DTR: requires BOTH ServiceRequest and Context
  • Standalone DTR: requires ServiceRequest(s) only
  • PAS-initiated DTR: requires Context only
• Referenced resources

ServiceRequest coding requirements

• CPT codes using http://www.ama-assn.org/go/cpt
• HCPCS codes using http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets

Practitioner / PractitionerRole / Location requirements

• Referenced resource must include NPI identifiers.

Supported Operations

Questionnaire/$questionnaire-package

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$questionnaire-package

• Supports standard and adaptive questionnaires
• Must include Patient, Coverage(s), ServiceRequest(s), and referenced resources
• Questionnaire profiles must be declared
• QuestionnaireResponse must conform to DTR profiles

Questionnaire/$next-question

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$next-question

• Requires adaptive QuestionnaireResponse
• Contained adaptive Questionnaire must be present
• Response may add questions as well as add/update answers to questions

Questionnaire/$log-questionnaire-errors

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$log-questionnaire-errors

• Only supported for questionnaires that allow error logging
• Unsupported attempts return OperationOutcome

ValueSet/$expand

URL: GET https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/ValueSet/$expand

• Must specify ValueSet URL via query parameters.

Epic Payer Support for DTR

High Level Description

Epic supports compliance with the HL7 Da Vinci Documentation Templates and Rules (DTR) implementation guide version 2.1.0. This service enables payers to provide structured documentation requirements and questionnaires to requesting systems using FHIR.

Endpoint & Availability

Epic DTR Base URL (separate from generic FHIR server base URL): https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations

Available: February 2026

Purpose

The DTR services support collection of clinical documentation needed to satisfy payer requirements. DTR may be invoked standalone or as part of CRD or PAS workflows.

Key Capabilities

• Provide standard and adaptive questionnaires
• Support standalone, CRD-initiated, and PAS-initiated DTR workflows
• Adaptive question progression using $next-question
• Optional logging of questionnaire errors
• ValueSet expansion support

Requirements

Required request properties

• Patient
• Coverage
• ServiceRequest(s) AND/OR Context identifier
  • CRD-initiated DTR: requires BOTH ServiceRequest and Context
  • Standalone DTR: requires ServiceRequest(s) only
  • PAS-initiated DTR: requires Context only
• Referenced resources

ServiceRequest coding requirements

• CPT codes using http://www.ama-assn.org/go/cpt
• HCPCS codes using http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets

Practitioner / PractitionerRole / Location requirements

• Referenced resource must include NPI identifiers.

Supported Operations

Questionnaire/$questionnaire-package

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$questionnaire-package

• Supports standard and adaptive questionnaires
• Must include Patient, Coverage(s), ServiceRequest(s), and referenced resources
• Questionnaire profiles must be declared
• QuestionnaireResponse must conform to DTR profiles

Questionnaire/$next-question

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$next-question

• Requires adaptive QuestionnaireResponse
• Contained adaptive Questionnaire must be present
• Response may add questions as well as add/update answers to questions

Questionnaire/$log-questionnaire-errors

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$log-questionnaire-errors

• Only supported for questionnaires that allow error logging
• Unsupported attempts return OperationOutcome

ValueSet/$expand

URL: GET https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/ValueSet/$expand

• Must specify ValueSet URL via query parameters.

Epic Payer Support for DTR

High Level Description

Epic supports compliance with the HL7 Da Vinci Documentation Templates and Rules (DTR) implementation guide version 2.1.0. This service enables payers to provide structured documentation requirements and questionnaires to requesting systems using FHIR.

Endpoint & Availability

Epic DTR Base URL (separate from generic FHIR server base URL): https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations

Available: February 2026

Purpose

The DTR services support collection of clinical documentation needed to satisfy payer requirements. DTR may be invoked standalone or as part of CRD or PAS workflows.

Key Capabilities

• Provide standard and adaptive questionnaires
• Support standalone, CRD-initiated, and PAS-initiated DTR workflows
• Adaptive question progression using $next-question
• Optional logging of questionnaire errors
• ValueSet expansion support

Requirements

Required request properties

• Patient
• Coverage
• ServiceRequest(s) AND/OR Context identifier
  • CRD-initiated DTR: requires BOTH ServiceRequest and Context
  • Standalone DTR: requires ServiceRequest(s) only
  • PAS-initiated DTR: requires Context only
• Referenced resources

ServiceRequest coding requirements

• CPT codes using http://www.ama-assn.org/go/cpt
• HCPCS codes using http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets

Practitioner / PractitionerRole / Location requirements

• Referenced resource must include NPI identifiers.

Supported Operations

Questionnaire/$questionnaire-package

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$questionnaire-package

• Supports standard and adaptive questionnaires
• Must include Patient, Coverage(s), ServiceRequest(s), and referenced resources
• Questionnaire profiles must be declared
• QuestionnaireResponse must conform to DTR profiles

Questionnaire/$next-question

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$next-question

• Requires adaptive QuestionnaireResponse
• Contained adaptive Questionnaire must be present
• Response may add questions as well as add/update answers to questions

Questionnaire/$log-questionnaire-errors

URL: POST https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/Questionnaire/$log-questionnaire-errors

• Only supported for questionnaires that allow error logging
• Unsupported attempts return OperationOutcome

ValueSet/$expand

URL: GET https://<hostname>/<IC-Instancename>/api/epic/2024/HL7DaVinciDTR/DTROperations/ValueSet/$expand

• Must specify ValueSet URL via query parameters.

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.

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.

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.

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.

FamilyMemberHistory describes the conditions, history, and relationship information of a patient's family members.

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.

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.

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.

The ImagingStudy resource returns information related to a DICOM imaging study.

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.

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.

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.

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.

The FHIR Location resource defines details and position information for a physical place where resources and participants can be found.

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.

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.

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.

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.

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.

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.

The Practicioner service covers data about providers of care or other health-related services.

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.

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.

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.

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.

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".

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.

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.

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.

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.

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.

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.