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>
