subject:"DV_DURATION and magnitude

Re: DV_DURATION and magnitude_status?

2018-09-25 Thread Ian McNicoll

Hi Slije,

Duration *should* support magnitude_status - it is alreqady defined as such
in the RM. The issue is about how to archetype this, not represent in data.

However  I am not exactly sure if current CDRs support storing
magnitude_status for Duration. Suggest you give it a go!!

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Tue, 25 Sep 2018 at 09:07, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Thanks for all your replies! 
>
>
>
> Attempt at summarising:
>
>- DV_DURATION doesn’t support <>=~ at the moment, but there’s some SEC
>work underway to fix this.
>- For now, using DV_QUANTITY with a property of time could do the
>trick.
>
>
>
> Is this a good summary?
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Diego Boscá
> *Sent:* Tuesday, 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
>
>
>
> 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, 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'm not sure if that was just a conversation or if we have a proposal from
> the SEC to make changes on that area, do you recall?
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
>
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> *Diego Boscá Tomás* / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> *VeraTech for Health SL*
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o ha recibido
> esta comunicación por error, le informamos que está totalmente prohibida, y
> puede ser ilegal, cualquier divulgación, distribución o reproducción de
> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
> devuelva el mensaje original a la dirección arriba mencionada. Gracias
> ___
> 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: DV_DURATION and magnitude_status?

2018-09-25 Thread Bakke, Silje Ljosland

Thanks for all your replies! 

Attempt at summarising:

  *   DV_DURATION doesn’t support <>=~ at the moment, but there’s some SEC work 
underway to fix this.
  *   For now, using DV_QUANTITY with a property of time could do the trick.

Is this a good summary?

Regards,
Silje

From: openEHR-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 have work to do :)

El lun., 24 sept. 2018 a las 23:36, Pablo Pazos 
(mailto:pablo.pa...@cabolabs.com>>) escribió:

On Mon, Sep 24, 2018 at 4:26 PM Thomas Beale 
mailto:thomas.be...@openehr.org>> 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 attribute of DV_DURATION.

that is also my understanding...

I'm not sure if that was just a conversation or if we have a proposal from the 
SEC to make changes on that area, do you recall?

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

--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

[https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]<https://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>

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

--

[VeraTech for Health SL]<https://htmlsig.com/t/01C268PZ>

[Twitter] <https://htmlsig.com/t/01C47QQH>  [LinkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [Maps]  
<https://htmlsig.com/t/01BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com<mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 654604676
www.veratech.es<http://www.veratech.es/>

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada 
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está destinada a 
ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le recordamos que 
sus datos han sido incorporados en el sistema de tratamiento de VERATECH FOR 
HEALTH, SL y que siempre y cuando se cumplan los requisitos exigidos por la 
normativa, usted podrá ejercer sus derechos de acceso, rectificación, 
limitación de tratamiento, supresión, portabilidad y oposición/revocación, en 
los términos que establece la normativa vigente en materia de protección de 
datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011 Valencia o 
bien a través de correo electrónico d...@veratech.es<mailto:d...@veratech.es>

Si usted lee este mensaje y no es el destinatario señalado, el empleado o el 
agente responsable de entregar el mensaje al destinatario, o ha recibido esta 
comunicación por error, le informamos que está totalmente prohibida, y puede 
ser ilegal, cualquier divulgación, distribución o reproducción de esta 
comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva 
el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

2018-09-25 Thread Diego Boscá

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, 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'm not sure if that was just a conversation or if we have a proposal from
> the SEC to make changes on that area, do you recall?
>
>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter 
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Pablo Pazos

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 attribute of DV_DURATION.
>
> that is also my understanding...
>

I'm not sure if that was just a conversation or if we have a proposal from
the SEC to make changes on that area, do you recall?


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


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Thomas Beale





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...

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

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Pablo Pazos

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 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 McNicoll ()
> escribió:
>
>> 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 on an
>> analyser where I think the non-modified value is robably a safe proxy for
>> the modified one. So, in this case I think it is safe.
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Mon, 24 Sep 2018 at 19:30, Diego Boscá  wrote:
>>
>>> 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 (<
>>> thomas.be...@openehr.org>) 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 have moved the date/time types out a bit so they did not inherit
 this attribute. Usually it is Void.

 - thomas



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

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

>>>
>>>
>>> --
>>>
>>> [image: VeraTech for Health SL] 
>>>
>>> [image: Twitter]   [image: LinkedIn]
>>>    [image: Maps]
>>> 
>>>
>>> Diego Boscá Tomás / Senior developer
>>> diebo...@veratech.es
>>> yamp...@gmail.com
>>>
>>> VeraTech for Health SL
>>> +34 654604676 <+34%20654604676>
>>> www.veratech.es
>>>
>>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>>> rectificación, limitación de tratamiento, supresión, portabilidad y
>>> oposición/revocación, en los términos que establece la normativa vigente en
>>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>>> d...@veratech.es
>>>
>>> Si usted lee este mensaje y no es el destinatario señalado, el empleado
>>> o el agente responsable de entregar el mensaje al destinatario, o ha
>>> recibido esta comunicación por error, le informamos que está totalmente
>>> prohibida, y puede ser ilegal, cualquier divulgación, distribución o
>>> reproducción de esta comunicación, y le rogamos que nos lo notifique
>>> inmediatamente y nos devuelva el mensaje original a la dirección arriba
>>> mencionada. Gracias
>>> ___
>>> 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
>>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá

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 McNicoll ()
escribió:

> 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 on an
> analyser where I think the non-modified value is robably a safe proxy for
> the modified one. So, in this case I think it is safe.
>
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Mon, 24 Sep 2018 at 19:30, Diego Boscá  wrote:
>
>> 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 (<
>> thomas.be...@openehr.org>) 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 have moved the date/time types out a bit so they did not inherit
>>> this attribute. Usually it is Void.
>>>
>>> - thomas
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] 
>>
>> [image: Twitter]   [image: LinkedIn]
>>  [image: Maps]
>> 
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º,

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Ian McNicoll

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 on an
analyser where I think the non-modified value is robably a safe proxy for
the modified one. So, in this case I think it is safe.

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 24 Sep 2018 at 19:30, Diego Boscá  wrote:

> 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 (<
> thomas.be...@openehr.org>) 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 have moved the date/time types out a bit so they did not inherit
>> this attribute. Usually it is Void.
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o ha recibido
> esta comunicación por error, le informamos que está totalmente prohibida, y
> puede ser ilegal, cualquier divulgación, distribución o reproducción de
> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
> devuelva el mensaje original a la dirección arriba mencionada. Gracias
> ___
> 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: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá

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 have moved the date/time types out a bit so they did not inherit
> this attribute. Usually it is Void.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Thomas Beale

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



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

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Thomas Beale


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

Not sure it would work in archetyping constraint but in data it 
would/should just be


value: "P24H"
magnitude_status: "<"

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com <mailto:i...@freshehr.com>
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
<mailto:ian.mcnic...@openehr.org>

Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 24 Sep 2018 at 17:08, Diego Boscá <mailto:yamp...@gmail.com>> wrote:


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 alternative of
dv_quantity, as a single one with range is impossible to be
created if they don't share the same units. When validating, only
one of the alternatives needs to be valid, thus complying with the
"or"



El lun., 24 sept. 2018 a las 17:39, Pieter Bos
(mailto:pieter@nedap.com>>) escribió:

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"
mailto:silje.ljosland.ba...@nasjonalikt.no>>:

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 Ljosland Bakke



Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no<http://arketyper.no/> / Twitter:
@arketyper_no<https://twitter.com/arketyper_no>



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

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



-- 


VeraTech for Health SL <https://htmlsig.com/t/01C268PZ>

Twitter <https://htmlsig.com/t/01C47QQH>LinkedIn
<https://htmlsig.com/t/01C4DPJG>Maps
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com <mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 654604676 
www.veratech.es <http://www.veratech.es/>

La información contenida en este mensaje y/o archivo(s)
adjunto(s), enviada desde VERATECH FOR HEALTH, SL, es
confidencial/privilegiada y está destinada a ser leída sólo por
la(s) persona(s) a la(s) que va dirigida. Le recordamos que sus
datos han sido incorporados en el sistema de tratamiento de
VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los
requisitos exigidos por la normativa, usted podrá ejercer sus
derechos de acceso, rectificación, limitación de tratamiento,
supresión, portabilidad y oposición/revocación, en los términos
que establece la normativa vigente en materia de protección de
datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011
Valencia o bien a través de correo electrónico d...@veratech.es
<mailto:d...@veratech.es>

Si usted lee este mensaje y no es el destinatario señalado, el
empleado o el agente responsable de entregar el mensaje al
destinatario, o ha recibido esta comunicación por error, le
informamos que está totalmente prohibida, y puede ser ilegal,
cualquier divulgación, distribución o reproducción de esta
comunicación, y le rogamos que nos lo notifique inmediatamente y
nos devuelva el mensaje original a la dirección arriba mencionada.
Gracias

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

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

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá

I'm not really sure that it even means what we need in this case

El lun., 24 sept. 2018 19:35, Diego Boscá  escribió:

> 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 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: "P24H"
>> magnitude_status: "<"
>>
>> Ian
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Mon, 24 Sep 2018 at 17:08, Diego Boscá  wrote:
>>
>>> 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
>>> alternative of dv_quantity, as a single one with range is impossible to be
>>> created if they don't share the same units. When validating, only one of
>>> the alternatives needs to be valid, thus complying with the "or"
>>>
>>>
>>>
>>> El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
>>> escribió:
>>>
>>>> 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" <
>>>> silje.ljosland.ba...@nasjonalikt.no>:
>>>>
>>>> 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 Ljosland Bakke
>>>>
>>>>
>>>>
>>>> Information Architect, RN
>>>>
>>>> Coordinator, National Editorial Board for Archetypes
>>>> Nasjonal IKT HF, Norway
>>>>
>>>> Tel. +47 40203298
>>>>
>>>> Web: http://arketyper.no<http://arketyper.no/> / Twitter:
>>>> @arketyper_no<https://twitter.com/arketyper_no>
>>>>
>>>>
>>>>
>>>> ___
>>>> openEHR-technical mailing list
>>>> openEHR-technical@lists.openehr.org
>>>>
>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>>
>>>
>>>
>>> --
>>>
>>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>>
>>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>>>   <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>>> <https://htmlsig.com/t/01BZTWS7>
>>>
>>> Diego Boscá Tomás / Senior developer
>>> diebo...@veratech.es
>>> yamp...@gmail.com
>>>
>>> VeraTech for Health SL
>>> +34 654604676 <+34%20654604676>
>>> www.veratech.es
>>>
>>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>>> exigidos por

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá

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 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: "P24H"
> magnitude_status: "<"
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Mon, 24 Sep 2018 at 17:08, Diego Boscá  wrote:
>
>> 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
>> alternative of dv_quantity, as a single one with range is impossible to be
>> created if they don't share the same units. When validating, only one of
>> the alternatives needs to be valid, thus complying with the "or"
>>
>>
>>
>> El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
>> escribió:
>>
>>> 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" <
>>> silje.ljosland.ba...@nasjonalikt.no>:
>>>
>>> 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 Ljosland Bakke
>>>
>>>
>>>
>>> Information Architect, RN
>>>
>>> Coordinator, National Editorial Board for Archetypes
>>> Nasjonal IKT HF, Norway
>>>
>>> Tel. +47 40203298
>>>
>>> Web: http://arketyper.no<http://arketyper.no/> / Twitter: @arketyper_no<
>>> https://twitter.com/arketyper_no>
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/01BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> ___
>> 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: DV_DURATION and magnitude_status?

2018-09-24 Thread Ian McNicoll

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: "P24H"
magnitude_status: "<"

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 24 Sep 2018 at 17:08, Diego Boscá  wrote:

> 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
> alternative of dv_quantity, as a single one with range is impossible to be
> created if they don't share the same units. When validating, only one of
> the alternatives needs to be valid, thus complying with the "or"
>
>
>
> El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
> escribió:
>
>> 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" <
>> silje.ljosland.ba...@nasjonalikt.no>:
>>
>> 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 Ljosland Bakke
>>
>>
>>
>> Information Architect, RN
>>
>> Coordinator, National Editorial Board for Archetypes
>> Nasjonal IKT HF, Norway
>>
>> Tel. +47 40203298
>>
>> Web: http://arketyper.no<http://arketyper.no/> / Twitter: @arketyper_no<
>> https://twitter.com/arketyper_no>
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/01C4DPJG> [image: Maps]
> <https://htmlsig.com/t/01BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o ha recibido
> esta comunicación por error, le informamos que está totalmente prohibida, y
> puede ser ilegal, cualquier divulgación, distribución o reproducción de
> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
> devuelva el mensaje original a la dirección arriba mencionada. Gracias
> ___
> 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: DV_DURATION and magnitude_status?

2018-09-24 Thread Diego Boscá

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
alternative of dv_quantity, as a single one with range is impossible to be
created if they don't share the same units. When validating, only one of
the alternatives needs to be valid, thus complying with the "or"



El lun., 24 sept. 2018 a las 17:39, Pieter Bos ()
escribió:

> 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" <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> 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 Ljosland Bakke
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no / Twitter: @arketyper_no<
> https://twitter.com/arketyper_no>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_DURATION and magnitude_status?

2018-09-24 Thread Pieter Bos

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 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 Ljosland Bakke



Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: 
@arketyper_no



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

DV_DURATION and magnitude_status?

2018-09-24 Thread Bakke, Silje Ljosland

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 Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Re: DV_DURATION and magnitude_status?

RE: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

Re: DV_DURATION and magnitude_status?

DV_DURATION and magnitude_status?

17 matches

Site Navigation

Mail list logo

Footer information