For Developers

 

Self Help Resources

There are a number of important resources available for developers to prepare for the UCSF sandbox:

  • Epic UserWeb - The UserWeb is an online collection of tools and information about Epic. In order to access the list of available APIs you must first create a UserWeb account. If you are a UCSF employee, you can create a UserWeb account at any time. More information can be found on the Epic UserWeb site.
  • Guide to APIs that are already enabled in ACE6 in the Mule Wrapper, to help you plan out which APIs you're able to use.
  • List of available Epic APIs - For an updated list, please logon to the Epic App Orchard and look at the specifications menu under "Build Apps"
  • Epic App Orchard - The App Orchard is where developers can learn about Epic's APIs (documentation, etc.) and list their apps for Epic community members to explore and access. See our App Orchard Quick Reference Guide for more info.
  • FHIR Setup and Support Guide
  • ACE6 OAuth2 Client Setup
  • App Orchard Quick Reference Guide
  • The Epic Interconnect help page, to learn details about how to call these services
  • System to System Integration - Client Credentials
  • How to call APIs in ACE6 directly using Postman
  • How to edit data in Hyperspace in ACE6, in case the data there isn’t sufficient
  • Epic Sandboxes - 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. Choose from open.epic or Epic USCDHI on FHIR.
  • The Slack Channel (UC Tech #ucsf-fhir, requires admin to add)

Development Pitfalls

Here are some of the pitfalls we have learned about over the years when developing these sorts of applications.

  1. Consider the browser. Many application developers start with the assumption that they can do all of their development and testing in Chrome. DON’T BE THAT PERSON. Test and validate in a variety of browsers. Previous projects we have worked on have either lost time or required massive accessibility concessions and workarounds when this factor was overlooked. Not only is Chrome difficult to work within the medical environment for all sorts of cache-related reasons (have you ever opened a form in Chrome and noticed that the previous user’s personal and financial information is auto-complete-saved to it, probably entirely by mistake? Us, too!), it is not the browser that many EHRs themselves use. This may change, but why set yourself up to fail? Which brings us to:
  2. Don’t assume that run of the mill code runs on the EHR browser. Even simple things like type-ahead, when they rely on javascript, have been known to cause problems. The power of being able to launch your application directly from the EHR needs to be balanced against the limitations these browsers impose. In general, the simpler/more accessible format beats the browser you need to open independently, no matter how many bells and whistles the latter may have.
  3. You must test as if you are a transitory user. This is harder to do than to say, but if you are testing an application at your desk, there are things you will get used to that simply will not be acceptable if you are accessing the same application at the medical center. Example: previous applications we have worked on required 10-20 seconds to log into. If you log in once a day, this may seem acceptable, but it won’t if you are using 5-10 computers each day with interruptions to return a page or step into a conference.
  4. Make firewall and other network requests early. The UCSF network team is very busy. Make sure that if you need a server address whitelisted, you do that at the beginning of this whole process. Likewise, if you end up needing to stand up a brand new server, request it very early. This way, after you finish your testing, you are not 3-4 months behind as you await your production server to be spun up, loaded, and whitelisted.
  5. Break the Glass