Question Steve Birnhak · Jul 11, 2024

Epic/MyChart integration

We have a stand-alone web platform (readysetrecover.com) that helps people prepare for surgery focusing on the non-clinical – holistic and logistic aspects (stress reduction via meditation, sleep etc. as well as things like setting up the house, coordinating help from others etc).

We had a meeting with a hospital, and they liked our solution but said their goal is ‘to provide patient education and communication on a single platform'. They currently use Epic and MyChart. In other words, they don’t like the idea of giving patients another site to visit, possibly with a different login, which is understandable.

We can pass data between our site and the hospital EHR system with IRIS for Health, however, this doesn't really address the user side.

Is there any way to integrate that would solve this issue? What do other sites do to create a more unified experience with an existing patient portal? Is there a way to have our site 'live' within MyChart or at least have a seamless sign in to our site once a patient is in MyChart (for example, they'd click a button in MyChart that would take them to our site, with a 'Return to MyChart' option at the top)? Very open to creative solutions here!

Comments

DC AI Bot · Jun 24 Bot

A practical pattern supported by the retrieved material is to keep your platform as an external web app and launch it from the EHR/portal using a SMART on FHIR EHR launch flow. The example shows an EHR launching an external SMART app with a URL containing the required iss and launch parameters, and describes this as a “seamless launch of multiple external SMART apps.” [1]

In that launch model, your app is registered as a SMART client and uses OAuth 2.0 for authorization. The retrieved material explains that SMART on FHIR uses OAuth 2.0, and in the demonstrated flow the launched app receives EHR context, goes through sign-in/authorization, and then retrieves patient and practitioner data from the EHR FHIR repository. [1]

For your user-experience goal, the documents support a model like this:

  1. The patient is in the hospital’s host system.
  2. They click a button/link there to launch your app.
  3. The host system passes SMART launch context using iss and launch.
  4. Your app uses SMART on FHIR + OAuth 2.0 to authorize and obtain the relevant context/data.
  5. Your app presents its workflow as an external experience launched from the host system. [1][2]

The retrieved material specifically supports the “click a button in the host system and open the external app with context” idea. It does not provide evidence that your site can literally “live within MyChart,” nor does it give MyChart-specific embedding guidance. What it does show is the external-launch pattern, not an embedded-in-portal pattern. [1]

If you are already using IRIS for Health on the backend, the example shows IRIS for Health being used as the FHIR repository, the OAuth2 authorization server, and the configured FHIR/resource server for the SMART launch workflow. It also shows that you can customize token validation/claims to include launch-related context such as patient and practitioner identifiers. [1]

On the app side, the retrieved material also points to the SMART JavaScript client approach. It shows using FHIR.oauth2.authorize(...) for the authorization code flow, notes that SMART-standard apps should place this in a launch.html page so a SMART launcher can find the application launcher, and explains that the library handles OAuth flow details and then gives the app a FHIR client for API access. [2]

Note: this code is provided to you copy and paste in OAuth 2.0 tab: [2]

So, based on the available documents, the strongest answer is:

  • yes, there is a standards-based way to make the experience more unified;
  • the documented pattern is SMART on FHIR EHR launch of your external app;
  • this can make access more seamless and context-aware;
  • but the retrieved material does not confirm that MyChart can host your UI inside the portal itself. [1][2]


Sources:

Tell us more:
Don't like the style
Not factually correct
Didn't fully follow instructions
Refused when it shouldn't have
Being lazy
More...
Submit
0 0