DateTime Stamps & TimeZones in OMHE Messages

[Alan]

Hello All:

This is in regards to convenience and helper commands.

While implementing blood pressure, we came across some interesting.
Many devices store multiple measurements so datetime is key.

As written the datetimestamp is in UTC/Zulu. So we need to add a
timezone offset 'tzo' so we can deal with things globally. I added
'tzo' as a proposal. What if more than one reading is in a single
OMHE text string?

The string:

'bp120/80p60 dt20100101:122005Z'

..is fine, but consider the string...

'bp120/80p60 bp100/70p70 dt20100101:122005Z'

The DateTime is ambiguous because we are unsure which datetime belongs
to the reading. Each OMHE message (name/value pair) needs a way to
associate certain information with the OMHE message within the string.

Proposed Solution:

"Each command in the convenience/helper category can be appended to
the base message as a '#' without spaces."

So the following OMHE string containing more than one MESSAGE is
valid:

'bp120/80p60#dt20100101:122005Z#tzo-5
bp100/70p70#dt20100202:185901Z#tzo-5'

Note we are still using the whitespace to delineate between OMHE
messages.

Now we have a way to say which reading was taken when. This simple
extension can apply to other helper commands too. For example a
device id, an id, etc.

Sound reasonable?

Thoughts? Discussion?

Alan

[Alan]

It was suggested that we consider using a different deliminator.
Instead of using "#", use "*"?

Thoughts?

Alan

[Alan]

This was a conversation about datetime and timezones via email that we
wanted to share

>
> Basically I'm suggesting that:
> bp120/80p60#dt20100101:122005Z#tzo-5
>
> is a valid OMHE string w/ an EXPLICT datetime stamp and time zone offset.
>
> The dt and tzo are optional. If they are provided, then this
> is the d/t/z associated with the reading. If its
> not, provided,
> then we just use the time of transmission (like it works now).
>
> Perhaps we should require tzo (if dt is provided) so it
> can be compared to a user's home tzo. We have indicated in OMHE,
> that the date when provided is always UTC (Zulu).
>
>
> Basic format suggested is this:
> YYYYMMDD:HHMMSS
>
> ..which is a standard in XML/XSD. Do you think we should use this
> or something else? Alternate like #y2010m02d26n45s20 ?
>
> In either case, our graphing example will have a toggle where we
> show 'all readings' or 'ideal time readings'.
>
> Sound reasonable? Thoughts?
>
> -Alan
>
> Alan,
>
> I totally agree..when I did a brief experiment with a friend, he noticed some problems with the Twitter API dealing with time zones when it came to deciding who among your friends did the most steps on their pedometer - it becomes a big hassle when you compare my last 24 hours with someone's last 24 hours in California.
>
> I think you're right about the approach and it seems most appropriate for the device that's most "personal" to you to be the gold standard for your time zone. Between you and your mobile phone and your BP meter, the more "personal" device is the phone, not the meter, so the meter should probably stick to what it knows best and not handle a person's body rhythm, unless that is integral to its purpose. For BP, it's not measuring time, just amplitude of waves in your arteries.
>
> We should track these on the Wiki as issues that we're proposing solutions too so other people can chime in on their experience. I've got no experience syncing time zones across medical devices!
>
> Regards,
>
> Ted
>
> ---
> Ted Eytan MD MS MPH
> Washington, DC, USA

>
>
> On Feb 17, 2010, at 1:05 PM, avi...@videntity.com wrote:
>
>> Ted:
>>
>> Agreed. We spent a good deal of time dealing with timezones (pun intended) and getting this aspect right early on. We came to the conclusion that keeping track of date/time is not enough..the only right way to do this is to manage everything in GMT/UTC (aka Zulu) on the backend and keep track of the user's home timezone/offset. That's why we ask for timezone in our signup process.
>>
>> You brought up a good point about what time the body thinks it is. Mobile Phones and many internet appliance automatically adjust when they move to another timezone, however blood pressure meter's I've seen have a clock but the time/zone does not change on its own. I think the best approach is this:
>>
>> 1. Store everything in UTC on the backend along w/ the user's home timezone (i.e. UTC offeset)
>> 2. User should be instructed not to change the clock on medical device and/or software client should be intelligent enough to recognize timezone shifts and still plot in UTC w/ home zone offset.
>>
>>
>> Time and timezones are one of those problems that seem easy on the surface, but can make you pull your hair out when it comes to implementation and practice.
>>
>> Thoughts?
>>
>> Alan Viars

>>
>>
>> --- On Tue, 2/16/10, Ted Eytan wrote:
>>
>> Date: Tuesday, February 16, 2010, 2:03 PM
>>
>> Hi Alan,
>>
>> Well...I was thinking about this myself, because when I did my own sequence of HomeBP, I got really messed up by the time zone change when I traveled. So we need to coach the patient to check their BP when their body "thinks" it's 0600-900 and 1800-2100, I think. But in any event, we have to normalize the time when the reading is to when the body thinks it is. Of course I assume a device will do this automatically and we could also just tell the patient to sms within 10 minutes to get this off the ground.
>>
>> I also think that the starting and stopping of the sequence is really important too, I'll fill out the Wiki page on that, and then I think we may have a start to finish workflow we can test out with our dummy patient!
>>
>>
>> Regards,
>>
>> Ted

[Alan]

All:

Thoughts on if TimeZone offset be required if the date is provided?

After thinking about it for a few days and listenting to the mHealth
talk at the FDA, I think it makes good sense to require it as part of
the date. As a medical/health microsyntax it seems like you would
always want it. This is really important when dealing w/ medical
devices.

I can't think of a situation where you would want a UTC date w/o the
timezone offset. Should we just require? Perhaps use the 'z' which
indicates UTC act as the delinator between the datetime and the
timezone offset?

so something like this...

YYYYMMDD:HHMMSSzTZ

..so for example....

20101217:083001z-5

..means:December 17 2010 8:30:01AM In the EST timezone

Thoughts? Discussion?

-Alan

[Mike Kirkwood]

Alan

This is consistent with what our team has done in our mobile/web apps.

Mobile phones do as well. Think it makes the most sense and support
this direction to support this.

However, a question remains of "where" to require timestamps and if it
is required in all circumstances.

So, a question still remains (in my opinion) on whether the device or
application is required to send it with each new log, or whether the
service (e.g. the twitter bot, or Polka's observation, et al) generate
it (or both).

What do you think we should do for devices that don't have this in
place already? Can the service be designed to do translation and have
that client (e.g. device) tell the service that it's dates are in a
particular format.

I think the decision here will be based on whether OMHE is primarily
for building new applicatinos, or is also supporting legacy and the
appropriate conversions/translations for them to join the ecosystem.

--Mike

[Rob Williams]

Whether the time-zone is required or not, it may not accurately tell you the
user's time-zone - it just let's you accurately record when something
happened.

For example, if SMS messages are coming through an SMSC gateway, the
time-zone on the message is likely to be the time-zone of the SMSC not the
originator. There's at least one major third party SMS gateway whose home
server is in Australia and all the messages that come via that gateway have
an Australian time-stamp - not too useful for figuring out whether someone
is eating breakfast or dinner !

The solution is to do what Twitter does and let the user set their time zone
offset independently. For Twitter it defaults to -28000 and, while many
users never change it, enough do for it to be useful.

So, in summary, consider adding a tz command to OMHE and use that to figure
out the user's time zone. Don't rely on the time zone in any other message
as an indicator of the user's time zone - just use it to accurately adjust
the timestamp on the data to UTC.

[Mike Kirkwood]

Rob,

It's an interesting way to look at it (comparing to Twitter). One of
the differences I see is that OMHE is a 'microsyntax'. And Twitter is
a Service (with an API).

So...the difference is that in Twitter, there is a Profile for the
person. Where is the Profile in OMHE? If one device uses OMHE,
aren't they alone seeing the time zone of their user. E.G., how does
a person who wants their messages to be portable then take these to
another service, or how do multiple services consume these if they
aren't the master profile?

Perhaps another consideration is to consider that there are "headers"
for OMHE messages, and that one thing they know is whether the OMHE
payload is being sent locally to systems that have profile information
about the user (e.g. the offset), and then perhaps there are verbose
headers that are required (perhaps even through interaction with the
user through a question/answer) to find out what is needed to process
that package of instructions.

I'm not against OMHE having a default profile out there in the
cloud...but as of today I don't think that exists. In Polka, we do
the same thing you mention (ask for an offset). But also, we assume
that the mobile device knows the "facts" of the timezone it's in (as
it also assumes this). So, in that scenario, it seems that the client
(not the carrier) has the unique ability to send it's offset.

Anyway, think this is an additional consideration to your suggestion.

--Mike

[Alan]

Alan

We (Videntity) also ask for the user's "home" timezone and manage
everything with UTC internally. Asking for the client's (the device's
not the user's) tz in addition is the ideal IMHO.

Rob's makes a good point...it likely be wrong if you rely on the
transport's/gateway's time. A mobile phone will usually know its
local time, but a device such as a BP meter typically does not have
that ability (this may change in time).

So maybe we should say it is best practice for your server side app's
user profile to store a the user's home time zone. (We've all come to
the same conclusion because all 3 of us already do so....just like
Twitter.) Maybe there should be a best practice for implementation
wiki page?

If I understand everyone correctly, we all agree that when time is
given we want UTC time AND Timezone offset. So if time is provided,
then the timezone is required. In other words a UTC time is invalid w/
o a timezone offset.

If I understand Rob correctly, then you can provide (optionally) just
the timezone (without the time). So you can always have tz-5, tz=-8,
etc etc by itself. Then you could potentially rely on the transport's
time if its reliable. This seems logical to me.

In short:

- 'dt' requires UTC datetime AND timezone offset

for example: dt=20101212:134509z-8

(I'm assuming/suggesting we use the z as the delineator between date
and timezone because this is already a convention and it makes the UTC
time more explicit)

- 'tz' is how you just express the timezone offset by itself...no
time required for that command.

for example:

tz-6

We want 'tz' to mean timezone not 'tzo' right?

Sound reasonable to everyone?

-Alan

> ...
>
> read more »

[Alan]

RE: 'Headers'

This might be a good flag to build into a parser. When our parser
(the fee one on Google Code) parsed a message, it creates a list of
dictionaries. Each dictionary entry represents 1 OMHE message.

We create some 'free extra' name/value pairs in the dictionary for
good measure. Chief amoung them are 'UUID'. In the most recent
development branch a datetime and timezone get created too. If the
datetime and/or UUID is supplied in the message (ideal but longer/more
complex) then we use that, else we generate it from the system. We
use the UUID as a client supplied transaction ID.

It might make sense to add a flag (an additional name/value par to the
dictionary) that indicates if the datetime/timezone was generated from
the client device or we grabbed it from the system. We can add that
to the free parser..makes sense to me.

Would this a sensible way to address 'headers' at the parser level?

As an aside:

You might notice that by creating a UUID and dt/tz we are
approximately modeling the basics for a map/reduce storage such as
CouchDB. We're not doing anything w/ MapReduce just yet but its good
to have the basic plumbing on our transaction model.

Alan

> ...
>
> read more »

[Alan]

That's the "free" on Google Code not the "fee" one.

(I corrected a couple other typos in my last post inline below.)

On Feb 19, 1:28 pm, Alan <alan.vi...@gmail.com> wrote:
> RE: 'Headers'
>
> This might be a good flag to build into a parser.  When our parser

> (the free one on Google Code) parses a message, it creates a list of

> dictionaries.  Each dictionary entry represents 1 OMHE message.
>
> We create some 'free extra' name/value pairs in the dictionary for

> good measure.  Chief among them are 'UUID'.  In the most recent

> development branch a datetime and timezone get created too.  If the
> datetime and/or UUID is supplied in the message (ideal but longer/more
> complex) then we use that, else we generate it from the system.  We
> use the UUID as a client supplied transaction ID.
>
> It might make sense to add a flag (an additional name/value par to the

> dictionary) that indicates if the datetime and timezone were generated from

> the client device or we grabbed it from the system.  We can add that
> to the free parser..makes sense to me.
>
> Would this a sensible way to address 'headers' at the parser level?
>
> As an aside:
>
> You might notice that by creating a UUID and dt/tz we are
> approximately modeling the basics for a map/reduce storage such as
> CouchDB.  We're not doing anything w/ MapReduce just yet but its good

> to have the basic plumbing in our transaction model.
>

[Christopher Boyce]

There is also a little ambiguity in the use of a single datetime. Are we talking about the date that some measurement (like blood pressure) was created/recorded or are we talking about the time that the omhe parser received a text message with the blood pressure information in it (more similar to twitter)?  We may need to record them both, but I think the real advantage is being able to send a reading into OMHE with past creation dates (i.e importing my past years blood pressure readings from my blood pressure hardware). Another point to think about, If the date timestamp is used as a creation/reading date can we assume that if no date was submitted it was created at the time the parser received it? -Chris --- On Fri, 2/19/10, Alan <alan....@gmail.com> wrote:

[Alan]

Chris:

Good point! I agree it could be ambiguous and perhaps a parser should
put both the 'measurement datetime' and the 'received datetime' in its
dictionary. If no datetime/offset or offset is provided in the OMHE
message then, those two datetime values would presumably be the same.
If the datetime/offset or offset IS provided, then the measurement
datetime could represent the 'measurement datetime'.

If the parser handles it like this, and service providers gather
user's timezone in their profile, then all the bases are covered.

- We can handle past measurements and send them later.
- We can understand the difference between transmission and
measurement
- We can deal with users traveling between timezones

(This reminds me of DOD/law enforcement/biometric stuff..the date you
arrest someone is not always the same as the date you book/transmit
their data to the system...so you they keep track of both even though
they are often the same)

-Alan Viars

On Feb 19, 2:21 pm, Christopher Boyce <cbo...@videntity.com> wrote:
> There is also a little ambiguity in the use of a single datetime. Are
> we talking about the date that some measurement (like blood pressure)
> was created/recorded or are we talking about the time that the omhe
> parser received a text message with the blood pressure information in
> it (more similar to twitter)?  We may need to record them both, but I
> think the real advantage is being able to send a reading into OMHE with
> past creation dates (i.e importing my past years blood pressure
> readings from my blood pressure hardware). Another point to think about, If the date timestamp is used as a creation/reading date can we assume that if no date was submitted it was created at the time the parser received it?
>
> -Chris
>

> --- On Fri, 2/19/10, Alan <alan.vi...@gmail.com> wrote:

> ...
>
> read more »

[Alan]

Chris and I were just discussing on Skype...wanted to capture thoughts
here in the public group...

Would it be useful if a 'tiny url-like' service that could grab a
datetime/zone stamp based on IP address?

Also per Mike's comments it might be best to flag in the parser's
message dictionary weather or not the 'measurement time (dt)' was
given.

So the parsed message would have measurement dt, transmission dt, and
a flag indicating if the measurement dt was explicitly provided or
inferred.

-Alan

> ...
>
> read more »