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)
On the other hand, why these objects do not follow archetype structure? why they are not inherited from C_DEFINED_OBJECT?
another question: why DATA_VALUE and C_PRIMITIVE do not share their basic capabilities via a common ancestor ?
Best Regards
Hi Abbas,
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) 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. 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?
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
I'm not clear here, how do you think the inheritance should work?
- thomas