Thanks Sebastian,
I think we agree that there is a important difference between
formatted text which can gracefully degrade to plain text without loss
of meaning, and text where significant semantics are carried in the
markup, and where there will be clinical safety issues if the markup
is lost.
It is certainly possible to adapt the current archetype to allow something like
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 {*}
DV_PARSABLE matches {
formalism matches {"text/html", "text/rtf", "text/plain"}
}
as you said the specialisation is not possible since it widens the
datatypes allowed by the parent constraint.
I am not too keen on adding DV_PARSABLE multi-attribute values since,
as everyone agrees, almost every 'narrative-style' DV_TEXT element in
every archetype might reasonably need to be changed.
Although I appreciate the extra overhead of carrying the original HTML
in feeder_audit, I think this is the most sensible workaround for now,
and we should concentrate on reviewing DV_TEXT and its cousins as
Thomas has suggested.
Ian
On 23 September 2013 15:19, Sebastian Iancu <sebastian at code24.nl> wrote:
> On 9/23/2013 3:29 PM, Ian McNicoll wrote:
>>
>> Hi Sebastian,
>>
>> This is a good summary of the alternatives. As I understand things the
>> use of DV_PARAGRAPH is how this sort of rich-text markup was intended
>> to be supported but I agree that it seems pretty tricky to implement.
>
> Tricky, especially when formats were wrongly applied: <b>lik</b>e
> he<i>re</i>, formatting not matching words boundaries will break the meaning
> of text stored in DV_TEXT.
>
>> One other alternative approach would be to carry the stripped down
>> 'raw text in the DV_TEXT value, with the HTML in the
>> feeder_audit/original_context attribute (from LOCATABLE).
>
> That comes also with an additional data costs, and syncing issues upon
> re-editing.
>
>> It would still be interesting and useful to better understand the
>> specific use-case for "Clinical synopsis" - will the markup be
>> restricted to formatting and perhaps linking, or do you envisage there
>> being further processable content within the HTML, which takes us more
>> into the realm of CDA-style 'narrative block' markup? and where I
>> think DV_PARSABLE is more appropriate.
>
> At this time not, just a few simple html formatting tags, to allow end user
> to highlight some parts of the text which might be important for the reader.
>
>> Whilst the idea of a multi-purpose Text datatype that can handle
>> anything from plain text through to xml or json seems technically
>> attractive, we have to be conscious of downstream systems being able
>> to correctly display the maneing of the text and not inadvertantly
>> hiding important content / context within the non-textual parts of a
>> parsable string.
>
> For me xml/json is more structured data rather than TEXT; a DV_PARSABLE is
> be more suitable for that.
>
>> Ian
>>
>>
>>
>>
>>
>> On 23 September 2013 13:56, Sebastian Iancu <sebastian at code24.nl> wrote:
>>>
>>> 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]
>>> 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
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>>
>>>
>>> _______________________________________________
>>> openEHR-technical mailing list
>>> openEHR-technical at lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>>
>>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
