Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/11, Thomas Beale Thomas.Beale at oceaninformatics.biz: Mattias Forss wrote: 2006/10/9, Mattias Forss mattias.forss at gmail.com: 2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. Another question related to this. Is there any need in an archetype editor to specify different data and state for some events instead of always creating them in the first event in the history and then let all the succeding events reference (use_node) the data and state in the first event? If a user decides to edit ADL manually and sets different data and state for some events, it is not supported by neither of the current archetype editors... In general this should not happen, since the phenomenon being recorded in each event is supposed to be the same one, just at different time-points. Just what I suspected. Thanks Mattias - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
Mattias Forss wrote: 2006/10/9, Mattias Forss mattias.forss at gmail.com: 2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. Another question related to this. Is there any need in an archetype editor to specify different data and state for some events instead of always creating them in the first event in the history and then let all the succeding events reference (use_node) the data and state in the first event? If a user decides to edit ADL manually and sets different data and state for some events, it is not supported by neither of the current archetype editors... In general this should not happen, since the phenomenon being recorded in each event is supposed to be the same one, just at different time-points. - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. /Mattias ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
2006/10/9, Mattias Forss mattias.forss at gmail.com: 2006/10/8, Sam Heard sam.heard at oceaninformatics.biz: Christoph Some things have been around for a long time in our development and one was to have state defined at the root level even though it applied to each event. The current editor should read both but saves the correct version. The result is attached, Sam I should point out that the embedded state within each event isn't supported by the Java Archetype Editor (only separate state with history), but a new version that supports this will probably be out soon... Actually, when the Java editor finds a state defined at the root level it is transformed to a state with history because that is the closest thing it resembles. Another question related to this. Is there any need in an archetype editor to specify different data and state for some events instead of always creating them in the first event in the history and then let all the succeding events reference (use_node) the data and state in the first event? If a user decides to edit ADL manually and sets different data and state for some events, it is not supported by neither of the current archetype editors... /Mattias ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061008/e7802fa8/attachment.html -- next part -- An embedded and charset-unspecified text was scrubbed... Name: openEHR-EHR-OBSERVATION.blood_pressure.v1.adl URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061008/e7802fa8/attachment.adl -- next part -- ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Archetype blood_pressure: Data - State - Protocol - correlation
Hi, I am writing my diploma thesis at the Vienna Medical University. I have two questions concerning the openEHR-EHR-OBSERVATION.blood_pressure.v1 Archetype (Date 22/03/2006) and would be very thankful if someone could answer them briefly. 1st: I read in the The openEHR Reference Model - EHR Information Model (openehr_ehr_im.pdf Revision: 5.1.0) in chapter 8.2.3.4 Two ways of Recording State that there are two ways to record States inside a History. In this Blood pressure measurement Archetype they have chosen the way where the state is recorded outside data History. Isn?t it necessary to correlate a blood pressure measurement [at0003] to a position [at0008] (Systolic: 120, Diastolic: 80, Position: Standing)? What is the medical reason for modelling it like that? Even if it is made the other way the problem still occurs with the protocol. When we try to match an Instrument [at0012] (from Protocol) to a certain blood pressure measurement (Systolic: 120, Diastolic: 80, Instrument: XYZ) we don?t know which instrument belongs to which blood pressure. Am I wrong? Is there a way to correlate them? Is there no need to correlate them? 2nd: Why does the state begin with an ITEM_LIST[at0007] and not with a History? In the documentation it looks as if state and data have the same structure. (http://www.openehr.org/uml/release-1.0/Printable/Printable.html#_9_0_76d0249_1109066126764_414607_2244) Thanks a lot in advance. Christoph Rinner ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
