I understand the problem that is solved with the plugin types. But I must admit, it took quite some while.
You write that the LinkEHR cannot use the plugin types because it follows the EN13606-2 specification, but that seems to me as a formal reason. I wonder why this does not change to comfort the people using the tool, and thus creating a possible market. Bert Op 24-6-2012 12:19, Thomas Beale schreef: > > > Have a look at the following extract from the ordinal test archetype > <http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/c_domain_types/openehr-test_pkg-SOME_TYPE.ordinals.v1.adls>: > > SOME_TYPE[at0000] matches { -- root item > standard_ordinal_attr matches { > DV_ORDINAL [at0004] matches { > value matches {|0|} > symbol matches { > DV_CODED_TEXT matches { > defining_code matches {[local::at0001]} > -- + > } > } > } > DV_ORDINAL [at0005] matches { > value matches {|1|} > symbol matches { > DV_CODED_TEXT matches { > defining_code matches {[local::at0002]} > -- ++ > } > } > } > DV_ORDINAL [at0006] matches { > value matches {|2|} > symbol matches { > DV_CODED_TEXT matches { > defining_code matches {[local::at0003]} > -- +++ > } > } > } > } > clinical_ordinal_attr_1 matches { > 0|[local::at0001], -- + > 1|[local::at0002], -- ++ > 2|[local::at0003]; -- +++ > 0 -- assumed value > } > } > > > The red part above is how you have to constrain an ORDINAL with > standard ADL, while the blue part is how you do it with a C_DV_ORDINAL > and its special syntax, defined in the openEHR Archteype Profile > <imap://tb015k8416 at > imap.blueyonder.co.uk:993/fetch%3EUID%3E/%5BGmail%5D/All%20Mail%3E4631/;section=2.2?part=1.2.2&filename=openehr_archetype_profile.pdf>. > > It's an unavoidable consequence of the logic of constraint that when > you want to constrain 2 covarying attributes (in this case, > DV_ORDINAL.value and DV_ORDINAL.symbol), you can't do it efficiently > using standard ADL/AOM. Therefore we added the capability to do this > with a plug-in type. DV_ORDINALs are ubiquitous in medicine, so it > seems worthwhile. Similar arguments go for the C_DV_QUANTITY and > C_CODE_PHRASE plug-in types. > > The LinkEHR tool follows the EN13606-2 specification, which did not > include these plug-in types, so it can only use standard ADL > constructs to express the constraints. > > Looking ahead, there are probably two solutions: > > * we stick with the openEHR approach of plug-in types and syntax > extensions (at least we know this works); > * or we invent a new 'standard ADL' construct that allows covariance > to be better expressed. > > If we went for the latter, it might look something like: > > DV_ORDINAL [at0006] matches { > {value | symbol/defining_code} matches { > 0 | [local::at0001], > 1 | [local::at0001], > 2 | [local::at0001]; > 0 > } > } > > (I used '|' instead of ',' since ',' is already being used as the list > item separator). If this existed, it is effectively telling the parser > to build something like C_DV_ORDINAL on the fly. Of course, it would > work for other types too. I am not sure that it is very intuitive though. > > Another possibility might be (to try to stick with the more normal > comma delimiter everywhere, and more 'set logic' feel): > > DV_ORDINAL [at0006] matches { > {value, symbol/defining_code} matches { > {0, [local::at0001]}, > {1, [local::at0001]}, > {2, [local::at0001]}; > 0 > } > } > > Either way, the corresponding AOM construct would be somewhat > complicated. It might be worth the extra complexity to obtain the > generality, but it will certainly entail some additional complexity in > parsers, validators and serialisers. > > For DV_QUANTITYs, the argument is the same, except there is no special > syntax, we just use a straight object-serialisation of the plug-in > construct in dADL. Here are the two ways of doing a DV_QUANTITY, from > the DV_QUANTITY test archetype > <http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/c_domain_types/openehr-test_pkg-SOME_TYPE.c_dv_quantity.v1.adls>: > > standard_quantity_attr matches { > DV_QUANTITY [at0001] matches { > -- property matches {"temperature"} > units matches {"C"} > magnitude matches {|>=4.0|} > } > DV_QUANTITY [at0002] matches { > -- property matches {"temperature"} > units matches {"F"} > magnitude matches {|>=40.0|} > } > } > clinical_quantity_attr_1 matches { > (C_DV_QUANTITY)< > assumed_value =< > units =<"C"> > precision =<0> > magnitude =<8.0> > > > property =<[openehr::127]> > list =< > ["1"] =< > * units =<"C"> > magnitude =<|>=4.0|>* > > > ["2"] =< > * units =<"F"> > magnitude =<|>=40.0|>* > > > > > > > } > You can see the covarying attributes in bold in the blue part. In the > red part, there is no way at all to constrain 'property', because it > is not in the reference model, and constraining assumed value is > difficult as well. > > - thomas > * > * > > > > _______________________________________________ > 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/20120624/8d48b122/attachment.html>
