Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

But you can't specify terms in DV_COUNT while DV_ORDINAL.symbol can be used
to specify the arbitrary units but not as physical property units of
measure, but as a terminology concept / term.

On Tue, Jan 30, 2018 at 1:30 PM, Thomas Beale 
wrote:

>
> On 30/01/2018 16:24, Pablo Pazos wrote:
>
>> Hi Silje,
>>
>> My thinking is for your use case, DV_QUANTITY doesn't apply for
>> arbitrary, since those seem not related with physical properties (mass,
>> length, area, concentration, etc.)
>>
>> As I said, "level of X" makes me think of DV_ORDINAL.
>>
>
> or even DV_COUNT.
>
> I have asked some questions of knowledgeable ontology sources; will post
> any replies I get here.
>
> - thomas
>
>
>
> ___
> 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

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

Re: Quantities of arbitrary units in openEHR

[Thomas Beale]

On 30/01/2018 16:24, Pablo Pazos wrote:

Hi Silje,

My thinking is for your use case, DV_QUANTITY doesn't apply for 
arbitrary, since those seem not related with physical properties 
(mass, length, area, concentration, etc.)


As I said, "level of X" makes me think of DV_ORDINAL.


or even DV_COUNT.

I have asked some questions of knowledgeable ontology sources; will post 
any replies I get here.


- thomas


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

Re: Quantities of arbitrary units in openEHR

[Pablo Pazos]

Hi Silje,

My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary,
since those seem not related with physical properties (mass, length, area,
concentration, etc.)

As I said, "level of X" makes me think of DV_ORDINAL.

DV_PROPORTION would be used for numerator / denominator modeling, but
currently doesn't support units so it's real / real. My suggestion was to
analyze the change from that to an arbitrary type for each numerator and
denominator, so you can model DV_QUANTITY / DV_QUANTITY proportions.

Also DV_ORDINAL doesn't have a unit but has a DV_CODED_TEXT, maybe your
arbitrary units are really terms from a given terminology, so this might be
good to model that.

But as I said, for this specific use case you might need to use many data
points (ELEMENTS) of different types, inside a CLUSTER to be able to comply
with all your requirements (please check my previous message where I
outlined your requirements as I understood them).


Hope that helps.



On Tue, Jan 30, 2018 at 11:55 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Hi Pablo,
>
>
>
> This is our current modelling, for reference (the administration unit
> denominator isn’t modelled):
>
>
>
> I don’t see how either ordinals or proportions, the way they currently
> work, can be of any help here.
>
>
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Monday, January 29, 2018 4:34 PM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* Re: Quantities of arbitrary units in openEHR
>
>
>
> Hi Silje,
>
>
>
> On Mon, Jan 29, 2018 at 11:15 AM, Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no> wrote:
>
> Hi,
>
>
>
> «Any units» isn’t the same as “arbitrary units”. As I wrote below,
> “arbitrary units” in the context of biomedicine are units which are defined
> by biological activity, such as level of allergic reaction or enzymatic
> activity.
>
>
>
> From the modeling point of view, I don't think using DV_QUANTITY for this
> is the right direction, since DV_QUANTITY.units are defined to contain a
> unit related to a physical property (mass, length volume, concentration,
> etc.). When talking about "level of X", my first idea is to go for
> DV_ORDINAL. If the ordinal part is not really needed, then downgrade to
> DV_CODED_TEXT (that is part of DV_ORDINAL).
>
>
>
> This is done to be able to compare the concentration of different
> substances which have the same effects in different mass or volume amounts
> – birch pollen extract vs grass pollen extract (measured in SQ-U;
> standardized quality units), retinol vs betacarotene (measured in RE,
> retinol equivalents), human insulin vs insulin analogues (measured in IU,
> international units).
>
>
>
> In this context, I think comparing levels will work with DV_ORDINAL.
>
>
>
>
>
> To be able to specify medication strength in a meaningful way, I need a
> numerator (amount active substance) and a denominator (amount helper
> substance). The numerator can be a mass (such as mg), a volume (such as ml)
> or an arbitrary unit (such as IU). The denominator can be a volume, a mass
> or an administration unit (such as tablet or puff).
>
>
>
> This would be normally modeled with DV_PROPORTION, but the issue is that
> we don't have units there, just real numerator and deonominator.
>
>
>
> This might lead to a requirement of having DV_PROPORTION den_type>, so something like DV_PROPORTION will
> work.
>
>
>
> Also, with DV_QUANTITY alone it is not possible to express an explicit
> numerator and denominator, just the final real value of num/den, but the
> units are flexible enough to satisfy this. But this leads to the issue you
> have again :)
>
>
>
> So if the requirement is:
>
>
>
> 1. to have explicit numerator and denominator,
>
> 2. have units for numerator and denominator,
>
> 3. have units that are not related with physical properties or that are
> not standardized,
>
> 4. be able to compare two values of this form
>
>
>
> With the current RM, I think it is not possible to model it directly as
> one datatype, so it might be a combination of datatypes and using a CLUSTER
> to put all together. Then some querying power will allow you to compare
> those structures.
>
>
>
> I can't think of a better solution with the current RM.
>
>
>
> Architecturally I think having DV_PROPORTION might
> be a better solution but needs changes to the RM. We already have this for
> DV_INTERVAL but a proportion is not the same as an interval.
>
>
>
> REF: http://www.openehr.org/releases/RM/latest/docs/data_
> types/data_types.html#_overview_4
>
>
>
>
>
> Since there can be approximately a million different variations on mass,
> volume and arbitrary units, I don’t want to specify them all in the
> archetype, but leave it up to the application, while still specifying the
>