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.
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.
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.
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.
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.
When it comes down to trusted ADL tooling I'm always a bit lost. Which one have you used? I tried to specialize original archetype with AE an than validating with ADL Workbench (both latest version). My ADL was
definition
EVALUATION[at0000.1] matches { -- Clinical Synopsis!
data matches {
ITEM_TREE[at0001] matches { -- List
items cardinality matches {1..*; ordered} matches {
ELEMENT[at0002.1] matches { -- ! - Synopsis
value matches {
DV_TEXT matches {*}
DV_PARSABLE matches {*}
}
}
}
}
}
}
and I get
ERROR (VSONCT) object node at path /data[at0001]/items[at0002.1|! - Synopsis>]/value (RM type DV_PARSABLE) does not conform to node at parent path /data[at0001]/items[at0002]/value RM type DV_TEXT
which I can agree with.
Your code looks a bit different; it might be valid, but it is not a specialization on original one, isn't it?
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.
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:
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:
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
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.
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.
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
Is that so, I never thought about it that way, a choice-pattern. Thanks for learning me that lesson.
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.
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?
Just to clear out few things:
- I was not intending to go for a specialized synopsis, but for a completely new local (offline) archetype with similar structure and meaning;
- I know that is not good for CKM usage, but it is a workaround for us until RM will be fixed;
- it is clear for me that a change (by adding PARSABLE) on archetypes from CKM is not elegant and neither sustainable on long term (as more archetype may need to suffer the same);
- off course we can move this discussion to CKM, but I think the things are clear for now, and it is anyway more related to RM than to archetypes.
