Dear all:
My name is Isabel Román.
I´m working in a demographic server. In a first version only Person information is considered and I´m using Demographic Reference Model to represent it. I would like to know if the Reference Model is going to be extended with PERSON attributes or if it is only a implementation feature.
And another question. Do you have some references to works in this line with public code?
I´ve written the RM in owl (a first version), you can see it in http://trajano.us.es/~isabel/EHR/ If some one of you are working with ontologies languages may be interested in reusing or extending it,
feed back from you will be very valuable.
Isabel Román Martínez wrote:
Dear all:
My name is Isabel Román.
I´m working in a demographic server. In a first version only Person information is considered and I´m using Demographic Reference Model to represent it. I would like to know if the Reference Model is going to be extended with PERSON attributes or if it is only a implementation feature.
And another question. Do you have some references to works in this line with public code?
I´ve written the RM in owl (a first version), you can see it in http://trajano.us.es/~isabel/EHR/ <http://trajano.us.es/~isabel/EHR/> If some one of you are working with ontologies languages may be interested in reusing or extending it,
feed back from you will be very valuable.
Thanks to all
Isabel Román
this is a somewhat old post which I just realised no-one replied to. The question above I believe is essentially: is openEHR going to add a few hard-wired features to classes like PERSON? You will note that there are already some nearly hard-wired features - namely 'identities' and 'contacts' (inherited from PARTY). It always seems tempting to try to add more features to classes like PERSON, e.g. "name", "date_of_birth" and so on. The trouble is that finding a globally agreed set of definitions for most such attributes is very difficult.
Attributes which I think there might be a possibility of agreeing on for PERSON might be:
date_of_birth : DV_DATE
place_of_birth: DV_TEXT
sex: DV_CODED_TEXT // note that this clinically has at least the values - 'male', 'female', 'indeterminate', 'intersex', ...
date_of_death: DV_DATE
A function 'name: STRING' could be defined as being generated from one of the identities (do we mean legal name, performance alias, nickname?...), however, it should not be defined as a data attribute, because names are commonly stored in pieces (first names, titles, family names, ...).
By extension, do people want to try and add certain hard-wired attributes to other classes in the openEHR demographic information model? Other attemptes in the standards arena have rarely met with global agreement, e.g. the CEN and HL7 models of PERSON. I am inclined to model nearly all if not literally all attributes in demographic archetypes which then become the object of standards discussions.
Thoughts on the above?
- thomas beale
Dear Thomas
Sorry for my english.
I have been working in a model for demographic server since my old mail, so
I have make some improvements in my model.
I´m agree with you, perhaps person attributes has to be included in an
arquetype for demographics, not in the reference model, that is what I´m
doing.
I haven´t see the Demographic_AM in the openEHR documentation, is there? but
I´m working with demographic arquetypes as with the other archetypes models,
the samples in your web has helped to me a lot...
The attributes identities are very important for my model because in these
fields all the information that could identify a person as a unique key are
included (SSN, Name+Surname...) The type STRUCTURE is wide enought to permit
me to model these keys as archetypes, reusing them wherever I need... The
same with the CONTACT attributes...
My idea, that can be wrong of course, is that the RM give you the more
common attributes and containers for the more specific one...
So I´m including all my needs in the archetypes without lot of problems, but
some of these attributes, perhaps, could be included in the RM because I
think that are very common.
For example some of them are the ones you propose:
date_of_birth : DV_DATE
place_of_birth: DV_TEXT
sex: DV_CODED_TEXT // note that this clinically has at least the values
- 'male', 'female', 'indeterminate', 'intersex', ...
date_of_death: DV_DA
Name (I´m agree is better in the identities atributes but perhaps to
standarised a common way of representing names isn´t very dificult)
And other ones could be discussed in this open working group that is a
perfect framework to meet a global agreement, difficult of course but not
imposible!! (GPIC from CEN, VCard or HL7 could be started points)
My idea is that all the thinks that you include in the reference model is
going to facilitate the interoperability, althought the idea of reusing
archetypes give this interoperability too...
for example, my model facilitate interoperability in a federated system
because they use the same services and archetypes (ontology). For
interoperability with other systems based in openEHR too but with diferent
archetypes more effort is needed. This effort will be smaller whatever more
common things the openEHR facilitates.
Is this a correct idea?
I have a question about the attribute "time_validity" in CONTACT too.
Your intention is to establish the valid time interval for this contact, but
in what sense?
is, for example, for specified the summer address, the home address, or the
work address and to know where to contact in each moment?
e.g. Today is July,5 so I have to send the letter to summer address...
or this attribute is for establish a time of lapsing for the contact?
e.g. this is the home address from today to next year (2005), if someone
read the information on the 2007 probably this address is not valid...
Perhaps this question sound stupid for you but is very important in my
demographic server model...
Your feed back is very valuable for me
Sorry again for my english!!
Regards to all
Isabel Román
Isabel Román Martínez wrote:
Dear Thomas
Sorry for my english.
no importa;-)
I have been working in a model for demographic server since my old mail, so
I have make some improvements in my model.I´m agree with you, perhaps person attributes has to be included in an
arquetype for demographics, not in the reference model, that is what I´m
doing.
I haven´t see the Demographic_AM in the openEHR documentation, is there? but
not yet, but there soon will be a set of 'profiles' which will replace all the AM models - each profile will indicate:
- which classes can sensibly be archetyped
- which attributes in each class can be archetyped
- exception classes - classes where special semantics are required, e.g. C_DV_STATE
I´m working with demographic arquetypes as with the other archetypes models,
the samples in your web has helped to me a lot...
The attributes identities are very important for my model because in these
fields all the information that could identify a person as a unique key are
included (SSN, Name+Surname...) The type STRUCTURE is wide enought to permit
me to model these keys as archetypes, reusing them wherever I need... The
same with the CONTACT attributes...
that's the idea. If you are having problems with this, let us know. Maybe you would like to add some of your examples to the openEHR examples?
My idea, that can be wrong of course, is that the RM give you the more
common attributes and containers for the more specific one...
that's correct
So I´m including all my needs in the archetypes without lot of problems, but
some of these attributes, perhaps, could be included in the RM because I
think that are very common.
in principle, this is the right way to be thinking...
For example some of them are the ones you propose:
date_of_birth : DV_DATEplace_of_birth: DV_TEXT
sex: DV_CODED_TEXT // note that this clinically has at least the values
- 'male', 'female', 'indeterminate', 'intersex', ...
date_of_death: DV_DA
Name (I´m agree is better in the identities atributes but perhaps to
standarised a common way of representing names isn´t very dificult)
And other ones could be discussed in this open working group that is a
perfect framework to meet a global agreement, difficult of course but not
imposible!! (GPIC from CEN, VCard or HL7 could be started points)
we could add a computed attribute to PARTY_IDENTITY called e.g. "as_string" of type TEXT - it would be computed from whichever identity had the purpose legal_name, and it would still allow the identity to model complex multi-part names. We could then use archetypes to describe the multi-part model of a name (e.g. a dutch name structure is often different from a spanish name structure - the first often has 'van der'; the latter often has a double family name), but still be guaranteed to be able to get a TEXT object with the resulting name as a string.
My idea is that all the thinks that you include in the reference model is
going to facilitate the interoperability, althought the idea of reusing
archetypes give this interoperability too...
for example, my model facilitate interoperability in a federated system
because they use the same services and archetypes (ontology). For
interoperability with other systems based in openEHR too but with diferent
archetypes more effort is needed. This effort will be smaller whatever more
common things the openEHR facilitates.
Is this a correct idea?
certainly - I think your current work will give us some more input into improving the demographic model, and maybe even help define criteria for the eternal question of "what goes in the RM, what does in archetypes".
I have a question about the attribute "time_validity" in CONTACT too.
Your intention is to establish the valid time interval for this contact, but
in what sense?
is, for example, for specified the summer address, the home address, or the
work address and to know where to contact in each moment?
e.g. Today is July,5 so I have to send the letter to summer address...or this attribute is for establish a time of lapsing for the contact?
e.g. this is the home address from today to next year (2005), if someone
read the information on the 2007 probably this address is not valid...
Perhaps this question sound stupid for you but is very important in my
demographic server model...
this is an excellent question - and looking at the model, it does not handle it properly. The existing attribute is meant to model the second semantic you describe above, e.g. my summer address is valid for the next 5 years. I can think of a number of solutions; the easiest would simply be to add a new attribute whose type is DV_GENERAL_TIME_SPECIFICATION (based on the HL7 type of the same name) - this would enable the periods during which a contact is actually used to be specified, e.g. "between 30 june and 1 september", or "19h00 - 22h00 on weekdays". THis is a bit like specifying time in a cron job on Unix, for those who know what cron is (do "man 5 cron" on a unix, linux or macos system to get a description).
There would be other ways to do this, but I think this would be the most obvious one. The new attribute could be called e.g. "availability_time", but you may think of a better name.
My suggestion is:
- add a new attribute to your implementation to support this
- when you have done some experimentation, propose the change you think should be made to the openEHR model, using a CR form (available on the web)
If others have thoughts on this issue, please contribute.
- thomas beale