More on ISO 21090 complexity
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
More on ISO 21090 complexity
On 24/11/2010, at 17:42, Grahame Grieve wrote: hi Tom I can only presume this email actually predated our other discussion 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
More on ISO 21090 complexity
yeah, Peter, thanks. You'd think that when I write that, I'd have the wit to actually check the date huh? Grahame On Wed, Nov 24, 2010 at 5:46 PM, Peter Gummer peter.gummer at oceaninformatics.com wrote: On 24/11/2010, at 17:42, Grahame Grieve wrote: hi Tom I can only presume this email actually predated our other discussion 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Grahame Grieve, CTO A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083 P: + 61 3 9450 2230 M: + 61 411 867 065 F: + 61 3 92450 2299 E: grahame at kestral.com.au W: http://www.kestral.com.au
More on ISO 21090 complexity
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 at 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 On 22 November 2010 17:29, pablo pazos pazospablo at hotmail.com wrote: 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. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.atalag at auckland.ac.nz To: openehr-technical at openehr.org Date: Mon, 22 Nov 2010 00:35:08 +1300 Subject: RE: More on ISO 21090 complexity 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
More on ISO 21090 complexity
In a message dated 21-11-2010 14:50:15 W. Europe Standard Time, hammo001 at 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 at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101122/246c87ff/attachment.html
More on ISO 21090 complexity
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 On Sun, Nov 21, 2010 at 4:09 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 21/11/2010 13:49, William E Hammond wrote: 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 * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101121/a4dccb3e/attachment.html
More on ISO 21090 complexity
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(V12.2.53) 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 dosesa 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 Sd!). 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 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, November 20, 2010 3:01 AM Subject: RE: More on ISO 21090 complexity 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. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: More on ISO 21090 complexity To: openehr-technical at openehr.org CC: openehr-technical at openehr.org From: hammo001 at mc.duke.edu Date: Fri, 19 Nov 2010 14:54:32 -0500 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 at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at 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 at openehr.org On 18/11/2010 06:51, Vincent McCauley wrote
More on ISO 21090 complexity
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 On Sat, 2010-11-20 at 19:38 +0530, Dr Lavanian wrote: 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(V12.2.53) 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 dosesa 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 Sd!). 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 - Original Message - From: pablo pazos To: openehr technical Sent: Saturday, November 20, 2010 3:01 AM Subject: RE: More on ISO 21090 complexity 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. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog
More on ISO 21090 complexity
- Telemedicine (Technical), Apollo Hospitals Group Former Deputy Director Medical Services, Indian Air Force Office: +91 20 32345045 Mobile: +91-9970921266 - Original Message - *From:* pablo pazos pazospablo at hotmail.com *To:* openehr technical openehr-technical at openehr.org *Sent:* Saturday, November 20, 2010 3:01 AM *Subject:* RE: More on ISO 21090 complexity 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. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Subject: Re: More on ISO 21090 complexity To: openehr-technical at openehr.org CC: openehr-technical at openehr.org From: hammo001 at mc.duke.edu Date: Fri, 19 Nov 2010 14:54:32 -0500 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 at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at 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 at openehr.org On 18/11/2010 06:51, Vincent McCauley wrote: 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML
More on ISO 21090 complexity
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 at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/8669876d/attachment.html
More on ISO 21090 complexity
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) (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 at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/195afbc0/attachment.html
More on ISO 21090 complexity
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 Sent from my iPhone On 19/11/2010, at 6:49 PM, Williamtfgoossen at cs.com wrote: 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 at results4care.nl telefoon +31 (0)654614458 fax +31 (0)33 2570169 Kamer van Koophandel nummer: 32133713 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/9818fa94/attachment.html
More on ISO 21090 complexity
On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote: 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
More on ISO 21090 complexity
Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage-Beale. Randy Neall On Fri, Nov 19, 2010 at 5:44 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote: 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
More on ISO 21090 complexity
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 at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at 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 at openehr.org On 18/11/2010 06:51, Vincent McCauley wrote: 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
More on ISO 21090 complexity
So what does he win? W. Ed Hammond, Ph.D. Director, Duke Center for Health Informatics Randolph Neall randy.neall at veri quant.com To Sent by: For openEHR technical discussions openehr-technical openehr-technical at openehr.org -bounces at 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 at openehr.org Following this debate is for me more interesting than a tennis match, and, in my opinion, it is advantage-Beale. Randy Neall On Fri, Nov 19, 2010 at 5:44 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote: 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
More on ISO 21090 complexity
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 ;-) On 19/11/2010 19:54, William E Hammond wrote: 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. * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/9b81e818/attachment.html
More on ISO 21090 complexity
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 at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at 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 at 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 ;-) On 19/11/2010 19:54, William E Hammond wrote: 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. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
More on ISO 21090 complexity
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. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Subject: Re: More on ISO 21090 complexity To: openehr-technical at openehr.org CC: openehr-technical at openehr.org From: hammo001 at mc.duke.edu Date: Fri, 19 Nov 2010 14:54:32 -0500 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 at oce aninformatics.com To openehr-technical at openehr.org Sent by: cc openehr-technical -bounces at 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 at openehr.org On 18/11/2010 06:51, Vincent McCauley wrote: 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
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
More on ISO 21090 complexity
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 grah...@kestral.com.au 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
More on ISO 21090 complexity
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
More on ISO 21090 complexity
On 18/11/2010 06:51, Vincent McCauley wrote: 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 * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101118/91741331/attachment.html
More on ISO 21090 complexity
[2nd attempt] On 18/11/2010 05:28, Grahame Grieve wrote: This is the data structure of a CD, with the HL7v3 message attributes in I guess you'll continue to dismiss them as hl7 v3 message attributes, but you miss the point by doing so - they are a response to a set of use cases that are not v3 - or even messaging - specific. They are in a different place to where you would like to have them, but that's about the above discussion The point is a) that they are HL7's idea, from HL7's architecture, of how to solve some problems. Had other engineers developers been involved, other, better and certainly different solutions could have been found. b) it is an unavoidable fact (an inconvenient truth) that HL7's approach of putting context/use case specific attributes in general models, and then expecting them to be 'profiled out' is contrary to maintainability and reusability of these models. Where I would like to see them is not my personal choice, it is just a conclusion of basic good modelling practices. I would have thought a more obvious method would be to define a type with a text field in it I don't think it's more obvious. It's certainly possible, but then I have terminology policy differences represented as different types in my engineering layer - rather a drawback from at least my point of view. I'd say more, but I think that's enough to demonstrate that it's not obvious. To determine which was better would be a long discussion, and we'd need to start by determining the scope of better for what? better for everything. We should be interested in generic, reusable data types here, not HL7 message specific ones, nor ones that try to incorporate every possible contextual use case into the same model. That just creates complexity and increases the likelihood of non-interoperable implementations, due to different implementers having interpreted the rules differently, and profiled the model differently. with the GUI making the relevant coding widgets available in the correct way uh? What's the GUI got to do with it? For the ISO 21090 data types, this is not in scope. I understand that this is in scope for openEHR, because you automatically build UI from model's choice of data type, and that's why you'll continue to use openEHR data types for that. fine, makes sense. I just used the example of the GUI to help people understand that there is no realistic danger of endless strings of terms, even if the model technically permits it. With respect to the openEHR data types, they have no specific relationship to GUI, messages or anything else. On the other hand, they can (and are today) used effectively in GUIs, messages, persistence, business logic and document processing. Contextually specific features needed in any of those places are included in the relevant models and software, not jammed into the data types. This is the way any good modelling works; the openEHR models just try to follow generally accepted good modelling principles. Note that I merged displayName and originalText, as this seems to be a modelling confusion or you could actually read the documentation that makes the differences very clear. In particular, note the restrictions on the use and implications of displayName. I will say that originalText is semantic in nature - inherent to the actual meaning, whereas displayName is distinctly interoperability related - and pretty much irrelevant in an openEHR context. I have read the spec, and I don't think it is even clear itself (here we come up again against trying to satisfy competing use cases within a single data types specification). Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user So is originalText the freely entered text of the user, or the term for the code which is being attached to some text? How is the original text the user entered more 'semantic' than the term from the terminology? The problem here is not specific to this type in this model, but in fact systemic in the whole specification: the /actual/ /formal/ semantics of any model are only what is expressed in the formal specification. Any further meaning of values in any field of any object defined by the data types specification is not the business of the latter, but of the /client code models using it/. However, this 21090 specification is full at every turn with natural language statements about how the various fields might be interpreted in various circumstances, according to use cases known by its authors. I am not saying this is not useful information, but what I am saying is that it is in /completely the wrong place/. Some posts ago, I suggested that a useful standard for data types could consist of: * a set of clean, clear
More on ISO 21090 complexity
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
More on ISO 21090 complexity
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 at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101118/b45e3a16/attachment.html
More on ISO 21090 complexity
On 18/11/2010 05:28, Grahame Grieve wrote: This is the data structure of a CD, with the HL7v3 message attributes in I guess you'll continue to dismiss them as hl7 v3 message attributes, but you miss the point by doing so - they are a response to a set of use cases that are not v3 - or even messaging - specific. They are in a different place to where you would like to have them, but that's about the above discussion I don't think I am missing the point at all. They are a) a response to some (undoubtedly real) needs by the hL7v3 design group, and are modelled according to the hL7v3 architecture, not some other architecture. I don't dispute the need to address the requirement that these attributes try to address, I am just pointing out that this is HL7's specific way of doing it (other people would have designed completely different solutions). b) there is no escaping the fact that these attributes are inherited into every other data type, a design that instantly renders these types not directly usable for situations other than messaging. Since the first thing any system will need to do with received data in messages is process and store it in some way, that's an extremely unfortunate thing to have done. I realise you had no choice, and this is the way beloved of HL7, but it does happen to break some basic OO rules of reuse and maintainability. I would have thought a more obvious method would be to define a type with a text field in it I don't think it's more obvious. It's certainly possible, but then I have terminology policy differences represented as different types in my engineering layer - rather a drawback from at least my point of view. I'd say more, but I think that's enough to demonstrate that it's not obvious. To determine which was better would be a long discussion, and we'd need to start by determining the scope of better for what? better for everything. I am just talking about a simpler, more comprehensible model, in the interests of less bugs and anomalies by implementers. with the GUI making the relevant coding widgets available in the correct way uh? What's the GUI got to do with it? For the ISO 21090 data types, this is not in scope. I understand that this is in scope for openEHR, because you automatically build UI from model's choice of data type, and that's why you'll continue to use openEHR data types for that. fine, makes sense. The openEHR data types have nothing specific to to with the GUI; I only made this comment because I have seen specious arguments about how certain model structures (like the one I proposed) would lead to infinite strings of data, which of course is nonsense. Thinking about how a real system works (e.g. at the GUI layer) may help some people to understand this. Note that I merged displayName and originalText, as this seems to be a modelling confusion or you could actually read the documentation that makes the differences very clear. In particular, note the restrictions on the use and implications of displayName. I will say that originalText is semantic in nature - inherent to the actual meaning, whereas displayName is distinctly interoperability related - and pretty much irrelevant in an openEHR context. I have read the documentation, don't worry! I still think it is conceptually mixed up. In fact, I am not even sure the spec is clear itself on what originalText really is: Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user So is it a representation of the code on the data input screen (i.e. the term for the code) ? Or is it some other freely entered text to which a code (and term) is being attached? Why is originalText 'semantic' and 'displayName' not - when it is in fact the proper linguistic rendering of the code, and therefore surely 'semantic'? The last sentence above indicates that the meaning of a code stored in data might depend on how it was chosen. This would break the basic immutability of meaning of codes in a code system. I wonder how we would compute with such data? yes, I wonder about that too. And the answer appears to be, pretty much, that you can't. Which is the point of recording the value set - so that some other person, later, can decide for themselves whether the limited value set undercuts the immutability of the meaning of the code. The problem is that this *does* happen in practice all the time, and merely banning it's occurrence in our mental model of the standard contributes to the standard being a fantasy. Needless to say, I argued against the inclusion of that particular text strenuously, but I end up recognising that it is merely a reflection of the real world more realistically, a reflection of committee-based standard building. The
More on ISO 21090 complexity
* * 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
