PERSON inherits from Locatable, and Locatable has the attribute ownerId.
It is not allowed to leave it empty.
Who is the owner of a PERSON (f.e. representing a patient)
If someone knows the answer.
Thanks
Bert
Excuse me, this email was wrong, the question is valid but wrong formulated, sorry for that, I was busy in a telephone-call while sending it (multitasking)
The question I meant to ask is:
It is about storing a PERSON in a VERSIONED_OBJECT, the documentation says:
Each VERSIONED_OBJECT has a unique identifier recorded in the uid attribute (a HIER_OBJECT_ID
typically containing a GUID), and a reference to the owning object (e.g. the owning EHR) in the
owner_id attribute
Each VERSIONED_OBJECT has a unique identifier recorded in the uid attribute (a HIER_OBJECT_ID
typically containing a GUID), and a reference to the owning object (e.g. the owning EHR) in the
owner_id attribute
Who is the owner of a PERSON (f.e. representing a patient)
Thanks
Bert
In a mysterious way,m sometimes, my messages do not appear on the list, that is why I send it again
PERSON inherits from Locatable, and Locatable has the attribute ownerId. It is not allowed to leave it empty.
Excuse me, this email was wrong, the question is valid but wrong formulated, sorry for that, I was busy in a telephone-call while sending it (multitasking)
The question I meant to ask is:
It is about storing a PERSON in a VERSIONED_OBJECT, the documentation says:
Each VERSIONED_OBJECT has a unique identifier recorded in the uid attribute (a HIER_OBJECT_ID
typically containing a GUID), and a reference to the owning object (e.g. the owning EHR) in the
owner_id attribute
Who is the owner of a PERSON (f.e. representing a patient)
Thanks
Bert
Hi Bert
Not sure if you have had discussions off line but I would say that it is the demographic service instance. The reference model documentation is clearly describing the EHR owning the composition (or something else) and it is not so clear in the demographic space as people are really a high level object.
It might be that a class VERSIONED_PERSON is the way to go – providing a unique space for each individual.
Let’s see if I can stimulate some response.
Cheers, Sam
Thanks for your reply, Sam, I did not have this discussion offline. I am
just waiting patiently for someone to guide me to the correct answer.
I think, owner_id should be optionally in versioned_object, or it should
be branched (for demographic purposes) from a root which has owner_id
optionally and a branch for the other purposes to a class in which
owner_id is required.
Bert
Try again.
Heath
Hi Bert,
Actually I replied back on 10th Aug, but it obviously didn't get through. I will forward my response again.
Heath
Thanks, Heath, I missed your previous send message. Maybe I was not
paying wel attention, or maybe it is the mailinglist system which seems
sometimes not to distribute messages, or with delay.
I also experienced that a few times.
I agree that a demographic system can be seen as the owner of a
demographic record. Thanks for this suggestion.
Then regarding to SystemID's. There isn't really a standard for this.
And what is a system? the computer? it's network-address? it's location?
it's owner? the software running on a computer?, or only the database?
(all these will change regularly)
And an ID is only useful if except from unique identifying the system
(which is not clear what a system is), it also can be used to localize a
system, and identify the owner of the system.
But I guess that this question is to difficult to solve in a mailinglist
discussion.
Bert
Hi Bert,
I somehow think this is related your last email about parent of Composition.
In that email, Thomas said that we can link Composition to EHR by VersionedComposition.owner_id with owner_id here is the id of EHR.
In this way, you can find other compositions of the same EHR.
So I think this also applies to VersionedParty.owner_id.
I would like to hear what others think.
Kruy Vanna
Graduate School of Global Information and Telecommunication Studies,
Waseda University