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, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101119/0ac7ab19/attachment.html>
