On 03-09-16 18:17, Thomas Beale wrote:

Bert,

doing most of what you want should come in AQL, e.g. the following in a WHERE clause is already possible.

SELECT
e/ehr_status/subject/external_ref/id/value, diagnosis/data/items[at0002.1]/value
FROM
    EHR e
        CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1]
CONTAINS Evaluation diagnosis[openEHR-EHR-EVALUATION.problem-diagnosis.v1]
WHERE
    c/name/value='Current Problems'
AND diagnosis/data/items[at0002.1]/value/defining_code *matches* { http://snomed.info/id/42570301000090487|cancer Dx refset|}

That is a very OpenEHRish way to do it, is comparing the code.

But what if you also want to find the subtypes, lungcancer (30 sub-types), etc, if you want to know about SNOMED attributes. For that purpose is the Expression Constraint language, and you need to query the terminology to know what you need to compare your data with.

The best way to do it is not invent another way to do it, but embed that language.
http://doc.ihtsdo.org/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf
When that is done well, you have the full power in one move.

One interesting question is whether 'inline' refset definitions would be allowed, e.g. using the SNOMED constraint grammar. We probably should add this to AQL as a plug-in syntax, since IHTSDO standardised it <http://doc.ihtsdo.org/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf>. What the solution is for ICDx I don't know.

I don know either.

There is more then just a plugin which does some separate work. Because the ECL also works on subtypes and attributes, and the attributes are not available. AQL must deliver them to the SNOMED engine, because they are on another path. There is code infrastructure needed.

For example: Find systolics higher then 165, in the archetype the type of the measurement can be in another element then the value of the measurement. This mapping between SNOEMD attributes and where they are in the archetypes must be done in some elegant way.

The main thing to understand is that if a SNOMED or ICD code for say leukaemia is found in EHR data, the code alone doesn't tell you the epistemic status, i.e. the kind of statement being made - i.e. current diagnosis, no risk of, risk of, fear of ... etc. Querying properly means understanding where in the data you are looking, and the archetypes help with that.

That will be one of the added values of archetypes.

Bert
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Reply via email to