View source for Safe querying of a RIM-based data model

[[category:Closed AID Issue]] 

==FHIR Notes==
This old RIMBAA item (phrased in terms of v3 classes) is probably still relevant in the context of FHIR.
*With FHIR it's very easy to create a Resource Repository (called an ''Object Net Repository'' below)
*Given the mainly RESTful nature of FHIR the burden would seem to be on the ''Query Placer'' to get hold of the appropriate subset of all of the available Resources.
**Some of the returned Resources may have been taken out of context (e.g. a FHIR document, a FHIR message) - guidance may be in order for a querying party as to ensure that the Resource set is clinically safe.
*Grahame: yeah, we made it safe: no context conduction across resources. I don't think this is resolvable in v3 / RIM context unless you nail conduction down on a per use case basis. But there's so many other problems with v3 as a genral reasoning tool that it doesn't seem important to me now

==Summary==
This page addresses the issue of "safe querying": 
*If one queries for 'relevant data' (however specified) and the source is an [[Object nets and object trees|object net]], then how does the responding application determine where to 'snip' the links? If one pulls an Act (e.g. observation) from the database which is at the core of the response, what other acts should one include in the response in order for the Act to be accurately securely semantically interpreted? If one doesn't snip any links then the entire net will have to be returned.

[[Image:Safe querying2.PNG]]

The analysis below uses the above Application Roles:
*Object net creator: the source of the object tree / object net
*Object net repository: the persistent archive for the merged object net
*Object net query placer: places a query for some subset of the object net
*Safe Template repository (a [[Model Registry]]): the persistent archive for static information models (including versions thereof) to which an object tree may claim conformance

==Analysis==
In general, there are three options when it comes to the determination what data is to be considered relevant in the context of the query:
#By the querying party (Object net query placer): 
#*If an Act is queried for, one could return the entire object net to ensure that all relevant semantics related to the Act are included in the response. The determination of the relevant subset is up to the querying party.
#*If a templateID for the response model were to be specified by the querying party the responding application would be able to respond with that exact subset (after retreiving the template definition from the template repository). Note that the same templateID may not have been used when the data was stored in the object net - the original object tree may have complied to another set of templateIDs. The data in the object net may be such that it doesn't conform to the requested templateId, in which case an error will result.
#**Note that templates may be open-ended (i.e. explicitly allow for additional attributes or associations beyond those described in the template class model, almost all LIMs are open-ended models) or closed (almost all CIMs are closed models). Both CIMs as well as LIMs (which in the context of RIMBAA applications amount to the same thing: a template). Querying using an open-ended template has the advantage that it standardizes the core set of classes in the desired response and the disadvantage that a lot of objects, related to the open-ends of the specified model, could be contained in the response. 
#By the responding party (Object net repository): If an Act is queried for, one could return a automatically determined subset of the data contained in the object net.
#*This could be done algorithmically by examining the direction and type of the Act's relationships.
#By the object net creator: if one stores an object net in the object repository ''jointly'' with a set of templateIDs (that are known by the object net creator to result in a safe subset) in the template repository. The querying party will have to use one of the specified templateIds if it wishes to ensure that the returned data is a safe subet. Other templateIDs may, or may not, result in safe subsets. 

The "safe template repository" has the capability to 
#identify templates that are safe, and 
#specify if an instance that complies with template X can be safely interpreted using a subsequent template X2; and if so, how the mapping (if any) between the two should look like. 

==Discussion==
*Bob Dolin: Related acts, context propagation, post-coordinated expressions, negationInd, etc - if not considered in a query, can all result in misrepresented data. I suspect some folks have a false sense of security when using templates, that by understanding the templateId they can safely process the data, even though there may be act relationships, etc.
*Bob Dolin: It makes me nervous when you (Grahame) state that you don't believe it should be the case that you need to understand all the components to safely interpret an act. Consider for instance that in CCD, we represent problem status (which includes values such as "ruled out") as a related act. Under what circumstances would you be comfortable basing decisions on an Act without looking at the (transitive) relationships?
*Grahame: I don't think you can safely ignore related acts. Though we could probably define some limitations to the impact they might make on the meaning of the code.
*Charlie McCay: It has never been robustly stated that you must process and understand all component acts to safely use act.code (indeed I do not believe that that is or should be the case) -- whereas it is clear that Snomed expressions can contain context modifying attributes (such as certainty and family history) - so if you can process an expression well enough to find the concept, you should know that just finding the concept is not enough. So not syntactic sugar - just clear processing rules for snomed expressions.
*Andy Harris: it depends on the context!, so basically all acts should be made available
*2010-01-19 Peter Hendler: I just met with Bob who said he noted that the way most vendors are querying RIM structures at HIMSS is error prone and dangerous.  It has to do with the fact that they do not take into consideration negation indicators or context conduction. He said our group (RIMBAA) is in his opinion one of the key groups now, and we would be the best ones to address this issue. He would like us to create a white paper about the correct ways to query RIM structures. Not down to the sql or hpath level as much as a white paper to show what can go wrong and how to avoid the pitfalls.  He wanted to come to our meeting but isn't free for Q2 tomorrow.  Brazil isn't a good idea because not many of us will be there, but next meeting in Boston he'd like to be on our schedule.
*2010-01-19 Grahame: As mentioned in Q1 MnM this morning, I volunteered to do this in the past. I agree that we need to progress this.