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 ____________________________________________ Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __________________________________________ -----Original Message----- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Remko Nienhuis Sent: Monday, 12 May 2003 4:38 PM To: openehr-technical at openehr.org Subject: Introduction and question 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030513/0bc41142/attachment.html>
