How to define a Party-Relationship archetype?

Implementers (archive)
1

Hi all,

I am looking for how to define a PARTY_RELATIONSHIP archetype.

I found an example from the Brazilian Demographic-archetypes, which are very good examples, but this one is, in my opinion not complete/correct.

The definition part looks like this:

definition

PARTY_RELATIONSHIP[at0000] matches { – Relações Pessoais

details matches {

ITEM_SINGLE[at0001] matches { – Item

item matches {

ELEMENT[at0002] matches { – Grau de parentesco

value matches {

DV_TEXT matches {*}

}

}

}

}

}

}

Now my question is how to define the PARTY_REF’s inside this ADL, I cannot get it done without errors. It must be something stupid

So what I tried was this:

PARTY_RELATIONSHIP[at0000] matches { – Relações Pessoais

details matches {

ITEM_SINGLE[at0001] matches { – Item

item matches {

ELEMENT[at0002] matches { – Grau de parentesco

value matches {

DV_TEXT matches {*}

}

}

}

}

source matches { <<---- line 54

PARTYREF[at0003] matches {

type matches {“PERSON”}

}

}

target matches {

PARTY_REF[at0004] matches {

type matches {“GROUP”}

}

}

I get an error in the adl_workbench on this

(already attempted; status = ERROR - line 54: parse error [last cADL token = V_ATTRIBUTE_IDENTIFIER]

line 54: expecting a new node definition, primitive node definition, ‘use’ path, or ‘archetype’ reference

[last cADL token = V_ATTRIBUTE_IDENTIFIER]

(Parse failed) (ARCH_REP_ARCHETYPE.parse_archetype)

Can someone tell me how to do this, or explain what I misunderstand, I cannot find an example.

Thanks very much

Bert

2

Hi Bert,

I don’t have the experiences with archetyping PARTY_RELATIONSHIP, but after skipping through your ADL, found three issues:

  1. The first issue is line 55, i.e. the next line after “source matches”, it should be PARTY_REF instead of PARTYREF

  2. There may be some things wrong with the curly braces: seems that the “source matches” and “target matches” are within “details matches” which is not correct. They should be outside of the “details matches”.

  3. PARTY_REF is not locatable, so it shouldn’t have atcodes defined, e.g. at0003 and at0004

I am not sure that fixing the above issues would resolve your problem, but it may make it a bit closer to the correct one.

Cheers,

Chunlan

3

Hi Bert,

First of all, that first set of demographic archetypes I have sent to you over a year ago have been through a number of revisions, was translated to English and can be downloaded from CKM. The party relationship you refer to (“personal relationships”) is now established directly in the person archetype instead of being a separate archetype.

The archetypes is now under the openEHR review process. We will very soon start the third review round for the person name and address archetypes. You are invited to review them.

Now trying to help you with your question, I may be mistaken, but I think the source and target of a party relationship will be set at runtime by locating the respective source and target parties (for example by a query to a database), instantiating new PARTY_REF objects with the id of the selected parties and setting the corresponding source and target attributes. You don’t need to (or you can´t) set constraints in the archetype.

Cheers,

Sergio

4

I don’t have the experiences with archetyping PARTY_RELATIONSHIP, but after skipping through your ADL, found three issues:

Thanks Chunlan,

For trying without ehvaing experience on this specific problem yourself.

I was to long trying that those errors slipped in the code, I must apologize that I did not see them while sending this email.
So, please forgive me.

But even when repairing these errors I still cannot write a good PARTY_RELATIONSHIP-archetype.
The adl_workbench accept this one:

definition
PARTY_RELATIONSHIP[at0000] matches { -- Rela��es Pessoais
details matches {
ITEM_SINGLE[at0001] matches { -- Item
item matches {
ELEMENT[at0002] matches { -- Tipo de Relacionamento
value matches {
DV_TEXT matches {*}
}
}
}
}
}
source matches {"PERSON"}
target matches {"PERSON"}
}

But it does not accept this one:

definition
PARTY_RELATIONSHIP[at0000] matches { -- party relationship person person
details matches {
ITEM_SINGLE[at0001] matches { -- onderdelen van de relatie-beschrijving
item matches {
ELEMENT[at0002] matches { -- tipo de relacionamento
value matches {
DV_TEXT matches {*}
}
}
}
}
}
source matches {
PARTY_REF{ <<<---- line 37
type{
DV_TEXT matches {"PERSON"}
}
}
}
target matches {
PARTY_REF{
type{
DV_TEXT matches {"PERSON"}
}
}
}

The error message is:

ERROR - line 37: parse error [last cADL token = SYM_START_CBLOCK]
line 37: expecting a new node definition, primitive node definition, ‘use’ path, or ‘archetype’ reference [last cADL token = SYM_START_CBLOCK]
(Parse failed) (ARCHETYPE_PARSER.parse_archetype)

Can you or someone else explain this?

or is the upper example enough to get an party_relationship validated against an archetype?
I also need the ID of which the party_ref is referring too, I did not dare to ask till now.

Thanks.

Bert

Op 20-01-10 00:24, Chunlan Ma schreef:

5

For trying without ehvaing experience on this specific problem yourself

Also please excuse my English spelling-errors (I did quite a lot this time)
:wink:

Bert

6

            PARTY_REF matches {
                type matches {"PERSON"}
            }
        }
    }

The problem with your archetype is that type is a string and not a
DATA_VALUE.

Thank you very much, Sergio, that did the trick

regards
Bert

7

Sergio,

First of all, that first set of demographic archetypes I have sent to
you over a year ago have been through a number of revisions, was
translated to English and can be downloaded from CKM. The party
relationship you refer to ("personal relationships") is now
established directly in the person archetype instead of being a
separate archetype.

Thank you, I know now where to look

The archetypes is now under the openEHR review process. We will very
soon start the third review round for the person name and address
archetypes. You are invited to review them.

As you wish, I will review them from Dutch point of view to see if Dutch
abnormalities can fit in

Now trying to help you with your question, I may be mistaken, but I
think the source and target of a party relationship will be set at
runtime by locating the respective source and target parties (for
example by a query to a database), instantiating new PARTY_REF objects
with the id of the selected parties and setting the corresponding
source and target attributes. You don't need to (or you can´t) set
constraints in the archetype.

There is only one constraint, that is the type of the PARTY_REF (or do I
misunderstand this?)

Bert