[2nd attempt]
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
The point is
a) that they are HL7's idea, from HL7's architecture, of how to solve
some problems. Had other engineers & developers been involved, other,
better and certainly different solutions could have been found.
b) it is an unavoidable fact (an inconvenient truth) that HL7's approach
of putting context/use case specific attributes in general models, and
then expecting them to be 'profiled out' is contrary to maintainability
and reusability of these models. Where I would like to see them is not
my personal choice, it is just a conclusion of basic good modelling
practices.
>> 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. We should be interested in generic, reusable data
types here, not HL7 message specific ones, nor ones that try to
incorporate every possible contextual use case into the same model. That
just creates complexity and increases the likelihood of
non-interoperable implementations, due to different implementers having
interpreted the rules differently, and profiled the model differently.
>> 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.
I just used the example of the GUI to help people understand that there
is no realistic danger of endless strings of terms, even if the model
technically permits it. With respect to the openEHR data types, they
have no specific relationship to GUI, messages or anything else. On the
other hand, they can (and are today) used effectively in GUIs, messages,
persistence, business logic and document processing. Contextually
specific features needed in any of those places are included in the
relevant models and software, not jammed into the data types. This is
the way any good modelling works; the openEHR models just try to follow
generally accepted good modelling principles.
>> 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 spec, and I don't think it is even clear itself (here we
come up again against trying to satisfy competing use cases within a
single data types specification).
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 originalText the freely entered text of the user, or the term for
the code which is being attached to some text? How is the original text
the user entered more 'semantic' than the term from the terminology? The
problem here is not specific to this type in this model, but in fact
systemic in the whole specification: the /actual/ /formal/ semantics of
any model are only what is expressed in the formal specification. Any
further meaning of values in any field of any object defined by the data
types specification is not the business of the latter, but of the
/client code & models using it/. However, this 21090 specification is
full at every turn with natural language statements about how the
various fields might be interpreted in various circumstances, according
to use cases known by its authors. I am not saying this is not useful
information, but what I am saying is that it is in /completely the wrong
place/.
Some posts ago, I suggested that a useful standard for data types could
consist of:
* a set of clean, clear core data types - no context information
like 'updateMode' or null flavour etc.
* a set of wrapper types designed to use the core types, optimised
for messaging
* other sets of wrapper types as needed, optimised for other
specific purposes, e.g. storage or whatever
The contextual / use case specific stuff would then go in the 'wrapper
specifications'.
>> 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
I would say it is a reflection of the committee-driven standards
building process. There is no realistic prospect of physicians or anyone
else going back through gigabytes of medical data and trying to decide
what might have been in the mind of the person originally recording the
data, and how that might have been somehow different from the
terminology's definition of the meaning, due to some knowledge about how
they chose it. There may be reasons to record the value set / ref set
id, and it may be true that the author of the data could only choose
some higher level code e.g. 'parasite infection' rather than 'giardia
infection'. But whatever term is chosen, it must be by definition the
correct thing to record in the data, otherwise the software and clinical
process is a nonsense.
>> 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)
well we can make the basic distinction:
* synonym: a different linguistic rendering of the same concept
* mapping: an association of a term, typically a classification,
with some text, for a particular purpose, e.g. an ICD code or DRG
code.
The terminology's business is to maintain the first kind; the second
kind is the business of EHR system and applications. Neither of these is
what people mean when they use the word 'translation' in the normal sense.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101118/094c27ec/attachment.html>
