Re: SV: [Troll] Terminology bindings ... again

[Michael.Lawley]

Hi Heather,


In general, anyone is welcome to participate in the work; you don't need to be 
one of the small number of Advisory Group members.  That helps with travel 
costs, but most of the real work is done on teleconferences, not so much at the 
face to face meetings.


I would be very interested to hear people's articulations of where they think 
the boundary should be for this boundary line.  I'd also be interested to 
understand better what people think the problem is with having "extra" / 
unnecessary pre-coordinated concepts; what advantage is to be gained from 
removing them, and what is the perceived scale of the problem.


michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

From: openEHR-technical  on behalf 
of Heather Leslie 
Sent: Thursday, 22 March 2018 9:46 AM
To: For openEHR technical discussions
Subject: RE: SV: [Troll] Terminology bindings ... again

Hi Mikael,

What efforts are being made to resolve the boundary problem?

I applied to get involved with the  SNOMED information modelling group but 
wasn’t successful, to try to engage on exactly that  point.

I’m not aware of any work going on. I’d be very pleased to get involved if I 
could. It’s a fiendish problem and we need cooperation and collaboration from 
both sides of the fence.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions 
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi Tom,

I believe that you proposal to ”move / remove the pre-coordinated codes out of 
SNOMED” is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don’t have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: 
openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to 

RE: SV: [Troll] Terminology bindings ... again

[Heather Leslie]

Hi Mikael,

What efforts are being made to resolve the boundary problem?

I applied to get involved with the  SNOMED information modelling group but 
wasn’t successful, to try to engage on exactly that  point.

I’m not aware of any work going on. I’d be very pleased to get involved if I 
could. It’s a fiendish problem and we need cooperation and collaboration from 
both sides of the fence.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Mikael Nyström
Sent: Thursday, 22 March 2018 1:00 AM
To: For openEHR technical discussions 
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi Tom,

I believe that you proposal to ”move / remove the pre-coordinated codes out of 
SNOMED” is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don’t have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: 
openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to critique SNOMED, as long as that critique is collegial, and 
above all intelligent. (BTW maybe Philippe was not entirely diplomatic, but he 
did implement a very nice post-coordinating terminology and clinical noting 
system, so he knows a thing or two).

So in that sense, I stand by my earlier comments that it would have helped (and 
still would help) if SNOMED International would consider some of my suggestions 
on separation of technology from content, separate the meta-model, and also a 
more serious effort to help connect terminology to information models / content 
models.  We are slowly solving this on our side, but strategic cooperation 
would be better.

One thing is clear: terminology is not a standalone proposition.

- thomas

On 21/03/2018 13:48, Mikael Nyström wrote:

Hi Philippe,



I think that you have missed that SNOMED CT is created for multiple use cases.



Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

On 21-03-18 16:32, GF wrote:

When I’n not mistaken:
Duration is not the same concept as Calendar.
IsoTime and Calendar are both data types defining an absolute point on 
the time line, but in different ways.


In the Java and Golang classes Calendar is also to indicate durations, 
it is in fact, to do Calendar calculations. You can calculate the first 
day (example 2004/1/1) and say, this date + 3 months, and then you get a 
new Date, which is a different number of days away then when the first 
date is 2005/1/1 + 3 months (because of Leap year)


For example, see here the Add function to Add months or weeks or years 
to a date

https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html#add(int,%20int)

That is what is needed when you calculate in the date range of the 
ISO8601 string.


When you do calculations in the time range, then you need to calculate 
with a Duration (which does in background everything in nanoseconds, but 
has convenience methods to use it for hours and minutes, etc)




Duration is the difference between points on the time line.

My point is that some times we can not/want not use points on the time 
line but use fussier terms like: begin of an event somewhere in 2015, 
or a duration of one month, or


Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 15:02, Bert Verhees > wrote:


I don't mind how you call it, programmers call it Duration and 
Calendar, both are well known datatypes, but they have other semantics.



On 21-03-18 14:53, GF wrote:


You gave proof that there are different kinds of time.
*Chrono-time* as used fro time stamping at one exact point in time.
And *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees > wrote:



On 21-03-18 10:50, GF wrote:

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago 
and that could not be inspected without a magnifying glass on a 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right 
(I prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org 


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Karsten Hilbert]

On Wed, Mar 21, 2018 at 04:32:53PM +0100, GF wrote:

> My point is that some times we can not/want not use points
> on the time line but use fussier terms like: begin of an
> event somewhere in 2015, or a duration of one month, or

Which can be modelled as

 +/- 

such as

 +/- <3 months>

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

When I’n not mistaken:
Duration is not the same concept as Calendar.
IsoTime and Calendar are both data types defining an absolute point on the time 
line, but in different ways.

Duration is the difference between points on the time line.

My point is that some times we can not/want not use points on the time line but 
use fussier terms like: begin of an event somewhere in 2015, or a duration of 
one month, or

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 15:02, Bert Verhees  wrote:
> 
> I don't mind how you call it, programmers call it Duration and Calendar, both 
> are well known datatypes, but they have other semantics.
> 
> 
> On 21-03-18 14:53, GF wrote:
>> 
>> You gave proof that there are different kinds of time.
>> Chrono-time as used fro time stamping at one exact point in time.
>> And Chairos-time used for imprecise relative time as used by humans,
>> 
>> Chrono-time is one primitive data type.
>> Chairos-time is defined using archetype/patterns
>> 
>> 
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl 
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 21 Mar 2018, at 12:25, Bert Verhees >> > wrote:
>>> 
>>> 
>>> On 21-03-18 10:50, GF wrote:
 Does including Duration in the RM fit with the scope for the RM?
 
 Why do we have archetypes?
 Why not include every thing in the RM?
 Do we want the HL7v3 Reference Model as it existed many years ago and that 
 could not be inspected without a magnifying glass on a sheet of paper that 
 was 2 by 1 meters?
 
 Is there one kind of duration?
 24 minutes, 5 seconds?
 For 2 hours past midnight?
 For 2 hours after (clinical) event x
 For 2 months after (clinical) event y
>>> 2 months cannot be technically represented in a duration, because month is 
>>> not a stable time-definition. It is a Calendar definition.
>>> It is therefor that most major programing languages have a Duration and a 
>>> Calendar class.
>>> Or you say that OpenEhr has no valid Duration-datatype, so always express 
>>> Duration in an archetype (your way),
>>> or say that OpenEhr has a valid Dv_Duration type, and do it right (I prefer 
>>> this way),
>>> or express months as if it is a stable time-indicator and ignore it is not 
>>> (like it is now)
>>> 
>>> Those are the three possible ways to solve this problem, I think
>>> I am curious to learn what the community will decide.
>>> 
>>> Bert
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> 
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

Pieter, the problem are the conflicting semantics. You should avoid 
having conflicting semantics in one class, that is confusing.
I think that is why Java and Golang have both in their standard 
libraries because of the conflicting semantics


There is no good reason to have months and hours in one class.
I must admit, days is a bit in between, although, when looking exact at 
it, one specific day can have in some years one second more or less.
I believe this is always December 31th. So days is more right to put in 
the Calendar class.


But I must leave this discussion, I notice I get involved too much. I 
have given my opinions, and others should give theirs


Best regards
Bert

On 21-03-18 15:52, Pieter Bos wrote:

I don't understand. You can implement a single class ISO8601 Duration, 
containing all the different fields, all optional, that directly maps to and 
from the string representation. You can also easily use it to model both P30D 
and P1M, which are indeed different things. Depending on the fields set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.


Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day...
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

  
Regards,


Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
 wrote:

 No Duration type is a ISO8601 duration, ISO8601 is just a string
 representation of a duration. No programming language can, from its
 standard library safely express an ISO8601 in a class, because the
 ISO8601 is a combination of two types.
 Unless you are wiling to have an uncertainty of 10%, you cannot express
 a month in a Duration type. For many software, this uncertainty is not
 acceptable. Maybe it is for medical purposes, but OpenEhr also has an
 Admin_Entry, and there this uncertainty is not always acceptable. How do
 you bill someone who was one month in a clinic? Make it 28 days or 31 days?
 
 And the solution is easy, and it has advantages.
 
 If we split the Dv_Duration in a Calendar part and in a Duration part,

 then both have their own merits. If you want to bill a stay of a month
 in a clinic, you express it by days (which are always 24 hours) P30D
 (represented by the Duration class) and if you want the patient to
 return every month, you can use the first part, P1M (represented by the
 Calendar class).
 
 I don't think this is complex or requires complex algorithms, even

 opposite, it makes it more simple and more certain to process and all
 the troubles and bad feelings when converting a month to 30 days, and
 then find out it was 28 days, are gone. I think Joda was a complex
 solution for a simple problem.
 
 Bert
 
 
 
 
 On 21-03-18 13:47, Pieter Bos wrote:

 > There seems to be some confusion regarding the concept of a ISO8601 
Duration. You can definitely define a duration of 2 months in ISO8601 Durations. 
It has separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be combined. 
It cannot be fully modelled using a single nanosecond field - you would run into 
trouble with years, months, and even days, plus you cannot express for example a 
duration of 1 hour with no precision in the minutes and seconds fields mentioned. 
I think  https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation 
of the concept.
 >
 > The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the definition 
of days. There are libraries available for golang that do model the full iso8601 
duration.
 >
 > Of course, I agree that we should not have a far too big reference 
model. There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the examples 
Gerard Freriks mentions for example:
 >
 > - 24 minutes, 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

On 21-03-18 15:02, Bert Verhees wrote:
I don't mind how you call it, programmers call it Duration and 
Calendar, both are well known datatypes, but they have other semantics.


Sorry for my unpleasant tone, I guess we are talking about the same things.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Pieter Bos]

I don't understand. You can implement a single class ISO8601 Duration, 
containing all the different fields, all optional, that directly maps to and 
from the string representation. You can also easily use it to model both P30D 
and P1M, which are indeed different things. Depending on the fields set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.


Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day... 
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

 
Regards,

Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

No Duration type is a ISO8601 duration, ISO8601 is just a string 
representation of a duration. No programming language can, from its 
standard library safely express an ISO8601 in a class, because the 
ISO8601 is a combination of two types.
Unless you are wiling to have an uncertainty of 10%, you cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?

And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).

I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.

Bert




On 21-03-18 13:47, Pieter Bos wrote:
> There seems to be some confusion regarding the concept of a ISO8601 
Duration. You can definitely define a duration of 2 months in ISO8601 
Durations. It has separate fields for years, months, weeks, days, plus an 
optional time with hours, minutes and seconds. All these fields are optional 
and can all be combined. It cannot be fully modelled using a single nanosecond 
field - you would run into trouble with years, months, and even days, plus you 
cannot express for example a duration of 1 hour with no precision in the 
minutes and seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.
>
> The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the 
definition of days. There are libraries available for golang that do model the 
full iso8601 duration.
>
> Of course, I agree that we should not have a far too big reference model. 
There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the 
examples Gerard Freriks mentions for example:
>   
> - 24 minutes, 5 seconds can be modelled as a single Element with a 
DV_Duration value. The ISO8601 text representation of the dv_duration.value 
field would be PT24M5S.
> - For 2 hours past midnight can be modeled with two Elements, for example 
a 'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
> - A duration after a specific clinical event can be modelled as however 
you want to model the reference to the clinical event, plus a single 
DV_DURATION field. In the first example the  value field of the DV_DURATION 
would be P2M, the second PT2H
>
> Say you want to model the duration after which to resume a specified 
daily activity 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

I don't mind how you call it, programmers call it Duration and Calendar, 
both are well known datatypes, but they have other semantics.



On 21-03-18 14:53, GF wrote:


You gave proof that there are different kinds of time.
*Chrono-time* as used fro time stamping at one exact point in time.
And *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees > wrote:



On 21-03-18 10:50, GF wrote:

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago 
and that could not be inspected without a magnifying glass on a 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Tom,

I believe that you proposal to ”move / remove the pre-coordinated codes out of 
SNOMED” is very appealing in theory. However it is very difficult in reality to 
agree on where the line between a suitable pre-coordinated concept and a 
concept that is better to post-coordinate or handle in another way are. The 
line between the two alternatives also seem to be use case dependent, which 
makes it even more difficult, and of cause also related to the boundary 
problem. However, until there is a strong agreement on where the line should be 
I continue to believe that it is better so include the concepts in the same 
pile and let each use case decide how to select the concepts they need and 
transform between the different representations.

I like discussions about SNOMED CT and I don’t have any problems at all with 
critical comments as long as they are fair. Those kinds of criticism quite 
often makes me writing change requests. I am also happy to answer questions 
about SNOMED CT. However, I and several other people that are involved in the 
SNOMED CT  community are quite tired of people that argue that SNOMED CT is bad 
based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for 
their narrow use case.

 Regards
 Mikael

Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 21 mars 2018 14:17
Till: openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again




Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, 
which would actually look a lot more like Philippe's (much smaller) terminology.

This relates to the old debate on reference v interface terminology, and just 
throwing out precoord concepts is probably not right - they need to be in a 
completely different hierarchy.

The post-coordination grammar in SCT is good, its theoretical challenge is the 
concept meta-model, i.e. what things like 'morphology', 'laterality' you can 
mention, and in what relationship. But this is hard for all of us, and requires 
some serious ontology work (Mikael and other experts know all about this of 
course).

What I would say is this: in a similar way that I think SNOMED should have 
separated out 'SNOMED technology' (representation, APIs etc) from content, I 
think the concept meta-model should have been / could be made a separate 
artefact, maybe even an OBO ontology - at the moment it is too hidden inside 
the giant content artefact. If that were done, we could work more effectively 
on aligning with information / content models, whose attribute names should, 
generally speaking relate to (or be the same as) the meta-model ontology 
entities. If we pursued this line, the ontology would instantly be expanded by 
examination of archetypes, and conversely, many archetypes could be fixed where 
they contain errors or questionable attribute names.

THis isn't to criticise experts or work done in SNOMED per se, but we should be 
perfectly happy to critique SNOMED, as long as that critique is collegial, and 
above all intelligent. (BTW maybe Philippe was not entirely diplomatic, but he 
did implement a very nice post-coordinating terminology and clinical noting 
system, so he knows a thing or two).

So in that sense, I stand by my earlier comments that it would have helped (and 
still would help) if SNOMED International would consider some of my suggestions 
on separation of technology from content, separate the meta-model, and also a 
more serious effort to help connect terminology to information models / content 
models.  We are slowly solving this on our side, but strategic cooperation 
would be better.

One thing is clear: terminology is not a standalone proposition.

- thomas

On 21/03/2018 13:48, Mikael Nyström wrote:

Hi Philippe,



I think that you have missed that SNOMED CT is created for multiple use cases.



Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED 
CT Compositional Grammar and SNOMED CT's concept model.



Another use case, that many implementers consider is important but you don't 
seem to care about, is the ability to handle legacy data to be able to keep a 
life-long  health record. Most people alive today where born when simple health 
records that only used simple coding where in massive use. (When that era 
started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts 
that can represent that kind of information. But SNOMED CT also has a machinery 
to transform between the different representations.  Your example "fracture of 
the left ankle" is not 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

On 21-03-18 13:57, Thomas Beale wrote:


although 'month' is not a scientific notion (it's not constant), we do 
treat it as a data type or unit in /social date time types/, which is 
what we are mostly dealing with, and what the types DvDuration, DvDate 
etc correspond to.


For scientific durations, use DvQuantity, and then you have a Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the 
RM, and also if we can, a standard model of 'time specification' which 
is the '3 times/day' kind of idea. We still don't have a good solution 
for this last one.




What is the problem with the Calendar type?
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

On 21-03-18 13:51, Thomas Beale wrote:


On 20/03/2018 23:33, A Verhees wrote:

One last remark.

There is in medical context need of a datatypes to express: "do this 
one time a month, for example on a specific date".


But technically seen, this is not a duration, the maybe a need for 
another datatype to express this.


Using the duration for this may be a handy shortcut in specs, but it 
is not right. It is in fact misusing a datatype which does not 
support this expression. The ISO string should also be changed 
accordingly.


we don't really use Duration to represent 3 times / day. There are old 
HL7 data types which we included in openEHR to do this, called GTS and 
its children 
. 
It seems that noone uses these. THere have been many other attempts to 
define either types or structures, like iCal and other 
calendar-related structures. But I don't see a clear winner in terms 
of standards.


THe medication archetypes solve it by using multiple fields, and in 
Task Planning we had to create some new time specification types as 
well - CLOCK_TIME, CALENDAR_TIME, and CUSTOMARY_TIME 
.


You can need Duration for many purposes
Which comes to mind. How long was the patient feeling bad? How long did 
the patient sleep? How long was he staying in the hospital. These are 
all Durations. How long was the pregnancy time, How much time is their 
between two named phases of a heartbeat



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Bert Verhees]

No Duration type is a ISO8601 duration, ISO8601 is just a string 
representation of a duration. No programming language can, from its 
standard library safely express an ISO8601 in a class, because the 
ISO8601 is a combination of two types.
Unless you are wiling to have an uncertainty of 10%, you cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?


And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).


I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.


Bert




On 21-03-18 13:47, Pieter Bos wrote:

There seems to be some confusion regarding the concept of a ISO8601 Duration. 
You can definitely define a duration of 2 months in ISO8601 Durations. It has 
separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:
  
- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration value. The ISO8601 text representation of the dv_duration.value field would be PT24M5S.

- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity.
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare


On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
 wrote:

 
 On 21-03-18 10:50, GF wrote:

 > Does including Duration in the RM fit with the scope for the RM?
 >
 > Why do we have archetypes?
 > Why not include every thing in the RM?
 > Do we want the HL7v3 Reference Model as it existed many years ago and
 > that could not be inspected without a magnifying glass on a sheet of
 > paper that was 2 by 1 meters?
 >
 > Is there one kind of duration?
 > 24 minutes, 5 seconds?
 > For 2 hours past midnight?
 > For 2 hours after (clinical) event x
 > For 2 months after (clinical) 

Re: SV: [Troll] Terminology bindings ... again

[Thomas Beale]

Nevertheless, I think it would have been good to move / remove the 
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable 
core, which would actually look a lot more like Philippe's (much 
smaller) terminology.


This relates to the old debate on reference v interface terminology, and 
just throwing out precoord concepts is probably not right - they need to 
be in a completely different hierarchy.


The post-coordination grammar in SCT is good, its theoretical challenge 
is the concept meta-model, i.e. what things like 'morphology', 
'laterality' you can mention, and in what relationship. But this is hard 
for all of us, and requires some serious ontology work (Mikael and other 
experts know all about this of course).


What I would say is this: in a similar way that I think SNOMED should 
have separated out 'SNOMED technology' (representation, APIs etc) from 
content, I think the concept meta-model should have been / could be made 
a separate artefact, maybe even an OBO ontology - at the moment it is 
too hidden inside the giant content artefact. If that were done, we 
could work more effectively on aligning with information / content 
models, whose attribute names should, generally speaking relate to (or 
be the same as) the meta-model ontology entities. If we pursued this 
line, the ontology would instantly be expanded by examination of 
archetypes, and conversely, many archetypes could be fixed where they 
contain errors or questionable attribute names.


THis isn't to criticise experts or work done in SNOMED per se, but we 
should be perfectly happy to /critique/ SNOMED, as long as that critique 
is collegial, and above all intelligent. (BTW maybe Philippe was not 
entirely diplomatic, but he did implement a very nice post-coordinating 
terminology and clinical noting system, so he knows a thing or two).


So in that sense, I stand by my earlier comments that it would have 
helped (and still would help) if SNOMED International would consider 
some of my suggestions on separation of technology from content, 
separate the meta-model, and also a more serious effort to help connect 
terminology to information models / content models.  We are slowly 
solving this on our side, but strategic cooperation would be better.


One thing is clear: terminology is not a standalone proposition.

- thomas


On 21/03/2018 13:48, Mikael Nyström wrote:

Hi Philippe,

I think that you have missed that SNOMED CT is created for multiple use cases.

Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using SNOMED CT's 
concepts a little higher up in the hierarchies together with SNOMED CT Compositional 
Grammar and SNOMED CT's concept model.

Another use case, that many implementers consider is important but you don't seem to care about, is 
the ability to handle legacy data to be able to keep a life-long  health record. Most people alive 
today where born when simple health records that only used simple coding where in massive use. 
(When that era started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts that can represent 
that kind of information. But SNOMED CT also has a machinery to transform between the different 
representations.  Your example "fracture of the left ankle" is not possible to express 
using a single concept from SNOMED CT, but if it had been possible it had been possible to 
automatically transform that concept to the expression below, which seems like to be what you argue 
for in your "modern approach" use case.

64572001 | Disease (disorder) | :
{  363698007 |Finding site| =
  {33696004 |Bone structure of ankle (body structure)| : 272741003 
|Laterality| = 7771000 |Left (qualifier value)|},
   116676008 |Associated morphology| = 72704001 |Fracture (morphologic 
abnormality)|
}

I therefore find your arguments against SNOMED CT equally relevant as arguments 
of the type

"SNOMED CT is useless, because it contains the concepts 285336007 | Background 
radiation (physical force) |, 60638008 | Planetary surface craft, device (physical 
object) | and 242250006 | Crash landing of spacecraft (event) | and I don't need that 
kind of concepts at my clinic."

because the simple solution is to not use what you don't need.

Regards
Mikael



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Thomas Beale]

although 'month' is not a scientific notion (it's not constant), we do 
treat it as a data type or unit in /social date time types/, which is 
what we are mostly dealing with, and what the types DvDuration, DvDate 
etc correspond to.


For scientific durations, use DvQuantity, and then you have a Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the RM, 
and also if we can, a standard model of 'time specification' which is 
the '3 times/day' kind of idea. We still don't have a good solution for 
this last one.


- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Thomas Beale]

On 20/03/2018 23:33, A Verhees wrote:

One last remark.

There is in medical context need of a datatypes to express: "do this 
one time a month, for example on a specific date".


But technically seen, this is not a duration, the maybe a need for 
another datatype to express this.


Using the duration for this may be a handy shortcut in specs, but it 
is not right. It is in fact misusing a datatype which does not support 
this expression. The ISO string should also be changed accordingly.


we don't really use Duration to represent 3 times / day. There are old 
HL7 data types which we included in openEHR to do this, called GTS and 
its children 
. 
It seems that noone uses these. THere have been many other attempts to 
define either types or structures, like iCal and other calendar-related 
structures. But I don't see a clear winner in terms of standards.


THe medication archetypes solve it by using multiple fields, and in Task 
Planning we had to create some new time specification types as well - 
CLOCK_TIME, CALENDAR_TIME, and CUSTOMARY_TIME 
.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: [Troll] Terminology bindings ... again

[Mikael Nyström]

Hi Philippe,

I think that you have missed that SNOMED CT is created for multiple use cases.

Your use case that you describe as "a modern approach" is a good use case that 
I like. In that use case SNOMED CT can be used in the way you describe using 
SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED 
CT Compositional Grammar and SNOMED CT's concept model.

Another use case, that many implementers consider is important but you don't 
seem to care about, is the ability to handle legacy data to be able to keep a 
life-long  health record. Most people alive today where born when simple health 
records that only used simple coding where in massive use. (When that era 
started and (potentially) ended is up to the reader to decide...) To cater for 
information that are more of legacy information, SNOMED CT also has concepts 
that can represent that kind of information. But SNOMED CT also has a machinery 
to transform between the different representations.  Your example "fracture of 
the left ankle" is not possible to express using a single concept from SNOMED 
CT, but if it had been possible it had been possible to automatically transform 
that concept to the expression below, which seems like to be what you argue for 
in your "modern approach" use case.

64572001 | Disease (disorder) | :
   {  363698007 |Finding site| = 
 {33696004 |Bone structure of ankle (body structure)| : 272741003 
|Laterality| = 7771000 |Left (qualifier value)|}, 
  116676008 |Associated morphology| = 72704001 |Fracture (morphologic 
abnormality)| 
   }

I therefore find your arguments against SNOMED CT equally relevant as arguments 
of the type

"SNOMED CT is useless, because it contains the concepts 285336007 | Background 
radiation (physical force) |, 60638008 | Planetary surface craft, device 
(physical object) | and 242250006 | Crash landing of spacecraft (event) | and I 
don't need that kind of concepts at my clinic."

because the simple solution is to not use what you don't need.

Regards
Mikael


-Ursprungligt meddelande-
Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Philippe Ameline
Skickat: den 15 mars 2018 16:18
Till: openehr-technical@lists.openehr.org
Ämne: Re: [Troll] Terminology bindings ... again

Le 15/03/2018 à 00:34, Mikael Nyström a écrit :

> Hi Philippe
>
> It seems like you are making a big deal of that SNOMED CT is an ancient 
> product, but I would like to see your explicit arguments about that instead 
> of only negative generalizations. From my point of view it is quite modern 
> with an OWL based ontology with additional features for terminology and 
> versioning, which basically is what SNOMED CT are.
>
>   Regards
>   Mikael

Hi Mikael,

The question will always remain "what component do you need at a given 
technological moment?"

If what you want to do is what has been done since 1980, that's to say fill 
forms inside a care place and exchange it with other care places, I guess that 
Snomed CT is the proper component.
Since it was born a coding system, you can create complicated meta-concepts in 
a single code (of course, it means you will have to find your own subset inside 
an always expanding universe, but ease comes with a price) and it is very 
convenient to fill the good old set of attribute–value pairs.

On the contrary, if you estimate that a modern approach would be to tell and 
organize a patient's journey, you have to exhibit more modern structures 
because in order to "tell something", you need not only a terminology (say a 
vocabulary) but also a grammar. A proper grammar (at least the one I use) can 
be a "dependency grammar" in the form of a graph or trees.
Now that you can tell elaborated things using a vocabulary (the
ontology) and a grammar (the graph of trees), the "agglutinating"
structure of Snomed rapidly sucks. Because now that "fracture of the left 
ankle" can be expressed as the branch "fracture" "located at" "left ankle", 
there is no longer a need for the hundred of thousand (and
counting) "codes" that where convenient for ancient systems but are now a 
genuine problem.

Do you imagine a natural language that would be so massively agglutinating that 
it would contain words like "FractureOfTheLeftAnkleThatWasTreatedButStillHurts"?
I guess that, due to a terrible learning curve, the children would speak at six 
;-)

To sum it up, Snomed is probably convenient for application with a structure 
schema that can only handle a coding system (hey, it also comes with a semantic 
network) but is not fit as a formal language vocabulary.

Best,

Philippe



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Pieter Bos]

There seems to be some confusion regarding the concept of a ISO8601 Duration. 
You can definitely define a duration of 2 months in ISO8601 Durations. It has 
separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:
 
- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration 
value. The ISO8601 text representation of the dv_duration.value field would be 
PT24M5S.
- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity. 
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare


On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:


On 21-03-18 10:50, GF wrote:
> Does including Duration in the RM fit with the scope for the RM?
>
> Why do we have archetypes?
> Why not include every thing in the RM?
> Do we want the HL7v3 Reference Model as it existed many years ago and 
> that could not be inspected without a magnifying glass on a sheet of 
> paper that was 2 by 1 meters?
>
> Is there one kind of duration?
> 24 minutes, 5 seconds?
> For 2 hours past midnight?
> For 2 hours after (clinical) event x
> For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because month 
is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration and 
a Calendar class.

Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it is 
not (like it is now)

Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Thomas Beale]

On 20/03/2018 21:54, Pablo Pazos wrote:
Yep, I know 
https://docs.oracle.com/javase/tutorial/datetime/iso/period.html


But this is not about anything Java specific, just giving an example 
why Duration might not be good for an assumed type on the openEHR specs :)


just to give some background, 'Duration' was always intended to 
represent a data type that could be considered like the ISO601 Duration 
type (also the ISO8601 Date type etc), which is also a W3C type 
(duration, gdate etc) - regardless of internal representation. For Java 
programmers, the joda library provided this; recent Java and C# have 
more modern things built in.


The Foundation Types spec now has a types cross-ref datatypes here 
. 
No guarantee it is correct ;)




On the other hand... (re)thinking: assumed types should not be 
considered as "supported by a programming language", but "supported by 
a programming language or application" ***. For instance, it is not so 
difficult to create a Duration class ourselves on any programming 
language, or even use one of the many available libraries that deal 
with Duration types and are compatible with ISO8601 durations.


Considering that, we might need to clarify:

1. What "assumed type" really is (it seems most tend to think that 
should be supported by a programming language, need to double check 
the specs to see how this is defined, maybe is clearly defined but not 
highlighted enough).


we are moving away from this terminology 'assumed types', and just using 
'primitive types', but the idea is the same - that it is assumed that 
the programming environment has some equivalent that can be connected to 
e.g. Duration, String etc, as they appear in the openEHR specs.




2. Clarify the use of the Duration class from CDuration where Duration 
is not on the specs (we can say it is assumed considering assumed as 
the definition ***)



it is now - in the Foundation Types spec 
.




3. Complementing 2. we can propose support for Duration on many 
programming languages by recommending certain libraries or core types. 
This can be an ITS or just an addendum/errata to v1.0.2 specs.


right - that xref table referred to above is an attempt to do this. We 
can expand that table to include more languages/technologies, or do it 
some other way.  If we can use this table, it means we can avoid 
publishing another separate spec.


- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[GF]

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago and that 
could not be inspected without a magnifying glass on a sheet of paper that was 
2 by 1 meters?

Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 00:22, A Verhees  wrote:
> 
> That is true, but I think it would be good if it would find its way in the 
> RM, for two reasons
> 1) misusing the duration does not seem right, and I think the ISO string 
> representing a duration must change. That is, I know, a long way, so the part 
> before the 'T' should represent a calendar datatype, and the other part 
> should be a duration. It is also worth considering to split the DV_DURATION 
> type in the same way.
> 2) If it find its formal way in the RM libraries will support it also, which 
> will help implementers to do it the right way.
> 
> Bert



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org