Grahame, Tom Given the enormous respect I have for both of you and your deep technical knowledge in this domain I hesitate to offer an opinion.
However, I have followed with great interest the evolution of the ISO dataypes from a small Standards Australia Technical working Committee, all the way through HL7 and ISO. >From the point of view of a clinical datatype implementer who has to write actual code, the ISO dataypes provide a level of detail that is both required and sufficient. They are definitely not "simple" in their definition but are mostly "simple" in terms of concept representation. The atom at one time looked "simple" and remains so in concept, though in fact having considerable underlying complexity. The level of detail required depends on your use case which seems to be a major contributor to your divergence of opnion. >>> 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? As you correctly observe Tom, this makes these particular codes "non-computable" and hence possibly not worth coding. However, as Grahame notes, it does reflect some real world instances where Grahame conceded (somewhat reluctantly) to the clinicians. Usage (or lack of it) will determine whether this has any actual value, but this issue probably needs to be highlighted in BIGGER LETTERS. Regards Vince Dr Vincent McCauley MB BS, Ph.D CEO, McCauley Software Pty Ltd www.mccauleysoftware.com Chair, IHE Australia www.ihe.net.au Treasurer, Medical Software Industry Association www.msia.com.au p: +61298186493 f: +61298181435 Jan. 2011 HL7 International Meeting: Sydney www.HL7.org.au/Sydney2011 ----- Original Message ----- From: "Grahame Grieve" <[email protected]> To: "For openEHR technical discussions" <openehr-technical at openehr.org> Sent: Thursday, November 18, 2010 4:28 PM Subject: Re: More on ISO 21090 complexity > 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
