Companies like https://validic.com/ integrate information from Fitbit, Garmin, Withings, Woop, Oura, Google Fit, Apple Health and others.
Regulations in the EU and North America enable users to request data from any of these wearables companies, and https://www.prifina.com/ enables users to opt-in to their platform and share this data with other apps.
How would this be accomplished on OpenEHR? Have you seen any examples of Fitbit/Garmin/Apple data streamed into OpenEHR?
Hi Jaan,
I believe that the data coming directly from wearables are extremely high volume and may not be directly going into an openEHR repository. The characteristics of this data are
Very high volume with most of it repetitive and not very significant from a long term view of a person’s health.
Only an extremely small subset of these values will trigger a decision support rule
Predominantly write operations. So any repository used should be write optimised and support constructs such as batch write, input queue etc.
Access is often in batches and often involves extrapolation and aggregation of the original data.
So the best strategy would be to consider a time series DB as the primary repository with only processed data of long term significance being added to the openEHR repository. From a GDL perspective, the primary time series repository can trigger creation of a composition in the openEHR repository when required, which inturn can trigger a GDL rule execution.
So, if the many puls rate measurements are in a time series database, how would we hook that up to the EHR? Looking for dreams about ideal solutions (not just copy the desired value). What I would like is to store a link as part of the EVALUATION.pulse.rate.value to contain a link to the datapoint in the time series db and for that value to be displayed in the UI. And when clicking it display the ‘entire’ time series.
We can off course add a linkto any node, but that only gets us inside the EHR scheme.
link supports any url. So you should be able to add the API path to your timeseries DB to achieve something like you are thinking of. But since the actual data resides outside the CDR, AQLs will not pick them up.
An ideal situation may be to duplicate some of the data that is required for regular clinical use into the CDR from the timesries DB. For example while the wearable produces readings every 10 sec, we may want the CDR to only contain hourly data(can be pint of time or an hourly average.)
The link can also be maintained in the composition for the full data set in the timeseriesDB.
From the spec: “ Links should be between archetyped structures only.”
And the link class only has a ‘target’ attribute for a DV_EHR_URI. So only links to EHR data right, or am I missing something?
In that case we may have to include an explicit DV_MULTIMEDIA node similar to how a link to an image in an external DICOM server is added in the composition.
Concerning data from wearables Region Östergötland in Sweden has done some work, including exploring openEHR data structures and also student projects from Linköping University created webapps for extracting and filtering/summarising data from Google Fit and storing in an openEHR CDR.
Regarding decision support based on personal wearables, “digital twin” technology may be even more interesting than GDL. Gunnar Cedersund’s research group at Linköping University do some cutting edge stuff there.