Well informed sources are suggesting that integration with Medicare Data Bases with the NEHRS has now been delivered and that we will soon see our Medicare Data under the relevant tab.
I checked earlier today - and while the screen has changed there is still no information in my record. There really should be some PBS records in mine if it was working I reckon.
I would be keen to have NEHRS watchers check from time to time and see if anything has yet changed with their record.
David.
13 comments:
What about the screen has changed? Mine appears no different as yet.
The screen was differently formatted when you asked for the Medicare Information compared with the very plain one I had seen previously.
There was, however, no actual data content.
David.
I noticed that www.ehealth.gov.au had maintenance pages up yesterday so something was going on...
My organ donor information is now displayed. It matches my organ donor registration in my Medicare Australia record.
And my other records (PBS, MBS and immunisation details) all say "no information available" - which is correct.
However there seems to be a small glitch. There are actually 2 display screens with my organ donor status - one says I registered in 2004, which is correct, and the other says that the 'record was created' when I was the age which I am currently - not in 2004. Also, the time is displayed as : 19 Aug 2012 20:36+1000. I am not sure what the +1000 means?
I do wish they would thoroughly test these releases before before going live with them.
19 Aug 2012 20:36+1000
Not sure but Australia (NSW) is Greenwich Mean Time (GMT) + 10:00.
David.
There is a standard way of displaying dates where time zones are involved. Does it match that? Australia does have more than one time zone, so it may make sense to include time zone.
Yup, I'd guess timezone. I have some data as well, mine is 19 Dec 2011 00:00+1100. That would be daylight savings time.
How a system deals with time is a good indicator of the analysis that went into its architecture.
Australia (unlike Singapore) is a multi-timezone country.
That would suggest a number of things:
1. Each record and activity associated with a record should have a timestamp, based upon some universal standard (e.g. UTC)
2. A patient should be able to indicate what time zone they would like their record and associated data to be displayed in.
3. someone viewing a record should also be able to indicate how time should be shown.
The ConOp is silent on most issues regarding time, although it does make the statements:
"All downloaded and printed clinical documents and views need to be clearly marked with the date and time of download/printing", without stating what time.
and
"The audit log will record the following information:
• The Date and Time that access was obtained (UTC Time)."
In other words, the only place where time stamping was considered to be important is in the audit log.
Not a lot of thought seems to have gone into the needs of the patient or healthcare professional. If that thought has occurred, it doesn't appear to have been documented be in the ConOp.
Time is critically important in something like an eHealth system. The order in which events occur, the ability to match events and when an event occurred all have high importance.
My guess is that deep in the bowels of the technical documentation is a requirement to timestamp (using UTC) all events.
However, IMHO displaying time data to end-users in UTC is not acceptable. Mistakes can easily be made in reading such information.
And trying to rely on someone's registered address to determine the timezone for display is a bad assumption.
I do hope this has all been thought through.
Hi Bernard
A great deal of thought goes into display of the timezone information, though since every data item has it's own considerations, I can't speak for all of them.
Generally, systems need to store a timezoned value. That can be done by storing UTC, or a specific timezone, or by fixing in the context of the system that all things happen in a single timezone. If you store UTC, you still need to determine which timezone something occured in, and this can be laborious. Most feeder systems assume that all things happen in single timezone, even when they don't. This is not something that the pcEHR can fix.
When it comes time to display the date, then the question is,hould you display it in the timezone in which it occured, or the timezone of the viewer? The answer to this is not obvious. And the usual answer is, in the original timezone, since the most common use of times is to place an event in the context of the local day and associated procedures. It's unusual to need synchronisation between events across timezones in the context of a person's healthcare - though it may happen in border areas when a patient is transferred from one state to another during an episode of care. However, in these areas, staff are usually alert to these issues - as long as the system displays the timezone.
So in my systems, I no longer store the date as UTC - it loses an important piece of information.
However for an audit trail on a national EHR, which is effectively timezone neutral, a UTC date makes perfect sense. Note that the reason the ConOps doesn't discuss other dates is because most of the them are inside the clinical documents, and subject to other governance (and many long "discussions" in many forums).
Since browsers do send the timezone, it would seem reasonable to display the audit trail in the timezone of the browser. On the other hand, if it doesn't, what else could one do?
I can see my record now.
It looks to be displaying data in the timezone it was provided - so it gives local time, and then the timezone after (e.g. +1000).
This makes sense to me - local time, but also telling you what zone that local time was in.
The audit log I know for a fact is stored in UTC, and displayed in NSW time.
Browsers do not reliably provide timezone, and also there are issues where a user changes timezone settings on their computer during a session that cannot be reliably addressed with current browser technology.
Graeme,
I don't disagree with anything you've said, however I still ask the question: "has this been thought through?"
According to one of the commenters "the time is displayed as : 19 Aug 2012 20:36+1000"
Which would indicate that there is no concept of timezone on the display. Not very user friendly.
And re using the browser's timezone, is this trustworthy? Do all computers sync with time.windows.com? Should this be assumed?
IMHO, the ConOp should have at least flagged this as a potential problem or issue.
If the system is to be trusted, there needs to be an indication that this is an area where the problems have been minimised. Otherwise the doubts just continue to grow.
HI Bernard
I think you're actually asking the question "has been thought through to my satisfaction?".
I can't speak to the audit trail - not my area. But in general, yes, this has been thought about a lot. It's hardly specific to health either. Which is probably why the ConOps didn't address it.
"Which would indicate that there is no concept of timezone on the display. Not very user friendly."
I don't know. I presume you mean, that somewhere on the screen - as in, *somewhere else*, you'd show the timezone, and then just put all the times in that timezone. That's be friendlier, but potentially dangerous, if some dates hae no known timezone. Then what do you do? displaying the timezone on every date is safe,
because there can be no confusion.
So you have here a tension between safe and friendly. No prises for guessing where a government program has to end up.
Grahame (My apologies for getting your name wrong earlier)
We can probably go on for ages discussing the ins and outs of displaying the time and boring the average reader.
And I know you indicated that the audit trail is not your area of expertise, however, looking at
http://aushealthit.blogspot.com.au/2012/08/the-nehrs-audit-trail-is-bit-of-joke.html
Approval Date/Time - Operation Performed - Organisation Name - Role- Access Condition- Action Type- Subject -Type Subject
And here is the content.
05/08/2012 09:09:05 AMgetConsolidatedViewIndividualReadIHIxxxxx01181142493
The ConOp specifically says that the time in the audit log should be UTC.
It would appear that the audit log quoted above has not used UTC.
AFAIK, UTC should use a 24 hour clock, not AM/PM. And if the raw data is in UTC and it has been converted to local time then there should be an offset.
A great deal of thought may have gone into the display of the timezone information. However, it seems that it hasn't all filtered through to implementation.
And I don't think it's a tension between safe and friendly. In this case it is a matter of getting it right.
Maybe someone who is familiar with this could set the record straight (so to speak). And those who have access to their audit log might keep an eye on it to see if gets quietly changed.
Post a Comment