No News lately on the conecctathon.
Is this still going on in private email sessions as it was before as I
complained about?
Or has it just been dropped completely since Sinji submitted his
documents?
--Tim
Hi, Tim
I submitted a proposal and now it in in the review process. I have not
received any review document from the office of MEDINFO 2010. When will
we receive the reviewers' comment is not described explicitly in the
medinfo site, but I guess Feburuary 2010 from the experience of former
medinfo.
I believe that our proposal will be accept, but it is not determined.
So I am waiting the result of review and preparing Ruby codes.
Otherwise, we have to expose each project to connectathon even if our
manuscript rejected.
Do you have any plan to go on?
Best regards,
Shinji
Well, yes. I have a plan. But it would be nice to see the document
that you submitted on our behalf.
Since Sam Heard was adamant in his faith in your ability to lead this
effort I'd like to know what your plans are for putting the connectathon
together. I've stated my initial plans on the wiki but I'm not certain
how valid they are now if this event is being run by Ocean Informatics
and the openEHR Foundation?
--Tim
Hi Tim
I can’t speak for the openEHR foundation, but Ocean is certainly not planning to run this. We have said that we want to be involved, as it seems like a really exciting idea, but not sure where the idea came from that we wanted to run it…
regards Hugh
Hi Hugh,
Well, As I said; the idea came from a series of off list discussions
that your CEO (and other Foundation board Members) was involved in and
concerned statements that he made about how he wanted things done and
who he wanted to do them. So, I assumed the CEO spoke for the company.
Seemed reasonable to me and their silence seemed to be agreement.
But that wasn't the point. The point is that KOBAYASHI, Shinji
submitted the papers at the last minute and as far as I know I am listed
as a co-author on at least one of them and I have never seen a copy of
the final submission. They (IMHO) should be posted as planning
documents on the wiki (shouldn't violate any pre-publication rules)
There hasn't been any planning/discussion going on since the papers were
published. No timeline set for testing etc. Just curious. Are we just
going to wait to see what happens?
--Tim
Hi Tim,
Sorry to late response. I have been troubled.
I list up what we have to implement for connectathon bellow:
i) Connectathon scineario(done)
http://www.openehr.org/wiki/display/resources/Connect-a-thon+Details
ii) Design archetypes and templates of each scene.(one month, Dec 2009)
iii) Determin the formalism (XML?) for each templates/archetypes. (two
months, Jan-Feb 2010)
iv) Prepare sample formalisms(XML?) for each scene. (two months, Mar-Apr
2010)
v) Fix transfer protocol(Web service?), (two months, May - June)
vi) Prepare test server which act as reference of this
connectathon. (two months Jyly-Aug 2010)
I realised we do not have much time to do them.
I cannot resolve every step only by myself. Please help me. This
connectathon needs many peoples' help.
I realised we do not have much time to do them.
I cannot resolve every step only by myself. Please help me. This
connectathon needs many peoples' help.
I'm sure that you'll get enough assistance.
So there's only 1 journey, right? I think the encounters could use
some date-times attached to them.
A suggestion for tackling the first problem area mentioned: during the
connect-a-thon the connect-a-thon coordinator (c24r) should run a
time-server, to which the machines running the health information
applications should sync their time with (say every 10 or 15 minutes).
The c24r could then use the time-server to 'fast-forward' through time
and have every machine update their date and time within 10 or 15
minutes.
Another idea might be to use a Google Wave to broadcast changes
real-time. Or use a Skype-meeting. They seem simpler to set up than
using an IRC channel for instant messaging. I don't know about
Twitter.
Best regards,
Roger
Hi Tim,
Thank you for your quick reply.
In that case, that sentence following my first request would have been
sufficient. But thank you for sending the document anyway.
But you still didn't send the final submission for the workshop
following your emails titled "Urgent! about developers' workshop in
medinfo2010" dated 14 Oct 2009.
That was sent roughly 24 hours before the deadline and contained the
text:
Hi Roger,
I do not think we need special time server, because we can use NTP
server to adjust time.
Hi Roger,
I do not think we need special time server, because we can use NTP
server to adjust time.
I think you may want to re-read Roger's email and reconsider his
reasoning. It is a solution to one of the issues I pointed out (on the
Wiki) that could be a problem.
BTW: Thanks for finally sending the Workshop document.
--Tim
Hi Tim, and Roger
I am sorry to misreading.
Otherwise, this is the first time to challenge connectathon. I think we
should suppose simple situation, such as same timezone, using NTP
server(or omit subtle time mismatch)
Best regards
Shinji
Hi Tim, and Roger
I am sorry to misreading.
Otherwise, this is the first time to challenge connectathon. I think we
should suppose simple situation, such as same timezone, using NTP
server(or omit subtle time mismatch)Best regards
Shinji
But Shinji, the "patient" doesn't see all providers at the same time.
We have to advance time in an unrealistic manner in order to SIMULATE a
real situation.
--Tim
Hi Shinji,
Thanks for pointing out that protocol to me. So you have experience
with testing future datetimes?
Roger
Yes, we should resolve date ordered versioning. What do you think about
RM:COMMON::CHANGE_CONTROL package. It seems that the package is one solution
for distributed versioning in openEHR, but
Hi Roger,
I have few experience in testing future datetimes. It was an appointing system.
In some situation we need future date time especially in instruction
entry.
The entry type models has time attibute to record when the
action/instruction. I think versioning system in openEHR is well
designed, but it is complexed, too. What do you think about
VERSION/VERSIONED_OBJEDT/AUDIT_DETAILS classes in the openEHR
specification.
Best regards,
Shinji
Hello Shinji,
Hi Roger,
I have few experience in testing future datetimes. It was an appointing system.
In some situation we need future date time especially in instruction
entry.
The entry type models has time attibute to record when the
action/instruction. I think versioning system in openEHR is well
designed, but it is complexed, too. What do you think about
VERSION/VERSIONED_OBJEDT/AUDIT_DETAILS classes in the openEHR
specification.
I am not experienced enough to have an opinion on these archetype details.
When I hooked into this thread I just wanted to address the technical
detail of making sure that respective encounters of the patient with a
health care provider would be recorded at various future date-times.
In order to make things easier to discuss: suppose you, me, and Tim
move an MS-Excel file around. It will contain rows with just two
columns: factnumber and a GMT date-time (e.g. "fact1",
"20100924_1659").
I assume you will do the following in the simulation during the connect-a-thon:
0) Startup up an ntp-daemon that broadcasts the time of your
workstation (I'm not knowledgeable about this?)
1) Adjust the time of your workstation to GMT 20100924 16:58
2) Now you enter in MS Excel the first record ("fact1",
"20100924_1659") and save the file
3) You adjust the datetime of your workstation to GMT 20101016 11:15 and
4) Have Tim's and my workstation pick up that date-time
5) Send the file to Tim
6) Now Tim enters in OpenOffice the second record ("fact2",
"20101016_1117") and saves the file
7) Tim tells you via irc/GoogleWave/Skype/phone that he changed the file
8) You adjust the date time of your workstation to GMT 20110331 08:45 and
9) Have Tim's and my workstation pick up that date-time
10) Tim sends the file to me
11) I use some python scripts to update the file with a third record
("fact3", "20110331_0849")
12) I send that file to you at the connect-a-thon
13) You open up the file and show it to the public (and collect the applause)
14) You clean up the file and start another journey with new future
date-times for another round at the connect-a-thon
I'd like to know how you propose to do step 0, 3, 4, 8, and 9.
Hi Roger,
I use UTC(Universal Time, Coordinated) for standardised terminology to
represent date/time insted of GMT. UTC and GMT point almost same time.
http://en.wikipedia.org/wiki/Coordinated_Universal_Time
In order to make things easier to discuss: suppose you, me, and Tim
move an MS-Excel file around. It will contain rows with just two
columns: factnumber and a GMT date-time (e.g. "fact1",
"20100924_1659").
I assume you will do the following in the simulation during the connect-a-thon:0) Startup up an ntp-daemon that broadcasts the time of your
workstation (I'm not knowledgeable about this?)
1) Adjust the time of your workstation to GMT 20100924 16:58
2) Now you enter in MS Excel the first record ("fact1",
"20100924_1659") and save the file
3) You adjust the datetime of your workstation to GMT 20101016 11:15 and
4) Have Tim's and my workstation pick up that date-time
5) Send the file to Tim
6) Now Tim enters in OpenOffice the second record ("fact2",
"20101016_1117") and saves the file
7) Tim tells you via irc/GoogleWave/Skype/phone that he changed the file
8) You adjust the date time of your workstation to GMT 20110331 08:45 and
9) Have Tim's and my workstation pick up that date-time
10) Tim sends the file to me
11) I use some python scripts to update the file with a third record
("fact3", "20110331_0849")
12) I send that file to you at the connect-a-thon
13) You open up the file and show it to the public (and collect the applause)
14) You clean up the file and start another journey with new future
date-times for another round at the connect-a-thonI'd like to know how you propose to do step 0, 3, 4, 8, and 9.
To simplify this date/time problem, I assume this record is observation
entry because it has only one time to record and no workflow. And we
must distinguish two time in records, when it occured and when it was
recorded. Events in hospitals are not recorded just when they happened, but
in most cases, they recorded after they happened.(For example, doctor
writes patient record after they examed patient).
0) NTP daemon is available anywhere in the Internet
We can adjust RTC within 10 mili seconds over the Internet automatically.
http://en.wikipedia.org/wiki/Network_Time_Protocol
3-9) If the recorded time means the event occured or event will occured,
we do not have to adjust workstation time.
I understand what you and Tim have addressed only just now. Sorry to
have much time and bother you.
In this connectathon, I assumed virtual time flow. As your example,
0) Adjust all workstation using NTP server
1) Tim send me the file recorded 'event1', '2009-10-30T12:18:11BST'
2) I received file and record it after change BST to UTC 'event1,
'2009-10-30T09:18Z' and record with timestamp.
3) I send Tim with the file recorded 'event2', '2010-01-22T01:22:22JST'
4) Tim receive the file and record 'event2', the time may be changed to
UTC/BST with timestamp.
Each system generate sample records before connectathon. To simplify
more, all the record within system and messages should be record in UTC
not localized timezonen and presentation layer of each system translate
UTC to localized time zone.
Hi Shinji,
0) NTP daemon is available anywhere in the Internet
We can adjust RTC within 10 mili seconds over the Internet automatically.
http://en.wikipedia.org/wiki/Network_Time_Protocol
3-9) If the recorded time means the event occured or event will occured,
we do not have to adjust workstation time.
I understand what you and Tim have addressed only just now. Sorry to
have much time and bother you.
Don't mention it. We just want to reach clarity...
In this connectathon, I assumed virtual time flow.
What is 'virtual time flow'?
As your example,
0) Adjust all workstation using NTP server
There seems to be no reason for this, if we don't have to keep our
workstations in synch.
1) Tim send me the file recorded 'event1', '2009-10-30T12:18:11BST'
2) I received file and record it after change BST to UTC 'event1,
'2009-10-30T09:18Z' and record with timestamp.
3) I send Tim with the file recorded 'event2', '2010-01-22T01:22:22JST'
So you change the datetime on your workstation independently of the
other workstations, right?
4) Tim receive the file and record 'event2', the time may be changed to
UTC/BST with timestamp.Each system generate sample records before connectathon.
Before? That's to test the whole setup before the connect-a-thon, right?
To simplify
more, all the record within system and messages should be record in UTC
not localized timezonen and presentation layer of each system translate
UTC to localized time zone.
+1 (eh, you've got my vote on that one, too :-))
Best,
Roger