Anthanasios, What we have Don in research based projects is use a persistent composition to record the cohort that the subject belongs too. It could be done using demographics where we have a registration relationship associated with the party but when you want population query on the ehr data you don't want to be doing a lookup on demographics to find the members of the cohort. Using this approach we didn't need to provided a hard link between an particular composition and the cohort as we were able to use aql t determine cohort membership and the composition template of interest was enough. But of you do need a hard link for some reason then as Thomas suggested links would be one way to do it, which allows a type property on the link. An archetyped DV_EHR_URI element value is another way that has been used mainly because it is supported by the archetype editor but I find this a softer link which is harder to implement queries against because it is not an intrinsic part of the RM. Personally I think the locatable_ref class is a more computable structure since you don't need to parse the URI and account for the variations of absolute/relative URIs and latest or specific versions, to extract the object id to retrieve the object to traverse the path. Perhaps a more restful implementation would work better with URIs. Problem is locatable_ref is only used in one place in the RM, not sure why this instruction details link was handled different. All this is implentation specific and we need to find a logical best practice, which I think is link since there is no restrictions where it can be used, but this is also it downside until we understand how to constrain, validate and query links efficiently. Heath On 04/09/2012 8:26 PM, "Athanasios Anastasiou" < athanasios.anastasiou at plymouth.ac.uk> wrote:
> Hello everyone > > I am coming across an openEHR use case for which there seem to be more > than one ways to deal with and that i would appreciate your help with. > > The main question is this: > When creating COMPOSITIONs that describe Template(able) stand-alone > entities that are well defined and should have clear relationships with > each other, is it a good practice to include "ID"s and references in order > to establish these relationships? > > A representative example: > In a Clinical Trials setting, there exist entities that should have clear > relationships with each other in order for queries to return properly > structured data that can later be used in analysis. > > For example, a COMPOSITION describing a "Site" should have a harder way of > linking it to the "Trial" than simple membership to the same EHR Folder > (The naming of the Folder will become an issue). > > All the same, the most interesting COMPOSITION, the one that contains the > data collected, should have a hard way of referencing [the "Trial", "Site", > "Stage", "Research Staff performing the data collection"] or other entity. > > Some of these relationships are already there (A Trial Group (e.g. Control > / Condition A, B, C), can possibly be expressed via the entities in the > Demographics package) and i suppose that it is advisable to use them but > what about describing new relationships? > > Looking forward to hearing from you > Athanasios Anastasiou. > > 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? > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120905/c7e6cd6d/attachment.html>
