# More on ISO 21090 complexity **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-11-17 14:34 UTC **Views:** 3 **Replies:** 35 **URL:** https://discourse.openehr.org/t/more-on-iso-21090-complexity/15031 --- ## Post #1 by @thomas.beale It might be just me thinking that some of the 21090 types are not that simple, so am interested in reactions of others. Here is the documentation of the term-code representation type CD, which explains how the 'no exceptions' (CNE) and 'exceptions' (CWE) variants should be realised: > A CD is a reference to a concept defined in an external code system, terminology, or ontology. A CD may contain a simple code - that is, a reference to a concept defined directly by the referenced code system, or it may contain an expression in some syntax defined by the referenced code system that can be meaningfully evaluated. e.g., the concept of a "left foot" as a post-coordinated term built from the primary code "FOOT" and the qualifier "LEFT". > > A CD may also contain an original text or phrase that served as the basis of the coding. This is preserved to allow for validation of the representation of the concept in various fashions. > > A CD can contain one or more translations into multiple coding systems. The translations are all representations of the same concept in various code systems. There is only one concept, and only the first CD may contain an original text. It is possible to represent the translation chain - which CD was translated from which - if desired. Each CD may also carry a rationale to indicate why it is represented. > > A CD with no nullFlavor attribute SHALL have a code attribute or nonNull originalText attribute. A CD that has a code, codeSystem or originalText attribute but does not meet external constraints of the applicable value set SHALL have a nullFlavor attribute with a value of OTH. > > Attributes with type CD are generally bound by externally specified constraints which constrain the coded concepts to which a CD may refer. These constraints may be qualified as "extensible" (CWE) or "not extensible" (CNE). If the constraint is not extensible (CNE), then a the CD that does not have a nullFlavor SHALL contain a code that conforms to the constraint. If the constraint is extensible (CWE) then a CD that does not have a nullFlavor SHALL contain either a code that exists in the domain with which the attribute is associated, a code from a locally defined code system, or just some originalText that describes the concept. If the code is taken from a locally defined code system, then the codeSystem property SHALL specify the local code system. > For both CNE and CWE constraint types, the translations may contain nonNull codes from any source unless otherwise specified by the constraining model. > > For code systems that define expression syntaxes, CNE constraints may be used, providing that the code system definitions define the appropriate support to enable value sets to make useful statements about how to control the expression syntax, and that the value set machinery used also has the appropriate support. This is the data structure of a CD, with the HL7v3 message attributes in red: ``` type CD = class ( ``` ``` * validTimeLow : characterstring,* ``` ``` * validTimeHigh : characterstring,* ``` ``` * controlInformationRoot : characterstring,* ``` ``` * controlInformationExtension : characterstring,* ``` ``` * nullFlavor : NullFlavor,* ``` ``` * updateMode : UpdateMode,* ``` ``` * flavorId : Set(characterstring),* ``` ``` code : characterstring, ``` ``` codeSystem : characterstring, ``` ``` codeSystemName : characterstring, ``` ``` codeSystemVersion : characterstring, ``` ``` valueSet : characterstring, ``` ``` valueSetVersion : characterstring, ``` ``` displayName : ST, ``` ``` originalText : ED, ``` ``` codingRationale : CodingRationale, ``` ``` translation : Set(CD), ``` ``` source : CD ``` ``` ) ``` Am I alone in thinking that this is not the simplest way to implement exceptions or not, to coding? The rules for setting NullFlavor are also not so simple. I would have thought a more obvious method would be to define a type with a text field in it, and then a subtype with coding, e.g. (with message attributes removed): ``` type TEXT = class ( ``` ``` text : ST ``` ``` mappings: Set(CD) ) ``` ``` type CD: TEXT = class ( ``` ``` code : characterstring, ``` ``` codeSystem : characterstring, ``` ``` codeSystemName : characterstring, ``` ``` codeSystemVersion : characterstring, ``` ``` valueSet : characterstring, ``` ``` valueSetVersion : characterstring, ``` ``` codingRationale : CodingRationale, ``` ``` translation : Set(CD), ``` ``` source : CD ``` ``` ) ``` This would enable specifiers to simply put TEXT for 'coded with exceptions' or CD for 'coded no exceptions' within a model, with the GUI making the relevant coding widgets available in the correct way (there are some slight benefits to making a more theoretically correct model, using 3 classes rather than just 2, but the differences are not significant). Note that I merged displayName and originalText, as this seems to be a modelling confusion; if originalText represents some other text, not the text of the code, then the whole data structure is essentially a mapping, not a coding of the text. One way to do this is shown with a 'mappings' attribute in the TEXT class (some people will object that this could be used infinitely, but in practice it is never a problem, since applications don't create such structures). In the original model, 'originalText' and 'displayName' would be the same much of the time. The rules to do with setting nullFlavor would make more sense elsewhere, not in the core model. There are also some interesting comments relating to the valueSet attribute: > In many cases, a CD is created from a value set – either a code/code system pair is chosen from a valueSet, or one is not chosen and the CD has the exceptional value of NullFlavor.OTH. If no code is chosen, it is generally inappropriate to reference the code system from which the code was chosen as the value set may not match the code system (may include a subset of the codeSystem, or additional terms from other code systems); instead, the value set should be provided. **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? 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). - thomas beale --- ## Post #2 by @grahamegrieve 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 --- ## Post #3 by @Vincent_McCauley 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 --- ## Post #4 by @grahamegrieve Thanks Vince > 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\. this kind of makes it sounds as though I needed to concede\! Even if I hadn't conceded, I was going to be outvoted on this issue, like some others ;\-\) I'm just the editor\! Grahame --- ## Post #5 by @thomas.beale > > ``` > > 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 --- ## Post #6 by @thomas.beale I see this as one of the major problems of HL7 actually. It seems to think that everything should be driven by use cases. This is not the case. The general drive in all engineering and software development is to have layers of highly reusable elements that work in all situations. Thus the design concept of 'Integer' and 'String' in a programming language is not specific to any particular used. Neither should the concept of 'codedtext', 'ordinal' or 'physical quantity'. The idea that a set of such data types should be built not just for messaging, but apparently with features for other more specific use cases is plain wrong. It is not good modelling. Contextual (i.e. use-case specific) features should always be added in specific classes / locations in models dealing with those specific use cases. The openEHR data types are designed like that - it is just basic god practice. They can be (and are) used in messaging, storage, GUI, business logic. Context specific features are modelled and coded where they are relevant, not integrated into what would otherwise be completely generic data types. Not understanding this basic modelling practice has lead HL7 to produce models that are very far from being easily implementable or reusable - which is a real pity. - thomas --- ## Post #7 by @thomas.beale [2nd attempt] > > ``` > > 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 --- ## Post #8 by @thomas.beale Apparently there are others including the CDISC people very unhappy about the ISO21090 data types. This comment from [Barry Smith's blog](http://hl7-watch.blogspot.com/2010/11/are-iso-21090-data-types-too-complex.html) (emphasis added by me): XML4Pharma said: > As an XML-guy, my major problem with all these 'standards' (as well HL7, ISO21090, OpenEHR) is that they all start from UML modeling and auto-generate the XML-schemas from that, ignoring any of the advanced features (such as native XML datatypes) of XML. > > I have no problem with UML modeling, but I have major problems with the naïve believe that one can generate high quality XML-Schemas automatically from UML diagrams. > Essentially, these 'standards' are abusing the XML standard itself. **They even manage to reinvent basic datatypes such as integer, date, time, duration which are already defined by XML and XML-schema itself**. For example, HL7- and ISO21090 'date' is expressed as YYYYMMDD, where there is already a base XML-schema datatype 'date' expressed as YYYY-MM-DD. So when validating an HL7-v3-message against the schema (and even against the schematron), the date 20070231 (February 31, 2007) is accepted as a correct date. If they had respected the XML standard instead of abusing it, then the same data in correct XML (2007-02-31) would have immediately been rejected by XML-Schema as being an invalid date. The same applies for many other HL7- and ISO21090 datatypes (e.g. date, time, datetime, duration). **Each time HL7 as well as ISO21090 'reinvents' these datatypes making life much more complicated than is necessary.** > I am one of the developers of the CDISC ODM standard used in clinical research. We also use UML for modeling, but our schemas are not automatically generated from them, but created manually. We use native XML datatypes as much as possible, not trying to reinvent the wheel. We try to make our standard so that instance files are even understandable by non-specialist when looking at the XML itself (so without stylesheet). They are also 'human-readable'. The latter cannot be said of any HL7- or ISO21090 instance file. > > Some time ago, our team was asked to enable ISO21090 in ODM. The request came from one of the largest nonprofit research organizations in the US. We had a teleconf with them and it soon became clear that they wanted us to replace our own (XML-Schema based) datatypes by the ISO21090 datatypes. **We refused**. > > **Instead, we will develop an ODM-extension that allows to attach ISO21090 data points** (in their own namespace) to ODM 'ItemData' elements. Doing so, the ODM standard will support ISO21090 AND remain ODM. > Somewhat more than a year ago, I developed a stylesheet to extract information from HL7-CCD (health records) to prepopulate clinical forms in ODM format. This stylesheet was soon regarded as a key-enabler for integration between health records and clinical research. However, I cannot guarantee that it will work for ANY health record in CCD format. The reason is that CCD is so complex that I fear that one can put the same information (for example a systolic blood pressure) in very many ways in a CCD. So how can I guarantee that the systolic blood pressure can be extracted in all cases? > > The ISO21090 'standard' is clearly a political compromise, not a technical compromise. As such, from the technical point of view it is probably not an improvement. > **In my personal opinion, the best that can be done for a data standard for healthcare is to restart from nearly scratch**. Yes, UML modeling can and should be used, but based on solid and agreed principles, and taking into account that XML will later be the transport format. So, no 'reinvention' of datatypes, but using the XML native datatypes right from the start. No fully-automated generation of XML-Schemas, but development of the schemas by schemawriters (though part of the work can be automated). > > And most of all, involve all eligible players (HL7, ISO, OpenEHR, etc.) right from the start. I am not involved with these people, but their response sounds entirely rational. In my view this just shows that the 21090 data types in their current form are not at all what we should be standardising on. - thomas --- ## Post #9 by @grahamegrieve > I see this as one of the major problems of HL7 actually\. It seems to think that everything should be driven by use cases\. shorter Tom Beale: Only by ignoring use cases can one design usable data types? > 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? The second only if it's the basis for the choice of the code\. So the two fields may contain the same information\. I'm not going to argue about the more general point you are making\. I don't think it's obviously true that your proposed alternative is better \(though it's certainly not obviously worse\)\. But I agree that there's no question that the data types are HL7's data types\. > 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 well, I thought so too\. But it already happens in some places\. > 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\. please inform the end users that you say that they must behave this way\. > 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\. where do you get that distinction? I'm not familiar with these terms from any terminology standard, though I haven't yet read the latest version of Heather's glossary > Essentially, these 'standards' are abusing the XML standard itself\. heh\. XML forever, it will solve every problem in the world\. Just if everyone else does it 'my' way, we'll be right\. > For example, HL7\- and ISO21090 'date' is expressed as YYYYMMDD, > where there is already a base XML\-schema datatype 'date' expressed > as YYYY\-MM\-DD\. So when validating an HL7\-v3\-message against the > schema \(and even against the schematron\), the date 20070231 > \(February 31, 2007\) is accepted as a correct date\. OpenEHR too\. We are all beyond redemption\. Actually, I don't know why he thinks that 20070231 is valid, I wrote and tested the regex to make it illegal, though the regex doesn't do the leap year thing\. \[edit: ahh no, that regex didn't make it in for some reason\. I don't recall why, but it was \-super\- long\.\]\. And we chose not to use the silly XML schema type with care\. I don't know if it was the right decision, but, unlike he says, there was a reason, to do with incomplete dates\. It's actually more compelling in times than dates but we do both the same way, as does openEHR > So, no 'reinvention' of datatypes, but using the XML native > datatypes right from the start\. No fully\-automated generation of > XML\-Schemas, but development of the schemas by > schemawriters \(though part of the work can be automated\)\. When I teach the data types or CDA, I point out that there's two irreconcilable camps in how to use XML\. The first camp says that XML is just a transport, and you keep away from being clever, so that it just works\. I call this is "the object mapping crowd" \(and it solidly includes both you and me\)\. The second camp says that XML is your concrete form, and you leverage it as hard as you can, including tricks in schemas and screwy one off things to make transforms easier\. I call this the "XML hacker" crowd\. And the two groups want different frequently incompatible things\. XML4Pharma who you are quoting is certainly in the second crowd\. The interplay between the two camps virtually guarantees that any XML standard is a political compromise\. Give that guy a beer or two, and ask him about schema\.\.\. \(and, btw, if one was to follow his recommended method, you'd end up at the same place, unless either camp was to somehow figure out how to exclude the other\. The details might be different, but the basic picture would be the same, I reckon\) Grahame --- ## Post #10 by @yampeku > shorter Tom Beale: Only by ignoring use cases can one design usable data types? I think is more like "you don't have to look only the use cases to design usable data types" > heh\. XML forever, it will solve every problem in the world\. Just if > everyone else does it 'my' way, we'll be right\. there is a quote that says "XML is like violence\. If it doesn't solve your problem, you're not using enough of it\." ;\) anyway, I prefer ISO dates whenever possible --- ## Post #11 by @pablo > > shorter Tom Beale: Only by ignoring use cases can one design usable data types? > > I think is more like "you don't have to look only the use cases to > design usable data types" I agree with this vision. Because we can't think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases. - Pablo. --- ## Post #12 by @williamtfgoossen Hi all, Given this discussion on ISO 21090 I would like to bring forward the following: 1. Every international standard is and has to be based on political decisions: all member countries have to be accepting it and hence will want to get something specific out of it, or block too difficult parts. That is the way of standards making, in contrary to what a group of friends like in OpenEHR foundation can do. This has nothing to do with committees working in the implementation space or sitting at a table. It is how formal democratic voting goes. Not a perfect system we know, but apparently chosen above totalitarian approaches. This democratic development (inclusive of all parties concerned, and voting by members) has been and is still the case for ISO 21090. The same democratic and transparant voting procedure by members is used in HL7 international (of course the membership is organised different from ISO). 2. The use cases for ISO 21090 do come from different sources: an older basic data type standard from ISO, clinical use cases, CEN standards, in particular the one on archetypes (13606-2), AND HL7 among others. The resulting set is accepted by the ISO membership, and indeed the HL7 membership, referring to it as datatypes R2 (and facing an enourmous piece of effort and work to redo a lot of the models and messages due to the harmonisation). And under the JIC, also the CDISC organisation deals with this since ISO 21090 is part of the joint harmonisation work. I think the willingness of the different JIC partners to step beyond their traditional route and harmonise this formidable and fundamental work is the most important achievement in the last 25 years of international standards work. I would like to compliment Grahame in particular that he managed to get a useful, albeit say 96% "perfect" standard out of this. 3. No standard or specification can be perfect. In particular, Tom's work might be closer to perfection than the ISO 21090, but that is hypothetically a matter of a percentage between 96% and 97.5% on a VAS of 0 - 100%. I personally are pragmatic, I need in Detailed Clinical Models and in HL7 v3 Care Provision message implementations about 20 - 30% of the ISO 21090, so do not bother about the rare use cases addressed. 4. Core principle behind the standard is that you create a profile around it that allows you to implement it in your system, or your message, or your datawarehouse or whatever. There is usually no way to have it 100% ready for use. The example from the blog that Tom talks about, where ISO 21090 is mapped into their own CDISC models is almost perfect. That is the way to go. Yes it will include mappings from ISO time format to XML time format. But if that works well on implementation, at the exchange level you are compliant. 5. If you adhere to ISO 21090 / conform to it / there is always the option to limit your implementation set. E.g. refer to particular chapters or codes in ISO 21090. 6. It looks from Tom's objections that OpenEHR cannot adhere to data type standard ISO 21090. Is that a problem in the OpenEHR specifications, or is that a problem on political level: we do want to invent our own because it is closer to perfection? What I mean here is: if I create archetypes in OpenEHR spaces (there are about 25 in Dutch available pending other issues to be solved before releasing). And from this system I need to exchange HL7 v3 messages in the Dutch national switshboard space, will I be in trouble because the OpenEHR archetypes cannot handle even the basic ISO 21090 datatypes? Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen@results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 --- ## Post #13 by @pablo Just one more thought about this. When someone design a custom software system, the information model is not only based on use cases. We all know about "general software quality characteristics" that we have to think about, like Usability, Maintainability (modifiability, adaptability, etc), Completeness, Conciseness etc, etc ([http://en.wikipedia.org/wiki/Software_quality#Maintainability](http://en.wikipedia.org/wiki/Software_quality#Maintainability)) (this are the basics of software engineering, nothing new to us). So, we have to think of something that: - reach something that meets the use cases (complete, adds complexity), - but it is also cocise (only needed things, must be simple), - and maintainable (generic, good organization, simple extend and change (adapt to other realities that may be not covered by the use cases)) - etc ... So, the use cases are a part of the puzzle, of course are the base of the design, but not the olny piece of the final puzzle (if we want quality). Kind regards, Pablo. > > shorter Tom Beale: Only by ignoring use cases can one design usable data types? > > I think is more like "you don't have to look only the use cases to > design usable data types" I agree with this vision. Because we can't think of all use cases, so we can never create datatypes that consider all posible cases. So, we need to think more general solutions, seeing not only the use cases. - Pablo. > > > heh. XML forever, it will solve every problem in the world. Just if > > everyone else does it 'my' way, we'll be right. > > there is a quote that says "XML is like violence. If it doesn't solve > your problem, you're not using enough of it." ;) > > anyway, I prefer ISO dates whenever possible > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________ openEHR-technical mailing list openEHR-technical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical --- ## Post #14 by @system Hi William Thanks for the kind words. It seems to me that we could define a mapping from openehr to iso 21090. I certainly designed it that way. The mapping is not perfect, but it's good enough to be useful except for corner cases. I just have to find the time to write it up properly, but that seems an increasingly distant prospect at the moment. Grahame --- ## Post #15 by @thomas.beale > Hi all, > > Given this discussion on ISO 21090 I would like to bring forward the following: > > 1. Every international standard is and has to be based on political decisions: all member countries have to be accepting it and hence will want to get something specific out of it, or block too difficult parts. > That is the way of standards making, in contrary to what a group of friends like in OpenEHR foundation can do. This has nothing to do with committees working in the implementation space or sitting at a table. It is how formal democratic voting goes. Not a perfect system we know, but apparently chosen above totalitarian approaches. I do hate to bring this up, but in the entire rest of existence, all engineering (i.e. all creation of technical artefacts) is done by 'totalitarian' approaches. If you know the person who would travel on a plane built by 'democracy' rather than engineering, please introduce us... > This democratic development (inclusive of all parties concerned, and voting by members) has been and is still the case for ISO 21090. > The same democratic and transparant voting procedure by members is used in HL7 international (of course the membership is organised different from ISO). > > 2. The use cases for ISO 21090 do come from different sources: an older basic data type standard from ISO, clinical use cases, CEN standards, in particular the one on archetypes (13606-2), AND HL7 among others. The resulting set is accepted by the ISO membership, and indeed the HL7 membership, referring to it as datatypes R2 (and facing an enourmous piece of effort and work to redo a lot of the models and messages due to the harmonisation). And under the JIC, also the CDISC organisation deals with this since ISO 21090 is part of the joint harmonisation work. I think the willingness of the different JIC partners to step beyond their traditional route and harmonise this formidable and fundamental work is the most important achievement in the last 25 years of international standards work. I would like to compliment Grahame in particular that he managed to get a useful, albeit say 96% "perfect" standard out of this. I don't have a problem with the fact that use cases have been researched, indeed that is an excellent achievement. I have a problem with the way the standard has been created on that basis; it tries to do way to much, incorporating all kinds of special cases that should not be included in the core generic data types standard. Such use cases can be accommodated in one or more separate 'packages' that show how to use the core classes for the specific purpose, and what extra classes are needed to formalise other data specific to the use case. > 3. No standard or specification can be perfect. In particular, Tom's work might be closer to perfection than the ISO 21090, but that is hypothetically a matter of a percentage between 96% and 97.5% on a VAS of 0 - 100%. I personally are pragmatic, I need in Detailed Clinical Models and in HL7 v3 Care Provision message implementations about 20 - 30% of the ISO 21090, so do not bother about the rare use cases addressed. no, no, no... wrong argument William! It is not about being on a sliding scale of good / better / perfect! This standard is in a different place altogether, 'designed' according to different permises, specifically that it should try and cover all known use cases in one standard. It is trying to do way too much, has numerous formal attributes and natural language guidelines not applicable to most use cases. It is built according to the wrong-headed HL7 notion of modelling which is: put everything in at the top/centre and profile it out later. Firstly this breaks basic rules of maintainability, encapsulation, etc, secondly, it is going to really damage the uptake and usefulness of this standard! Just like software and models based on the HL7v3 RIM, where NO TWO IMPLEMENTATIONS CAN COMMUNICATE, this will be the same. > 4. Core principle behind the standard is that you create a profile around it that allows you to implement it in your system, or your message, or your datawarehouse or whatever. There is usually no way to have it 100% ready for use. The example from the blog that Tom talks about, where ISO 21090 is mapped into their own CDISC models is almost perfect. That is the way to go. Yes it will include mappings from ISO time format to XML time format. But if that works well on implementation, at the exchange level you are compliant. mappings are unavoidable with standards. But having to do this 'profiling' with every HL7 standard is nonsense - having to decide which attributes I don't need, which ones I can set to 0 or Nil, or False, or some other special value.... just think about the combinatorial complexity of all those decisions over an object with 10 data fields! ANd then multiply that by the number of organisations having to make those decisions. > 5. If you adhere to ISO 21090 / conform to it / there is always the option to limit your implementation set. E.g. refer to particular chapters or codes in ISO 21090. particular chapters, particular classes, particular attributes, but only in specific circumstances.... the 'profiling' work has to be done all over the place, so even when the standard is fully accepted, noone except HL7v3 message people can directly use it! It doesn't even make sense in its current form for CDA! (And I forgot to mention it is full of CDA specific stuff which also makes no sense being in a supposedly generic standard). > 6. It looks from Tom's objections that OpenEHR cannot adhere to data type standard ISO 21090. Is that a problem in the OpenEHR specifications, or is that a problem on political level: we do want to invent our own because it is closer to perfection? What I mean here is: if I create archetypes in OpenEHR spaces (there are about 25 in Dutch available pending other issues to be solved before releasing). And from this system I need to exchange HL7 v3 messages in the Dutch national switshboard space, will I be in trouble because the OpenEHR archetypes cannot handle even the basic ISO 21090 datatypes? openEHR can handle all of the data types conceptually, that isn't the problem. The mapping, just like for everyone else with a normal kind of object model, will be painful because of the irrelevant stuff in ISO 21090, and annoyances like TS.DATE, and numerous other details. But, **much more importantly**, which profile should openEHR map to? Some core profile? A 13606 profile? A CDA profile? A v2 profile? an NHS profile? The Sweden profile? How many mappings will we need? Remember, archetype designers don't care about which specific way the archetypes might be deployed - in messages, on a screen etc, so any attributes specific to those uses won't make sense. Do we need an 'archetype' profile of 21090? Please have a look at this specification: [openEHR Support Information Model ](http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf)- the section on 'Assumed types' shows how little openEHR assumes about underlying basic types. On top of that, it builds a core set of data types that have no attributes relating to messaging, null flavours, or obscure use cases. All of that latter is handled in contextually sensible places. Normal object models created according to normal design principles always end up like this. ISO 21090 doesn't, because it follows the HL7 include-everything-then-profile approach. - thomas --- ## Post #16 by @Randolph_Neall Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage-Beale. Randy Neall --- ## Post #17 by @William_E_Hammond Tom, Now I know why HL7 has so much trouble\. \-\- "just basic god practice\. " Shouldn't god be capitalized? I think HL7 needs to pay Tom a consulting fee \- for all the advice\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Thomas Beale              <thomas\.beale@oce              aninformatics\.com To              > openehr\-technical@openehr\.org              Sent by: cc              openehr\-technical              \-bounces@openehr\. Subject              org Re: More on ISO 21090 complexity                                                                                          11/18/2010 06:38              AM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                                   >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\. I see this as one of the major problems of HL7 actually\. It seems to think that everything should be driven by use cases\. This is not the case\. The general drive in all engineering and software development is to have layers of highly reusable elements that work in all situations\. Thus the design concept of 'Integer' and 'String' in a programming language is not specific to any particular used\. Neither should the concept of 'codedtext', 'ordinal' or 'physical quantity'\. The idea that a set of such data types should be built not just for messaging, but apparently with features for other more specific use cases is plain wrong\. It is not good modelling\. Contextual \(i\.e\. use\-case specific\) features should always be added in specific classes / locations in models dealing with those specific use cases\. The openEHR data types are designed like that \- it is just basic god practice\. They can be \(and are\) used in messaging, storage, GUI, business logic\. Context specific features are modelled and coded where they are relevant, not integrated into what would otherwise be completely generic data types\. Not understanding this basic modelling practice has lead HL7 to produce models that are very far from being easily implementable or reusable \- which is a real pity\. \- thomas --- ## Post #18 by @William_E_Hammond So what does he win? W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Randolph Neall              <randy\.neall@veri              quant\.com> To              Sent by: For openEHR technical discussions              openehr\-technical <openehr\-technical@openehr\.org>              \-bounces@openehr\. cc              org                                                                    Subject                                        Re: More on ISO 21090 complexity              11/19/2010 01:08              PM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage\-Beale\. Randy Neall --- ## Post #19 by @thomas.beale I knew that one wouldn't get past.... still, I could not in all conscience accept payment for so much unused advice over the years ;-) --- ## Post #20 by @William_E_Hammond Tom, As you have often pointed out, we do disagree but we are friends\. In aqny case, I enjoy the banter\. At a minimum, it teaches me reserve\. Unfortunately, the issues go beyond technical and even philosophy\. The problem is when you put 500 people to writing standards, most of whom are technical, the result demands compromise and that results in complexity\. The other choice is each will have its own standard\. Not bad as long as it is my standard\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Thomas Beale              <thomas\.beale@oce              aninformatics\.com To              > openehr\-technical@openehr\.org              Sent by: cc              openehr\-technical              \-bounces@openehr\. Subject              org Re: More on ISO 21090 complexity                                                                                          11/19/2010 04:17              PM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             I knew that one wouldn't get past\.\.\.\. still, I could not in all conscience accept payment for so much unused advice over the years ;\-\) --- ## Post #21 by @pablo It's hard get both: standard by consensus and to base standards on good design practices. I think the point of the discussion is: what model (or way of modeling) is good and why? On one hand we have the HL7 way of modeling things, that do not follows the best known practices but is accepted by many parties. (HL7 models are tight coupled with XML Schemas, for exmple, the "choice" construcor in the diagrams is a bad way of modeling things that can be modeled better with subclassing in UML, as every developer that works with HL7 v3 knows, this adds complexity to the development). In the other hand we have some models that follow the best design practices, but are acepted by a group of "friends". The strong point in one is the weak point in the other. So, in reality, we have to live with a god and with many atheists, and believe in both. --- ## Post #22 by @thomas.beale > ``` > Tom, As you have often pointed out, we do disagree but we are friends. In > aqny case, I enjoy the banter. At a minimum, it teaches me reserve. > Unfortunately, the issues go beyond technical and even philosophy. The > problem is when you put 500 people to writing standards > ``` Ed, I think you just identified the problem.... --- ## Post #23 by @lavanian Dear friends, My thoughts on this debate wrt complexity of HL7 and similar such standards as also the slow pace of adoption: I think it is time we went back to basics \(especially when a simple thing like describing Blood pressure \(110/70 mmHg\) can take more than a Kb of memory\) The reason being that our worthy IT compatriots wish to micro\-manage and detail each \(atomic\) component of medical literature\. That is not and will never be possible \- period\. The results of all this \- >> huge groups and sub groups to make ever more complex "standards"\(V1\.\.\.\.2\.\.\.\.\.2\.5\.\.\.\.3\) millions of bucks to create, sustain and propagate such "standards" >> millions more to train thousands of people to learn this \(mostly unwanted 'language'\), thousands more to program it >> spawning of hundreds of \(unnecessary\) support industries to care for this/these "Standard\(s\)" >> and so on and so forth\.\.\.\.\.\.\.\.\. Of course all of this is awfully good for business \(mine included\), job creation, pay hikes and promotions\. BUT\.\.\.\(my conscious bleats\)\.\.\.\.who finally pays?? we all know that >> ultimately\.\.\.\. the poor patient\!\! and in countries like the UK\.\.\.\.\. every citizen\! I think it is a case of the cure being worse than the ailment\. Remember, doctors have their own standards\. I can read a case history written in English, on a plain A4 sheet of paper, by a clinician from any part of the globe \(and vice versa\) and understand every word \(if I am of that specialty\)\. And we have been doing this for more than 200 years\. So let us not wrap tons of extraneous information to the already large medical knowledge pool\. Informatics is good and does help clinicians \(see my company's logo\), but in the right doses\.\.\.\.a toxic dose \(more than LD50\) can kill\. We have now reached \(IMHO\) a stage where our 'Help' is actually becoming a big fat obstruction\. I say, "KISS" \(Keep it simple S\*\*\*\*d\!\)\. I do believe that a real standard should be one that does the job and is simple enough to self learn in a day or two\. Elegance not diarrhoea is the need of the day\. Bottom line \- we now need to seriously think about going back to basics and simplify \- simplify \- simplify\. I welcome comments from my worthy colleagues \. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www\.hcitconsultant\.com Certified HL7 Specialist Member\- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert \- Healthcare Informatics and TeleHealth Former Vice President \- Healthcare Products, Bilcare Ltd Former Vice President \- Software Division, AxSys Healthtech Ltd Former Co\-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President \- Telemedicine \(Technical\), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: \+91 20 32345045 Mobile: \+91\-9970921266 --- ## Post #24 by @lavanian Dear friends, My thoughts on this debate wrt complexity of HL7 and similar such standards as also the slow pace of adoption: I think it is time we went back to basics (especially when a simple thing like describing Blood pressure (110/70 mmHg) can take more than a Kb of memory) The reason being that our worthy IT compatriots wish to micro-manage and detail each (atomic) component of medical literature. That is not and will never be possible - period. The results of all this - >> huge groups and sub groups to make ever more complex "standards"(V1....2.....2.5....3) millions of bucks to create, sustain and propagate such "standards" >> millions more to train thousands of people to learn this (mostly unwanted 'language'), thousands more to program it >> spawning of hundreds of (unnecessary) support industries to care for this/these "Standard(s)" >> and so on and so forth......... Of course all of this is awfully good for business (mine included), job creation, pay hikes and promotions. BUT...(my conscious bleats)....who finally pays?? we all know that >> ultimately.... the poor patient!! and in countries like the UK..... every citizen! I think it is a case of the cure being worse than the ailment. Remember, doctors have their own standards. I can read a case history written in English, on a plain A4 sheet of paper, by a clinician from any part of the globe (and vice versa) and understand every word (if I am of that specialty). And we have been doing this for more than 200 years. So let us not wrap tons of extraneous information to the already large medical knowledge pool. Informatics is good and does help clinicians (see my company's logo), but in the right doses....a toxic dose (more than LD50) can kill. We have now reached (IMHO) a stage where our 'Help' is actually becoming a big fat obstruction. I say, "KISS" (Keep it simple S****d!). I do believe that a real standard should be one that does the job and is simple enough to self learn in a day or two. Elegance not diarrhoea is the need of the day. Bottom line - we now need to seriously think about going back to basics and simplify - simplify - simplify. I welcome comments from my worthy colleagues . With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant [www.hcitconsultant.com](http://www.hcitconsultant.com) Certified HL7 Specialist Member- American Medical Informatics Association Member HIMSS Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Governmental Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 --- ## Post #25 by @Tim_Cook2 Dr D Lavanian, Just so I understand what you are saying\. Are you promoting what is in this email as a solution or the stuff from your website? "Put simply, we are a One\-Stop Shop for all of your needs in the Healthcare technology Domain\. Be it strategy, software design, ergonomy validation, software, hardware, medical equipment, project management, clinical content management, field trials/testing, marketing or bundled turnkey services \- we do it all\. Our services are listed on the pane to your right\." Maybe you just have a guilty conscious for taking Australian's money? I dunno\.\.\.I can't figure it out\. Cheers, Tim --- ## Post #26 by @Seref Greetings, I'd say that simplification is a must in medical informatics, but I would not attempt to bring that simplification to the standards or the scope of medical informatics. The level of detail and complexity we introduce into our solutions is there because most of the time, even with the best practices history has thought us, there is a certain amount of complexity we can not avoid. As long as the requirements are in the lines of "connect every hospital, every information system, every mobile device to healthcare data.." there will be these endless versions Where we need simplification is the front end of the technologies we are developing. That is tooling and clinical systems and other outputs, pretty much anything that relies on standards and software development. the real challenge in medical informatics IMHO is to give a doctor something that feels at least as convenient as the A4 sheet of paper and does at least a little bit better. I personally do not think that this is necessarily a challenge completely linked to the underlying complexity of the standards or information systems. There is certainly a connection, but complex specifications on their own are not reason for still not having the solutions we have been dreaming about. If you try to reflect the requirement of a layer onto others, you'll almost always end up losing capability. In fact, the price of power and simplicity is most of the time increased complexity at the background. For example, any expensive car with an F1 style gear shifting gives you a much simpler way of managing the gear. One button up, other button down. Now think about the complexity of the system that is giving you that gear shifting. It is much more complex than the usual gear box you'd have in a 1997 Ford Escord (my old car, which needed an exorcist at the back seat to stop it from killing me with its weird problems..) Iphone? Same thing. What a simple UI! Just put your finger on it. The technology backing it up? Definitely more complex than your first cell phone, which could easily replace a brick in your garden wall.. Let's try to simplify the right things, and we'll get there. Best Regards Seref --- ## Post #27 by @Koray_Atalag Hi All, what a discussion J Just a few points: we have developed an endoscopy reporting application based on a very comprehensive domain model (some of you already know – I am obsessed with this model!) using openEHR specifications. There were many obstacles – including data types (for example a quantity data type with two alternate units of which one was not in the list of selectable units defined in a small terminology) but a solution could always be found. I can say that it has worked for us and in a few weeks time we will release the code as open source. There was a mention of GUI with data types; indeed I must say that they almost always dictate the type of widget on screen – that’s our experience. Rest of the GUI definition comes from what we call “GUI Directives” inserted into Templates as annotations. I suggest that we define a specific entry for GUI for each node at template level. There relevance of this message to this thread is that, I have repeated this argument several times before, I suggest working on some concrete examples when discussing about pros and cons of different standards. So I’d be very interested to see some examples (caution not to use ‘use case’ here ;) where one standard data type works and the other doesn’t and vice versa. Perhaps a wiki page where the ordinary readers like me could understand fully and appreciate the many arguments thrown so far. It’s a pity that we are using so little of the available e-collaboration tools effectively while calling ourselves as (health) informaticians ;) I personally think we, health informaticians, make life a lot more complicated than it should be. I am pretty confident that the solution of >90% of problems is a no brainer and that we need more of it for the remaining. My gut feeling is that the chances of getting something working out there are higher if we start with simple and generic data types. Based on the needs during ‘real-world’ implementations (not well thought use cases) I think they can evolve ‘incrementally’. I must admit that I may just be too simplistic here but this is my approach to solve problems. There were also a few mentions about ‘maintainability’ and ‘software quality’. Well I know a little bit about this (indeed my research is all about this topic!). Maintainability, according to the well accepted ISO/IEC 9216 and 25000 series standards quality model, is a quality characteristic – a very important one because it has a dramatic effect on software cost. The rule of thumb is to avoid complexity – in code, design artefacts, process etc. The preliminary results of our research shows that it takes seven times less time to implement changes and the complexity is nine times less in the openEHR based application compared to a ‘typical’ object-procedural/relational DB application. One next research question now in my mind is to build a third application using HL7 based on exactly the same requirements. I’d be very keen to collaborate if you find the idea interesting and worth investigating. I guess this should then be the “Evidence based health informatics” ?? Cheers, -koray --- ## Post #28 by @William_E_Hammond To all, I think these conversations are becoming interesting\. Systems are complex because designers either do not take the time to build them correctly or are not smart enough to make them simple\. Of course, simplicity is a matter of preference\. A story about Mark Twain\. He wrote a long letter and appoligized that he did not have time to write a shorter one\. In my on work, It takes me much longer to write a short paper than a longer one \- I have to think about content\. Most designers like to show you what they know, and modelers never finish modeling\. I think there are some smart people on this list\. I also think we spend too much time criticizing what is; and I think we have focused too much on components\. I designed my first "compound data elements" in 1972\. In a metadictionary, I defined the components \- whose order defined the structure; included the prompts for data collection; and stored with delimiters separating the components\. Heart murmur is an example, and we could query for any heart murmur \- or define the degree of specifity\. The overhead of XML tags and including the data structure is huge\. Even with CDA, to send a single data value takes a lot of characters\. I think we should be able to define structures independent of the transmission of the data\. How do we work together to move ahead? Koray, I like your thoughts\. W\. Ed Hammond, Ph\.D\. Director, Duke Center for Health Informatics              Koray Atalag              <k\.atalag@aucklan              d\.ac\.nz> To              Sent by: For openEHR technical discussions              openehr\-technical <openehr\-technical@openehr\.org>              \-bounces@openehr\. cc              org                                                                    Subject                                        RE: More on ISO 21090 complexity              11/21/2010 06:37              AM                                                                                          Please respond to                 For openEHR                  technical                 discussions              <openehr\-technica               l@openehr\.org>                                                                             Hi All, what a discussion J Just a few points: we have developed an endoscopy reporting application based on a very comprehensive domain model \(some of you already know – I am obsessed with this model\!\) using openEHR specifications\. There were many obstacles – including data types \(for example a quantity data type with two alternate units of which one was not in the list of selectable units defined in a small terminology\) but a solution could always be found\. I can say that it has worked for us and in a few weeks time we will release the code as open source\. There was a mention of GUI with data types; indeed I must say that they almost always dictate the type of widget on screen – that’s our experience\. Rest of the GUI definition comes from what we call “GUI Directives” inserted into Templates as annotations\. I suggest that we define a specific entry for GUI for each node at template level\. There relevance of this message to this thread is that, I have repeated this argument several times before, I suggest working on some concrete examples when discussing about pros and cons of different standards\. So I’d be very interested to see some examples \(caution not to use ‘use case’ here ;\) where one standard data type works and the other doesn’t and vice versa\. Perhaps a wiki page where the ordinary readers like me could understand fully and appreciate the many arguments thrown so far\. It’s a pity that we are using so little of the available e\-collaboration tools effectively while calling ourselves as \(health\) informaticians ;\) I personally think we, health informaticians, make life a lot more complicated than it should be\. I am pretty confident that the solution of > 90% of problems is a no brainer and that we need more of it for the remaining\. My gut feeling is that the chances of getting something working out there are higher if we start with simple and generic data types\. Based on the needs during ‘real\-world’ implementations \(not well thought use cases\) I think they can evolve ‘incrementally’\. I must admit that I may just be too simplistic here but this is my approach to solve problems\. There were also a few mentions about ‘maintainability’ and ‘software quality’\. Well I know a little bit about this \(indeed my research is all about this topic\!\)\. Maintainability, according to the well accepted ISO/IEC 9216 and 25000 series standards quality model, is a quality characteristic – a very important one because it has a dramatic effect on software cost\. The rule of thumb is to avoid complexity – in code, design artefacts, process etc\. The preliminary results of our research shows that it takes seven times less time to implement changes and the complexity is nine times less in the openEHR based application compared to a ‘typical’ object\-procedural/relational DB application\. One next research question now in my mind is to build a third application using HL7 based on exactly the same requirements\. I’d be very keen to collaborate if you find the idea interesting and worth investigating\. I guess this should then be the “Evidence based health informatics” ?? Cheers, \-koray --- ## Post #29 by @thomas.beale > ``` > To all, > ... Even with > CDA, to send a single data value takes a lot of characters > > ``` openEHR would be the same in that respect. But the criteria we judge on now include things like computability, re-usability (of information) and so on, not just number of bytes and time to display. > ``` > I think we should be able to define structures independent of the > transmission of the data. How do we work together to move ahead? > > ``` I have been arguing with HL7 folk for years on this point. But HL7 appears locked into defining the content within a message based model, full of message-related attributes and design features. This makes it very hard to re-use an HL7 content definition, even assuming it was agreed to be done as an HL7 template (unfortunately, this is in XSD, a disasterous modelling technology) or an RMIM. One of the things we tried to do from the outset with archetypes was to get away from this. Yes, openEHR archetypes implicate the openEHR reference model, but only about 30% of it - the semantics that matter to clinical modellers. And from openEHR templated archetypes, we can generate diverse downstream artefacts for use by normal programmers. The message XSD is a end-of-the-line downstream product, not a starting point in openEHR. - thomas --- ## Post #30 by @Seref Well said! Here is my take on the problem. Imagine having N barrels, and a number of pipes, connecting these barrels. Barrels are filled with water, and pipes carry water from barrel A to barrel A. At an abstract level, both barrels and pipes contain water, but they are supposed to allow different uses of water, and this is reflected to their design. A pipe mostly has a smaller diameter compared to a barrel, since it is supposed to go through walls, and it is usually made from a different material, considering problems like freezing. So you insert two ends up a pipe into two barrels, and it would help you carry water from one barrel to another. The barrel on the other hand, is designed to hold water, and it has a large cover, matching its wider diameter. You can get a water pot, sink it into the barrel, and fill it with water. This would be your local use of water. By design, pipes provide barrel to barrel connectivity, and people in front of the barrels get their water from the barrel. Now, both in theory and in practice, you can use pipes to store water. Imagine how you'd do it: you get 40-50 pipes, close one end, then bind them all together and put them on the ground , making them stand on their closed end. Then you need to either connect 50 pipes to your 50 vertical pipes, or try to fill them with a water pot, making sure that you don't spill water into the space between them. When it is time to use this set of pipes to fill water into water pot, you can't sink the water pot into the pipe's opening, so you'd have to lean the pipes to fill water to water pot, of course, since all pipes have an open top, you'd have to have to deal with water being wasted. Likewise, you can remove the tops and bottoms of barrels, join them, and try to use them as pipes. This time, you'd be wasting an awful amount of space, since only a certain amount of water is supposed to flow from one point to another and also, you'd find out that 30 cm thick walls can't really contain barrels with 60 cm diameters. Trying to use HL7 to build the whole information system is like trying to use the pipes to store water. It somehow happens, but both the people building the storage (information system) and the people trying to feel the water pot (end users) have problems. If you try to use comprehensive models you've designed to run a clinical information system for messaging, you're trying to put barrels into walls. I think you can see what is wrong here, but life is funny when it comes to software; if it more or less works, then it is simply called "working". I for one, will not be storing water in pipes... Best Regards Seref --- ## Post #31 by @williamtfgoossen In a message dated 21-11-2010 14:50:15 W. Europe Standard Time, hammo001@mc.duke.edu writes: > I think we should be able to define structures independent of the > transmission of the data. How do we work together to move ahead? Hi Ed, this is the 6 year ongoing work on detailed clinical models, no more no less. comment on the UML is irrelevant on this, since we also have XML, ADL and R-MIMs created from the data elements base. However, one thing on data elements is very important: relationships between some data elements need to be expressed, e.g. for total scores, derivations. Met vriendelijke groet, Results 4 Care b.v. dr. William TF Goossen directeur De Stinse 15 3823 VM Amersfoort email: wgoossen@results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 --- ## Post #32 by @pablo Hi Koray, As an example of a "real-world implementation", we have build an EHR for trauma care. Our project was developed in one year and four months. The core of the development is an openEHR-based framework, wich takes archetypes and our own templates (with GUI directives), and generate GUI, data binding with RM structures, validation of data against archetypes contraints, and persistence of the RM structures. BTW, this framework has been open sourced: http://code.google.com/p/open-ehr-gen-framework/ (sorry docs in spanish only). I've estimated that this particular project without the "openEHR overhead" could be finished in 6 months. But if I have other project like this today (same size, same complexity, etc), I think we can finish the development en 3 months, using our openEHR-based framework. So, if we have 10 projects this are the numbers: * Without openEHR tools: total of 160 months (13.3 years) * With openEHR tools: total of 56 months (16 months for the first development, 4 months for the rest 9 projects, that's 4,7 years!!!) If we can improve the tools, these times could be improved, and the final solutions have the advantage of separating the knowledge from the software, and we can share and reuse archetypes between diferent projects, that's just great! :D Hope this experience can help you. --- ## Post #33 by @grahamegrieve hi Tom I can only presume this email actually predated our other discussion > 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\. which architecture is, everything completely denormalised\. And so they're not suitable for an environment where you want to normalise\. y\. > 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'? OriginalText is a problem\. The definition was agonised over a great deal\. It's the text that's the basis one which the code was assigned \- if there is any\. displayName is an algorithmic conversion from the code to it's designated display\. Generally, the two are logically exclusive \- it doesn't make sense to have one and not the other\. But sometimes it does\. grrr\. > 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\. maybe\. The definition doesn't seem crisp to me\. How precise does the different linguistic rendering have to be before it's a true synonym? If it's not a synonym, it's a mapping\. Or the other way around? Grahame --- ## Post #34 by @Peter_Gummer1 I'd say so, Grahame, because the date on Thomas's email was 18th November, and I recall reading its content already, many days ago\. \- Peter --- ## Post #35 by @grahamegrieve yeah, Peter, thanks\. You'd think that when I write that, I'd have the wit to actually check the date huh? Grahame --- ## Post #36 by @ian.mcnicoll Hi Pablo, Your project is very interesting and I think needs more discussion, outside the context of this thread on the ISO datatypes\. Perhaps you should re\-post it on a new thread or on the 'openEHR adoption' thread, as it might give some useful pointers as to how we can best share from and support open source projects like yours and Koray's\. There are also some interesting discussion to be had about how to share the archetype you have developed, or at least feed your ideas into broader developments\. Would you mind re\-posting in a different/new thread? Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical analyst, Ocean Informatics openEHR Clinical Knowledge Editor www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www\.phcsg\.org --- **Canonical:** https://discourse.openehr.org/t/more-on-iso-21090-complexity/15031 **Original content:** https://discourse.openehr.org/t/more-on-iso-21090-complexity/15031