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

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

More on ISO 21090 complexity

- Original Message - From: "Grahame Grieve" To: "For openEHR technical discussions" 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 tha

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 ou

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 "simp

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

More on ISO 21090 complexity

Apparently there are others including the CDISC people very unhappy about the ISO21090 data types. This comment from Barry Smith's blog (emphasis added by me): XML4Pharma said: As an XML-guy, my major probl

More on ISO 21090 complexity

> 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

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.

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 c

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 p

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), Com

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

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

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, > > Give

More on ISO 21090 complexity

enehr-technical -bounces at openehr. Subject org Re: More on ISO 2

More on ISO 21090 complexity

Subject Re: More on ISO 21090 complexity 11/19/2010 01:08 PM

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

More on ISO 21090 complexity

-bounces at openehr. Subject org Re: More on ISO 21090 complexity

More on ISO 21090 complexity

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.o

More on ISO 21090 complexity

On 19/11/2010 21:26, William E Hammond wrote: > 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

More on ISO 21090 complexity

om: 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 modeli

More on ISO 21090 complexity

roducts, 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

More on ISO 21090 complexity

t; > 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 Hospi

More on ISO 21090 complexity

es at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Seref Arikan Sent: Sunday, 21 November 2010 6:50 a.m. To: Dr Lavanian; For openEHR technical discussions Subject: Re: More on ISO 21090 complexity Greetings, I'd say that simplification is a must in medical informa

More on ISO 21090 complexity

-technical -bounces at openehr. cc org Subject RE: More on ISO 21090

More on ISO 21090 complexity

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 n

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

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 mod

More on ISO 21090 complexity

p://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: k.ata...@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 endoscop

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 - o

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

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 wrote: > On 24/11/2010, at 17:42, Grahame Grieve wrote: > >> hi Tom >> >> I can only presume this email actually predated our other disc

More on ISO 21090 complexity

t; > > ________ > 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