I want patient to give authorization to openemr from their wearables like fitbit, through a module

Fitbit does not allow authorization inside iframe and openemr is currently adopting iframe for every page created. How do I go about this please?

Fitbit recommendation
The recommended and officially supported integration for web applications has always been to redirect the user away from your application to the authorization page in the primary browser window or a pop-up. The authorization page then redirects the user back to your application.

If you have the recommendation, why don’t you follow it?

1 Like

The recommendation won’t work on the current architecture of openemr. That is why I need help @juggernautsei

why can’t you pop out of OEMR into a new window. Look at the tab log in the billing manager. It pops out into a new tab.

So how about the redirect page on openemr how will I achieve this?

You want to use Fitbit as way to authenticate into the system?

No I want patient to give openemr authorization to access their Fitbit data @robert.down

I think maybe I’d look at this differently. If it were me, and I was writing this integration. I would look at the to systems as completely separate entities that probably should never talk to each other.

I would first write an application that interfaces with fitbit. This takes all the openEMR complexity out completely. As openEMR changes, this application doesn’t have to. I would then save this fitbit data into a database.

Next I would start working on getting that data into openEMR. You have 2 choices here. You could have this new application post back to the openEMR FHIR API’s. Now I don’t know much about them, but I did something similar with EPIC FHIR API’s in the past.

Another option would be to create a module in openEMR that has a service that polls the new program for updates. Once an update is found, download the update, mark the data as retrieved. However you’d like to make that happen. Then save that data into openEMR where ever you’d like that saved. Personally, this is the route I’d take. you would avoid any hard authentication stuff. (hard only for the fact I don’t know how to do it.) You would have control of how you want to authenticate to your application.

So in short, the patient would have access to this application and possibly use single sign-on using with the patient portal. I don’t know much about the signing on abilities of patient portal, but if it does have OIDC support then theoretically using an authentication service like Azure B2C you could make it all seamless.


@brad this is the current implementation which has not been fully completed. But we had the taught of complexity of setting up this whole systems for any health providers. that is why we wanted it to be independent.
So what we have currently is.

  • openemr
  • openemr smart app from which patient is expected to.
  • openemr module that patient authenticated code and use it to fetch data from Fitbit
    start the authorization process.
  • web app between the emr and Fitbit
  • hapi fhir server

I don’t think complexity would be that bad. There is a level of complexity of both solutions. However I believe separate smaller systems in this case will save you on maintaining code later. It’ll be easier to fix problems when you’re looking at the smaller chunks. Plus if you try to move it all into openEMR you might end up locking yourself into what ever version you’re using to do this. If openEMR were to suddenly change on you, then you may find upgrades nearly impossible.

If you’re trying to do this for systems of providers that have different openEMR installations, I still thing the webapp idea will be you’re best bet. Just decide how you want to handle the multi-tenancy of the data. You could just handle it in database with account numbers and such or go off and make a different db for every system. I personally would use 1 database and handle the multi-tenancy in code and records.

This really isn’t that difficult of system to write. Just be cautious on maintaining it and not to accidently lock yourselves into a version of openEMR that you can not leave.

@brad, I believe there should always be a way out if openemr changes from their current architecture, I did prefer it to be independent and simple as possible for maintainability purpose and other cost, because this supposed to be open.

So I’m confused on what is preventing you from using the Standalone SMART app architecture. I’m trying to understand what is preventing your module from launching a new window tab, redirecting to the fitbit SMART app handling all of the authentication pieces, grabbing your authorization code, stuffing it in the browser’s session storage or local storage, and then doing whatever stuff your app needs to do such as closing the browser tab and returning information from the original launch point you are wanting.

Is the problem that you are feeling constrained by the in-EHR launch profile being in a dialog? There’s nothing preventing you from extending the launch button to do a redirect instead of launching a dialog window for a specific kind of registered smart app. In fact it’d be a great pull request if you want to contribute to this ‘open’ project.

Thank you @adunsulag , I think I just found part of solution from your response, I am not aware you could set smart app to open on new tab.
Also one other thing is, I need to register a redirect url on Fitbit, how will I create one on openemr. Preferable on the module if possible