PartyIdentity -> Purpose

system · 7 December 2007 14:40

Maybe Rong, has some time to answer this, but I am very glad with
anyone's answer.

I have a question about the ref_java_impl. I checked the latest TRUNK
version, there is something that is not clear to me.

I looked in the document: Demographic Information Model, version
Revision: 2.0.1, which is, I believe, the latest published version.

I look at PartyIdentity and see the required attribute "purpose".
But it is not in the rm-domain-object PartyIdentity in the constructor.
This an annotated constructor, the annotations are used by the
rm-builder. So there is no way, by using the rm-builder, to assign the
attribute "purpose"

I found a few similar situations, and have about the same question.

thanks in advance
Bert Verhees

Sergio_M_Freire · 7 December 2007 16:10

Hi Bert,

purpose is a function that returns the value of the inherited name
attribute. It is implemented in the method purpose()

Cheers,

Sergio

system · 7 December 2007 16:30

Sergio Miranda Freire schreef:

Hi Bert,

purpose is a function that returns the value of the inherited name
attribute. It is implemented in the method purpose()

Cheers,

Sergio

Thanks Sergio,

But there is no setter for it. It returns this.name, which is set in the
constructor.
But this seems wrong to me, because in the rm-builder the name of
property is demanded, that is why it is an annotated constructor.
In archetypes the attributename also is "purpose"

So there should be a mapping then from "purpose" to "name"

I do not understand why this is, also because in the eiffel reference
code, the attribute "purpose" is defined

Bert

Sergio_M_Freire · 8 December 2007 15:55

Hi Bert,

Sergio Miranda Freire schreef:

purpose is a function that returns the value of the inherited name
attribute. It is implemented in the method purpose()

But there is no setter for it. It returns this.name, which is set in the
constructor.
But this seems wrong to me, because in the rm-builder the name of
property is demanded, that is why it is an annotated constructor.

I do not know if I understood what you meant. Why should we have a setter
for purpose if it is not an attribute of PartyIdentity, but is derived
from name which is set in the constructor of Locatable? Besides, purpose
is not a parameter of the constructor.

In archetypes the attributename also is "purpose"

So there should be a mapping then from "purpose" to "name"

I guess we are using the openehr-demographic-person.person.draft archetype.
I have the same question. The archetype suggests that purpose is an
attribute of PartyIdentity. Here I think that instead of having a purpose
attribute, there should be a constraint on the values of the name
attribute, and there would be no need of a mapping. Also it would be
consistent with the reference model.

We are here in Brazil designing a set of archetypes that could be used to
build a demographic service. Although the openehr archetypes could be
inspiring, they are, as you said in a previous message, incomplete. As
soon as we have a draft version of them I will send them to you and would
very much appreciate your comments.

I do not understand why this is, also because in the eiffel reference
code, the attribute "purpose" is defined

I guess the java implementation is following the reference model
specification.

Best regards,

Sergio

system · 8 December 2007 17:19

sergio@lampada.uerj.br schreef:

Hi Bert,

Sergio Miranda Freire schreef:


purpose is a function that returns the value of the inherited name
attribute. It is implemented in the method purpose()

But there is no setter for it. It returns this.name, which is set in the
constructor.
But this seems wrong to me, because in the rm-builder the name of
property is demanded, that is why it is an annotated constructor.

I do not know if I understood what you meant. Why should we have a setter
for purpose if it is not an attribute of PartyIdentity, but is derived
from name which is set in the constructor of Locatable? Besides, purpose
is not a parameter of the constructor.

Thanks, Sergio, for thinking with me,

I think it should be in the constructor, because, reading the specs, it
is a required attribute, please take a look in
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/rm/demographic_im.pdf
It must be the same as "name", you are right, and "name" is an annotated
parameter in the constructor.

But the way it is now, we have a required attribute, which is with
another name (which is "name") in the constructor, this makes it
difficult to interpret ADL. Because people will use in ADL "purpose",
because they read the specs, and when the reference java kernel is used,
"purpose" in ADL must be mapped to "name"
Anyway, this must be in the rm-builder, which is also a part of the
ref_java_impl, because the rm-builder, maybe you did not take a look at
the code, simply said, uses archetype-input and data to construct an
RM-object (that why it is called the RM-builder). I would have called it
"rm-factory", but that is not important.

If you look at the code, you'll see it uses the annotated constructors
from the openehr-rm to get a definition of the rm-objects to build, and
it maps these constructors to the data given to the rm-builder. These
data are mapped to attributes in the archetypes, and in the archetype,
"purpose" is used, instead of "name"

It is a fine piece of code, and I use it as a base, but this is a problem.

Besides that, what is the use of a required attribute, when it will be
called differently in the constructor?

Confusing!

I would like to have more clearity on this, because as it is now, this
will lead to stupid code in the rm-builder

thanks
Bert

Sergio_M_Freire · 9 December 2007 11:27

Hi Bert,

I think we are speaking of openehr-demographic-person.person.draft.adl
archetype. I think it should be designed like this:

PERSON[at0000] matches { -- person demographics
    identities matches {
     PARTY_IDENTITY[at0001] matches { -- legal name
      name matches {
        CODED_TEXT matches {
          code matches {[ac0001]} -- legal name
        }
      }
      details matches {
         ...

instead of

PERSON[at0000] matches { -- person demographics
    identities matches {
     PARTY_IDENTITY[at0001] matches { -- legal name
      purpose matches {
        CODED_TEXT matches {
          code matches {[ac0001]} -- legal name
        }
      }
      details matches {
        ...

because, as far as I understood, purpose is a function, not an attribute,
according to the rm specification.
Therefore, it is not in the list of attributes of PARTY_IDENTITY that
could be constrained by an archetype.

If you think it is the archetype that is wrong, then everything else seems
to be consistent for me, doesn't it?
On the other hand, if the archetype is to be kept like it is now, then I
agree with you that several changes must be done, the rm specification
included.

By the way, I reviewed the rm-builder code and I have two comments:
1) In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
by DvProportion, according to the 1.0.1 specification, right?;
2) For the sake of clarity, the local variable typeMap in method construct
(line 241) could be renamed to something like attributeTypeMap in order to
not be confounded with the typeMap class attribute .

Thanks for the discussion.

Sergio

system · 9 December 2007 13:32

Sergio M. Freire schreef:

Hi Bert,

I think we are speaking of openehr-demographic-person.person.draft.adl

Thanks for being persevering, you are right, I checked again the docs,
and it is a function. It was indeed this archetype, which confused me,
this happens sometimes, the changes in specs, leaving old traces of
previous specs behind

Thanks
Bert

system · 9 December 2007 13:56

Sergio M. Freire schreef:

Hi Bert,

I think we are speaking of openehr-demographic-person.person.draft.adl
archetype. I think it should be designed like this:

PERSON[at0000] matches { -- person demographics
    identities matches {
     PARTY_IDENTITY[at0001] matches { -- legal name
      name matches {
        CODED_TEXT matches {
          code matches {[ac0001]} -- legal name
        }
      }
      details matches {
         ...

instead of

PERSON[at0000] matches { -- person demographics
    identities matches {
     PARTY_IDENTITY[at0001] matches { -- legal name
      purpose matches {
        CODED_TEXT matches {
          code matches {[ac0001]} -- legal name
        }
      }
      details matches {
        ...

because, as far as I understood, purpose is a function, not an attribute,
according to the rm specification.
Therefore, it is not in the list of attributes of PARTY_IDENTITY that
could be constrained by an archetype.

If you think it is the archetype that is wrong, then everything else seems
to be consistent for me, doesn't it?
On the other hand, if the archetype is to be kept like it is now, then I
agree with you that several changes must be done, the rm specification
included.

By the way, I reviewed the rm-builder code and I have two comments:
1) In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
by DvProportion, according to the 1.0.1 specification, right?;
2) For the sake of clarity, the local variable typeMap in method construct
(line 241) could be renamed to something like attributeTypeMap in order to
not be confounded with the typeMap class attribute .

Sorry, I didn't read the second part of your writing. I must say, that I
don't work with the latest version of the specs, I am somewhere between
0.95 and 1.0.1. This is because, I am almost ready with a working
kernel, also persistence, and archetype-interpretation, and rm-builder.
I have my own code, but heavily based on the work of Rong.
When I am ready, and it is stable, I will fully migrate to 1.0.1 which
is not that hard to do.

Your suggestions concerning the rm-builder, I leave them for Rong to
reply on, because he is the java-kernel-maintainer.

Just for interest, what are you doing with the java-kernel? Are you
working on a product?

Bert

system · 10 December 2007 08:01

Hi Bert,

I think we are speaking of openehr-demographic-person.person.draft.adl
archetype. I think it should be designed like this:

PERSON[at0000] matches { – person demographics
identities matches {
PARTY_IDENTITY[at0001] matches { – legal name
name matches {
CODED_TEXT matches {
code matches {[ac0001]} – legal name
}
}
details matches {
…

instead of

PERSON[at0000] matches { – person demographics
identities matches {
PARTY_IDENTITY[at0001] matches { – legal name
purpose matches {
CODED_TEXT matches {
code matches {[ac0001]} – legal name
}
}
details matches {
…

because, as far as I understood, purpose is a function, not an attribute,
according to the rm specification.
Therefore, it is not in the list of attributes of PARTY_IDENTITY that
could be constrained by an archetype.

If you think it is the archetype that is wrong, then everything else seems
to be consistent for me, doesn’t it?
On the other hand, if the archetype is to be kept like it is now, then I
agree with you that several changes must be done, the rm specification
included.

By the way, I reviewed the rm-builder code and I have two comments:

In method loadTypeMap, in line 67, DvQuantityRatio should be replaced
by DvProportion, according to the 1.0.1 specification, right?;

For the sake of clarity, the local variable typeMap in method construct
(line 241) could be renamed to something like attributeTypeMap in order to
not be confounded with the typeMap class attribute .

Thanks, Sergio!
The rm-builder is still stuck on the 0.95 branch and needs to be migrated to the trunk. We need to keep a todo list for this task and probably put it in the wiki.
/Rong

system · 10 December 2007 08:09

Hi Bert,

I think we are speaking of openehr-demographic-person.person.draft.adl
archetype. I think it should be designed like this:

PERSON[at0000] matches { – person demographics
identities matches {
PARTY_IDENTITY[at0001] matches { – legal name
name matches {
CODED_TEXT matches {
code matches {[ac0001]} – legal name
}
}
details matches {
…

instead of

PERSON[at0000] matches { – person demographics
identities matches {
PARTY_IDENTITY[at0001] matches { – legal name
purpose matches {
CODED_TEXT matches {
code matches {[ac0001]} – legal name
}
}
details matches {
…

because, as far as I understood, purpose is a function, not an attribute,
according to the rm specification.
Therefore, it is not in the list of attributes of PARTY_IDENTITY that
could be constrained by an archetype.

If you think it is the archetype that is wrong, then everything else seems
to be consistent for me, doesn’t it?

Hi Bert, Sergio

I think the same way as Sergio. It’s the archetype that needs to be updated according to the specification. If we would have an archetype validator that checks archetypes against RM class and attribute names/types, this archetype wouldn’t pass validation. This is not difficult to do and will be very useful to have. It’s good to catch this type of errors early on.

Cheers,
Rong

Sergio_M_Freire · 11 December 2007 12:05

Hello Bert,

I must say, that I
don't work with the latest version of the specs, I am somewhere between
0.95 and 1.0.1. This is because, I am almost ready with a working
kernel, also persistence, and archetype-interpretation, and rm-builder.
I have my own code, but heavily based on the work of Rong.
When I am ready, and it is stable, I will fully migrate to 1.0.1 which
is not that hard to do.

Just for interest, what are you doing with the java-kernel? Are you
working on a product?

Thanks for the interest. I work as an assistant professor at the State
University of Rio de Janeiro.
I intend to do some research about the openehr approach and maybe develop
some information systems to be used at our hospital.
Right now, I am studying the specifications and their corresponding
implementations. Until I get some software running, I envisage going
through the same path as yours and raising the same issues as you do.
That´s why I read your messages with great interest.

Regards,

Sergio

Topic		Replies	Views
More doubts about assertions Technical (archive)	13	23	2 September 2006
Class Archetype, eo Implementers (archive)	9	11	9 August 2006
Mapping Archetypes to HL7 and vv [from Heath Frankel] Implementers (archive)	4	8	4 August 2006
(Im)mutable java RM? (Was: Re: Improving the minimal terminology service) Reference Implementation: Java (archive)	3	8	18 December 2007
Mapping Archetypes to HL7 and vv Implementers (archive)	4	9	25 July 2006
openEHR and HL7 – some thoughts on the current discontents from Chair of openEHR Announcements (archive)	5	6	6 October 2006
ResourceDescriptionItem Reference Implementation: Java (archive)	9	13	12 October 2006
Could not find a setter for property normalRange in class org.openehr.rm.datatypes.quantity.DvOrdinal Reference Implementation: Java (archive)	15	20	26 November 2006
How to define a Party-Relationship archetype? Implementers (archive)	6	10	21 January 2010
Questions on EHR implementation Technical (archive)	12	20	22 October 2007

PartyIdentity -> Purpose

Related topics