Grahame
It is like being reviewed by a tornado - even my teeth feel clean!
> >>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.
This is quite usual I guess.
> >>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
I tend to agree with your reasoning - really equivalence is 1 from a
mathematical point of view. These values will only be included if they are
already in mapping tables and would only be used for automatic processing -
and could be determined independent of the EHR and perhaps should be - but
it might be useful when you translate - for example - so Ross River
(Australian disease) might come out as an Arbo Virus Infection in Italy -
they will not know Ross River anyway and will see that the statement was
more specific - they will know it is a type of arboviral infection that is
not in their set.
> >>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
This was an area we wanted to cover but not control at the moment. It will
only have textural meanings at present but it could be helpful in some
jurisdictions - they can code it!
>
> >>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.
That is why we can have more than one - and then one can be marked as the
relevant one.
I will leave the rest to you - hope you get some sleep - Sam
> 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
That is true - but it can be after the fact if that is appropriate.
>
> >>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
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
