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 ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: <Administrator at inetsrv-1.chime.ucl.ac.uk> Cc: <openehr-technical at openehr.org> Sent: Monday, July 05, 2004 5:01 AM Subject: Re: Demographic Server > 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/%7Eisabel/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 > > > -- > ____________________________________________________________________________ _______ > CTO Ocean Informatics (http://www.OceanInformatics.biz) > Hon. Research Fellow, University College London > > openEHR (http://www.openEHR.org) > Archetypes (http://www.oceaninformatics.biz/adl.html) > Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html) > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
