On 18/11/2010 05:28, Grahame Grieve wrote:
>
>
>> This is the data structure of a CD, with the HL7v3 message attributes in
> I guess you'll continue to dismiss them as "hl7 v3 message
> attributes", but you miss the point by doing so - they are a response
> to a set of use cases that are not v3 - or even messaging - specific.
> They are in a different place to where you would like to have them,
> but that's about the above discussion
I don't think I am missing the point at all. They are
a) a response to some (undoubtedly real) needs by the hL7v3 design
group, and are modelled according to the hL7v3 architecture, not some
other architecture. I don't dispute the need to address the requirement
that these attributes try to address, I am just pointing out that this
is HL7's specific way of doing it (other people would have designed
completely different solutions).
b) there is no escaping the fact that these attributes are inherited
into every other data type, a design that instantly renders these types
not directly usable for situations other than messaging. Since the first
thing any system will need to do with received data in messages is
process and store it in some way, that's an extremely unfortunate thing
to have done. I realise you had no choice, and this is the way beloved
of HL7, but it does happen to break some basic OO rules of reuse and
maintainability.
>> I would have thought a more obvious method would be to define a
>> type with a text field in it
> I don't think it's more obvious. It's certainly possible, but then I have
> terminology policy differences represented as different types in
> my engineering layer - rather a drawback from at least my point
> of view. I'd say more, but I think that's enough to demonstrate that it's
> not obvious. To determine which was better would be a long discussion,
> and we'd need to start by determining the scope of "better for what?"
better for everything. I am just talking about a simpler, more
comprehensible model, in the interests of less bugs and anomalies by
implementers.
>> with the GUI making the relevant coding widgets available in the correct way
> uh? What's the GUI got to do with it? For the ISO 21090 data types,
> this is not in scope. I understand that this is in scope for openEHR,
> because you automatically build UI from model's choice of data
> type, and that's why you'll continue to use openEHR data types for that.
> fine, makes sense.
The openEHR data types have nothing specific to to with the GUI; I only
made this comment because I have seen specious arguments about how
certain model structures (like the one I proposed) would lead to
infinite strings of data, which of course is nonsense. Thinking about
how a real system works (e.g. at the GUI layer) may help some people to
understand this.
>> Note that I merged displayName and originalText, as this seems
>> to be a modelling confusion
> or you could actually read the documentation that makes the differences
> very clear. In particular, note the restrictions on the use and implications
> of displayName. I will say that originalText is semantic in nature - inherent
> to the actual meaning, whereas displayName is distinctly interoperability
> related - and pretty much irrelevant in an openEHR context.
I have read the documentation, don't worry! I still think it is
conceptually mixed up. In fact, I am not even sure the spec is clear
itself on what originalText really is:
Original text can be used in a structured user interface to capture what
the user saw as a representation of the code on the data input screen,
or in a situation where the user dictates or directly enters text, it is
the text entered or uttered by the user
So is it a representation of the code on the data input screen (i.e. the
term for the code) ? Or is it some other freely entered text to which a
code (and term) is being attached? Why is originalText 'semantic' and
'displayName' not - when it is in fact the proper linguistic rendering
of the code, and therefore surely 'semantic'?
>
>> 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?
> yes, I wonder about that too. And the answer appears to be, pretty much, that
> you can't. Which is the point of recording the value set - so that some other
> person, later, can decide for themselves whether the limited value set
> undercuts
> the immutability of the meaning of the code. The problem is that this *does*
> happen in practice all the time, and merely banning it's occurrence in our
> mental model of the standard contributes to the standard being a fantasy.
> Needless to say, I argued against the inclusion of that particular text
> strenuously, but I end up recognising that it is merely a reflection of
> the real world
more realistically, a reflection of committee-based standard building.
>> 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).
> really? how would you define so? Do you mean, translations to other languages?
> otherwise, the terms mappings vs translation are used about as consistently
> as any other terminological terms. (See, it's the proven blind leading the
> blind when the terminologists tell us that they can lead us to consistent use
> of terms)
>
you are right in that there is probably more complexity to this bit that
we have time for here, but we can at least distinguish between:
* a true synonym (different linguistic rendering of the same
concept), AND
* a mapping - usually done for classification purposes, e.g.
association of a broad ICD or DRG code to some specific disease or
condition text.
To me, the fact that there are so many things worth debating in the
standard really tells me that the committee-based approach hasn't
worked; a proper engineering review process would have changed the
standard significantly and for the better in my view.
- thomas
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101118/e79a2aec/attachment.html>
