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
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
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”
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
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
I’m not really sure that it even means what we need in this case
Indeed it does, as may be verified with the ADL Workbench
It was added to the RM years ago to support quantities in lab results, which are sometimes of the form <X, >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
yeah, I can see to be useful for that, but seems weird to constraint it in any way
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
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
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.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?
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 
Thanks for all your replies! 
Attempt at summarising:
Is this a good summary?
Regards,
Silje
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