Introduction and question

Technical (archive)
1

Dear list members,

My name is Remko Nienhuis and I am currently working for a small Dutch company named 2Cure, which is an international medical software supplier. At this moment, my major goal in life is understanding the OpenEHR design paradigm and reference models and the way it can or will influence futureous developments on our products. I started studying OpenEHR just a couple of weeks ago, so despite the great documentation, there is still a lot to learn.

One of the things I do not fully understand is how a softwaresystem should be able to relate an instruction(entry) with the futureous result of this instruction, which will in
many cases be a new transaction, for instance a Radiology visit. This kind of relation, which can also be nested and then will create a kind of ehr-thread on its own, will occure rather often. Because the initiating instruction and the resulting transaction will not share the
same Clinical_Context and are not the result of the same Contribution, their relation can not be derived that way. Ofcourse it is possible to put both transactions underneath the same Folder, but that won’t create a relation between the instruction and a transaction.

As I understand the Link class can be used to create such relationships, but in the above scenario the Link can only be created afterwards (after the second Transaction has been created). How to constrain such a relationship?

I think I’m missing a major point here. Please help me out.

Best regards,

Remko Nienhuis.

2

Dear Remko

The link class can only be associated with either instance and we have some work to do on how to go about this. The first thing that I would say is that we may want to create a ‘report’ transaction archetype that has a context attribute “In resonse to” and then a URL to the transaction that contains the order. This would mean that we have a firm idea of the link between a report and the order (even if it was made at another site). To work in a distributed environment it would mean that any order should give the URL of the instruction in the order (even if it is an HL7 message or other artefact) If the order is an openEHR extract it carries the URL with it.

To work efficiently we will need the threads to be easy to follow - this will mean that the local EHR server will have to know which links point to which transactions from other transactions - this is an indexing problem and an example of what the server can do to make this work locally. You will not know links from outside that point in - but that is OK.

Another issue that will make this far easier is smart transactions (in house) - that is to say - how we store transactions in the local DB with only smart updates - so only deletions, edits and additions are stored. If we solve this at a kernel level then updating states and links will be trivial in terms of local DB work.

I hope this helps - you can see why we are not worried about commercial advantage for local application vendors as there are many implementation issues for us to consider as yet.

Cheers, Sam

3

Hi Remko,

Remko Nienhuis wrote:

Dear list members,

My name is Remko Nienhuis and I am currently working for a small Dutch company named 2Cure, which is an international medical software supplier. At this moment, my major goal in life is understanding the OpenEHR design paradigm and reference models and the way it can or will influence futureous developments on our products. I started studying OpenEHR just a couple of weeks ago, so despite the great documentation, there is still a lot to learn.

One of the things I do not fully understand is how a softwaresystem should be able to relate an instruction(entry) with the futureous result of this instruction, which will in
many cases be a new transaction, for instance a Radiology visit. This kind of relation, which can also be nested and then will create a kind of ehr-thread on its own, will occure rather often.

The we we do this is with the LINK type, defined on the class LOCATABLE, which almost every node type inherits from. It is therefore possible to create a LINK between 2 TRANSACTIONs, one of which contains the INSTRUCTION representing e.g. a medication order, and another which contains OBSERVATION entries describing the administration. The links can be named, and typed, and can be used to construct "problem threads", "issue threads", causal linkages or whatever.

Because the initiating instruction and the resulting transaction will not share the
same Clinical_Context and are not the result of the same Contribution, their relation can not be derived that way.

correct - LINKs cut right through all that.

Ofcourse it is possible to put both transactions underneath the same Folder, but that won't create a relation between the instruction and a transaction.

no need to do this either.

As I understand the Link class can be used to create such relationships, but in the above scenario the Link can only be created afterwards (after the second Transaction has been created). How to constrain such a relationship?

aha - you have read more than I thought;-). Links can be added to both the source and the target transaction, but obviously the target transaction has to exist first. When it is created, you create the link in either the target or the source, depending on its meaning and intended use - if you modify the source (i.e. the previously existing TRANSACTION) you just create a new version of it.

THis is a good question - it's a classic scenario.

- thomas