Updated XSLT

Hi, I'm using the XSLT openEHR_RMtoHTML.xsl (found here https://openehr.atlassian.net/wiki/display/dev/openEHR+Composition+XML+to+HTML?focusedCommentId=32014341#comment-32014341) to format XML compositions into HTML in the EHRServer (https://github.com/ppazos/cabolabs-ehrserver). Recently I adde

Re: Representing microseconds in DateTime

Well, we can change the spec if people find it confusing, but as far as I can see, it doesn't say anything about milliseconds or limiting fractional seconds to 3 places. But if you want to propose a wording change, feel free to raise a PR, we can address it in the next minor release. - tho

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

And I just noted, Ocean's Archetype Editor does allow for microseconds but when you select and save it cannot save it. So it is a bug. It looks definitely a deficiency of the openEHR RM. Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of B

RE: [FORGED] Re: Representing microseconds in DateTime

Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains to milliseconds. In my case it is action potential measurement from myocytes Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: Tuesday, 2 Feb

Re: Representing microseconds in DateTime

Probably we should be faithful to ISO8601 and allow this, I don't see any reason why we shouldn't. 2016-02-02 10:51 GMT+01:00 Koray Atalag : > Hi, > > > > I have a requirement to capture timeseries data which happens at 250 > microseconds – that is 0.000250 seconds. > > While many programming lang

Representing microseconds in DateTime

Hi, I have a requirement to capture timeseries data which happens at 250 microseconds - that is 0.000250 seconds. While many programming languages, and the ISO8601 spec, supports this openEHR RM seems to b

RE: Representing microseconds in DateTime

Hi Tom, I've been experimenting to save to Ehrscape and it seems the implementation is truncating (not rounding off) beyond 3digits. So whatever I include after 3rd digit is not saved. "encounter/body_weight:0/any_event:1/time": "2016-02-01T01:04:09.907123Z" > I get: "encounter/body_weight:0/an

Re: Representing microseconds in DateTime

I don't think there is any assumption that [,sss] means there are no microseconds. The field is just called 'fractional_second' and it's a Real (i.e. a float). We just used 'sss' as an arbitrary indicator of fractional seconds (how many 's' do you want ;-) - thomas On 02/02/2016 09:51, Kora

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

Hi Bert, yes it is an extreme case - most clinical measurements will not go in this range. Python's DateTime library (which I'm using at the moment) supports 6 digits after decimal point which gives resolution of 1 microseconds. Cheers, -kora

Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote: Hi Bert, I was saying ISO8601 do support this – it is openEHR that constrains to milliseconds. You are right, you do say that. I don't know if your code supports this, because the ISO-time-string will be converted to a Time-class and must have the sa

Re: Representing microseconds in DateTime

Just for the record, which medical requirement makes measuring micro-seconds necessary? By the way, ISO allows one or more digits to represent a decimal fraction of a second. I don't have the original standard at hand, but Wikipedia says: https://en.wikipedia.org/wiki/ISO_8601 There is no lim