Context Conduction in RIMBAA Applications

Summary

• HL7 v3 contains a definition for Context Conduction. Particulary for RIMBAA implementations the support for this methodology is crucial - querying part of an object tree without knowing what conducts where could lead to real problems. For example: if you want to pull a subset out of a object hierarchy - you'll have to first determine the conducted context to the subset, before actually creating the subset.
• Related: Context Conduction in cyclic RIM graphs, Object nets and object trees.

Analysis

There seem to be two options when one received a serialized v3 model in a RIMBAA context:

1. on import: denormalize the conduction, i.e. replicate the conducted context (participations, act relationships) where appropiriate. The RIMBAA application (except when importing/exporting the data) is agnostic as to the meaning of context conduction. Resembles [forward chaining]
   • If you don't import data that often, but execute a lot of queries on the data, it may be better (in terms of performance) to deal with it before persisting the data.
2. at query time: deal with the conductivity at 'run-time', i.e. whenever a query is made determine what conducts and include that in the response. Resembles [backward chaining]
   • If one imports lots of data, but doesn't execute a lot of queries, then it may be better to deal with it whenever the query is executed (at the price of having to do additional joins).

• What are the advantages/drawbacks of these two options? Who has chosen to use what option?

Peter, February 1, 2010:

• I wonder if it would be possible, instead of context conduction going forward (distal to the ActAssociation or Participation where it is first defined), to go backwards. By that I mean that every distal ActAssociation or Participation would be required to have a new attribute that identified the Object that it gets it's context from.
• Currently, if you are trying to find the context of a distal object, you have to traverse up the tree (proximally) until you find some ActAssociation AA or Participation P where the context is defined. You don't know how high up you have to go, and if it is and acycic graph it causes even more problems knowing how to find the context.
• Wouldn't it be nice if for any AA or P you would have an attribute that was the object ID for the proximal AA or P where it's context was defined? In a database you could just go right to the defining AA or P and get the context.
• Of course this would require a new optional attribute for AAs and Ps. If they were not added to the RIM, then I suppose a best practice for RIMBAA databases would be to add this as a column in any AA or P tables.

Rene: The big question is: is conduction limited to a snapshot of a particular sutuation (a snapshot of an object tree), in which case 'denormalization upon import in a RIMBAA application' is a valid implementation, OR is context conduction a long-lived semantic thing, i.e. if one specifies that all participations conduct from Act1 to Act2, does that also mean all participations that are added to Act1 (even if the obect tree in question doesn't use nor mention Act2 at all) at any any future points in time? In the latter case the denormalization-upon-receipt method won't work.

Discussion

• Upon import is the safer option. If one receives lots of 'overlapping object structures' it may not always be able to reconstruct the 'correct' context at query time. See also the Safe querying of a RIM-based data model issue.
• Does one need 'historic snapshots' at query time, or a set of business objects? That also impacts the choice. See also the Temporal aspects of RIMBAA databases issue.

Java SIG Reference implementation

Peter Hendler: I added some context conduction to the javaSIG API.

Example: In a CDA you have the "subject of record" way at the top of the document. Then you go down Component StructuredBody Component Section Entry and finally you get to ClinicalStatement. By the time you get there in a CDA, you are far away from the "Author" and "Subject of Record". But because of context conduction it is assumed that since you didn't over ride these from the very top of the graph, they still hold. When you literally lay these down into a RIMBAA database. Then in your Act Table you have an Observation. But to find the patient who that Observation is for, you must do backward joins all the way back to the ClinicalDocument Act, and then from there you have to join RecordTarget to get to PatientRole where the Patient.ID lives.

Context conduction copies this "context" information and puts it in the optional "subject" and "author" ActRelationships that are directly connected to the Observation in the ClinicalStatement. The result is if you do this in memory before you lay the graph down into the database tables (called option 1 in the above discussion), then when you query you can do far fewer joins. What we found is that the time it takes to do this in memory before laying the graph down in the database takes as much time as it does to do all of the joins. So it's pay up front (option 1) or pay as you go (option 2). Gunther thought he could do a more efficient context conduction algorithm than the one I did that wouldn't take so long. But he's found that it's really not so bad to do the joins. Once you have the SQL or HQL it can be a stored or named query and it's no big deal.

It's been a long time but I think we conducted everything (=full support for all elements of context conduction as defined in v3). We collected Context as we went down and we pasted context where it was missing. The application doesn't track whether or not an association is acquired by context conduction.

MnM Hot topic discussion 2010-01-19

Discussion of the 'new' way to deal with context conduction:

• Rene: 80-90% of useful context conduction is participations author/subject/performer. Ernst agrees.
• Charlie: need an easy option to switch it off.
• Could tie conduction to association_type, e.g. no conduction on Refers, reasonOf. Lots of work to specify conduction for each and every association type. Lloyd: There's probably only 10-15 that we really want to conduct (by default; things that can conduct, do conduct by default). Plus option to switch conduction off for certain things in an act relationship. e.g. excludeConductionType attribute SET<CS> [0..*] on associations (we probably need two attributes, one for associations, one for participations).
• MnM will work on a detailed proposal.
• Rene: In essence this doesn't change the way how conduction works (as an abstract concept), but it does provide a different way/system of dealing with it. This new option leaves less choice to the implementer by having defaults. Which is probably a good thing. For RIMBAA implementers this new option leads to much more deterministic information about conduction