Re: Generic modeling and issues for querying

[Thomas Beale]

On 15/09/2018 22:45, Pablo Pazos wrote:
Thanks Thomas, that in fact seems to generate different nodeIDs for 
each analyte, thus avoids the querying issue.


right. The key is that it is done in specialisations - so the querying 
in the generic form based on the generic archetypes will still work, 
including with LOINC codes. I did not show how to include LOINC codes 
directly in the specialisations, but that could be done.




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.




that will be a short term state of affairs - the new Archie tool can 
read all these archetypes, but the UI is rough for now (but probably 
good enough for a techie like you ;)
Also, the soon-to-be-released Marand ADL-designer Mk2 will (I believe) 
have an ADL2 parser added at some stage, since it is AOM2 internally.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Generic modeling and issues for querying

[Pablo Pazos]

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 
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
> 
> 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
> .
> 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 

Re: Generic modeling and issues for querying

[Thomas Beale]

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 
 
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 
. 
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Generic modeling and issues for querying

[Pablo Pazos]

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://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

Re: What's the correct XML in an OPT for multiple terminology references?

[Pablo Pazos]

Just remembered children of attribute can handle multiple alternatives,
while this is syntactically correct I'm not sure if the alternatives can be
of the same object type:



defining_code
  

  
  
CODE_PHRASE

  



*terminology:LOINC*
  
  
CODE_PHRASE

  


*
terminology:SNOMED-CT*
  


On Sat, Sep 15, 2018 at 2:56 PM Pablo Pazos 
wrote:

> Hi,
>
> I'm having trouble generating OPTs (1.4) from archetypes that reference
> multiple terminologies from a DV_CODED_TEXT.
>
> For instance, I have a coded node that will be coded by LOINC or
> SNOMED-CT, that can be set in the archetype. But when exporting the OPT
> from the Template Designer, only LOINC appears in this way:
>
> 
>  CODE_PHRASE
>  
> true
> true
> false
> false
> 1
> 1
>  
>  
> * terminology:LOINC*
>
>
>
> Now, looking at the OPT schema (I think I got it from the TD), it says the
> C_CODE_PHRASE only can have one *referenceSetUri* element, so it is not
> possible to add more elements with other terminologies.
>
> So, how can we put many terminologies on the OPT?
>
> Should that be multiple values in that element? like this:
>
> *terminology:LOINC
> terminology:SNOMED-CT*
>
> (that looks ugly and I don't think is valid)
>
>
> I'm surprised to find this simple case can't be supported by tools or the
> OPT format itself. Any tips are welcome.
>
>
> Best,
> Pablo.
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter 
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
>
>

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

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

What's the correct XML in an OPT for multiple terminology references?

[Pablo Pazos]

Hi,

I'm having trouble generating OPTs (1.4) from archetypes that reference
multiple terminologies from a DV_CODED_TEXT.

For instance, I have a coded node that will be coded by LOINC or SNOMED-CT,
that can be set in the archetype. But when exporting the OPT from the
Template Designer, only LOINC appears in this way:


 CODE_PHRASE
 
true
true
false
false
1
1
 
 
* terminology:LOINC*
   


Now, looking at the OPT schema (I think I got it from the TD), it says the
C_CODE_PHRASE only can have one *referenceSetUri* element, so it is not
possible to add more elements with other terminologies.

So, how can we put many terminologies on the OPT?

Should that be multiple values in that element? like this:

*terminology:LOINC terminology:SNOMED-CT*

(that looks ugly and I don't think is valid)


I'm surprised to find this simple case can't be supported by tools or the
OPT format itself. Any tips are welcome.


Best,
Pablo.

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

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