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
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
