More generic reference model

Bert Verhees bert.verhees at rosa.nl
Sat Sep 3 12:34:19 EDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160903/90e834ef/attachment-0002.html>


More information about the openEHR-clinical mailing list