September 25, 2018 9:32 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: DV_DURATION and magnitude_status?
>
>
>
> After rereading what Silje needed, I think the mentioned attribute would
> do the trick for her
>
penEHR-technical On Behalf
Of Diego Boscá
Sent: Tuesday, September 25, 2018 9:32 AM
To: For openEHR technical discussions
Subject: Re: DV_DURATION and magnitude_status?
After rereading what Silje needed, I think the mentioned attribute would do the
trick for her
However seems like we at SEC hav
After rereading what Silje needed, I think the mentioned attribute would do
the trick for her
However seems like we at SEC have work to do :)
El lun., 24 sept. 2018 a las 23:36, Pablo Pazos ()
escribió:
>
>
> On Mon, Sep 24, 2018 at 4:26 PM Thomas Beale
> wrote:
>
>>
>>
>> On 24/09/2018 16:19,
On Mon, Sep 24, 2018 at 4:26 PM Thomas Beale
wrote:
>
>
> On 24/09/2018 16:19, Pablo Pazos wrote:
> > I think there was a conversation about being able to constraint the
> > magnitude of a DV_DURATION instead of the String expression. The issue
> > was the magnitude is a function, not an
On 24/09/2018 16:19, Pablo Pazos wrote:
I think there was a conversation about being able to constraint the
magnitude of a DV_DURATION instead of the String expression. The issue
was the magnitude is a function, not an attribute of DV_DURATION.
that is also my understanding...
I think there was a conversation about being able to constraint the
magnitude of a DV_DURATION instead of the String expression. The issue was
the magnitude is a function, not an attribute of DV_DURATION.
On Mon, Sep 24, 2018 at 4:01 PM Diego Boscá wrote:
> But the meaning is for this attribute
But the meaning is for this attribute is to be be used in measures like lab
result to express things that are probably barely measurable, not to
express that in modelling time the other defined constraint is meant to be
the upper (or lower) part of a range
El lun., 24 sept. 2018 a las 20:49, Ian
Hi Diego,
We have certainly had to use it in some lab test integrations. I would
normally agree that it might be risky to carry this kind of modifier as a
separate attribute, which could easily be missed in queries, but these are
gnerally imprecise values (as in Silje's use-case) or out-of-range
yeah, I can see to be useful for that, but seems weird to constraint it in
any way
El lun., 24 sept. 2018 a las 20:29, Thomas Beale ()
escribió:
> It was added to the RM years ago to support quantities in lab results,
> which are sometimes of the form Y etc. If I had my time again, I
> would
It was added to the RM years ago to support quantities in lab results,
which are sometimes of the form Y etc. If I had my time again, I
would have moved the date/time types out a bit so they did not inherit
this attribute. Usually it is Void.
- thomas
Indeed it does, as may be verified with the ADL Workbench
On 24/09/2018 14:22, Ian McNicoll wrote:
Hi Diego,
Does DV_DURATION not inherit magnitude_status as a separate attribute
from the RM?
https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
standings
>
> El lun., 24 sept. 2018 19:23, Ian McNicoll escribió:
>
>> Hi Diego,
>>
>> Does DV_DURATION not inherit magnitude_status as a separate attribute
>> from the RM?
>>
>>
>> https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83
I've never understood the usefulness of that attribute: Seems strange to
populate an attribute that will end up in data with a value that could
provoke misunderstandings
El lun., 24 sept. 2018 19:23, Ian McNicoll escribió:
> Hi Diego,
>
> Does DV_DURATION not inherit magnitu
Hi Diego,
Does DV_DURATION not inherit magnitude_status as a separate attribute from
the RM?
https://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
Not sure it would work in archetyping constraint but in data it
would/should just be
value: "
Yeah, it is supported in 1.4. However, I'm not sure that that Durations are
the way to go here, as all the duration is constraint as string, which
means string lists or regex in best case scenario, which IMO makes pretty
difficult to represent the "<" or ">". Personally I would go with an
Not sure if this is already in the RM version you use and not sure if ADL 1.4
supports this, but can this be a DV_INTERVAL of DV_DURATION?
Regards,
Pieter Bos
Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland"
:
Hi,
I’ve got a use case where we need to represent a time duration (of a
Hi,
I've got a use case where we need to represent a time duration (of a symptom),
which can be for example <24H or >3M. Is it possible to represent this using
the DV_DURATION data type, like you can do with DV_QUANTITY and
magnitude_status? If not, what should we do?
Kind regards,
Silje
17 matches
Mail list logo
