Many thanks for your responses Heath and Thomas. Please see below
On 05/09/2012 05:02, Thomas Beale wrote:
> 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.
I was thinking of something similar with a list of some form of ID as an
Archetype but it looks a bit like a hack because these IDs would not
make sense if they were to be transferred outside of a system.
This is why i thought that if we are talking about a graph based openEHR
model it would probably be better to formalise the edges.
From the look of things, different sets of entities will be required to
deal with domain variations. Everyday clinical practice uses one set,
Clinical Trials will probably require a different one. Formalising those
links between these entities would allow both to co-exist.
Realising the links themselves is not difficult but if at some point you
would like to constraint things like:
*) No self connections are allowed (reasonable / easy)
*) Given Entities [A,B,C,D,E], A can only connect to [B,C]
Then some form of "Relationship Template" would be required.
>> 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.
My main worry with anything that is not a hard link is that somehow the
IDs will get into a mess and that would disassociate everything or that
different organisations will agree to different patterns and then you
would not be able to exchange anything. The same applies to Folders. I
think Folders are purely cosmetic. Not to be used as sets.
Why not look up the demographics? Would that make the query too complex
and slow? So far, if something is already provided by openEHR i attempt
to re-use it that's why i would set-up Clinical Trial groups through the
Demographics package.
>> 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.
LINK Templates on the horizon? :)
> 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.
From my (limited) experience that's the most common relationship. That
makes the graph directed and is general enough (Reciprocal connections
just need two edges)
> 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>.
The Set is a better alternative (than nothing) but sometimes you might
also need a List. If i am retrieving a patient's Data Collection
Sessions for a specific Arm in a Trial then i can add something like
"order by date" and get them in the right order. There might be cases
where you need order but there is no obvious key to use other than the
order by which the data was entered.
All the best
Athanasios Anastasiou
