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
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[category:RIMBAA Issue]]  
+
[[category:Closed AID Issue]]  
 +
 
 +
==FHIR Notes==
 +
Some aspects of this old RIMBAA item (phrased in terms of v3 classes) are relevant in the context of FHIR, notably FHIR Messaging
 +
*It describes a way to update contained (unidentified) resources based on the context of those resources
 +
*It discusses the requirement to capture context in a MessageHeader and Provevance resource
 +
*It discusses the role of Snapshot mode
 +
*A lot of issues are reminiscent of the issues discussed [http://www.ringholm.com/docs/04350_mapping_HL7v2_FHIR.htm here]
 +
*Grahame: as part of FHIR, we have to decide this. What's missing from that page is any connection of this to transaction boundaries.
 +
 
 
==Summary==
 
==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.
 
*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.
Line 6: Line 15:
  
 
==Analysis==
 
==Analysis==
*Ewout has taken the action item to write an analysis.
 
  
 
*In a real-world scenario one might assign more 'weight' to certain information from certain senders. Or to ignore 'demographics' sent by a Laboratory application. But then again: if the lab sends me stuff about a new patient (i.e. one unknown to me) it may be a best practice to import whatever demographics the lab is sending me. Or the receiver could decide to query the MPI for full details. But all of the above requires contextual knowledge (which senders are masters for what category of information) on the part of the object store.
 
*In a real-world scenario one might assign more 'weight' to certain information from certain senders. Or to ignore 'demographics' sent by a Laboratory application. But then again: if the lab sends me stuff about a new patient (i.e. one unknown to me) it may be a best practice to import whatever demographics the lab is sending me. Or the receiver could decide to query the MPI for full details. But all of the above requires contextual knowledge (which senders are masters for what category of information) on the part of the object store.
 +
*Certain senders may use 'Act References' - minimally populated objects (however: always with an ID which acts as a reference). An Act Reference should not be used to update an existing object, it purely exists for the purpose of identification/object merging.
 +
*When it comes to the identity of objects: two objects can be ''identical'' (same identity), or ''equal'' (same value). See [[Object identity|identity of objects]] for a detailed discussion; the identity of objects is a core issue when it comes to merging of object trees.
 +
*See also these articles on the merging of object trees: [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.4003]
  
*When it comes to the identity of objects: two objects can be ''identical'' (same identity), or ''equal'' (same value).
 
 
*See also these articles on the merging of object trees: [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.4003]
 
 
===example===
 
===example===
Below an example of three different object trees. The rectangles represent object instances, the labels (A, B, etc.) the business identifiers of the objects. Some objects don't have an identifier. M1 is a directed graph, serialized using starting point B. M2 is serialized using F as its starting point, M3 using G.  
+
Below an example of three different object trees. The dots represent object instances (note: RIM association classes are also shown as dots), the labels (A, B, etc.) denote the business identifier of an objects. Some objects don't have an identifier (e.g. most association classes). M1 is a directed graph, serialized using starting point B. M2 is serialized using F as its starting point, M3 using G.  
 
<br/>
 
<br/>
[[Image:Object_trees.PNG|250px]]
+
[[Image:Object_trees.PNG]]
  
 
Upon receipt of these three structures the receiver will 'merge' the information about one and the same object. Objects A, B and F appear in multiple object trees.
 
Upon receipt of these three structures the receiver will 'merge' the information about one and the same object. Objects A, B and F appear in multiple object trees.
 
<br/>
 
<br/>
[[Image:Object_net.PNG|200px]]
+
[[Image:Object_net.PNG]]
  
 
Note that the resulting object net is a directed graph, where links may be bidirectional in nature. Given the directed graphs (the object trees: M1, M2, M3) the object net, G links to B, and B links to F, but F doesn't link to B.
 
Note that the resulting object net is a directed graph, where links may be bidirectional in nature. Given the directed graphs (the object trees: M1, M2, M3) the object net, G links to B, and B links to F, but F doesn't link to B.
  
==Discussion==
+
===Merging based on known model constraints===
*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).  
+
Merging op object trees may use the fact that a known constraint can be used to identify (by means of their context) an otherwise unidentified object. See [[Object identity|identity of objects]] for detailed discussion.
**For Roles the situation is a bit of a muddle, because one doesn't know if the Role.id is a unique identifier of this single role instance, or whether it is an identifier used for a set of role instances. An example of the latter is a national identifier (e.g. SSN in the USA) to identify multiple roles. In those cases the identity of the role is based on the tuple (Role.id, 'Scoper') where 'Scoper' could be the Entity.id or the Entity.name of the scoping entity.
+
 
**This is especially relevant in the process of deciding when to 'merge' objects into an object net.
+
Below an example constraint model (CIM or LIM)
**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.
+
<br/>
**Example #2: a RIMBAA application persists an ''Observation with subject Patient 123 with scoping entity 'hospital A'''.  
+
[[Image:CIM object tree.PNG]]
**#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.
+
The image below shows two different object trees ('''m1, m2'''). If the receiver is somehow aware that both object trees comply with the constraint model shown above it has the ability to merge these object trees into the '''net1''' object net. If the constraint isn't known the resulting object net would be '''net2'''. The 0..1 cardinality on the participation allows the receiver to deduce that the two non-identified objects in the two object trees are one and the same 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.
+
<br/>
**As a consequence of the role identity issue described above (''this is an open methodology issue''), all RIMBAA applications, in order to decide if two roles are the same (one and the same object, just different versions of it) will have to build some kind of "role identity management component". Roles may or may not have an id, scopers may or may not be present, scopers may not have an id, the id may be specified via an IDENT role, the entity may have an ID whereas the Role it plays has not, the ID of the entity may have to be gleaned of another role played by the entity.. identity crisis, indeed.
+
[[Image:Merged net CIM constrain.PNG]]
 +
 
 +
So how does one know that (parts of) an object tree conform to a constraint model? The only way is to explicitly convey the Trigger Event (the ControlAct), the identity of the trigger event act, the time when the trigger event happened (to deal with temporal aspects of persisting objects) and the identifier of any constraint models applicable.
 +
<br/>
 +
[[Image:TE object tree.PNG]]
 +
 
 +
XXXX: an object tree may have multiple templates associated with it - open discussion item.
 +
===Snapshot Mode===
 +
 
 +
Interactions are effectively a ''snapshot''.  An initial laboratory results message (labeled TE1 in the figure above) may be updated by a final laboratory results message (labeled TE2); where the contents (in terms of classes instantiated and attributes used) of the final message could be different from the contents of the initial message.  
 +
 
 +
If both object trees are known to conform to one and the same R-MIM, the receiver should:
 +
#Undo any merging that it did upon receipt of TE1
 +
#*This requires that one persists the fact that certain objects are associated with TE1. It also requires that one has a temporal database to revert to a prior version of objects/attributes.
 +
#Merge the contents of TE2 with whatever objects the receiver already was aware about.
 +
 
 +
Note: if we were dealing with CDA documents [which have no Trigger Events] (where the document with ID TE2 replaces the document with ID TE1), the same principle would apply. Delete all objects/data sourced from the entries in the old document, and update using the entries in the new document.

Latest revision as of 19:56, 7 October 2015


FHIR Notes

Some aspects of this old RIMBAA item (phrased in terms of v3 classes) are relevant in the context of FHIR, notably FHIR Messaging

  • It describes a way to update contained (unidentified) resources based on the context of those resources
  • It discusses the requirement to capture context in a MessageHeader and Provevance resource
  • It discusses the role of Snapshot mode
  • A lot of issues are reminiscent of the issues discussed here
  • Grahame: as part of FHIR, we have to decide this. What's missing from that page is any connection of this to transaction boundaries.

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

  • In a real-world scenario one might assign more 'weight' to certain information from certain senders. Or to ignore 'demographics' sent by a Laboratory application. But then again: if the lab sends me stuff about a new patient (i.e. one unknown to me) it may be a best practice to import whatever demographics the lab is sending me. Or the receiver could decide to query the MPI for full details. But all of the above requires contextual knowledge (which senders are masters for what category of information) on the part of the object store.
  • Certain senders may use 'Act References' - minimally populated objects (however: always with an ID which acts as a reference). An Act Reference should not be used to update an existing object, it purely exists for the purpose of identification/object merging.
  • When it comes to the identity of objects: two objects can be identical (same identity), or equal (same value). See identity of objects for a detailed discussion; the identity of objects is a core issue when it comes to merging of object trees.
  • See also these articles on the merging of object trees: [1]

example

Below an example of three different object trees. The dots represent object instances (note: RIM association classes are also shown as dots), the labels (A, B, etc.) denote the business identifier of an objects. Some objects don't have an identifier (e.g. most association classes). M1 is a directed graph, serialized using starting point B. M2 is serialized using F as its starting point, M3 using G.
Object trees.PNG

Upon receipt of these three structures the receiver will 'merge' the information about one and the same object. Objects A, B and F appear in multiple object trees.
Object net.PNG

Note that the resulting object net is a directed graph, where links may be bidirectional in nature. Given the directed graphs (the object trees: M1, M2, M3) the object net, G links to B, and B links to F, but F doesn't link to B.

Merging based on known model constraints

Merging op object trees may use the fact that a known constraint can be used to identify (by means of their context) an otherwise unidentified object. See identity of objects for detailed discussion.

Below an example constraint model (CIM or LIM)
CIM object tree.PNG

The image below shows two different object trees (m1, m2). If the receiver is somehow aware that both object trees comply with the constraint model shown above it has the ability to merge these object trees into the net1 object net. If the constraint isn't known the resulting object net would be net2. The 0..1 cardinality on the participation allows the receiver to deduce that the two non-identified objects in the two object trees are one and the same object.
Merged net CIM constrain.PNG

So how does one know that (parts of) an object tree conform to a constraint model? The only way is to explicitly convey the Trigger Event (the ControlAct), the identity of the trigger event act, the time when the trigger event happened (to deal with temporal aspects of persisting objects) and the identifier of any constraint models applicable.
TE object tree.PNG

XXXX: an object tree may have multiple templates associated with it - open discussion item.

Snapshot Mode

Interactions are effectively a snapshot. An initial laboratory results message (labeled TE1 in the figure above) may be updated by a final laboratory results message (labeled TE2); where the contents (in terms of classes instantiated and attributes used) of the final message could be different from the contents of the initial message.

If both object trees are known to conform to one and the same R-MIM, the receiver should:

  1. Undo any merging that it did upon receipt of TE1
    • This requires that one persists the fact that certain objects are associated with TE1. It also requires that one has a temporal database to revert to a prior version of objects/attributes.
  2. Merge the contents of TE2 with whatever objects the receiver already was aware about.

Note: if we were dealing with CDA documents [which have no Trigger Events] (where the document with ID TE2 replaces the document with ID TE1), the same principle would apply. Delete all objects/data sourced from the entries in the old document, and update using the entries in the new document.