I would advise against putting markup directly in DV_TEXT.value - that
will surely led to non-interoperable data. I would suggest using
DV_PARSABLE, with the XML or HTML you want.
However the problem here is that the parent clinical_synopsis archetype
on CKM has this definition:
ELEMENT[at0002] matches { -- Synopsis
value matches {
DV_TEXT matches {*}
}
}
This is too narrow, since DV_PARSABLE does not inherit from DV_TEXT, but
is likely to be needed for situations requiring formatting. Ideally this
archetype in CKM would be upgraded to include DV_PARSABLE as an
alternative.
That's the solution within the current RM. It is debatable whether we
shouldn't fix the text cluster in the RM, so that there is a clearer way
of doing a) paragraphs and b) formatting. I believe we still need to
retain the atomic idea of a DV_TEXT as something containing no
formatting, and yet being minimally boldable / emphasised in the rendering.
We have had some discussions before on this, which I myself would need
to dig up to remember previous conclusions. But as we are about to enter
into a phase of RM revision we can certainly contemplate the kind of
updates we want.
I would suggest (without having done sufficient analysis - just thinking
out loud here) that we may need types like:
DATA_VALUE*
*
* *DV_TEXT* (abstract)
o <- DV_SIMPLE_TEXT (includes simple formatting + URL, that
applies to whole atom)
+ <- *DV_CODED_TEXT* -- coded term
+ <- DV_PLAIN_TEXT -- can only be plain text
o <- DV_FORMATTED_TEXT -- take care of paragraphs and formatting;
works like a DV_PARSABLE
The bolded types are RM 1.0.2 types. We can get very close to doing the
above and retaining backward compataibility for DV_TEXT and
DV_CODED_TEXT data.
If we want perfect backward compatibility, we would need to do the
following:
DATA_VALUE*
*
* DV_TEXT_ITEM (abstract)
o <- *DV_TEXT *(includes simple formatting + URL, that applies to
whole atom)
+ <- *DV_CODED_TEXT* -- coded term
+ <- DV_PLAIN_TEXT -- can only be plain text
o <- DV_FORMATTED_TEXT -- take care of paragraphs and formatting;
works like a DV_PARSABLE
We need to do a proper analysis on this in the upcoming revision, and I
suggest a change along these lines would go into release 1.0.3. Then
the current clinical synopsis archetype would in fact be correct!
BTW, I'm not in favour of any solution in which plain text and formatted
text replicate each others' content (see why
<http://wolandscat.net/2012/01/28/the-cda-dual-content-conundrum/>).
hope this helps. We'll be getting started on release 1.0.3 in the next
couple of weeks, so look out for announcements.
- thomas
On 23/09/2013 14:29, 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/64402208/attachment.html>
