Thanks for your reply! I think link is a good fit in my model.? And I will go through the specification in more detail.? Still I'm glad to hear any suggestion on this questions.
Thanks! Kind regards, Li Wang On Sep 11, 2014, at 11:37 PM, Athanasios Anastasiou <a.anastasiou at swansea.ac.uk> wrote: Hello Wang Please see below: ? ? ? ?> My model is simple, an doctor requests a lab test and gets corresponding ? ? ? ?> result, and the result are related to the request. Great, what is the real world need that triggers the design of this template? What is the purpose for this doctor's request? Is this to cover a standard procedure that is going on in the Health System or to serve the purposes of a specific research project? ? ? ? ?> For example, if the ? ? ? ?> doctor orders two lab test requests, full-blood-count-request and ? ? ? ?> liver-function-request, then there are two lab test results, ? ? ? ?> full-blood-count-result and liver-function-result, and the ? ? ? ?> full-blood-count-result is related to the full-blood-count-request, the ? ? ? ?> liver-function-result is related to the liver-function-request. So that ? ? ? ?> the corresponding result can be found from the request and vice versa. My perception from the way you describe this use case is that you don't need a template that brings the archetypes together. What you can do is create (or re-use) an archetype for your INSTRUCTION. This will have its own lifetime within the EHR. Furthermore, you can create (or re-use) another archetype for your OBSERVATION that will contain a link (perhaps of type "related_to") to the INSTRUCTION that generated it. There is a detail here that I am not sure about and this is that an INSTRUCTION will trigger a set of ACTIONs and ACTIVITYs of which one could be leading to the generation of the actual OBSERVATION. In this case, there will effectively be a trace between the OBSERVATION and the INSTRUCTION but I am not sure if that would be as easily query able. ? ? ? ?> In programming language, a possible implementation I think may be that ? ? ? ?> there are two classes, lab-test-request and lab-test-result, ? ? ? ?> lab-test-result has an attribute stores id of lab-test-request instances ? ? ? ?> to hold the relationship between these two classes. ? ? ? ?> Does use LINK in archetypes go the same way? The LINK attribute ? ? ? ?> in archetype lab test result points to archetype lab test request, and ? ? ? ?> in lab test result archetype instance the LINK attribute stores id of ? ? ? ?> lab test request archetype instance? Is that right? I would advise against thinking in programming terms when you are at the level of archetype/templates. When you are "up there" it is better to think in terms of the real-world, the real need, the facts and processes of reality. Data and information will be captured within the EHR no matter what the back-end gets to be (relational, graph, other). ? ? ? ?> And how to use template to model the relationship between lab test ? ? ? ?> request and lab test result? I get the sense that you need to do a bit of background reading about how the whole thing works and for this I would recommend that you go through the Architecture Overview (http://www.openehr.org/releases/1.0.2/architecture/overview.pdf) and EHR IM (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf) cover-to-cover. Very briefly though, think of Archetypes as models of atomic concepts of reality. These are building blocks of more complex data structures used in healthcare. Archetypes tend to be general, i.e. "Blood Pressure" rather than "Blood Pressure Observation To Cover The Needs Of Project XYZ". You can still do the second by _specialising_ a definitive "Blood Pressure" archetype. To create more complex data structures used in healthcare, you use templates. Think of the template as a form (in the real world). Templates can apply further constraints on one or more archetypes that compose them. That whole thing of course is half the story. The other half is how is an openEHR storage system structured. That is, a set of EHRs. Each EHR is composed of folders and each folder has a set of compositions which in turn have a set of entries. That is where the (archetypeable) data actually live (think of a huge tree). This general structure along with the specific structure of the archetypes and templates determines how are data stored and how they will be queried via AQL. Hope this helps. All the best Athanasios Anastasiou _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140911/0b6be27c/attachment.html>
