Query recursion

Within the Choose and Book domain of the NHS CFH project, a requirement has been identified to allow dynamic recursion of queries. The topic was raised at the HL7 UK Infrastructure meeting on June 14th, 2006 and the consensus of those present at that meeting was that the current query mechanism is not sufficiently flexible to do what Choose and Book message designers need it to do.

A Query Modelling Presentation was given at the UK Infrastructure meeting, and includes a summary of the business requirements, an explanation of why we believe the current mechanism doesn't work, and our proposed solution - namely introducing the concepts of choice boxes and recursion to the query mechanism in order to dynamically process nested queries (examples are given in the presentation).

Comments/questions/suggestions on regarding this modelling problem are requested and would be gratefully received either here on the Wiki or via the message lists.

recursion may be an option (although it may allow for monstruous queries that are effectively non implementable..) Suggest to also have a look at option 3 using a new "blue" relationship class that in itself need not have an attributes instead of the COMP act relationship or an act based CMET (in short: when in blue class country, stick to existing and/or new blue classes). If this is turned into a proposal you'd have to show how the RIM would have to be changed... Rene spronk 11:19, 15 Jun 2006 (CDT)

Are there other options? I would agree that a new "blue" relationship would be the better way to go. COMP was only used to demonstrate the kind of functionality we were talking about as people will be familiar with it. Ian

It would be up to you to define "new" options, i.e. new blue classes. You know what you need in terms of use-cases.. Rene spronk 08:05, 19 Jun 2006 (CDT)

Thanks Rene, what is the process for making a proposal for this? And is it something that we should take to InM in September? Ian ian.townend@cfh.nhs.uk

Just put the "new" model in a Word document or on the Wiki, and inform INM that you'd like to have it discussed and approved. INM can then take it up on a teleconference or during the next WGM, depending on in how much of a hurry you are.. Rene spronk 00:02, 20 Jun 2006 (CDT)

We will put that together then. Could I request that some time be allocated at the next WGM for discussion? That will give us plenty of time (as we're quite busy at the moment) and I think it would be better if we were there and able to discuss it. Thanks. Ian

I'd like to encourage you to create something before the WGM and discuss it on a teleconference. That way initial feedback can be given and a more finalized version can be discussed during the WGM. Note that the area of the RIM you're intending to change doesn't have a desription nor a domain nor any implementations. This is going to be a lot of work on your part to specify all the missing artefacts. All of which needs time to be discussed. Rene spronk 05:33, 3 Jul 2006 (CDT)

---

You say, "It is the nested logical statements which pose a problem as the query mechanism does not allow for recursion (i.e. a RelationalExpression cannot have a component which is a RelationalExpression)." I don't understand. You nest using LogicalExpression. I don't see what it is that you can't do. Of course, if you remove the nesting, as you show in your choices, then you can't nest - that's what you are saying. But you can just leave things as they are in the RIM, and there's no issue? Or have I missed something? Grahame Grieve 18 Jun 2006 (CDT)

Yes, you can nest using LogicalExpression but you have to explicitly model what level of nesting is required. We can't say any way of doing it dynamically. We don't know how many levels of nesting will be required so can't model it explicitly. How can this dynamic method be done currently? Ian