These comments relate to v1.7.1
Section 4.2 DV_BOOLEAN. are the values {true, false}
case sensitive? Generally, is openehr case sensitive
or not?
Section 5.1.1. Terminology Id's - this section doesn't
seem consistent with the Terminology section of
the external package. Also, terminology versions
aren't included, but this is usually important
Section 5.1.5. includes the following example:
blah blah Ross River infection blah blah blah bronchial pneumonia
with some annotations about how these concepts are coded.
But I don't understand what the value of this is when the text
could be either of:
Patient has Ross River infection which caused severe bronchial pneumonia
Lab Result of Ross River infection is wrong. Patient has bronchial pneumonia
5.1.5.2 This section introduces the "match" attribute, which has one
of the following values:
-1 code provided is more specific than it should be
0 code matches intent
+1 code provided is not as specific as the intent
The use of values like this seems poorly modelled - surely this
is a variation of the datum interpretation concept from the design
principles? Also, the use of a numerical value seems to fall into the
design practices condemned in that section, and makes me think that
some users/implementors will start putting in -10 when they feel strongly
about the coding issue (and who doesn't feel stringly about coding...)
5.1.6 Language Translations. This whole issue is a nightmare, but it bother's
me that because "it's not known what will be needed", we won't allow multiple
langauges. Surely, if the source material is in multiple languages - not
too unusual here with a signficant migrant population and many doctors from
these ethnic groups - then we know what the requirements are?
5.2.1 TERM_MAPPING.purpose - no terminology? how could this have any practical
meaning with a controlled usage?
5.4.1 TEXT_FORMAT_PROPERTY. It seems strange to me that this makes use of
CSS, rather than introducing semantic based markup. HTML is a mess, but
semantic based markup is a good thing, where as CSS is the opposite
6.3 - interval. I'm not sure why there is an implicit type Interval<T> and
this extra type - it's hard to work out what the implications of their
differences is
6.4 reference Range type - this seems a little simple to handle the gloriously
complicated reference ranges much beloved by endocrinologists. What is the
intent in these cases?
12.2.5 HL7 types. Ok, I have to comment.
1. I changed BIN to List<BN> from LIST<BL> so that the null issue is clarified.
2. ARRAY<CHAR> is not the same as ARRAY<BYTE>
3. ST is a problem but it is a list<ST> (oh, err, LIST<CHAR>) not a LIST<BL>.
4. I reworked the null stuff a little
so that's out of date now ;-)
Grahame
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
