Modeling generic concepts, considerations for querying

Bakke, Silje Ljosland silje.ljosland.bakke at nasjonalikt.no
Tue Sep 26 05:22:50 EDT 2017


Hi all!

I agree with Heather, making even just a subset of the generic archetypes context specific will lead to governance horrorfest, both on the CKM level and for each application/vendor. I imagine it also could make querying for specific clinical concepts across different clinical contexts more unpredictable?

To me, who’ve never used AQL for anything practical, but who do archetype governance every day, this seems like a no brainer. Is there something about AQL that makes including the template in the query harder?

I know there’s an argument going around for making specific COMPOSITION archetypes for each clinical context, and while this is certainly less terrifying than doing it for each ENTRY archetype, it will lead to the same kind of governance monstrosity in the end. I think, like Ian pointed out in his reply, that terminology coding of composition names in templates could be a governable way to handle this problem.
Regards,
Silje

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Heather Leslie
Sent: Tuesday, September 26, 2017 10:56 AM
To: For openEHR clinical discussions <openehr-clinical at lists.openehr.org>
Subject: RE: Modeling generic concepts, considerations for querying

Hi Pablo,

The modeller’s dilemma!

If you make clinical synopsis more specific then how many variations will there be in the end? We will end up with zillions of variations of all the generic archetypes which will be an absolute governance nightmare.

I would prefer to see the queryable filter made at the template level – even as simply as using the COMPOSITION.encounter inside a ‘Psychotherapy consultation’ template. Use that template within all of the Psychotherapy consults for that app consistently.

Then query for the EVALUATION.clinical_synopsis across all templates that contain the COMPOSITION.encounter which has specifically been renamed to ‘Psychotherapy consultation’.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Pablo Pazos
Sent: Tuesday, 26 September 2017 11:52 AM
To: For openEHR clinical discussions <openehr-clinical at lists.openehr.org<mailto:openehr-clinical at lists.openehr.org>>
Subject: Modeling generic concepts, considerations for querying

Hi all,

I'm working with the clinical synopsis archetype, using it to model very open psychotherapy notes. The difference of that archetype from, for instance, blood pressure, triage, problem/diagnosis, is these archetypes are more or less very specific concepts, while synopsis might be used in many contexts, by different specialties, to save different kinds of data. The synopsis itself is a very generic concept.

Considering querying for a synopsis, I think queries should consider the context, not only the archetype id. For instance if I want the psychotherapy notes instead of other kinds of clinical synopsis, some extra data should be given in the query.

I can see two ways of doing this, with more 1. specific archetypes or 2. using templates to filter the query results. 1. means the synopsis archetype might  be specialized to synopsis-psychotherapy, so queries can use that new archetype id. 2. at the template level using the synopsis archetype, and the template is for psychotherapy. This implies the template id should be used on the query as context/filter.

What alternative do clinical modelers see as more correct?

I like specializing archetypes because we can keep queries simple, but we might end up with a lot of archetypes. Using templates makes queries more complex, but we don't need more archetypes for specializations.

Thanks!

PS: please let me know if this doesn't make sense :)

--
Ing. Pablo Pazos Gutiérrez
e: pablo.pazos at cabolabs.com<mailto:pablo.pazos at cabolabs.com>
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>


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


More information about the openEHR-clinical mailing list