This wiki has undergone a migration to Confluence found Here

Query Expression and Execution Technology

From HL7Wiki
Revision as of 13:53, 4 October 2010 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

How does one query a RIM graph (memory or file) for pre-defined clinical criteria. Codes, values, ages, dates, AND, OR - the usual sort of things. There is a need for a query representation format, and then a tool to run those queries.

  • Ideally it would be:
    • Understandable by a non-developer or non-RIM expert. Some sort of query builder or parameter modifier may be needed that sits on top of one of the other query expression formats.
    • A standard of some sort
    • Possible get it working quickly, days rather than weeks



Grahame: OCL can be used directly. See [1] for discussion.

  • Rik: 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.

Rik: Doesn’t add much over OCL, not that that is any easier, but we could just use that instead of the Gello subset.


  • Pros: runs on anything, implemented already, if I serialize the data (or DOM it).
  • Cons: Not RIM aware nor datatypes aware. Not ITS agnostic but that isn’t really an issue.

Rik: 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). HPath is a better language (than XPath), since it shares the same intent but is properly tied to v3 semantics.
  • Cons: not well documented, needs the JavaSIG code integrating, might be hard for a non-JavaSIG based project. The javasig implementation is not generally useable. No support for recent MIFs nor data types R2.


Query By example (QBE) - express queries as Acts etc with isCriterionInd set to true.

  • Pros: It’s HL7
  • Cons: Complicated to express queries. No way to execute queries without writing your own engine.
  • NCI (Jean Duteau) are implementing QBE right now.
  • Bob: Another I would throw into the consideration mix is HQMF [2], 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.