Example wearables integrations and standardizing in OpenEHR using HL7, etc, for GDL CDS tools?

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?

@johngrant4est pointed me to Devices - Devices - Confluence – a large harmonization and integration effort for wearables data.

I imagine the GDL language will eventually support risk scores based on wearables, for example the Apple watch functions as a single-lead EKG and can detect arrhythmia, which can feed into a GDL risk score CDS tool (GitHub - openEHR/gdl-guideline-models: Common clinical models in the forms of openEHR archetypes and GDL guidelines).

Not sure who to ask about this but looking forward to figuring out what the lift would be to make this happen!

Thank you for all your help,
Jaan

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

  1. Very high volume with most of it repetitive and not very significant from a long term view of a person’s health.

  2. Only an extremely small subset of these values will trigger a decision support rule

  3. Predominantly write operations. So any repository used should be write optimised and support constructs such as batch write, input queue etc.

  4. 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.

I hope that helps.

regards

2 Likes

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.

regards

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?

Sorry. You are right.

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.

regards

Alternatively use FEEDER_AUDIT - which can be applied to any LOCATABLE node

That allows Identifiers at the top level e.g could be a FHIR resource identifier, Id or a some other uniqueID for the data item

https://specifications.openehr.org/releases/UML/latest/index.html#Architecture___18_1_83e026d_1433773264057_196291_6114

and more detailed info about he source system if required.

https://specifications.openehr.org/releases/UML/latest/index.html#Architecture___18_1_83e026d_1433773263740_183956_5413

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.

Feel free to pick up the stalled Discourse thread: Physical activity archetypes; exercise, steps etc from apps & devices

…and perhaps have a look at the student projects linked from GitHub - regionostergotland/Physical_activity pages 28+ in the initial student report contains some screenshots.

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.

If you want to follow clickable links in the image below, it is slide #30 from 2020-12-07-Vebjørn+Erik-openEHR-Norwegian-archetype-governance-v4.pptx - Google Präsentationen

Translation hints: tvilling = twin, ofiltrerat = unfiltered, filtrerat = filtered, berikat = enriched, självvald lagring = (patient’s) own choice of (private) storage, Regionens lagring = Storage at helathcare provider/region