Hi Sebastian,
In that case you will need to create a specialisation with a new
element to hold the parsable text. I am interested in knowing from
other implementers whether there is a strong case for adding this to
the current 'official' archetype.
This could be done as a revision i.e backwardly compatible. We could
also add DV_PARSABLE to the current Synposis element as a 'datatype
choice' but I am pretty sure this would require us to create a new
version 2 archetype, for the same reasons that this is not possible to
do as a specialisation, which would not be backward compatible.
The real solution is, I think we agree, to handle this in the RM so I
am reluctant to mess about too much with the existing archetype but if
there is a strong demand for immediate changes from implementers, we
have to take that seriously, even if it feels like a bit of a
temporary hack.
I would be interested to know from others whether you agree with
Sebastian's approach, or whether my suggestion to use the existing
feeder_audit/original_content attribute is an acceptable workaround.
Also, I would like to start to move this conversation on the CKM
discussion space for clinical _synopsis, so that we can document
thoughts and approaches there for future reference. Any objections?
Ian
On 24 September 2013 10:13, Sebastian Iancu <sebastian at code24.nl> wrote:
> Thank you all for your feedback.
> It was good to see the same concern on others (facing similar problems), the
> suggested workarounds and the openness of addressing this on an upcoming RM
> change.
>
> In the mean time I'm more in favor of using locally modified archetypes,
> that allows PARSABLE alternative to TEXT. We only need this on a few
> archetypes (at this time), and we anyway need to change them later again as
> soon as the new RM is released.
>
> Sebastian
>
>
> On 9/23/2013 7:28 PM, Ian McNicoll wrote:
>>
>> 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
>>
>>
>>
>
>
> _______________________________________________
> 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
