Re: UCUM/SNOMED/custom units

[Pablo Pazos]

REF https://openehr.atlassian.net/browse/SPECPR-96

On Mon, Jul 23, 2018 at 9:15 AM, Bert Verhees  wrote:

> On 23-07-18 13:45, Diego Boscá wrote:
>
>> Units need to be (and will be) revamped, we also need other things
>> already discussed in other posts like rubric, long descriptions (which
>> could be language dependent), etc. This could be very useful for better
>> describing custom UCUM units too.
>> Several alternatives are being explored in order to not break current
>> units definitions. Maybe adding an optional codephrase or terminology
>> mapping could do the trick, as then you can tell where the unit comes from
>> and allows you to provide a "code" which could either contain a Snomed code
>> or a UCUM expression. Inputs are appreciated as always :)
>>
>
> I think your suggested solution is just right ;-)
> But possible I do not oversee all consequences
>
> Bert
>
>
> ___
> 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: UCUM/SNOMED/custom units

[Bert Verhees]

On 23-07-18 13:45, Diego Boscá wrote:
Units need to be (and will be) revamped, we also need other things 
already discussed in other posts like rubric, long descriptions (which 
could be language dependent), etc. This could be very useful for 
better describing custom UCUM units too.
Several alternatives are being explored in order to not break current 
units definitions. Maybe adding an optional codephrase or terminology 
mapping could do the trick, as then you can tell where the unit comes 
from and allows you to provide a "code" which could either contain a 
Snomed code or a UCUM expression. Inputs are appreciated as always :)


I think your suggested solution is just right ;-)
But possible I do not oversee all consequences

Bert

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

Re: UCUM/SNOMED/custom units

[Diego Boscá]

Units need to be (and will be) revamped, we also need other things already
discussed in other posts like rubric, long descriptions (which could be
language dependent), etc. This could be very useful for better describing
custom UCUM units too.
Several alternatives are being explored in order to not break current units
definitions. Maybe adding an optional codephrase or terminology mapping
could do the trick, as then you can tell where the unit comes from and
allows you to provide a "code" which could either contain a Snomed code or
a UCUM expression. Inputs are appreciated as always :)

Regards

2018-07-23 13:14 GMT+02:00 Bert Verhees :

> I wonder if it is possible to use other units then UCUM units in
> DV_QUANTITY. I read from Pablo in Stackoverflow that the SEC is considering
> custom units. I think this is great, but I see some problems coming up. I
> have some questions about this,
>
> I wonder how you can do that without changing the DV_QUANTITY-definition,
> because it has a units-attribute, it says it must be expressed in UCUM
> syntax. It does not say anything about the unit itself, only about the
> notation.
>
> Must we understand UCUM so, that it has not only a syntax for its own
> units, but also for custom units?
>
> That is strange, because custom-units (non-UCUM) can carry custom
> (non-UCUM) syntax-descriptions. So if we are writing a custom unit, and
> using a syntax to specify it, then we need two references, don't we?
>
> One reference for where the unit comes from, and one reference for the
> syntax?
>
>
> A custom unit can also occur in another standard, for example SNOMED, also
> a UCUM-unit can occur in SNOMED, but is it sure it means the same? Normally
> we are very prudent about things like this.
> I found a HL7 wiki about this. Someone did some thinking about this. I
> think that also applies to OpenEhr.
>
> http://wiki.hl7.org/index.php?title=Representation_of_Units
>
> Best regards
> Bert Verhees
>
> ___
> 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

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

UCUM/SNOMED/custom units

[Bert Verhees]

I wonder if it is possible to use other units then UCUM units in 
DV_QUANTITY. I read from Pablo in Stackoverflow that the SEC is 
considering custom units. I think this is great, but I see some problems 
coming up. I have some questions about this,


I wonder how you can do that without changing the 
DV_QUANTITY-definition, because it has a units-attribute, it says it 
must be expressed in UCUM syntax. It does not say anything about the 
unit itself, only about the notation.


Must we understand UCUM so, that it has not only a syntax for its own 
units, but also for custom units?


That is strange, because custom-units (non-UCUM) can carry custom 
(non-UCUM) syntax-descriptions. So if we are writing a custom unit, and 
using a syntax to specify it, then we need two references, don't we?


One reference for where the unit comes from, and one reference for the 
syntax?



A custom unit can also occur in another standard, for example SNOMED, 
also a UCUM-unit can occur in SNOMED, but is it sure it means the same? 
Normally we are very prudent about things like this.
I found a HL7 wiki about this. Someone did some thinking about this. I 
think that also applies to OpenEhr.


http://wiki.hl7.org/index.php?title=Representation_of_Units

Best regards
Bert Verhees

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