*
* It might be just me thinking that some of the 21090 types are not that
simple, so am interested in reactions of others. Here is the
documentation of the term-code representation type CD, which explains
how the 'no exceptions' (CNE) and 'exceptions' (CWE) variants should be
realised:
A CD is a reference to a concept defined in an external code system,
terminology, or ontology. A CD may contain a simple code - that is,
a reference to a concept defined directly by the referenced code
system, or it may contain an expression in some syntax defined by
the referenced code system that can be meaningfully evaluated. e.g.,
the concept of a "left foot" as a post-coordinated term built from
the primary code "FOOT" and the qualifier "LEFT".
A CD may also contain an original text or phrase that served as the
basis of the coding. This is preserved to allow for validation of
the representation of the concept in various fashions.
A CD can contain one or more translations into multiple coding
systems. The translations are all representations of the same
concept in various code systems. There is only one concept, and only
the first CD may contain an original text. It is possible to
represent the translation chain - which CD was translated from which
- if desired. Each CD may also carry a rationale to indicate why it
is represented.
A CD with no nullFlavor attribute SHALL have a code attribute or
nonNull originalText attribute. A CD that has a code, codeSystem or
originalText attribute but does not meet external constraints of the
applicable value set SHALL have a nullFlavor attribute with a value
of OTH.
Attributes with type CD are generally bound by externally specified
constraints which constrain the coded concepts to which a CD may
refer. These constraints may be qualified as "extensible" (CWE) or
"not extensible" (CNE). If the constraint is not extensible (CNE),
then a the CD that does not have a nullFlavor SHALL contain a code
that conforms to the constraint. If the constraint is extensible
(CWE) then a CD that does not have a nullFlavor SHALL contain either
a code that exists in the domain with which the attribute is
associated, a code from a locally defined code system, or just some
originalText that describes the concept. If the code is taken from a
locally defined code system, then the codeSystem property SHALL
specify the local code system.
For both CNE and CWE constraint types, the translations may contain
nonNull codes from any source unless otherwise specified by the
constraining model.
For code systems that define expression syntaxes, CNE constraints
may be used, providing that the code system definitions define the
appropriate support to enable value sets to make useful statements
about how to control the expression syntax, and that the value set
machinery used also has the appropriate support.
This is the data structure of a CD, with the HL7v3 message attributes in
red:
type CD = class (
/ validTimeLow : characterstring,/
/ validTimeHigh : characterstring,/
/ controlInformationRoot : characterstring,/
/ controlInformationExtension : characterstring,/
/ nullFlavor : NullFlavor,/
/ updateMode : UpdateMode,/
/ flavorId : Set(characterstring),/
code : characterstring,
codeSystem : characterstring,
codeSystemName : characterstring,
codeSystemVersion : characterstring,
valueSet : characterstring,
valueSetVersion : characterstring,
displayName : ST,
originalText : ED,
codingRationale : CodingRationale,
translation : Set(CD),
source : CD
)
Am I alone in thinking that this is not the simplest way to implement
exceptions or not, to coding? The rules for setting NullFlavor are also
not so simple. I would have thought a more obvious method would be to
define a type with a text field in it, and then a subtype with coding,
e.g. (with message attributes removed):
type TEXT = class (
text : ST
mappings: Set(CD)
)
type CD: TEXT = class (
code : characterstring,
codeSystem : characterstring,
codeSystemName : characterstring,
codeSystemVersion : characterstring,
valueSet : characterstring,
valueSetVersion : characterstring,
codingRationale : CodingRationale,
translation : Set(CD),
source : CD
)
This would enable specifiers to simply put TEXT for 'coded with
exceptions' or CD for 'coded no exceptions' within a model, with the GUI
making the relevant coding widgets available in the correct way (there
are some slight benefits to making a more theoretically correct model,
using 3 classes rather than just 2, but the differences are not
significant). Note that I merged displayName and originalText, as this
seems to be a modelling confusion; if originalText represents some other
text, not the text of the code, then the whole data structure is
essentially a mapping, not a coding of the text. One way to do this is
shown with a 'mappings' attribute in the TEXT class (some people will
object that this could be used infinitely, but in practice it is never a
problem, since applications don't create such structures). In the
original model, 'originalText' and 'displayName' would be the same much
of the time. The rules to do with setting nullFlavor would make more
sense elsewhere, not in the core model.
There are also some interesting comments relating to the valueSet attribute:
In many cases, a CD is created from a value set -- either a
code/code system pair is chosen from a valueSet, or one is not
chosen and the CD has the exceptional value of NullFlavor.OTH. If no
code is chosen, it is generally inappropriate to reference the code
system from which the code was chosen as the value set may not match
the code system (may include a subset of the codeSystem, or
additional terms from other code systems); instead, the value set
should be provided. *In addition, there are some known use cases
where the value set that a user or system was offered when choosing
a code affects the interpretation of the code*.
The last sentence above indicates that the meaning of a code stored in
data might depend on how it was chosen. This would break the basic
immutability of meaning of codes in a code system. I wonder how we would
compute with such data?
The 'translations' attribute is also strange: according to the
documentation it is not about translations but about code synonyms
and/or mappings (in reality two different things).
- thomas beale
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101117/a0b668c3/attachment.html>
