Call to the Community regarding VistA and Time Zones

Sam Habiel's picture
OSEHRA is seeking your valuable input. The Department of Veterans Affairs has expressed an interest in whether the Open Source VistA Community has viable solutions on how to allow users from multiple time zones to use a single VistA instance. All feedback and input on this topic is welcome, including: switching the locale on your computer; reworking how we store dates in VistA; don't do it; and others. 
 
This is an important opportunity to advocate for open source, and we encourage the community to submit their suggestions and solutions to info@osehra.org by January 15th 2017.
like0

Comments

VistA time zones

allansf's picture

I am sitting in Honolulu HI and ordering a lab at the Albany VAMC  (Eastern Time zone – lets let daylight saving slide). Blood is drawn 15 minutes later. That will look good on my reporting on how long it takes to receive a sample. If I save the Hawaii time, I am now 5 hours late.  Why is my physical location germane?

We need a specific Use Case to see what we are trying to solve.

like0

VistA Time Zones

Raja Gopalan's picture

So the use-case is this (per my understanding of industry standards).  For this, we would need a table of locales (HI, CA, IL, DC, NY, etc.) and the time zone offset from a good system time (say ET)

The use-case/benefit would be as follows:

1.   A doctor orders a lab at 10 am Hawaii time which is 3 pm Eastern time in Washington DC.  

2.  The culture needs to be sent to the mainland (say Chicago, central time) by 4 pm Hawaii time, analyzed and returned in 24 hours or less.  

3.   Another doctor from Indianapolis (Eastern time) would drive down to review the culture

4.   A proper transport method would be needed to send the culture back to Hawaii (if required)

In such a case, across so many time zones, it is critical that the VistA system be able to manage and track all the time zones involved.  So the process would be as follows:

Step 1.   The system will detect the Hawaii location based on the locale (10 am HI) and save a calculated time of 3 pm ET (system time)

Step 2.  To avoid confusion, the system would record this 9 pm ET and send email alerts to providers in Hawaii and Chicago notifying them of the progress and deadlines, all based on the recipients' local times.

Step 3.   The doctor in Indianpolis would then time his 3 hr drive appropriately, analyze the culture and send it back.  Vists would record the time for his activities starting with ET and finishing with CT but the system would also faithfully translate everything to the correct system time.

4.   A proper transport method would be called to send the culture back to Hawaii by the appropriate deadline.  Again, the system woud record everything correctly so the value of the culture is retained.

Hope this is closer to what you are looking for?

like0

Use $zhorolog for the time stamp instead of $horolog

K.S. Bhaskar's picture

In YottaDB (and GT.M), the $zhorolog intrinsic special variable has four comma-separated pieces:

  • The first two pieces are identical to $horolog.
  • The third piece is the number of microseconds within the current second, and not relevant to this discussion.
  • The fourth piece is the number of seconds that the current timezone is offset from UTC, ranging from -43200 (for UTC-12:00) to +50400 (for UTC+14:00).

Therefore, as a practical matter, $zhorolog is a drop-in replacement for $horolog (it is highly unlikely that any code includes $length($horolog,",")) for application software that is initially not time zone aware.

In POSIX systems, while there is a default timezone, the TZ environment variable of a process specifies the timezone for that process, e.g., EST5EDT for processes operating in US Eastern time (and switching between EST and EDT). Thus, if a record for a blood test order stores the $zhorolog of that order, and if the blood draw is carried out in a different time zone, but the record has the time in the local $zhorolog, and if the lab is in a third time zone, the test result could be in the $zhorolog of the lab. When the person ordering the test sees the results, all times can be converted to his/her time zone by using the fourth pieces of $zhorolog for each record. A nice feature of this approach is that if the person ordering the test is in a time zone that doesn't switch the clock, has not yet switched the clock, or has already switched the clock, s/he will still get the time reported in his/her current timezone.

like0

Several things to consider

Brian Morgan's picture

To do something like this, one would have to consider several things - conversion of data when moving VistA instances from separate time zones to one (if required to make sure the stored times are all in the same zone), data input by users, display of data both to the screen and in reports.

If this were a brand-new system, then I would definitely agree with the above statement regarding the use of $zhorolog as a potential solution, however, given I would expect that there is existing data in the systems, when the databases are merged, a conversion should take place to ensure the raw stored data is all in the same time zone.  A blanket conversion to all VistA systems back into the same storage location would accomplish this step in lieu of during the migration phase (assuming that older code uses $P or FileMan functions to extract time when needed in lieu of assuming there is nothing beyond the second storage piece).  Given what I have seen over the years, I would not make this assumption.  To avoid having to create new date/time storage locations for all timestamps to accommodate this and/or correcting any code that does not use proper data retrieval techniques, I would recommend converting the data to all use the same timezone, leveraging the same format as currently stored, and store this back into the same field to save time/money.

From an input/display solution, I would recommend inclusion of a new field in the user settings that allow time zone selection at the user level for input/output purposes (assuming there isn’t one already - it’s been a while since I have worked on VistA).  The FileMan functions that leverage the time data (both input or output) could then be modified to accommodate the offset based on the user by leveraging the difference between the system time zone and the user time zone.

Another consideration would be in the data transmission between VistA and external systems - as long as proper techniques have been used to accommodate the offset in HL7 data transmissions, this should be seamless given the use of system time in those cases.  Other system interfaces (especially those locally deployed such as CPRS) may require modifications as well to ensure date/time storage is accurate - this is may not a problem as long as the same user credentials are used when data is passed to VistA, but should be considered.

I have been away from active VistA coding for several years, so my assumptions may no longer be accurate, but this is likely how I would solve the challenge given my past knowledge/experience.

like0

Time Zones in Modern Enterprise Applications

Preston Lee's picture

While I'm not familiar with detailed implementation issues specific to VistA and can't even pretend to be competent in M, engineering this into modern client-server enterprise applications is a solved issue. I strongly advise trying to incorporate current best practices to time zones to the greatest extent possible.

General speaking, time zones need to be accounted for at two levels: within the data authority tier(s), and at the user-specific session level. This high-level approach:

  • Works for desktop, mobile native, responsive and hybrid client application architecture styles.
  • Supports the case of time zone changes during a session, such as before/after an airplane trip, or those leaving an application open during a commute across state lines.
  • Is not affected by VPNs or complex network architectures that can result in misrepresentation of user locale in some cases.
  • Provides a layer of security from time-based attack vectors by decoupling datetime trust between client and server processes. 

Data Tier-Level Time Zones

Within a given database, timezones should almost always be included in datetime-like fields. There is rarely a reason to do otherwise, even if deployments are intended to be geographically constrained to a single time zone. Architecturally, I prefer to force normalization of datetimes to UTC at the application tier as a policy, but still retain an explicit time zone in fields such that any data sneaking into the database from external sources may safely deviate from UTC defaults. In this case, time zones can either be force-normalized on subsequent updates to said records by the application, or left intact. Either way, the database is responsible for transparently applying timezone offsets on relevant queries. Simultaneously, clients have no presumption of data time zone alignment with session time zone, even within a single request/response cycle. Thus, the client-side is safe to send/receive heterogeneous (non-UTC) data by responsibly applying offsets, based on session locale.

It is often acceptable and sometimes preferred to not normalize to UTC. The main proponent argument is that it allows for embedding of an additional semantic in the field: the time zone used during origination of the record. I prefer the normalization approach, however, because use cases requiring this don't often occur in practice, are usually ambiguous when they do, and homogeneity is a better goal. Either way, client-side approaches are the same.

User Session-Level Time Zones

Modern operating systems -- both desktop and mobile -- automatically detect and change time zones using numerous methods. This works reasonably well in most applications, and is usually transparent to the user. Simply detecting the time zone from the OS and setting it in a user session-specific field is almost always expected application behavior, with client-side offsets being applied automatically, even if the time zone(s) of underlying data are heterogeneous. As long datetime fields have a timezone, client libraries should transparently accomodate any diffs. Similarly, server-side libraries should automatically apply any zone normalization, when/if necessary.

Providing a feature to allow user override of the automatically detected and session-adjusted timezone, if needed, is usually done at the user level, as opposed to the session level, such that it fixates the user to a specific time zone -- or better, a full locale also including language and currency -- regardless of where they geographically travel across all their sessions. It is not usually a problem to implement, given sufficient language/framework support and a hospitable database. ;)

Preston

like0