I was being impulsive (and maybe selfish?) by choosing whatever was convenient for me. I just totally forgot to consider the importance/implication/restrictions for both the projects for a moment there.
My mind literally told me, “Hey hey hey!!, Would you look at that! Aren’t you experienced with oAuth? Guess it will be easier for you.”.
Fitbit stores all the data. We don’t need to make a record, we can just do API calls when we need data. But still, doing an API call for each patient every day at intervals to check if everything is okay, seems impractical.
Fitbit doesn’t have an alert system for something looking off, yet. While doing API calls and checking if everything is okay might still work for the moment(which still is impractical nonetheless) but won’t be much use when Fitbit introduces their own alert system as Apple did.
Regarding how data is utilized: The whole scenario would need to be kicked off by the patient provider. There is not a need for us to keep current with patients fitbit data but dynamically request data when needed.
I mean, why would the provider be interested in this resource? Whatever the interest, provider would prescribe to the patient what data to track and for what period. At anytime provider could make a request via API to update his encounter tracking form. Also, certain data could be statistically weighted/scored and made available to CDR.
For the fitbit part, i’m at a disadvantage. I haven’t any experience with the device plus, at my age, i’m scared to know what the darn thing would tell me!
Also not sure what type of data sets API provides or if possible to grab date period chunks however, to save unnecessary data accumulation I believe the best implementation would be provider initiated.
Lets say a patient has a pacemaker where provider may be interested with comparing data that can be supplied by a fitbit device with pacemaker data or similar if this doesn’t make clinical sense.
He might prescribe an exercise routine and wants to monitor statistics where he could initiate an encounter care plan or other created custom form to track progress.
Before patient next visit or between visits, provider could request, using fitbit API, the targeted data.
For patient authorization process they would be directed to a custom openemr page to carry out the process either while at clinic or home.
So I tested out two fitbit apps for the watch itself.
QR Codes by Brian Ouellette
And Barcodes by Terry.
No autobrightness.
String types plaintext or base 64 encoded.
Offers QR codes, DataMatrixCode, PDF412 Code(found often in shipping labels), Aztec Code(uses less space, google camera does not appear to support)
Gives you 7 barcodes(linear) and the option to automagically increase screen brightness, for ease of scanning. You need to know the number to type into the phone interface for the watch app.
Encoding options EAN/UPC/Code-128, Code-128, Code-39
UPC stands for universal product code, it’s what gets scanned at the grocery store counter. Can be scanned upside down or right-side up.
If you scan the QR code without having logged in recently it gives the session id is missing error.
Assuming you are logged in already/recently from the browser then we’d still likely need a shorter “vanity URL” to be able to fit it on the tiny fitbit screen.
For a clinician there are another two apps that might be of interest, clean hands, clean cues, reminds you to wash your hands and gives a 20 second timer. Modern Analog has a second hand which will allow you to count pulse/respiratory rate.
There’s an always on display set of clock faces, so you can see what time it is/step counts, count seconds without having to touch the button. (In theory you can light up the screen hands free by rotating the wrist but that doesn’t typically work for me.)
Tap Tap looks nice and minimal. Voyager has a nice look to it. You have to pay for both. Full chrono is free.
Shfit clock calendar doesn’t appear to have a second hand but it does have a very minimal color coded calendar. It costs $1.99 though.