Grahame Grieve wrote:
> 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.
> 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
As far as we can determine, there is no extant standard for names of
terminologies. There is an ISO standard 11179 which we have yet to
obtain and study. If this provides a more standard way of expressing
names of terminologies, then we will use it. So far, we have used the
form "name(version)" for terminologies, e.g. "SNOMED-CT(2003)". In the
terminology ids section, we have for example:
Terminology_id_Languages: SET<STRING> = {
ISO:639-1(1988)
,
ISO:639-2(1998)
...}
-- ISO language names; see
http://www.loc.gov/standards/iso639-2/langhome.html
Terminology_id_Countries: SET<STRING> = {
ISO:3166-1
,
ISO:3166-2
, ...}
-- ISO country codes & country subdivision codes
So here, the nameof the first terminology is "ISO:639-1" and the version
"1988". I don't think this is inconsistent, but there may be better ways
to express such names.
> 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
actually, there was no intention that these two terms be linked in the
text - the intention was to show that both text (DV_TEXT) and a coded
term (DV_CODED_TEXT) could have mappings of other terms added.
> 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.
> 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...)
They might. But the specification explicitly says that only comparisons
of >, =, and < 0 are meaningful.
> 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
multiple languages are allowed - no doubt about that - it's why DV_TEXT
records language at the finest level.
> too unusual here with a signficant migrant population and many doctors
> from
> these ethnic groups - then we know what the requirements are?
The requirements are very complex. It is easy to find use cases, the
problem is that there are so many use cases that nobody has worked out a
general way of dealing with them all yet. Some of the challenges:
- translation and version control - should translations be allowed as
new trunk versions, side versions or be forced to be new version trees?
- what if some of the latest most up to date information is only
available in another language (due to the patient getting sick while in
the Amazon for example)?
- what if translations don't translate the whole text of existing entries?
> 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.
> 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...
> 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
DV_INTERVAL is just a type which inherits from DATA_VALUE, INTERVAL does
not. DV_INTERVAL could easliy be implemented using an INTERVAL<>.
> 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 ...
> 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...
> 2. ARRAY<CHAR> is not the same as ARRAY<BYTE>
because of double width characters presumably?
> 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>.
>
> 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;-)
- thomas beale
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
