Hi all,
Lately I've been working a lot with lab test reports. Current CKM modeling
for this relies on a generic model that applies to any kind and structure
of result in this way:
- COMPO.report-result // any result document
- OBSERVATION.laboratory_test_result // results container, can be used
as a panel
- CLUSTER.laboratory_test_analyte // single result
This kind of generic model relies on specific structures to be set at
runtime, and also to use specific codes to know which type of result is
contained in the analytes (which remembers me of the way CDAs are modeled).
*An example*
For a lipids panel result, which contains analytes for cholesterol,
triglyceride, HDL and LDL, we need systems to create that structure and use
specific codes like:
- COMPO
- OBSERVATION
- CLUSTER = cholesterol, LOINC::14647-2
- CLUSTER = triglyceride, LOINC::14927-8
- CLUSTER = HDL, LOINC::2085-9
- CLUSTER = LDL, LOINC::39469-2
That is 4 occurrences of the same CLUSTER, and inside each CLUSTER, the
same ELEMENTS (name, result, comment, etc).
*Issues for querying*
Now if we want to query that structure, we need to rely in the codes
instead of in the structure, because the structure is set at runtime not at
design time. So If we need the COMPOs that have cholesterol > 10 mmol/L we
need a query like this:
SELECT ...
FROM ..., CLUSTER[CLUSTER.analyte] c
WHERE c/path_to_code = 14647-2 AND c/path_to_magnitude > 10 AND
c/path_to_units = mmol/L
*What's the problem with that query?*
If we have instances like this:
- COMPO
- OBSERVATION
- CLUSTER = name=cholesterol, code=LOINC::14647-2, value=6.3 mmol/L
- CLUSTER = name=triglyceride, code=LOINC::14927-8, value=12.3 mmol/L
- CLUSTER = name=HDL, code=LOINC::2085-9, value=2.0 mmol/L
- CLUSTER = name=LDL, code=LOINC::39469-2, value=1.5 mmol/L
c can be any of the 4 CLUSTERs set at runtime since all of them are
occurrences of the same node defined in the archetype and the correspondent
OPT. So when comparing the code, value and units that can match values from
the other CLUSTERs, so we need a way to ensure those paths have the same
instance parent, and that can't be done with archetype paths.
So the query above might find the code 14647-2 in the first CLUSTER, but
check the magnitude against the second CLUSTER that is > 10.
The issue goes away if each CLUSTER can have a specific nodeId that
complies with the specification on the archetype but is really an instance
nodeId.
Another solution might be to add some kind of extra expression to the AQL
to say "these paths should be under the same parent instance".
But the simplest would be just not to have generic models, so the "lipids
panel" archetype would have 4 CLUSTERs each with it's own nodeId, so when
querying, the paths are pointing to different CLUSTERs and they contained
ELEMENTs.
Not sure how others solve these cases, would like to hear if you use these
generic models, how to query them without these issues, or if you just go
with specific models.
Thanks.
--
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
