> > I suspect this is an intentional difference between current 13606 and > openEHR; to faithfully capture the current (incompatible) situation > versus aiming to change the current situation. Can those different > goals really meet in one RM or do we need two standardized > RMs?http://dilbert.com/strips/comic/2011-08-02/ > > > I should perhaps point out that openEHR has a perfectly usable generic > Entry > type<http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html>that > does the same as 13606 Entry. This Entry type is designed for weakly > structured data. > > It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is now only complicates de model by creating a standalone branch. Instead of that, I would prefer to look for a solution where the ENTRY class is directly instantiable. Thus, an implementer can choose to use it if the lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs. Moreover, it would be easy to cast an ENTRY instance into any of its descendants when needed.
David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/120f3d44/attachment.html>
