Rich text format in DV_TEXT
Hi Bert,
This is perfectly legal ADL created with the Ocean AE - it allows for
a single value with a 'choice' of datatype. We use this pattern fairly
frequently.
Ian
On 24 September 2013 07:15, Bert Verhees bert.verhees at rosa.nl wrote:
On 09/23/2013 07:28 PM, Ian McNicoll wrote:
It is certainly possible to adapt the current archetype to allow something
like
definition
EVALUATION[at] 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}
}
Did someone already mention? If so, sorry for repeating that.
Specs needs to be changed for this, ELEMENT can only have one value
according the current specs.
Bert
___
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
Rich text format in DV_TEXT
Yes, as Ian says it's a pretty common pattern
2013/9/24 Ian McNicoll Ian.McNicoll at oceaninformatics.com
Hi Bert,
This is perfectly legal ADL created with the Ocean AE - it allows for
a single value with a 'choice' of datatype. We use this pattern fairly
frequently.
Ian
On 24 September 2013 07:15, Bert Verhees bert.verhees at rosa.nl wrote:
On 09/23/2013 07:28 PM, Ian McNicoll wrote:
It is certainly possible to adapt the current archetype to allow
something
like
definition
EVALUATION[at] 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}
}
Did someone already mention? If so, sorry for repeating that.
Specs needs to be changed for this, ELEMENT can only have one value
according the current specs.
Bert
___
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
___
openEHR-technical mailing list
openEHR-technical at 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/20130924/6c79b1ab/attachment.html
Rich text format in DV_TEXT
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
Rich text format in DV_TEXT
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
Rich text format in DV_TEXT
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] 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
Rich text format in DV_TEXT
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[at] 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]
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
SV: Rich text format in DV_TEXT
This is a very relevant issue. We have the same in our application. Some of the fields will be DV_TEXT but we want to show some rich formatting. It is crucial to be compatible with Archetypes from CKM, and different vendors producing or consuming Archetypes. So it is not an option to make changes on the Archetype. Just as you tell. We did not find any workarounds. So any good idea or proposal is very welcome. Vennlig hilsen Bj?rn N?ss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10tel:+47%2093%2043%2029%2010 Opprinnelig melding Fra: Sebastian Iancu sebastian at code24.nl Dato: 23.09.2013 14.57 (GMT+01:00) Til: For openEHR technical discussions openehr-technical at lists.openehr.org Emne: Re: Rich text format in DV_TEXT 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-boun...@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.orgmailto:openEHR-technical at 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/2063f598/attachment-0001.html
Rich text format in DV_TEXT
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. 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). 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. 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. 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 -- 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
Rich text format in DV_TEXT
This is valid ADL
definition
EVALUATION[at] 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[at] 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.orgopenEHR-technical at
lists.openehr.org
http://lists.openehr.org/**mailman/listinfo/openehr-**
technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
__**_
openEHR-technical
Rich text format in DV_TEXT
' 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 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 mailto: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 mailto: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 mailto: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 mailto: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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/11c12eb6/attachment-0001.html
Rich text format in DV_TEXT
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: blik/be heire/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
Rich text format in DV_TEXT
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
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130920/401ed47b/attachment.html
