hi Tom > It might be just me thinking that some of the 21090 types are not that > simple
no, they're not simple. That's not the relevant question. Instead, it's how well designed they are. I could design a set of "simple" types that met the requirements, but the profusion of resulting types would not be simple to implement. So the long term question is not how simple the types are, but how you can work with them. I do recognise that the simplicity of the types is related to that, but there is more to it than just that. The ISO 21090 types are designed using a different philosophy and design pattern to what you use - they are *dense*. This is not to everybody's liking, but does have more benefits the further you get into implementation. It certainly has the problem that the initial engagement with the data types requires more investment before favourable outcomes start to occur We could discuss who this benefits if you want, but the saying that they just aren't "simple" is... too simple > 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 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?" > 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. > 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. >> In addition, there are some known use cases where the value set >> that a user or system was offered when choosing a code affects >> the interpretation of the code. > 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 > 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) Grahame
