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