Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This article pertains to: INFORM (V2)

The Validic Inform API suports Dexcom CGM data as intraday, or high-frequency data. But you already knew that.

What you may not know is that the implementation of the Dexcom intraday data includes some things that are worth calling out to ensure that you are properly capturing all possible data for your patients.

Historical Data

Validic captures a maximum of 7 days of Dexcom historical data. This would be the 7 days prior to the Dexcom user first syncing to Validic. While Dexcom may be able to have more than 7 days of historical data, Validic chose to only pull in 7 days due to the sheer volume of intraday data that would have to be captured, stored, and then made available in the Inform API.

Getting ongoing data from Dexcom

As noted on this page,https://helpdocs.validic.com/docs/high-frequency-data , Validic is getting the CGM data from Dexcom in 5 minute intervals via hourly data pulls. Each new hourly pull of data from Dexcom looks at the timestamp of the last record received and then adds 5 seconds to that time to look for new data. Because of the 1 hour delay that Dexcom has on the CGM data, this means that each payload would include the readings from the previous hour. For example, the 10am payload would include the records from 8am to 9am.

Duplicate Data

If a patient fully disconnects Dexcom from their Validic user and then reconnects that same user within 7 days, it is highly likely that the data pulled in upon reconnection will contact duplicate data that you have already received. Normally you would use the Validic "id" and "checksum" to check for data you may have already consumed. This will not work for the Dexcom CGM data. You would want to check the "time" and "value" pairs of the records to check for possible duplicates.

Timezones

Validic does not get timezone information from Dexcom. Therefore, the user is asked to provide their home timezone when connecting to Dexcom via the Validic Marketplace. If they had previously provided this timezone information, they will not be prompted for it again. The offset_origin for Dexcom will be "user_defined".

As a result, if a user is traveling across timezones, their Dexcom data will still show their timezone (utc_offset) as their base or home timezone. If this same user has other devices in use, like Fitbit or Apple Health, that do provide updated timezone information from the user's phone, you may see different utc_offsets depending on the data source.

  • No labels