Modeling generic concepts, considerations for querying

Bert Verhees bert.verhees at rosa.nl
Tue Sep 26 15:10:25 EDT 2017


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
>         	<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
> 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/20170926/71756821/attachment-0002.html>


More information about the openEHR-clinical mailing list