New Data Types draft + open questions

Technical (archive)
1

Dear all,

A new proposed draft of the openEHR data types is available at http://www.deepthought.com.au/health/openEHR/data_types_1_5_2.pdf. This draft includes a major rewrite of the explanation of text types (plain text, coded text and friends). The model is not drastically different, apart from the addition of a new attribute in DV_TEXT called mappings. This is an important attribute, as explained in the text, and covers the semantics of classifying terms, equivalents (HL7 "translations"), and other scenarios where text (coded or otherwise) is mapped to other terms.

OPEN QUESTIONs

There are a few outstanding questions on the model, which terminology experts on this list might like to respond to.

1. The use of rubrics in TERM_REFERENCE and DV_CODED_TEXT.
The "rubric" is the textual rendering corresponding to a code. We have put it in TERM_REFERENCE, which models exactly the 1:1 asscociation of a rubric and a code, and also in DV_CODED_TEXT, where it means the final text string generated by the terminology service, taking into account qualifiers. For almost all instances of DV_CODED_TEXT, there is only one TERM_REFERENCE anyway, so the two rubrics are duplicates. For those cases where post-coordination of a primary and one or more qualifiers is generated by the terminology service (e.g "lung, left"), the rubric of each TERM_REFERENCE will be the primary and the qualifier terms ("lung" and "left", respectively), while the rubric of the DV_CODED_TEXT the coordinated result ("lung, left").

Sam Heard suggests that there is no reason to keep the rubrics of the TERM_REFERENCEs, since a) it is almost always a duplicated of the rubric of the DV_CODED_TEXT, and b) it will never be needed even in cases where qualifiers are used.

Is there any reason to keep TERM_REFERENCE.rubric?

2. Mode-changing term flag
We have not currently used a flag to indicate change of mode such as "risk of", "history of" etc. Our analysis is that the proper use of archtyped information structures obviates the need for any such special indicator.

Dipak Kalra and David Lloyd (and I suspect many others) argue that such a flag or indicator is still needed.

Are there other opinions on this matter?

3. Negation flag
Simiarly, we don't believe that any special flag is needed for negation, and in fact is likely to be dangerous.

We know however that many might not agree, since almost all of us are used to the "old" world in which EHR data was not constructed according to well-defined models. Are there any arguments for adding a flag to indicate negation to the DV_CODED_TEXT class - with evidence and examples please. Please read the arguments in the document first, before replying!

- thomas beale

2

Dear All

Some further information on my thoughts on these matters.

1. Rubrics

I believe that the textural entry in the record should be the only text that
is carried - not the individual rubrics - as not only is this unnecessary -
but it leads to the danger of use of the rubrics without access to the
terminology service from which they are derived. Remember, if the codes are
there then the rubrics are available if you have access to that terminology
service - and the final 'rubric' or post coordinated string is always
present.

2. Mode changing

Alan's idea of mode is important - some 'modifiers' change the meaning of
the term to something quite different. I suggest that such relationships
have to be in the archetypes - such as 'risk of' or 'family history of' amd
we have archetypes for these notions. The argument for this is that we need
more than these term associations anyway - family history in the future will
require the nature of the relationship and also if it was genetic or not.
Risk will require quantification and almost certainly some details of how it
has been calculated.

Fear of probably does not fall into this category - and should not be
available as a qualifier for this reason. I would suggest a specific place
holder in the problem archetype for this - remebering that agorophobia is a
precoordinated version of this anyway and we should be careful to ensure
that there is some consistency about this.

3. Negation - there are limited terms that have sensible negation - but
family history is an example where you may wish to say that there is no
family history of XXX on the maternal side - as this may be significant. For
this reason there is a negation placeholder in the family history archetype.
This may be required in a number of places.
Negation does not sit well at the term level - how would we describe the
situation above - 'Family history - maternal relatives - not(ovarian
cancer)'. This is not what we want to say - it should be 'not(Family
history - in maternal relatives - of ovarian cancer)' - something that is
only possible in the archetype structure.

Although it is tempting to consider the utility of palpable having
not-palpable as a negation - present and absent do not work so well - and
most polar extremes such as high pitched and low pitched are not negations
at all. What if someone records 'not(liver)'.

These are my initial contributions to this debate.

Cheers, Sam