On 04/09/2012 18:05, Heath Frankel wrote: > > 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. >
good point. For others, that's the LOCATABLE_REF type you see here <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109331021343_528780_2066Report.html>. A DV_EHR_URI is just a stringified version of this (or some other ref), which as Heath says, needs to be parsed. URIs are normally recommended if you are passing the reference outside the system. In theory we should have a guaranteed parse structure for a DV_EHR_URI <=> LOCATABLE_REF... this needs to be addressed. > 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. > A conversation that came up today at Intermountain was that their LINKs ('Associations') can be a) written to the EHR separately from other things, and b) contains both a source pointer and N x target pointers. In openEHR the LINK is a bit anaemic, with only a single target reference. Adding it separately to the EHR is not hard, that's just a question of where, and creating new version of something, which may be a dedicated COMPOSITION to hold LINKs to other things, but then if you do that, you might as well just use DV_EHR_URIs. The 13606 LINK has target as a Set<II>. I will create an issue on this at some point so we can consider it further. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120904/b1f5f851/attachment.html>
