My original concern – possibly misguided – with using ‘let’ the way you suggest was a feeling that with a large and complex data base it might lead to unneccessarily long response times or overflow conditions somewhere, or both.
The operational system we have in mind currently contains about 172,000 anonymous patient records with an average size in XML of more than 13 kb, based on a sample of 500 records, and grows at the rate of 25 records per day, seven days a week. I have been trying to demonstrate the use of QUIP for nine samples selected from our files of more that 200 actual searchs conducted during the last two years.
The problem at hand is the following:
Find the total number of elective and emergency primary and re-op isolated coronary- artery-bypass-graft (CABG) patients between 1990 and 1993, and the mean red blood cell units (RBC’s) used per patient each year. (Primary means first open-heart surgery, re-op means any open-heart surgery after the first one, isolated means no other procedure performed at the same time as the bypass.) Data are to be presented in three groups:
1) Elective (anyone that is not an emergency) Primary Isolated CABG
2) Reoperations (elective or emergent) Isolated CABG
3) Emergent Primary CABG
Combine the Intra and Post-Op RBC’s and list the mean units per patient for each year. (The Intra and Post-op units are stored in the XML data model as separate sub-elements under the complex element , which is located at the 6th level in the hierarchy. I expect to flatten this out somewhat in the next prototype design.).
At a detail level we are completing the following table.
—Average RBC’s per patient–
Year 1990 1991 1992 1993
Group 1 x x x x
Group 2 x x x x
Group 3 x x x x
In addition to the detailed data requested we are usually also expected to provide a set of base data about each of the patients in the selected group. This includes items like birth date, ***, prior diagnoses for certain conditions, prior blood test results, status as a smoker, etc. It is therefore unacceptable to retrieve detailed data without the ability to retrieve other associated patient-specific information.
My approach to this problem was to begin with:
for $b in collection (“Demo500”)/PatientRecord[./EpisodeOfCare/TherapeuticProcedures/Surgery[./@SurgeryDate > “1989-12-31” and ./@Surgery < “1994-01-01”]/RevascularizationProcedure],
$c in $b/EpisodeOfCare/Management/TherapeuticProcedures/Surgery[./@SurgeryDate > “1989-12-31” and ./@SurgeryDate < “1994-01-01”][./RevascularizationProcedure]
($b contains complete patient records, $c contains only the surgical details for those operations which included revascularization (CABG).)
I would retrieve the same set of patients and the same set of operations if I said:
let $b := collection(“Demo500”)/PatientRecord???.. ,
$c := $b/Episode???..
Next, to identify the operations that were isolated CABG, I started adding conditions in a where clause. For example,
for $b in collection (“Demo500”)/PatientRecord??? ,
$c in $b/Episode???.
where empty($c//ValveReplacement)
continues to produce a correct (but shorter) list of patients and procedures, while
let $b := collection (“Demo500”)/PatientRecord??? ,
$c := $b/Episode???.
where empty($c//ValveReplacement)
does not produce any output at all.
To complete the query I still have to specify six more empty conditions, divide the results into twelve sets (three groups x four years), and calculate the required averages for each set, including the fact that any given operation may have both intra-op and post-op numbers that have to be taken into the same average.
Bill
#webMethods#API-Management#Tamino