>>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?
>
>no they're not. I'm not sure what it means to say "is openEHR
>case-sensitive or not" - wherever Strings occur, it is, since String
>processing in computing is always case-sensitive by default. Only in
>specific places (e.g. the Windows NTFS file system) has it been removed.
hmm. I will come back to this later.
>>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?
>
>not sure why you say this - the only meaning for this attribute is to
>indicate match. There is no other data in the attribute. But you might
>argue that it should be an enumerated type rather than an Integer. We went
>for an integer for the following reasons:
>- it is quite common in the C languages for -1/0/+1 to be the results of a
>comparison, e.g. with the string routines.
>- to allow for the possibility in the future that sensible meanings could
>indeed be attached to higher /lower values.
yes, and we could use 0 to indicate null too, which is common practice in
the c langauges.
I do argue that this should be an enumerated type. If it get's extended to
higher
and lower values, then begin a terminology makes the problems with changing it
explicit
>>5.2.1 TERM_MAPPING.purpose - no terminology? how could this have any
>>practical
>>meaning with a controlled usage?
>
>I think it probably should be coded as well (I presume you meant here
>"without controlled usage"). But there are no terminologies for this at
>the moment, although it would not be hard to invent one.
oh yes - I did mean without. This is one of those horrible little corners
for which
one must invent a terminology
>>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
>
>the whole point is here not to introduce any semantic markup. We only want
>simple formatting. If you want to include whole tracts of semantic text,
>use DV_PARSABLE or DV_ENCAPSULATED...
oh - parsable? interesting. I read that and ignored it since it said so little
about what it was. why is it constrained to plain text?
back to the point. Why don't you want semantic markup?
>>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?
>
>to record only the reference range for a given datum, for a given patient,
>for the given test etc - not to record whole reference range tables. In
>most pathology this appears to suffice. But I'll say again - it's not to
>include all the reference range tables or data - only to record the
>particular values for the particular measurement and patient ...
but the reason endocrinologists have such wonderful reference ranges is
that the particular values may not be
known (or even knowable). LH and FSH are classic examples - here's a set of
reference ranges for different
stages of the cycle. The test as probably ordered to give some indication
of where the cycle is - so instead
of interpreting the test result in terms of the reference range for the
patient's situation, we are interpreting
the patient's situation in terms of the result compared to it's reference
ranges.
But more generally, pathology test providers do not have enough information
to assign
a patient to one of a set of reference ranges, where they have them
>>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.
>
>for BINs, EDs and STs I presume. Not for anything else...
yes, but there's no other LIST<BL> anywhere. and elsewhere, the presence of
null items in the list isn't so outright stupid as in LIST<BL>.
>>2. ARRAY<CHAR> is not the same as ARRAY<BYTE>
>
>because of double width characters presumably?
yes
>>3. ST is a problem but it is a list<ST> (oh, err, LIST<CHAR>) not a
>>LIST<BL>.
>
>Going by the 4th ballot, I must have missed something - it seems to be
>that ST inherits from ED then BIN, which is bound to LIST<BN>.
ah yes, but we tricked you and pulled a fast one by redefining it's
ancestor. This is a fun trick to pull, so
I'll explain it a bit better:
LIST<T>
head() : T
tail() : LIST<T>
BIN = LIST<BN>
head() : BN
tail() : LIST<BN>
ED
head() : BN
tail() : LIST<BN>
ST
head() : ST
tail() : ST
because BIN is a LIST<BN>, then the head and tail take types BN and list<BN>.
But when we come to string, we pull a fast one, and ST is actually a LIST<ST>.
or ST is actually a ST. or something. So you see what I mean by we saying that
we pulled a fast one. Though I think mostly we tricked ourselves. And it
should
be clear, that as editor of the spec, my current project is to fix that
little mess!
>>4. I reworked the null stuff a little so that's out of date now ;-)
>
>as soon as I can understand the 4th ballot, I will write an update for
>this section;-)
oh - well I won't hold my breath. When you do understand, can you let
everyone know
Grahame
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
