Hi Athanasios, On 04/09/2012 04:56, Athanasios Anastasiou 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).
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. > > 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? I had not thought of using the Demographic package for that, but if you want to describe the trial actors in detail, that would be the way of doing it. > > 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? * * 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? 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? - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120904/d62d523f/attachment.html>
