A lightweight REST-based access layer for standard HL7-defined data models. Read the spec
Get FHIR'd up! Epic's Sandbox now supports DSTU2 resources. All resources below are supported in Epic's 2015 release and forward.
New to FHIR? Check out our tutorial to get started!
The FHIR Condition resource defines detailed information about a Condition, problem, or diagnosis relevant to the health of the patient. Conditions are typically associated with other resources, such as the reason for a prescription, procedure, diagnostic test, etc. A Condition might be acute or chronic, but it is not used to represent an adverse reaction or an allergy intolerance.
using Chrome, Safari, or Firefox ("FHIRFox"??).
Click the button. Go on.
|Relative URL||FHIR Interaction||HTTP Method||Action|
||Search||Get||Retrieve Condition resources using the specified search criteria.|
The Search interaction enables the client to query for all problems associated with a given patient's Conditions. The client, having established the patient in question, now wishes to retrieve the list of that patient's problems or documented health concerns. Currently, Epic's sandbox supports querying the folloing search parameters:
onsetsearch parameter will return all active conditions in addition to other data returned in the search.
|Parameter Name||Parameter Type||Description|
||Reference||Search for Condition resources using one or more server ids (equivalent to one or more
||Reference||Search for Condition resources for a specified patient ID.|
||Token||Indicates the type of Condition resource associated with the patient. The standard FHIR category code of
||Token||Further refine a search for Conditions by providing a status of the condition. By default,
||Date||Further refine a search for Conditions by providing by specifying a date or range of dates for when the condition first affected the patient. Note: all active conditions will be returned in the response in addition to other data returned in the search.|
||Returns all Conditions for Jason Argonaut.|
||Returns all resolved Conditions for Jason Argonaut.|
||Returns all Conditions for Jason Argonaut of category healthConcern.|
|Relative URL||FHIR Interaction||HTTP Method||Action|
||Read||Get||Retrieve details about Condition
The Read interaction enables the look up of a Condition resource by a constant server ID. Clients can store only the server ID, and with a single request, retrieve the most up-to-date information about the Condition. Read interactions typically begin with a client having previously established a relationship, often through querying for patients through the search interaction.
Condition Create Interaction
The create request sends a Condition resource through the request body to the server. For more technical details on our implementation of this resource, check out our App Orchard program.
When things go wrong, the Epic EMR responds with an error code and a human-readable description to describe the incorrect submission. Currently, the error code is not included in the REST version of the specification, but it is provided here for your reference. These codes are meant for developer use only - they should not be presented to end users. Instead, your application should interpret the codes and provide user-friendly resolution steps when data cannot be filed.
FHIR Errors come in two flavors:
- Fatal Errors cause the response to contain no results and are usually due to requests from the client processed as invalid - missing or invalid data in the request, unauthorized access, or expired content in the system.
- Warning Errors accompany a successful response and are used to indicate that part of a request could not be fulfilled - for example, if a status is unknown, but the request can be fulfilled, the API will return the data and indicate that part of the request couldn't be understood.
FHIR Error Codes
|4100||Fatal||The resource request contained an invalid parameter||Invalid parameter such as a non existent patient ID:
|4101||Warning||Resource request returns no results||A request for data that was otherwise valid but no information was documented or found (i.e. a patient with no pertinent implanted devices, or a demographic search where no patients met the search criteria).|
|4102||Fatal||The read resource request contained an invalid ID||Invalid Resource ID:
|4107||Fatal||The read resource request has been merged||Requesting a Patient which has been merged - in this event, in addition to the error response, we will respond with an HTTP Redirect status. To browsers and many HTTP clients, the redirect will be transparent.|
|4110||Fatal||No parameters are provided in the search request||An invalid search request such as :
|4111||Fatal||Required search parameter missing from request||A request missing a required parameter (such as the patient):
|4112||Fatal||The resource request contained an invalid combination of parameters||A search containing multiple different patient ID:
|4113||Fatal||Session ID for cached search results has expired.||Making a request for previously accessed paginated search results after the search has expired.|
|4115||Fatal||Required search parameter has an invalid value||An invalid parameter required for searching:
|4117||Warning||No CVX code for Immunization resource||Request for an Immunization resource without a documented CVX code.|
|4118||Fatal||User not authorized for request||Request data that the authenticated user is not allowed access to view (i.e. a patient asking for data about a stranger's allergies).|
|4119||Warning||Additional data may be present for patient||Request data while authenticated as an authorized patient or patient proxy. Inidicates that data available to the patient may not be the complete medical record within the system.|