Mattias Forss wrote: > Hello, > > I'm trying to figure out which reference model Ocean's achetype editor > follows. I have an example regarding the data type Quantity, see > below. There seems to be great differences depending on what reference > model the archetypes follow.
I pretty sure that the reference model is the same in all cases. There is only one definition of DV_QUANTITY in the openEHR reference model, and as far as I know, only one assumed in archetypes. However, it may look different. There are two ways of representing constraints on Quantity in an archetype. One is to use the 'standard' method of creating C_COMPLEX_OBJECTs which mimic the sructure of the QUANTITY class; the other is to use an instance of C_QUANTITY, which is a custom replacement type which provides a better model of the possible constraint on QUANTITY (while still assuming the same underlying definition of QUANTITY). To see this difference illustrated, see the C_QUANTITY archetype at http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/test/clinical_types/?rev=0&sc=0 A detailed explanation for why we do this is in section 10 of http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/architecture/am/adl.pdf > > Background: > I'm trying to figure out how to get the property of a quantity but > this doesn't seem to be supported by the java kernel I'm using, so I'm > asking if anyone has a good idea on how to support this in other ways. the property attribute is defined only in the type C_QUANTITY. It provides a convenient way to capture the constraint that you want only length or pressure, without saying which unit. If only the property is set in the C_QUANTITY in the archetype, then when the kernel checks to see if an instance of DV_QUANTITY conforms to the C_QUANTITY in the archetype, it is up to the C_QUANTITY to carry out this check in sensible way, i.e. by determining what property the actual units measure. > > The current problem is that the java adl parser returns a CQuantity > object whenever it recognizes the string "quantity", but when it's > something else, e.g. C_QUANTITY, it returns a CComplexObject. I'm not familiar with the inner workings of the java parser, so I don't understand what is happening here. > > Idea: > I could solve this by looking up the RM type names and the attribute > names to figure out if the ComplexObject represents something that can > be interpreted as a Quantity data type. In this way I can support the > various known structures of the data type that currently exist. Any > suggestions? > > By the way, shouldn't the property attribute represent a CODED_TEXT > object that can be linked to a local or external terminology? this is true; we watered it down to make people in CEN and HL7 happy, but I no longer believe such compromises are sensible. We will probably change this to a CODED_TEXT. > This seems to be the case according the specifications and it goes all > the way back to version 0.9 that I think the current version of the > java kernel supports (partly at least). I would really like to know > what RM Ocean's archetypes follows. > > > Ocean Archetype Editor archetype: > > C_QUANTITY < > property = <"Acceleration"> > list = < > ["1"] = < > units = <"cm/s2"> > magnitude = <|< 0.0|> > > > ["2"] = < > units = <"ft/s2"> > magnitude = <|>= 0.0|> > > > > > > > > this is a C_QUANTITY instance, expressed in dADL, embedded in the cADL section of an archetype. > > Ref impl java kernel archetype: > > QUANTITY matches { > magnitude matches {|<0.0|} > units matches {"cm/s2"} > } this is a constraint on the same kind of QUANTITY, but expressed in standard cADL. > > Acode ADLParser test achetype: > > REAL_QUANTITY matches { > property matches {"Acceleration"} > units cardinality matches {1} matches { > UNIT matches { > unit_string matches {"cm/s2"} > magnitude matches {|< 0.0|} > } > UNIT matches { > unit_string matches {"ft/s2"} > magnitude matches {|>= 0.0|} > } > } > } This one does not match any kind of QUANTITY model in openEHR that I remember; certainly from 0.9 onward, it has not changed much. I think if you ask the Acode guys, you will find that they have used some other model for some reason. (I am even wondering if one of my very early examples of what an archetype might look like in ADL from a few yeras ago might have looked like this, but in fact none of our archetypes or reference models do. It looks more like some HL7-ish example perhaps done for an HL7 meeting). hope this helps - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
