This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Object nets and object trees"

From HL7Wiki
Jump to navigation Jump to search
Line 11: Line 11:
 
*Rene: this is again related to the issue of identity of objects. The business identity of a RIM class is contained in its Id attribute (for Acts, Entities and -managed- Participations). For Roles identity is based on the tuple (Role.id, 'Scoper') where 'Scoper' could be an Entity.id or an Entity.name.  
 
*Rene: this is again related to the issue of identity of objects. The business identity of a RIM class is contained in its Id attribute (for Acts, Entities and -managed- Participations). For Roles identity is based on the tuple (Role.id, 'Scoper') where 'Scoper' could be an Entity.id or an Entity.name.  
 
**This is especially relevant in the process of deciding when to 'merge' objects into an object net.
 
**This is especially relevant in the process of deciding when to 'merge' objects into an object net.
**Example: a RIMBAA application persists an ''Observation with subject Patient 123 with scoping entity 'hospital A'''.  
+
**Example #1: Dr. Smith is a part-time employee of two different hospitals, A and B. Within each organization he performs a different role (different role.code values). Each role has different contact details, address etc. However: both hospitals (the scopers of the respective roles) both know Dr. Smith using one and the same ID: his 'national healthcare provide identity', 607802. Given that the roles are different, but the Role.id values are the same (607802), one has to use the scoper.Id (A or B) in combination with the Role.id to uniquely identify a role instance.
 +
**Example #2: a RIMBAA application persists an ''Observation with subject Patient 123 with scoping entity 'hospital A'''.  
 
**#If it subsequently receives an object tree with ''Demographics update for Patient 123 with scoping entity 'hospital A''' - in that case the patient objects are one and the same.
 
**#If it subsequently receives an object tree with ''Demographics update for Patient 123 with scoping entity 'hospital A''' - in that case the patient objects are one and the same.
 
**#If it subsequently receives an object tree with ''Procedure with subject Patient 123 with scoping entity 'hospital B''' - the objects won't be merged - they're not the same.
 
**#If it subsequently receives an object tree with ''Procedure with subject Patient 123 with scoping entity 'hospital B''' - the objects won't be merged - they're not the same.
 
**#If it subsequently receives an object tree with ''Demographics update for Patient 123 without a scoping entity being present''' - the objects won't be merged, the scoper of the new object is unknown and therefore can't be merged automatically with any other Role object.
 
**#If it subsequently receives an object tree with ''Demographics update for Patient 123 without a scoping entity being present''' - the objects won't be merged, the scoper of the new object is unknown and therefore can't be merged automatically with any other Role object.

Revision as of 15:48, 28 February 2010

Summary

  • v3 artefacts, when used in a messaging context, are object trees. When one persists these in a RIMBAA application all objects that share one and the same id are 'merged' into one single object. A stack of trees where objects interconnect based on their shared identity is an object net. Object nets have different characteristics than object trees, e.g. in areas such as context conduction, querying of object net subsets, and object versioning.

Related: Context Conduction in cyclic RIM graphs

Analysis

  • Ewout has taken the action item to write an analysis.

Discussion

  • Rene: this is again related to the issue of identity of objects. The business identity of a RIM class is contained in its Id attribute (for Acts, Entities and -managed- Participations). For Roles identity is based on the tuple (Role.id, 'Scoper') where 'Scoper' could be an Entity.id or an Entity.name.
    • This is especially relevant in the process of deciding when to 'merge' objects into an object net.
    • Example #1: Dr. Smith is a part-time employee of two different hospitals, A and B. Within each organization he performs a different role (different role.code values). Each role has different contact details, address etc. However: both hospitals (the scopers of the respective roles) both know Dr. Smith using one and the same ID: his 'national healthcare provide identity', 607802. Given that the roles are different, but the Role.id values are the same (607802), one has to use the scoper.Id (A or B) in combination with the Role.id to uniquely identify a role instance.
    • Example #2: a RIMBAA application persists an Observation with subject Patient 123 with scoping entity 'hospital A'.
      1. If it subsequently receives an object tree with Demographics update for Patient 123 with scoping entity 'hospital A' - in that case the patient objects are one and the same.
      2. If it subsequently receives an object tree with Procedure with subject Patient 123 with scoping entity 'hospital B' - the objects won't be merged - they're not the same.
      3. If it subsequently receives an object tree with Demographics update for Patient 123 without a scoping entity being present' - the objects won't be merged, the scoper of the new object is unknown and therefore can't be merged automatically with any other Role object.