A little more about the sandbox

To help you test your applications, Epic provides both an online testing harness, for playing sample calls, and a full-fledged instance of Epic, configured according to our recommendations, that you can POST and GET data from.

Getting started with SMART on FHIR? Check out the Epic FHIR and OAuth 2.0 tutorials.

If you'd like to get a dedicated OAuth 2.0 client id for testing patient facing apps using the common clinical data set of FHIR resources in the sandbox, set up a new application using MyApps. Additional APIs and FHIR resources are available through the App Orchard program.

How do I access the sandbox?

The sandbox currently offers FHIR resources, a lightweight patient portal for patient-directed OAuth 2.0 linking to external applications, a SMART on FHIR launchpad, and an HL7v2 message validator.
  • FHIR-based resource test GUI: Clicking "Explore the spec" on any FHIR integration points listed on open.epic.com takes you to a GUI web-based test harness that allows you to paste in commands and see the output from the server. The page also includes details about valid arguments and a list of sample data.
  • FHIR resource server: We also expose the server behind the web test harness (https://open-ic.epic.com), so you can test accessing the resources from a terminal or your own FHIR-based application. Different services are hosted on different virtual directories. To get more information about how to call a particular service, navigate to the FHIR resource page that describes the service and look at the endpoints documented there.
  • Web-based patient portal: To allow you to test patient-facing applications, such as those enabled by the Meaningful Use API offerings, we have a lightweight version of our patient portal, MyChart. Following the SMART on FHIR specification, use the metadata endpoint (https://open-ic.epic.com/Argonaut/api/FHIR/Argonaut/metadata) to find endpoints for authorization and token requests. You can also log into our sandbox MyChart at https://open-ic.epic.com/mychart/ to test revocation flows. Since patients are shared in the sandbox, please do not unlink other developers’ applications. To get more information about patient-directed authorization as well as sample accounts, check out our OAuth 2.0 tutorial.
  • Web application launchpad: This set of APIs allows a user to authenticate to your web app with an existing Epic user session. you can currently launch your app using a simple encrypted HTTP Get query string and either unprotected SMART-on-FHIR for testing or SMART on FHIR with OAuth 2.0.
  • HL7v2 validator: Clicking "Explore the spec" on any HL7v2 integration points listed on open.epic.com takes you to a GUI web-based message format validator. The validator allows you to paste messages to validate they match Epic's recommended structure. You can access the validator here: HL7v2 Validator

How do I connect my App to Epic's APIs?

All of Epic's publicly available APIs are accessible through RESTful HTTP calls. You're welcome and able to use the programming language of your choice — JavaScript, Objective-C, C#, etc. — to interact with these APIs. There are also a handful of open source frameworks specifically for use with FHIR-based APIs such as the ones Epic supports.

Can I have access to Epic to see if my testing worked?

At this point, the online sandbox contains only the backend database and logic driving Epic, not the front end. We do not provide access to Epic, a trial license, a shareware license, or a freeware license. If you were able to complete your calls without errors, you are well on your way toward a successful integration with Epic.

If you are writing a web-based application that you intend to embed in Epic, you may find that your application may require minor modifications to embed within the Epic App Container web viewer. We offer a simple testing harness to help you validate that your web application is compatible with the embeddable web application viewer.

So when I finish my testing, everything should just work?

Every Epic organization is a little different. Once you've found a customer who's interested in your application, you'll complete another round of onsite testing to make sure your app has been installed and integrated correctly with the customer's environment.

What is the security model for the sandbox?

Currently, the sandbox web services are unsecured. As we continue work on our OAuth 2.0 implementation of these services, we'll provide a second, secured instance that you can use for testing. At that time, we'll also allow you to register for a sandbox ID and sandbox secret that will allow you to call the secured services.

Can I use your sandbox to test something else?

We're constantly enabling services in the sandbox, so keep checking back. If there are particular integration points you'd appreciate testing, please let us know.

Do you have any other recommendations for interoperability testing?

Check out the CDA validators on the NIST and SITE pages. You can use these to test for exchanges with Care Everywhere.