On 17/02/2014 17:43, Diego Bosc? wrote:
> (Posting this here as Ian suggested)
> I was looking at the Demonstration archetype and found something strange.
>
> When I look where ac0001 is used in this archetype I feel that too
> much implied knowledge is being used.
>
>
> ELEMENT[at0011] matches
> { -- Text That is Sourced From an External Terminology
> value matches {
> DV_CODED_TEXT matches {
> defining_code matches {[ac0001]} -- SubsetA
> }
> }
> }
>
> As defining_code is a CODE_PHRASE, which is an entity with a code and
> another entity of TERMINOLOGY_ID type, I don't see how a realistic
> system would solve this ac code and assign the different alternatives
> where needed.
>
> In theory you can transform a domain type into a standard equivalent
> form. Which is the standard equivalent form for this ac0001 constraint?
in the latest form of ADL 1.5, it's a TERMINOLOGY_CODE, which is now
treated as an ADL built-in. Hardold Solbrig at Mayo also suggested this
was the best way to go for AML (UML-based ADL). The ac-code in ADL 1.5
is now a value-set id given as a constraint in a C_TERMINOLOGY_CODE,
which is what the lexical [ac0001] above now is parsed as.
That's now the only place an ac-code can occur in the definition - it
can't be used on any other primtive (or other) constraint type
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140217/dbac2f05/attachment.html>
