Mattias Forss wrote: > > >> 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. > > > Thank you for your answer Thomas, > > I bet the reference model is the same, but do the Ocean archetype > editor fully conform to the reference model? Take a look at the > ITEM_TREE class definition for example. You will see that the correct > attribute for the physical representation of the tree will be either > "representation" for version 0.9 of the specifications or "root" for > version 0.95+ of the specifications. However, the Ocean archetype > editor does not use neither of these attributes, instead it uses > "items" but maybe this is correct if the editor conforms to an earlier > version of the specifications than 0.9. Anyone who knows about this?
Hm, good point. I will bring that up with the Archetype Editor team.... > >> 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). > > > This is interesting, but I'm getting slightly confused about the > naming here. Could you explain more and tell me the difference between > QUANTITY, C_QUANTITY and C_DV_QUANTITY. It is probably a lot easier to > grasp for someone like you. Actually, we habitually don't put the DV_ in data types in the archetypes. But the intention is that they are the openEHR data types. We originally used the DV_ in the data types to a) make it clear they were data types, and b) to avoid name clashes with other built-in classes like Boolean or State or whatever. In hindsight, it might have bene better not to have done this, but it doesn't matter really. In the archetypes however, some people object if they see DV_ because they know it means openEHR, whereas if they don't see it, they feel comfortable - even if the implied model is exactly the same! We are working on getting people to understand that the model on which clinical archetypes are based - if they are to be sharable - must itself be seen as a standardised ontology. Thus the function of the openEHR RM is as a "base domain ontology" for clinical computing, a suitable basis for archetypes. The fact people are able to build so many successful archetypes shows that the underlying model is relatively good for this purpose. So in the future, it may be that a subset of openEHR will be standardised for this purpose: a domain base ontology for EHR and other clinical computing purposes. In such an ontology, there would be no DV_. Such is the politics and psychology of international standardisation. C_QUANTITY on the other hand is a class whose instances are constraints on a QUANTITY (DV_QUANTITY). > > I believe the C_QUANTITY corresponds to the CQuantity (inherits from > CDomainType) class in the java reference kernel, and the parser gives > me this object if the archetype looks like Q1. Nevertheless, I'm > starting to think that this isn't right and that the parser instead > should give me the CQuantity object if the archetype looks like Q2. > What do you think? By the way, should there exist a class called > Quantity in the java kernel or maybe it is sufficient with the > CComplexObject (that mimics the structure of the QUANTITY class)? well, I don't know how Acode have built the parser, but I agree with what you say above. In the Eiffel reference ADL parser, Q1 would generate a C_COMPLEX_OBJECT and Q2 would generate a C_QUANTITY. >> >> 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. > > > I'm not getting this... as an example, do you mean that a C_QUANTITY > with its property set to "length" is supposed to check if "meters" or > "inches" in the DV_QUANTITY conforms to this C_QUANTITY? How is it > supposed to do that, it seems to me that the C_QUANTITY then must know > what allowable units there can be for the length property. Where are > those units supposed to be stored if only the property is set in the > C_QUANTITY? the C_QUANTITY needs access to shared units tables. I don't know what the Acode code does here, but we have this implemented in the .Net version; the underlying tables can be made available if you want them (in fact, they are probably in the knowledge_tools_dotnet repository somewher,e but I don't know where off-hand; let me know if you need that). > > >>> 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. > > > Ok, I suppose you're referring to the Ocean archetype editor now? Iin the AOM as well. - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
