Modeling generic concepts, considerations for querying

Pablo Pazos pablo.pazos at cabolabs.com
Sun Oct 1 03:35:04 EDT 2017


Everyone, thanks a lot for all your comments and feedback.


@Lars, yes both things are not exclusive, but modeling small archetypes
makes template ids not needed at the query level.

I agree with your point of the difficulty of keeping track of templates in
queries, since at some point we might want to share queries between
different implementations of the same tools or even different vendors.


@Heather, that way of modeling is very nice since it works on v1.0.2, just
to rephrase: you propose to use COMPOSITION.name to be DV_CODED_TEXT on
instances defined by the COMPOSITION.encounter archetype. On this case,
there is not need of a filter by template id since it can be done directly
by the codeString.

I mentioned DV_CODED_TEXT on purpose here because I don't think searching
by free text names is a robust solution, mostly considering
internationalization of systems.


@Ian +1.

For all, we are discussing about a composition classification attribute to
be added to the RM, something that is already on CDA and FHIR (classCode)
but we don't have, it is used in XDS environments, and can be used for
querying. Is a concept that can group many templates. DIPS implementation
has something like this in software.


@Diego I think we need to look into the LOINC direction for "composition
type" codes, and hopefully try to find SNOMED mappings. On the other hand,
looking at XDS they say these codes should be coordinated by the affinity
domain members. This is orthogonal to my question, but might also help to
solve queries.


@Silje I agree with the governance problem of creating a lot of archetypes,
but I'm not sure if that can make querying more unpredictable, since
querying would be more specific since there are more specific archetypes
for each context.

Thinking about governance horrorfest, maybe the problem is not really
having a lot of levels of archetype inheritance/specialization, but that
current modeling tools are not prepared to handle that workflow and do
things automatically to check consistency, auto update dependencies,
release full updated specialization hierarchies when one of the most
generic archetypes changes, etc.

On AQL I couldn't find one example that actually uses a template id as a
filter or criteria. Not sure if this is even supported or if it's just an
scenario that wasn't considered when creating the specs. Maybe AQL
implementers can give some light on this area.


@Seref, +1. Please check last paragraph ^, I think we might be missing the
use of template ids on AQL.


@Pekka, I think that goes in the lines of having that "classCode" attribute
added to the RM (mentioned on @Ian), or modeling it in
COMPOSITION.context.other_context (might be done by COMPOSITION.encounter
archetype specialization or be resolved to an ITEM_STRUCTURE archetype on
the template), or having COMPOSTION.name<DV_CODED_TEXT> (mentioned on
@Heather).



@Thomas, I'm far for ADL2 support yet :)



Thanks all, this is why I love this community <3


On Sat, Sep 30, 2017 at 5:18 PM, Thomas Beale <thomas.beale at openehr.org>
wrote:

>
> In ADL2 it doesn't really matter. THe only difference is that in an ADL2
> template, specialisations are local 'overlays' inside the patient template,
> rather than distinct archetypes in the archetype library.
>
> In which case, you should specialise with archetypes as long as the
> archetypes are likely to be reusable; when they are not, it would make
> sense to further specialise by the use of overlays in a template.
>
> All this is moot for people still using ADL1.4 tools ...
> - thomas
>
>
> On 26/09/2017 02:52, Pablo Pazos 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
> p: +598 99 043 145 <099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
>
> _______________________________________________
> openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pazos at cabolabs.com
p: +598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.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/20171001/7aa10e4a/attachment-0002.html>


More information about the openEHR-clinical mailing list