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_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) > > 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 - 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
