And i’m grateful to see the initial research for openemr integration. Any type of device integration is very important especially for Institution implementation of openemr.
I’m truly surprised a student hasn’t picked up on these types of projects. They can be fun and creative to implement.
I have a student intern currently working on integrating with cronometer. Unfortunately they don’t offer an API and seem to have no interest in making one. So right now he’s working on processing and visualizing data uploaded via csv files.
We have used HybridAuth based access for users. That component puts a wrapper around various external authentication services including generic OAuth2 as one of the providers.
@sjpadgett is in best position to judge if we can bring portal and REST users into regular users with appropriate role of ‘patient’. That will eliminate duplication of the authentication mechanism.
We probably need to provision for users of type ‘device’ and be able to log and control the updates coming from that session.
Would you be able to elaborate on what you are planning to do exactly? Is the shared link an attempt to replace the current authentication platform of OpenEMR?
That shared link just shows how we enabled OpenEMR users to bypass standard login process by using configured/enabled OAuth2 or OpenID authentication services. In our case on the standard logon screen we show a set of available auth services. If you click Google and you are logged on to a Google account, HybridAuth will handle OAuth2 mechanism to validate that open session. In response, Google will confirm and provide certain account details. We then use those details e.g. email address and find unique user with that email address to grant access.
Here’s a summary of my initial understanding of this undertaking for posterity and assistance in planning. Copied from a slack conversation so it looks pretty conversational.
I think this would be a very popular feature so I believe it would do well to be integrated into the core openemr codebase instead of as a module.
There’s a couple things that should need to happen to for an administrator to enable usage. Under Administration -> Globals -> Features menu you’d want to add a checkbox that says something like “enable fitbit via onsite patient portal”
That might initiate something like a popup directing them to the Administration -> globals -> portal menu and tell them to enable onsite portal access by clicking the checkbox and configuring the site address if they haven’t already.
You’ll want to add a setting which is autopopulated by the text from the onsite portal address followed by something like https://yourwebsite.com/openemr/portal/fitbitAuthentication you might need http instead of https based on their settings. Then provide instructions on how to have them register their clinic for access to fitbit’s web API. To do that see: 2. Register your application to get API client credentials. https://dev.fitbit.com/build/reference/web-api/
They will need to create a fitbit account for their clinic.
To add the menu items/checkboxes you’ll probably want to see /openemr/interface/super/edit_globals.php @sunsetsystems appears to be the author of this file so you may want to ping him about adding a new feature to this screen.
Once the clinician has turned on the patient portal and said they’d like to enable fitbit access then you’ll want to focus on writing code to obtain patient permissions. Next you’ll want to look at code in the openemr/portal directory. @sjpadgett did a lot of work on the onsite patient portal so hopefully he can be a resource when integrating your code into the portal.
The way patient permission works is you have a patient click a link that directs them to a the fitbit’s login page where they select what information to share and they send back an access token via oauth to the site specified in the fitbit api access application they filled out earlier. There are some different permission options so you’ll want to store what fitbit data the user gave permissions for. E.g just sleep, everything but GPS data, etc. in a mySQL table somewhere along with the token. This exchange takes place via OAuth2.
There’s this repository called guzzle. I think it can handle some of the oauth stuff for you. I believe it’s located in openemr/phpfhir/vendor/guzzlehttp
However, there’s plenty of other example implementations of fitbit api authentication using php and javascript linked above.
To test authentication and access, you’ll need access to a fitbit account (ideally a physical fitbit,I have a spare and can enter data for you) and a public IP. If you put in a pull request on github and put your code in it, @brady.miller should be able to help you put an OpenEMR instance with your code online in the “demo farm” https://www.open-emr.org/wiki/index.php/Development_5.0.2_Demo
You’ll want to write code to pull the new data from the fitbit servers at some frequency, perhaps every day, every week, or maybe even a custom frequency per patient.
There is another option, called the fitbit subscriptions web API, this is where you “subscribe” to patient fitbit data and the fitbit server automatically tells you when there’s new data available. You can probably skip this unless it’s easier for you.
You’ll need to maintain a table of patients, their tokens, and data access permissions in the mySQL database along with different tables for their data referenced by patient ID(pid) I’m pretty good with MySQL and can help with this part.
For plotting of the data you import you can try chart.js. You can load it by importing globals.php it’s in directory openemr/interface/globals.php Your code will be running in openemr/portal/some other directory so you’ll need to go up a few directories to openemr and down into /interface to grab the what you need from globals.php. It and other repositories are stored in a directory openemr/public/assets
One you get the data in the fun part starts. You can make a new tab on the patient dashboard. Or maybe use the pre-existing external data tab.
Actually thats not nothing, that is something I’ve been planning to do. More on improving the existing authentication system of OpenEMR. Thank you for the integration, couple of questions;
Since the update was a while ago (commit), and you’ve updated the branch as well, is it safe to assume the latest code on your repo contains the integration with HybridAuth?
This has been discussed numerous times with a general inclination to incorporate.
I have some reservations, however, i’ll open a new topic and see where it goes.
I’ll be more than happy to help integrate where I can.
@RachelEllison
My GSOC proposal was based on PACS Server Integration. Fitbit API Integration suits me over PACS. I created some PRs but nothing related to PACS. As I haven’t actually started working on PACS Integration so changing my proposal subject would mean no loss to me except a couple of hours. Would Fitbit API Integration make up for an appropriate GSOC proposal?
I beg you to stay with this. It is very important to advancing OpenEMR in institutional settings and very useful in practice setting.
If you need help, please speak up. We have folks that can help i’m sure.
@RachelEllison,
Thx for summarizing expected approach to fetching data. But something not clear from a clinician’s perspective is what happens next?
When a patient in my practice enables this feature, are we expecting someone to pull up dashboard for that patient on a daily basis and see if everything is OK? Since that is impractical, does the scope of this integration include automated rules engine that will alert staff about exceptions - which I suspect is patient’s expectation when they enable the link.
We had same issues with automated receipt of lab results and the lab occasionally started sending results for orders by other providers.
How to store the huge amount of data about every step or heartbeat of each patient deserves its own dedicated conversation.
Fitbit and such consumer products are transient. We have seen huge issues - both legal and moral - when any data from external source becomes a record in an EMR and provider does not even know about it. It is akin to patient expecting the physician to follow every patient 24 hrs a day and pay only for 15 minute visit a year.
On the other hand medical devices emit actionable data and there are existing parallel mechanisms that will alert recipients about transmissions.
Thank you. Please don’t scare an old man like that!
Google has to be very interested in any projects that deal with interop. In today’s healthcare world it is essential. Besides, it can’t hurt your resume!
I wonder if PRO, Patient Reported Outcomes, is a fit(get it!) here. I’m integrating with FHIR Questionnaire and @brady.miller brought in a module/feature which I can’t remember its name.
It is very important to advancing OpenEMR in institutional settings and very useful in practice setting.