Query Expression and Execution Technology
- Rik: I want to query in a RIM graph (memory or file) for pre-defined clinical criteria. Codes, values, ages, dates, AND, OR - the usual sort of things.
- Ideally it would be:
- Understandable by a non-developer or non-RIM expert
- A standard of some sort
- Possible get it working quickly, days rather than weeks
I’d like the queries to be readable to end users, but realise that this isn’t easy. Some sort of query builder or parameter modifier may be needed that sits on top of one of the other query expression formats.
There is obviously a need for a query representation format, and then a tool to run those queries. Although an off the shelf implementation would be nice, that is not really HL7’s department. I can see that I’m not likely to find an easy implementation of the main contenders, so that actually levels the playing field a little.
Grahame: You can use OCL directly. See  for discussion.
Constraint and the selection part of a query seem to be allied but different to me - I know I already lumped these together in the question but now I'm trying to tease out the differences. I imagine a set of OCL constraints annotating a model, but they could be too fragmented to constitute a query.
- Does anyone imagine firing off OCL queries and getting result sets/graphs back?
- Grahame: yes, an invariant is only a query that must have type boolean and is required to evaluate to true. In our own use we define a different binding called "query"
- so instead of context T inv: [expression which is of type boolean] it's context T query: [expression which returns OclAny]. I have this working against CDA, but not in a general v3 context.
Pros: on paper seems the ideal fit. A standard. Use cases shown recently on DSS list look similar to mine.
Cons: hard to implement, no off the shelf tools I can integrate with my own code, not widely adopted.
Doesn’t add much over OCL, not that that is any easier, but we could just use that instead of the Gello subset.
Q’s: what’s the current Gello in the ballot “Gello R2: OCL-Like” or “V3 Gello R1: OCL-Based”?
Pros: runs on anything, implemented already, if I serialize the data (or DOM it).
Cons: Not RIM aware or datatypes aware. Not ITS agnostic but that isn’t really an issue. Not integrated with any terminology (HL7 or otherwise, but then neither are any of the others, except maybe HPath for HL7 vocabs)
I see XQuery as a technology built mostly on XPath so would have some advantages if I was to make a lot of use of XPath but the same weaknesses (lack of model awareness, datatypes integration etc).
Normally I tend to "query" using XSL and XPath so have not really looked into XQuery much. I expect it is a better way to do XPath-like queries properly.
Pros: a better XPath for HL7, an implementation exists (JavaSIG)
Cons: not well documented, needs the JavaSIG code integrating, might be hard for a non-JavaSIG based project.
While it's true that javasig has an implementation of HPath - which is a better language (than XPath), since it shares the same intent but is properly tied to v3 semantics - the javasig implementation is not generally useable.
Qs: Supports datatypes R2 and recent coremifs?
“Raw RIM” - express queries as Act etc with EVN.CRT (or the post harmonization version of that), relationshipConjunction etc.
Pros: It’s HL7
Cons: Complicated to express queries. Not clear that it is possible to express complex queries. No way to execute queries without writing your own engine.
Q’s: does anyone really express queries this way?
Bob: Another I would throw into the consideration mix is HQMF , which makes heavy use of criteria (previously known as criterion mood). It kinda works like a Query By Example. One of the topics we're exploring with DSS in Cambridge is whether we should enable GELLO, ARDEN, etc in the <expression> field (e.g. where observation.value is data type EXPR_PQ).
Rene: Given the lack of constraint language tooling in SMD / Visio there is no way to predict what constraint language will prevail at some future point in time. My guess is that it'll be OCL. So right now the direction seems to be QBE + embedded OCL.