Hello Thomas Thanks for your response, please see below.
> Doing this properly I think needs extra classes in the RM to represent > notions of 'trial' 'site' and so on - we are talking with the CDISC > people about doing this. > > For now it would have to be done with references to a COMPOSITION(s) > containing ADMIN_ENTRYs. References can be created as LINKs or using > DV_EHR_URIs in the data if you want it more fine-grained. Ah! LINKs, that will probably do for the moment, thank you very much. >> P.S. Do you think that it would be beneficial to add an >> "OBJECT_RELATIONSHIP" entity to the Content package just like the >> "Party_Relationship" of the Demographics Package? This would >> completely describe relationships between entities (source, target, >> ordering, multiplicity,...). In this way, we could even do away with >> the "strict" tree organisation of the EHR and express the whole >> storage as a graph of Template(able) entities interconnected with >> (proper) "OBJECT_RELATIONSHIP"s. What do you think? > * > * there is already an ID type OBJECT_VERSION_ID and OBJECT_REF (see here > <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109331021343_528780_2066Report.html>), > which can be used to turn the id into a reference, and record the target > type. I guess what you want to do here with the other things (ordering, > multiplicity) is to state constraints? Yes. Because in some cases, qualifying the relationship is necessary and also to make life easier when querying the graph (from the AQL point of view). If i get hold of an entity, it would be nice to be able to navigate to all the related entities just by following relationships. > We have been looking at this > previously. Essentially it is putting constraints on a link or reference > that limit details about what it points to - a kind of runtime > 'constrained reference'. We have not modelled this, and the concept > doesn't exist in normal IT as far as I know (other than a limitation on > type), but it may be worth thinking about. The difficult is that at > runtime you get data which is nearly what is intended, but some detail > is different. Do you establish the reference or not? I am not sure i get this. Can you describe it a bit more please (?). You establish links in a bottom-up fashion. To create a DV you need a Value, to create an Element, you need a DV, to create a CLUSTER, you need an ELEMENT....and so on. In Clinical Trials for example, a data collection session would have to be related to a number of other entities which are known and well defined. All the best Athanasios Anastasiou
