Modeling generic concepts, considerations for querying

Pekka.Pesola at tieto.com Pekka.Pesola at tieto.com
Wed Sep 27 03:28:48 EDT 2017


I agree that option 1 might not be the best. However if you have several templates for a specialty like psychotherapy keeping your queries in sync with templates being created does not sound practical. In Finland we have a national codeset for specialties which we include in every template. This allows us to do queries like “get me all clinical synopsis archetypes related to psychotherapy”.

-Pekka

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Bert Verhees
Sent: tiistaina 26. syyskuuta 2017 22.10
To: openehr-clinical at lists.openehr.org
Subject: Re: Modeling generic concepts, considerations for querying

I agree with this one. Option 1 would create a kind of forest of dependencies, many many archetypes in complex hierarchic systems, like SNOMED in the endnodes.
I don't think anyone would want this.

Option 2 is the option represents the power of OpenEHR.
By the way, SNOMED also supports higher hierarchical concepts, although this is not the question, I mention it because it is an interesting opportunity for coding more generic concepts and connect them to more generic archetypes.
I think, interesting algorithms are possible in finding specialization-possibilities and in template design
But I guess, that will be another discussion.

Bert


On 26-09-17 11:50, Jussara macedo wrote:
I also recommend to use option 2. The most powerful feature of the openEHR approach is to have the concepts builds as lego blocks, the maximum data, aiming they can   be reused in several scenarios.
That let out of the messy spaces of specialist systems, each one modeling their own vision of concepts. From a national governance perspective whose goal is to have a national repository, that is the preferred way of modeling.
Regards
Jussara Rotzsch


Em ter, 26 de set de 2017 às 06:25, Seref Arikan <serefarikan at kurumsalteknoloji.com<mailto:serefarikan at kurumsalteknoloji.com>> escreveu:
Hi Pablo,

I am not a clinician but as an implementer I see the benefits of less specific archetypes quite often. The fundamental role of archetypes is reuse. It is so by design and templates solve the problem of composition (in the object oriented sense, not the RM type).

I think the rule I try to follow when I think about the models is: when you're decreasing the reuseability of an archetype, you're taking a decision in a direction that is against the design of openEHR. Sounds a bit harsh, I know :) this is not a rule we can always follow but in your case I think using the template approach to define context and reuse the archetype in different contexts is a better option.

I think you'll see the benefits of focusing on archetype reuse as an implementer, even if you don't consider other parties reusing your archetypes: a case which Heather, Ian, Silje et.al<http://et.al>. are sensitive about since they keep an eye on the global state of affairs. If you go with templates, everybody wins :)

All the best
Seref


On Tue, Sep 26, 2017 at 2:52 AM, Pablo Pazos <pablo.pazos at cabolabs.com<mailto:pablo.pazos at cabolabs.com>> wrote:
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<tel:+598%2099%20043%20145>
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>


_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
--
Jussara Rötzsch Sent from Gmail Mobile




_______________________________________________

openEHR-clinical mailing list

openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


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


More information about the openEHR-clinical mailing list