Thanks Thomas, that in fact seems to generate different nodeIDs for each analyte, thus avoids the querying issue.
BTW, to be generic is not a requirement on my side, just wanted to reuse what is published on the CKM, I can create specific archetypes per panel or analyte, but that approach seems to diverge from the editor's modeling style. But my idea is the same as yours: try to distribute pre-built OPTs for specific panels. I think I need to evaluate the cost of migrating to ADL2 since I see this as a blocker for 1.4 ADL and OPTs. Also I might need to adopt the workbench as modeling tools since there is no other tools available that can be installed easily or is open. Thanks! On Sat, Sep 15, 2018 at 6:22 PM Thomas Beale <[email protected]> wrote: > Pablo, > > I have also seen a need for queries that distinguish analyte level > objects, within the new lab archetypes. The original reason was to be able > to distribute pre-built panel templates (or even archetypes) to EMR (=PEP) > locations in Brasil, but your need is generic. > > This wiki page > <https://openehr.atlassian.net/wiki/spaces/healthmod/pages/91139266/Implementing+Laboratory+Tests+in+openEHR> > discusses the question; in this solution, you do create distinct archetype > paths, and use normal queries. IN ADL2, this can be done with templtes, > since templates are archetypes, and AQL works the same with them. The way > to do it in ADL2 is shown by the examples here > <https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/laboratory>. > If you load these archetypes you will see: > > The point here is that you can just specialise the eixsting > laboratory_test_analyte archetype into the specific analytes you want and > then template the group to get a panel. On the basis that probably 100-200 > analytes covers the vast majority of lab tests, I think this is > sustainable. > > I have not tried it in ADL1.4 / OET. > > - thomas > > On 15/09/2018 22:08, Pablo Pazos wrote: > > 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. > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- *Ing. Pablo Pazos Gutiérrez* [email protected] +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 [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
