Dear Thomas Thank you for your reply. This is exactly my concern, taking some concepts (e.g. version, demographic etc.) outside of Archetype perspective, opens room for exceptions to appear, which gradually makes the design incoherent and distracted. Further, these different type of elementary concepts, need different implementation designs, that again, reduces flexibility and increases design and development efforts. In my opinion, the problem with LOCATABLE is that, it has reference to an Archetype while it would be far better if it has been an inherited class.
Bests Abbas On Sat, Aug 20, 2011 at 11:42 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Hi Abbas, > > > On 20/08/2011 05:19, Abbas Shojaee wrote: > > Hi > > OpenEHR is a great effort, but some questions remained with me yet. The > two level approach to Reference Model, is undertaken to help physical > implementation to remain apart and unchanged once domain level knowledge > changes. So why do we have other building blocks (e.g. Demographic package > or version etc.) built without using this fundamental concept and formed > fixed structures. (I know that a link to an archetype exists that for > example may further describe PERSON or ORGANIZATION, but this does not > provide the same level of flexibility and coherence). Is there a specific > reason? (except, that, elements of Demographic or versioning or .. are > inherently fixed and not changing) > > > well versioning (I assume you mean the classes > here<http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html>) > is more or less an infrastructure concept and not sensible to archetype in > any way I can think of. > > The demographic classes can be archetyped in the same way as EHR classes - > you can see about 25 demographic archetypes on > CKM<http://www.openehr.org/knowledge>. > Can you elaborate on what you mean by these not being sufficiently flexible? > > > > On the other hand, why these objects do not follow archetype structure? > why they are not inherited from C_DEFINED_OBJECT? > > > well PERSON etc is ultimately a descandant of LOCATABLE, like all the EHR > information classes, which is what makes it archetypable. Classes that > descend from C_DEFINED_OBJECT are not information classes, they are the > classes of the archetype model itself (i.e. a model of any archetype). > > > another question: why DATA_VALUE and C_PRIMITIVE do not share their basic > capabilities via a common ancestor ? > > > what capabilities would you expect them to share? > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Abbas Shojaee, M.D. Medical Informatics Consultant & IT Lead. Dubai Irani Hospital Dubai, UAE Tel: +97143440321 Cell: +971508598876, +989153172172 Fax: +973440321 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110829/166d2098/attachment.html>
