Contact Us

Contact Us

SMART on FHIR F.A.Q

SMART on FHIR app development and integration with EHRs

Well, there are two modes that a SMART on FHIR app can be launched. EHR Launch and Stand Alone Launch. In EHR Launch, the user of the EHR would launch your SMART on FHIR app from within the EHR. So for example, users of Cerner will launch a Technosoft EHR Launch SMART on FHIR app from within Melimium software and users of Epic will launch the SMART on FHIR app from within the Epic Hyperspace software. The SMART on FHIR app will be shown within the Hyperspace/Melinium+ in the Bottom right mainframe. (Top frame and left navigation bar continue to show Melinium or Hyperspace content).

For the stand-alone launch, the SMART on FHIR app is launch from the vendor’s app. When the SMART on FHIR app is launched, the EMR’s login screen is shown to the user. Users would enter their login credentials for the EMR (ie Epic, Cerner, Allscripts, Athena, etc) and after the user is authenticated an authenticated token to the FHIR server is passed to the calling application. From there the calling app can call the FHIR server and fetch patient data.

Usually, each vendor that we work with, has some part of their current software’s UI that they would want to incorporate into the SMART on FHIR app. We can help them incorporate the UI into a SMART on FHIR or we can just set up their SMART on FHIR environment and let their engineers do the UI part.  And along the way, we provide consultancy if their engineers get stuck or need help with FHIR or any other part of integration

Technosoft deals with this issue with what we call a chain of trust solution. With EHR launch if someone is calling a URL of your SMART on FHIR app, this call will include an authenticated token to an FHIR server. Your client Hospital, at the time of setting up the SMART on FHIR app, will provide you with the URL to that FHIR server already and that FHIR server will already be whitelisted in your system. So if you get an authenticated token for that whitelisted FHIR server then you would know that the caller with those credentials is a legitimate user of Epic/Cerner/Allscripts etc. EHR and you can trust this user since Epic trusts this user. Further authorization levels can be implemented based on the user access and credentials passed by/to your smart on FHIR.

You don’t need to involve Hospital unless you are creating a specific application for them or you want to use their App Orchard account, (if they allow you a minimum fee for EPIC App orchard account is $5K and $15K if you want to use their Non-SMART based APIs). If you are creating a SMART on FHIR application like Technosoft’s meds compare which can be used by any Hospital you just need to test your application with Epic sandboxes and make it compatible using their compatibility tools and upload it to App Orchard Gallery. An interested client will then contact Epic to integrate your application with them.

Smart App Store is a free app store where developers can upload their smart on FHIR applications free of cost. It was designed so that people who are interested in your application can see a demo of the application with Smart on FHIR sandbox. In order to sell your application, you would need to upload your application on App Orchard  Gallery (in case of EPIC) then anyone (client) who is interested in your application will contact Epic and then Epic will set up your application for them and will involve you as well. There is a concept of enabling application keys for a client and we do that when Epic setups the application on the client’s environment. You don’t have to implement anything regarding keys, it is a feature from EPIC.

It depends on how the app is configured, it can be shown only to a specific set of users or all users depending on the need.

Epic, In their Hyperspace desktop application, Allows launching of SMART on FHIR app from the top menu bar, sidebar or at any specific workflow feature.

You need to think about the data and the UI. Data as it relates to the FHIR version. Each EHR has a different level of FHIR support; some are still at DSTU2 level and some provide support at STU 3 and beyond. So depending on the FHIR APIs used, this can be a factor. Secondly, the SMART on FHIR app is served in an IE container. And What version of the EHR is installed, the IE support will change. So, for example, Epic 2015 Configuration 10001 supports IE 11, Epic 2015 other configuration support IE10. So UI wise, one will need to make sure that their SMART app is compatible not only across the EHR but also across different versions of the same EHR.

SMART on FHIR is basically patient-centric solution and SMART on FHIR allows one to work with a single patient patient. There are ways to get a collection of patients via encounters and other FHIR collections but usually, those are not easily exposed by the major EMR vendors in their FHIR implementations. Please see our article(https://techno-soft.com/integrating-smart-app-with-epic.html) to see more info on this.

Yes, we can consume FHIR API’s on backend server using “fhir-net-api” for .net. But according to my understanding authentication (OAUTH 2.0) will be done on the client-side and then we can consume FHIR APIs at the backend using the obtained token.

Yes, for one time someone will need to authenticate from client-side and after that, we can use the token returned from EHR FHIR authorization server. There is an option to define the “offline_access” scope while sending a request to the authorization server which means that it will give us the ability to refresh token (in case of expiry) on our own and the user would not need to authenticate again and again.

FHIR is a standard that is used by major EMRs. So if your use case requires general data access that is available through FHIR and is commonly exposed by major EHRs through FHIR then SMART on FHIR will be the way to go. So that you can re-utilize your SMART App code in multiple EHRs. But if you have a specific need and would want to get data from an EMR that is not available or exposed through FHIR by the vendor then you would want to use the Vendor’s proprietary APIs for each vendor.

If your web application can show PDFs then it shouldn’t be a problem to display it inside the Hyperspace as well.

In order to display the PDF in the web application, you will need a good javascript library to do that since most browsers will just download the PDF once they receive it from the server-side.

Please see below two screencasts showing PDF rendered in HyperSpace Test harness.

HyperSpace Simulator: https://screencast-o-matic.com/watch/cqllXjvcWB,
Hyperspace Desktop Testing Harness: https://screencast-o-matic.com/watch/cqllX0vVcR

There are many factors to consider here because the behavior of Epic and web application will be different in each case. We will need to know the EHR, EHR Version and Launch Type information before we can provide the actual answer.

In short, with the latest version of Epic, we can get the NPI in case of an EHR launch.  However, it looks like there is no way to get the same using Standalone launch

Again it depends on factors like  EHR, EHR Version, and Launch Type information. In the case of the EHR launch, we can get some Providers’ data attributes like NPI, ID, Name.

In the case of standalone launch, we can call the /introspect API endpoint that is only available in Garden and Terrace tiers. From this API response, we can get the user’s ID and then we can use FHIR resource Practitioner. Read with the retrieved userID to get more information of the practitioner like name, gender, and photo.

This process might simplify with latest versions of Epic as then Epic will be OIDC compliant.

PractitionerRole.Read (STU3) and Organization.Read (STU3) could be useful here.

Epic provides a testing harness to test the functionality of the app in case of EHR launch (embedded app). This is windows desktop application with a web view just like Hyperspace. So this is almost the exact environment setup as of EHR Launch from Hyperspace. In the README file they have provided the details for the configuration of this testing harness which gives us the idea about the compatibility of the Epic Version with IE version, i.e.

Epic 2012 + IE8: 8000

Epic 2012 + IE9: 8000

Epic 2014 + IE9: 8000

Epic 2014 + IE10: 8000

Epic 2014 + IE11: 10001

Epic 2015 + IE11: 10001

Which means as of today it is safe to assume that most Hospitals will be running Epic Version > 2015 and making the app IE11 compatible should be enough. 8000 and 10001 are just the configuration values for the software.

Introspect API endpoint can be used at any time to get the information about the passed in token. Again it is Epic’s Private API and is only available in Garden and Terrace tiers.

Technosoft provides multiple levels of support for companies considering SMART on FHIR implementation. Following are a few options:
  1. Technosoft can provide consultancy to your technical resources and help them create their first SMART on FHIR app themselves.
  2. Technosoft can reuse your application code and have our team create an end to end solution for you.
  3. Technosoft can become your outsourced Integration Department equipped with an Integration Manager. We talk to your client hospital’s IT folks on your behalf and help you finalize the workflow that will best suit them and you for the integration and SMART on FHIR app development. Most of our customers do not have years of healthcare integration knowledge. We usually fill that missing piece of knowledge and help them add major EMR users to their customer base.
We are collecting FAQs for the SMART on FHIR app development and integration with EHRs. If you have any particular question, feel free to send to us, we will be happy to answer and add here if it is been asked frequently.