More generic reference model

Thomas Beale thomas.beale at openehr.org
Sat Sep 3 12:17:11 EDT 2016


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

Where the final bit stands for a SNOMED refset containing all cancer 
diagnoses. Here the existing 'matches' operator to means 'member of 
set', i.e. in the ref-set. This query would return an EHR patient ref 
and a diagnosis for every EHR that contains a cancer diagnosis, i.e. all 
'cancer patients' (obviously it would need to be refined to be useful, 
e.g. current in- plus out-patients or Dx in last 10 years etc)

As far as I know this syntax is covered by the current AQL specifiction. 
However the semantics may need refinement.

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.

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.

- thomas

On 02/09/2016 09:55, Bert Verhees wrote:
> On 02-09-16 16:45, Thomas Beale wrote:
>>
>> Actually SNOMED did exist when we designed the openEHR RM, and even 
>> if today's SNOMED CT had existed we would have done pretty much the 
>> same thing I think. The Observation model for example is a structural 
>> model of time series data, adapted to direct software use. Trying to 
>> use SNOMED to code all that would be painful, and contrary to what 
>> SNOMED is for.
> Blood pressure is not such a good example. Better examples are 
> concepts with much hierarchy or other relationships/attributes connected.
>
> I am not sure what you mean by using SNOMED for coding. Of course 
> SNOMED can be used for expression constraints, for example, to create 
> an expression which indicates a systolic higher then 165. The 
> expressions could be embedded in AQL if it would be ready for that.
>
> Another expression would constrain: Does the patient have a specific 
> disease, or one of the twenty diseases which have an "is a" relation 
> with that disease, and then with a specific attribute and a specific 
> value, etc..
> Also for datamining and population care this would be good.
>
> An example is always dangerous, because, the wrong example does not 
> mean that the argument is wrong, but the example can become argument 
> of discussion. But I try anyway.
>
> Find all patients which had a form of cancer with a specific attribute 
> or one of the child forms of that cancer and a specific therapy or one 
> of the twenty therapies which are a child-form of that therapy, this 
> is maybe not easy to do in OpenEHR right now.
>
> It might be possible that the archetype-structure in which different 
> cancers are describes have a different structure for different 
> cancers, so it is not on a steady path where you can find 
> characteristics about that disease. Same counts for the therapies
>
> And it would be nicer if the query could be embedded in AQL.
>
> So, in my opinion, you need equally formed archetypes for different 
> diseases, especially if they are in the same clinical hierarchy, so 
> you can find clinical attributes of that disease-hierarchy and 
> terminology codes on the same node-Id's and in the same structure.
>
> Maybe a hospital thinks about that when designing archetypes, and is 
> doing a good job, but the concept does not enforce this good job.
> On the contrary to SNOMED which is well guarded by IHTSDO
>
> OpenEHR could profit from that.
>
> Maybe there are better ideas to integrate SNOMED better in OpenEHR?
>
> best regards
> Bert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160903/21994498/attachment-0002.html>


More information about the openEHR-clinical mailing list