We could also need to register someone who is unconscious and with no legal documents, or a newborn who has not been registered yet. There are even people who has not been registered yet in some places.
Cheers, Sergio On Mon, Aug 30, 2010 at 6:18 AM, Diego Bosc? <yampeku at gmail.com> wrote: > What about a person that is only used for family history for an > illness? Maybe you only know that the grandparent called 'John' > suffered from the same disease of your patient, but you don't know > much more about him. > > 2010/8/30 Stef Verlinden <stef at vivici.nl>: > > Hi Sergio, > > From a non-technical perspective: what's the use of registering a person > > with no known legal identity? I one would allow that to happens your > > database will be contaminated with unidentifiable 'ghosts' and I don't > think > > we should let that happen. I forgot where but there is a special function > to > > register anonymous people, maybe that's something you can use. > > Cheers, > > Stef > > > > Op 30 aug 2010, om 01:21 heeft Sergio Freire het volgende geschreven: > > > > Hi Sebastian and all, > > > > IMHO, I think that the invariant Legal_identity_exists: > has_legal_identity > > is too restrictive, because it may happen that you may register a person > > without no known legal identity at the moment of registration. I think it > > should be removed from the reference model. > > > > We also had to include the types of identity as a constraint in the name > > attribute because the rm demands it. Again I think this is too > restrictive > > because we cannot register two identities of the same type because the > name > > must be unique among siblings. I wonder why the name attribute should > > receive the type of the identity. If we remove these restrictions, the > type > > of identity could be moved to a normal ELEMENT in the archetype. > > > > Cheers, > > > > Sergio > > > > > > On Thu, Aug 26, 2010 at 5:27 AM, Sebastian Iancu <sebastian at code24.nl> > > wrote: > >> > >> Hi Ian, > >> > >> I was not thinking on names attribute of an archetype as holding more > than > >> names. Yet, the demographic_im.pdf is suggesting/stating to use them to > >> associate a type meaning the the owner objects (i.e. things like > >> PERSON/name/value = "PERSON" or ROLE/name/value = "General > practitioner"), > >> and for some objects the purpose() is designed that way as well. > >> > >> As you previously said, there can be RM-types and Archetype-types and > the > >> later is introduced in demographic package through this construction of > >> 'name' attribute. As long as the scope of that 'type' is within (or > related) > >> that owner archetype domain I don't see any problem, but if that that > 'type' > >> need used outside I don't really see it working, without a proper coding > >> system or at least a binding. > >> > >> Maybe I was not very clear in previous emails about my reasoning, maybe > I > >> am just confused about specifications or about the modeled archetypes on > >> CKM, but nevertheless one of my main technical question remains: > >> how can a function like ACTOR.has_legal_identity() be implemented > >> regardless the archetypes being used? > >> If you or somebody else can give some suggestion on this, I think it > will > >> be much more easier to understand the concepts behind the demographic > >> package. > >> > >> Sebastian > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100831/4315e103/attachment.html>
