Hi, I have a question:
Which entity is the parent of a composition
A quick answer would be, the EHR.
But that is impossible, because an EHR does not inherit from Locatable.
So, better is, I have two questions:
What is the purpose of the Parent-attribute of Composition?
How can I link from a Composition to the EHR where it uniquely to
belongs?
Maybe I missed or misunderstood something in the documentation?
Thanks
Bert
hi,
The parent of composition is ContentItem which can be Section or Entry.
You can link from Composition to EHR through EHR’s compositions attribute.
Please correct me if I am wrong.
Cheers,
Kruy Vanna
Graduate School of Global Information and Telecommunication Studies,
Waseda University
hi,
Sorry in my last post i said
“The parent of composition is ContentItem which can be Section or Entry.”
which is wrong.
Kruy Vanna
+81 90 8344-3697
+81 423971721-101
Graduate School of Global Information and Telecommunication Studies,
Waseda University
hi,
Sorry in my last post i said
"The parent of composition is ContentItem which can be Section or
Entry."
which is wrong.
Doesn't matter, we all make mistakes.
What rest is the second question. I wonder why there is a link from EHR
to composition, but not reverse.
In this way it is hard to find the EHR to which a composition belongs.
This can be needed, f.e. if a certain composition is found via AQL, it
is difficult to find to whom it is belonging, and what other
compositions exist for that same person.
I can hack a link in the system, and overrule the specs, but I don't
like doing that very much. Because, it has complications, for example
when using the RM-XSD that is published, or when using the open source
code, or when doing messaging with other EHR-systems.
Bert
Bert,
Maybe your ISP is catching duplicates (like GMAIL does)? Because these
resends that you are doing are on the list. If you have doubts, please
check the archives after an hour or so.
Thanks,
Tim
Hi Bert,
COMPOSITION.parent should return Void (i.e. null), just like any root object of a hierarchy.
To make a link from a Composition to its EHR, the VERSIONED_COMPOSITION.owner_id would be used. See section 6.2.2 of the Common IM spec. A Composition object itself also carries a Uid, which should be an OBJECT_VERSION_ID from the VERSION object. This is not stated anywhere in the specifications, so we should fix this. I suggest you create an issue on the SPECPR issue tracker for this purpose (please out a detailed enough description in!).
Bert Verhees wrote:
I understood the specs completely different, Thomas, I implemented it in a different way.
But I implemented it as: the COMPOSITION.uid is not a object_version_id, but a HIEROBJECT_ID. The uid’s of the versions containing a COMPOSITION are an OBJECT_VERSION_ID which is partly based on the COMPOSITION.uid.
The VERSIONED_OBJECT.owner_id is a good place to link the COMPOSITION to an EHR, thanks for that suggestion.
I also noticed that the VERSIONED_COMPOSITION, and other VERSIONED-classes do not differ from VERSIONED_OBJECT. I implemented that as a generic class, which can have a COMPOSITION as type.
Bert
(and now something completely different: sometimes I reecieve my own send emails from the mailinglist, sometimes within a few minutes, sometimes with a strange delay of some hours, sometimes not at all. But they did receive the mailinglist (others told me offline), only I don’t know. I will check ever time in the archive if this is again the case, and will not complain again about this on the list.)
Bert Verhees wrote:
Hi Bert,
COMPOSITION.parent should return Void (i.e. null), just like any root object of a hierarchy.
To make a link from a Composition to its EHR, the VERSIONED_COMPOSITION.owner_id would be used. See section 6.2.2 of the Common IM spec. A Composition object itself also carries a Uid, which should be an OBJECT_VERSION_ID from the VERSION object. This is not stated anywhere in the specifications, so we should fix this. I suggest you create an issue on the SPECPR issue tracker for this purpose (please out a detailed enough description in!).
I understood the specs completely different, Thomas, I implemented it in a different way.
But I implemented it as: the COMPOSITION.uid is not a object_version_id, but a HIEROBJECT_ID. The uid’s of the versions containing a COMPOSITION are an OBJECT_VERSION_ID which is partly based on the COMPOSITION.uid.
this is perfectly reasonable since we have not specified this. But it needs to be specified to be interoperable…
The VERSIONED_OBJECT.owner_id is a good place to link the COMPOSITION to an EHR, thanks for that suggestion.
I also noticed that the VERSIONED_COMPOSITION, and other VERSIONED-classes do not differ from VERSIONED_OBJECT. I implemented that as a generic class, which can have a COMPOSITION as type.
exactly. VERSIONED_COMPOSITION inherits from VERSIONED_OBJECT; it just allows specific functionality to be added, also helps languages that can’t do generic types.
To make a link from a Composition to its EHR, the
VERSIONED_COMPOSITION.owner_id would be used. See section 6.2.2 of
the Common IM spec. A Composition object itself also carries a Uid,
which should be an OBJECT_VERSION_ID from the VERSION object. This
is not stated anywhere in the specifications, so we should fix
this. I suggest you create an issue on the SPECPR issue tracker for
this purpose (please out a detailed enough description in!).I understood the specs completely different, Thomas, I implemented it
in a different way.
But I implemented it as: the COMPOSITION.uid is not a
object_version_id, but a HIEROBJECT_ID. The uid's of the versions
containing a COMPOSITION are an OBJECT_VERSION_ID which is partly
based on the COMPOSITION.uid.this is perfectly reasonable since we have not specified this. But it
needs to be specified to be interoperable......
I agree it needs to be exactly specified. But I think your solution is
wrong.
I think, that it should be the way I describe. Because, as you say,
assigning a OBJECT_VERSION_ID to a COMPOSITION seems wrong to me. I
think a uid of a COMPOSITION should not change after assigning. In a
OBJECT_VERSION_ID it could change (because part of the OBJECT_VERSION_ID
is the version-number). I don't have the specs with me at this time.
The VERSIONED_OBJECT.owner_id is a good place to link the COMPOSITION
to an EHR, thanks for that suggestion.I also noticed that the VERSIONED_COMPOSITION, and other
VERSIONED-classes do not differ from VERSIONED_OBJECT. I implemented
that as a generic class, which can have a COMPOSITION as type.exactly. VERSIONED_COMPOSITION inherits from
VERSIONED_OBJECT<COMPOSITION>; it just allows specific functionality
to be added, also helps languages that can't do generic types.
But making it an generic class prevents redundant code. But it is not
very important how it is solved, if the specs work.
Bert
Bert Verhees wrote:
I agree it needs to be exactly specified. But I think your solution is wrong. I think, that it should be the way I describe. Because, as you say, assigning a OBJECT_VERSION_ID to a COMPOSITION seems wrong to me. I think a uid of a COMPOSITION should not change after assigning. In a OBJECT_VERSION_ID it could change (because part of the OBJECT_VERSION_ID is the version-number). I don't have the specs with me at this time.
how could it change? Every Composition is always just one version, and immutable (in openEHR, ‘modifying’ anything means creating a new version).
Thomas Beale schreef:
Bert Verhees wrote:
I agree it needs to be exactly specified. But I think your solution is wrong. I think, that it should be the way I describe. Because, as you say, assigning a OBJECT_VERSION_ID to a COMPOSITION seems wrong to me. I think a uid of a COMPOSITION should not change after assigning. In a OBJECT_VERSION_ID it could change (because part of the OBJECT_VERSION_ID is the version-number). I don't have the specs with me at this time.how could it change? Every Composition is always just one version, and immutable (in openEHR, ‘modifying’ anything means creating a new version).
I am sorry, I did not express it clear.
Not the Composition would change, but the EHR-CompositionList would change if a new version of a Composition would replace an older version. I think this is not necessary.
If a new version is created and added to an EHR, the old version is not the latest and should not to be pointed at in the list of Compositions in the EHR.
The way I implement is, having an normal UIDBased ID, f.e. a random-GUID assigned to a Composition. This will never change, also not in other versions.
It is the Version-class which is the container of a version, and that has an ObjectVersionId. But the Version-class has no meaning in the domain-part, its function is purely for maintenance (versioning). So it should not be visible, nor should any part of it be visible or be of any importance inside the domain-functionality-part of the EHR.
It still is possible to find the latest version with that Composition with that GUID (found in the EHR-Composition-list) as ObjectId-part of the Object_Version_Id, and the latest versiontreeId. It is also possible to find all previous versions by that same Composition with that GUID, which is in every Version the same ObjectId-part of the Object_Version_Id, but with a different VersiontreeId.
Having an ObjectVersionId as uid of a Composition is possible, but not necessary/useful in my implementation, and still I have perfectly version-possibilities, and no bookkeeping in the CompositionList of the EHR when posting a modified version of an already existing Composition
That’s the idea.
(I hope I made myself clear now 
Bert
Bert Verhees wrote:
I am sorry, I did not express it clear.
Not the Composition would change, but the EHR-CompositionList would change if a new version of a Composition would replace an older version. I think this is not necessary.
If a new version is created and added to an EHR, the old version is not the latest and should not to be pointed at in the list of Compositions in the EHR.
ok, but the EHR just points to the list of VERSIONED_COMPOSITIONs; it does not indicate any particular version to look at. The easiest way to implement this is simply to store VERSIONED_COMPOSITIONs in whatever form you like with the owner_id of each one set to the EHR id, and store this value in an index field. The retrieval of Compositions for a given EHR is just based on an index lookup.
The way I implement is, having an normal UIDBased ID, f.e. a random-GUID assigned to a Composition. This will never change, also not in other versions.
It is the Version-class which is the container of a version, and that has an ObjectVersionId. But the Version-class has no meaning in the domain-part, its function is purely for maintenance (versioning). So it should not be visible, nor should any part of it be visible or be of any importance inside the domain-functionality-part of the EHR.
yes, that’s true.
It still is possible to find the latest version with that Composition with that GUID (found in the EHR-Composition-list) as ObjectId-part of the Object_Version_Id, and the latest versiontreeId. It is also possible to find all previous versions by that same Composition with that GUID, which is in every Version the same ObjectId-part of the Object_Version_Id, but with a different VersiontreeId.
Having an ObjectVersionId as uid of a Composition is possible, but not necessary/useful in my implementation, and still I have perfectly version-possibilities, and no bookkeeping in the CompositionList of the EHR when posting a modified version of an already existing Composition
ok - you are assigning a new GUID to each Composition, unlrelated to any other GUID being used. My suggestion is that you could use an existing GUID (from the Version) or the full object version id, meaning that each Composition is stamped with the id of its Version container.
I would be interested in other implementer views of this. The ‘right’ answer is the one that makes the most practical sense I think, so it is implementations that count from my point of view.
ersion-possibilities, and no bookkeeping in the CompositionList of the EHR when posting a modified version of an already existing Composition
ok - you are assigning a new GUID to each Composition, unlrelated to any other GUID being used. My suggestion is that you could use an existing GUID (from the Version) or the full object version id, meaning that each Composition is stamped with the id of its Version container.
You misunderstand me, or I misunderstand you.
Every new version of a Composition has the same GUID as the previous version of that same Composition. It is connected to the Version-class in the ObjectVersionId of the Version-class. The objectVersionId’s first part (ObjectID-part) is the GUID of the data (Composition) it contains. The last part is the VersionTreeId (for finding the latest (or a specific) version).
So retrieving the latest version of a Composition, using the EHR-CompositionList is a follows (pseudo-SQL)
SELECT data (=composition) FROM VERSION where OBJECTID=GUID (from EHR-List) ORDER REVERSED BY VERSIONTREEID LIMIT 1
It is also possible to retrieve a version of the composition of an earlier date (date from AUDIT_DETAILS in VERSION), the same applies for all domain-data inside the openehr system,
so it is possible to create a timemachine in all domain-related aspects of system-functionality
Bert
Bert Verhees wrote:
ersion-possibilities, and no bookkeeping in the CompositionList of the EHR when posting a modified version of an already existing Composition
ok - you are assigning a new GUID to each Composition, unlrelated to any other GUID being used. My suggestion is that you could use an existing GUID (from the Version) or the full object version id, meaning that each Composition is stamped with the id of its Version container.
You misunderstand me, or I misunderstand you.
Every new version of a Composition has the same GUID as the previous version of that same Composition. It is connected to the Version-class in the ObjectVersionId of the Version-class. The objectVersionId’s first part (ObjectID-part) is the GUID of the data (Composition) it contains. The last part is the VersionTreeId (for finding the latest (or a specific) version).
ok- this means that if version-1 and version-2 of the same logical COMPOSITION were sent from system A to system B in an Extract (or two different Extracts), system B is likely to assume that they are both the same data object, then there will be problems because the contents are different.
I am not saying that we should not do this - if we do, it certainly needs to be documented.