Entities & Relationships within the EHR

Technical (archive)
1

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?

2

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. 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. there is already an ID type OBJECT_VERSION_ID and OBJECT_REF (see ), 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

3

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&gt;\),
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

4

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

5

good point. For others, that’s the LOCATABLE_REF type you see . 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. 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. I will create an issue on this at some point so we can consider it further. - thomas

6

Many thanks for your responses Heath and Thomas. Please see below

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? :slight_smile:

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.

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