This is valid ADL
definition
EVALUATION[at0000] occurrences matches {1..1} matches { -- Clinical
synopsis
data existence matches {1..1} matches {
ITEM_TREE[at0001] occurrences matches {0..1} matches { --
ITEM_TREE
items existence matches {0..1} cardinality matches {0..*;
unordered; unique} matches {
ELEMENT[at0002] occurrences matches {0..*} matches {
-- ELEMENT
value existence matches {0..1} matches {
DV_TEXT[at0003] occurrences matches {0..1}
matches {*} -- DV_TEXT
DV_PARSABLE[at0004] occurrences matches {0..1}
matches {*} -- DV_PARSABLE
}
}
}
}
}
}
Or even as an specialized archetype
[image: Im?genes integradas 1]
[image: Im?genes integradas 2]
2013/9/23 Sebastian Iancu <sebastian at code24.nl>
> Trying with Archetype Editor was not possible. Besides, none on
> DV_PARAGRAPH or DV_PARSABLE inherits from DV_TEXT. To make an alternative
> sibling node next to DV_TEXT didn't looked right to me.
>
> definition
> EVALUATION[at0000] matches { -- Clinical Synopsis
> data matches {
> ITEM_TREE[at0001] matches { -- List
> items cardinality matches {1..*; ordered} matches {
> ELEMENT[at0002] matches { -- Synopsis
> value matches {
> DV_TEXT matches {*}
> }
> }
> }
> }
> }
> }
>
> Do you have a suggestion or an example?
>
> Sebastian
>
>
>
> On 9/23/2013 3:00 PM, Diego Bosc? wrote:
>
>> Can you elaborate a little more why do you think second option is not
>> valid?
>>
>> 2013/9/23 Sebastian Iancu <sebastian at code24.nl>:
>>
>>> Hello,
>>>
>>> Actually the question is more generic, the archetype itself is not very
>>> important.
>>>
>>> What we need is to store rich-text (html from a web-editor) on a DV
>>> element.
>>> The text may include several paragraphs, and a few simple formatting tags
>>> like bold, italic, colors, etc. To my knowledge, to accomplish this the
>>> RM
>>> 1.0.2 specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks
>>> holding
>>> necessary formatting) or alternatively DV_PARSABLE (with
>>> formalism=html). In
>>> any case not a single plain DV_TEXT.
>>>
>>> Thus, if we intend to use published archetypes on CKM
>>> (openEHR-EHR-EVALUATION.**clinical_synopsis.v1), from your experience
>>> what is
>>> the best option:
>>> - use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the
>>> right
>>> formatting ( = not an easy option to implement in our app, and also that
>>> specific archetype is not prepared for that)
>>> - specialize the archetype the so that allows also DV_PARAGRAPH or
>>> DV_PARSABLE ( = I don't think that is allowed by the owned constraints)
>>> - propose changes to RM so that DV_TEXT allows also 'simple' rich-text
>>> content, like html for instance, and not only per-word-formatting
>>> - create our own local archetypes based on CKM version, but with the
>>> 'right'
>>> DV elements ( = not a nice option considering knowledge management)
>>> - or use a single DV_TEXT, and misuse its 'value' to hold also html.
>>>
>>> Thanks,
>>> Sebastian Iancu
>>>
>>>
>>>
>>>
>>> On 9/23/2013 5:06 AM, Heather Leslie wrote:
>>>
>>> Hi Alessandro,
>>>
>>>
>>>
>>> Curious as to the use case for the DV_PARSABLE. Can you share?
>>>
>>>
>>>
>>> I?ll let the engineers discuss potential enhancements to the datatype?
>>>
>>>
>>>
>>> Heather
>>>
>>>
>>>
>>> From: openEHR-technical [mailto:openehr-technical-**
>>> bounces at lists.openehr.org <openehr-technical-bounces at
>>> lists.openehr.org>]
>>> On Behalf Of Alessandro Torrisi
>>> Sent: Friday, 20 September 2013 11:57 PM
>>> To: For openEHR technical discussions
>>> Subject: Rich text format in DV_TEXT
>>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> we are using an archetypes from the CKM called
>>> openEHR-EHR-EVALUATION.**clinical_synopsis.v1. Over there is an DV_TEXT
>>> element called Synopsis
>>>
>>>
>>>
>>> One of our clients want to use rich text format inside that field.
>>> According
>>> the specification it is not allowed to put formatted text over there. I
>>> rather should use a DV_PARSABLE.
>>>
>>>
>>>
>>> How should i handle this correctly? The options i see are :
>>>
>>> - specialise the archetype and add an DV_PARSABLE, and leaf the existing
>>> DV_TEXT empty
>>>
>>> - create my own archetype where I set the Synopsis element to a
>>> DV_PARSABLE
>>>
>>>
>>>
>>> beside this question, i wonder if it will be better to give the DV_TEXT
>>> datatype the possibility to put over there rich text. If we also add the
>>> parameter formalism to it, there is no really need any more for a
>>> DV_PARSABLE.
>>>
>>>
>>>
>>> --
>>> Alessandro Torrisi
>>>
>>>
>>>
>>> ______________________________**_________________
>>> openEHR-technical mailing list
>>> openEHR-technical at lists.**openehr.org<openEHR-technical at
>>> lists.openehr.org>
>>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> openEHR-technical mailing list
>>> openEHR-technical at lists.**openehr.org<openEHR-technical at
>>> lists.openehr.org>
>>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>>>
>> ______________________________**_________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.**openehr.org<openEHR-technical at
>> lists.openehr.org>
>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>>
>
>
> ______________________________**_________________
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org<openEHR-technical at
> lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/6fb01ca9/attachment.html>
