On Wed, Dec 2, 2009 at 14:33, KOBAYASHI, Shinji <skoba at moss.gr.jp> wrote: > > On Tue, 1 Dec 2009 22:32:21 +0100 > Roger Erens <roger.erens at e-s-c.biz> wrote: > >> Hi Shinji, >> >> >> What is 'virtual time flow'? >> > >> > In this scenario, it takes more than three month or year in real time. >> > It is not efficient. In this connectathon, I have assumed participants >> > exchange records that have ranged time, more than three month, within >> > some minutes >> > For example, >> > ? ?Real time ? ? ? ? record ? ? ? recorded time >> > i) ?09:00 ? ? ? ? ? ? Event1 ? ? ? 2008-11-22T10:15:43Z >> > ii) 09:01 ? ? ? ? ? ? Event2 ? ? ? 2008-12-11T09:22:10Z >> Aha. I assumed that a health application would determine the 'recorded >> time' directly based on the 'Real time' (workstation's system clock). >> Here you seem to 'fabricate' a recorded time. > > Do you use only real data in any test phases?
Well, it depends. If it is a test geared towards a programmer, e.g. unit tests, the data does not have to be real. (For example a person called A Aaa, born on 1-1-'1, because this helps in entering some data quickly) But if the test is geared towards an end-user, like I presumed the connect-a-thon to be, I think we should use as much as possible real data within the health applications. Simulation of data should be kept as much as possible outside the application. For the date-times that get recorded, that would mean manipulating the system clock. > >> >> > 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? >> > >> > I cannot understand what you meant in 'independently'. >> > For some authentication procedure, we need to sync date tome on our >> > workstation. So wee need 0). >> > I think the time in record, when the event happened, does not depend on >> > the clock of the workstation. >> But the time the event was recorded does, see my assumption above. > I'm not a native English speaker, too, so I have to interpret the choices you give me below: > Do you mean 'my workstation change intrinsic clock to other datetime > than the other wokrstation' If this means 'change the system date of your workstation (on linux using the command 'date' for this) and let the other workstations synch with your workstation via e.g. the NTP-protocol': yes. This system time is used for the 'recorded time' by the health application when the end-user hits the save button after he entered the medical data, including the 'time that the medical event happened'. So the former time should be 'real', the latter time may be 'constructed'. > or 'my workstation record the data with its > own timestamp'? > Sorry, I could not understand. If this means "record the data with both the 'date it happened' and 'date it was recorded' constructed": no. > > >> > Because data exchange is not always simultaneous and data record does >> > not progress just on time. >> > >> >> > 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? >> > Connectathon is intersystem integration test. Data generation should be >> > tested before connectathon as unit test. >> Ah, OK. I was almost led to believe that, during the connect-a-thon, >> you wanted to exchange records that were fabricated before the >> connect-a-thon :-\ > > I am sorry but we cannot use fully real data in test. I agree that there needs to be some degree of simulation in it. But on second thought, I disagree with your definition of the connect-a-thon as an intersystem integration test. My understanding is that the connect-a-thon should be like a demo or show-case, with records created during the presentation. Its purpose: show non-openEHR-people that openEHR-based applications work together. The intersystem integration test should have been done before the connect-a-thon. Its purpose: show ourselves (the application builders/developers) that openEHR-based applications work together. Best regards, Roger
