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
