Modeling generic concepts, considerations for querying

Clinical (archive)
1

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 :slight_smile:

2

Hi

I prefer modelling with specialized and small archetypes, this way I may choose to query across templates (contains [openEHR.EHR.OBSERVATION.whatever.v1]) or ask for the template/specific composition if the context is important.

So, your model method 1 does not exclude using queries method 2, but choosing modelling method 2 makes queries model 1 harder in my opinion. For this reason, I prefer model 1.

Best regards

Vennlig hilsen

Lars Morgan Karlsen

Seniorkonsulent

DIPS ASA

8037 BODØ

Mobil (+47) 900 54 284

Tlf: (+47) 75 59 20 00

http://www.dips.no

Denne meldingen er bare ment for mottakeren, og kan inneholde fortrolige opplysninger eller annen privat informasjon.

Hvis du mottar denne ved en feil, vær så vennlig å varsle avsender og slett meldingen.

3

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

4

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

5

I agree with Ian that we should probably use a real ‘coded’ approach? I believe HL7 uses Loinc for that. Spanish MoH has also proposed snomed terms for each entry in the national archetypes. Maybe we can explore something like this before trying to create our own pseudoterminology

6

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.

7

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 :slight_smile: 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. are sensitive about since they keep an eye on the global state of affairs. If you go with templates, everybody wins :slight_smile:

All the best
Seref

8

Hi due to

We developed a UK oriented termsrt as the LOINC based list used by HL7 CDA was too US oriented but the principle is identical. We will probably apply the term to composition name/value which allows mappings rather than the templateid. Both are available to AQL

Ian

9

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

10

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

11

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

12

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
13

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 :slight_smile:

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

14

Hi Thomas,

in Germany, we really would like to start our “green field” project using ADL 2 for reasons like this. We would highly appreciate if the official governance tools of the openEHR Foundation would start to support ADL 2 very soon so that we don’t have to migrate eventually.

Best,

Birger

15

well the AOM2 and ADL2 specifications are already official. And the ADL Workbench implements the whole standard, so it’s possible to compile (and somewhat edit, in a graphical mode) ADL2 archetypes and templates.

Secondly, the forthcoming new release of the ADL-designer from Marand is based internally on AOM2 but with some missing elements, because the current aim is to support .oet templates. So a bit of incremental effort is needed to add the final ADL/AOM2 facilities like ADL2 templates, ADL2 save, OPT2 and so on. There are new libraries available in openEHR to do this with, and we have an Antlr4 expression of ADL2/ODIN to help.

It is the persistent repository that is the real question. It depends on which one your project will use. If it is an open source implementation, it may be that you need to work with the developers to add in support for ADL2. This isn’t as hard as it sounds, because what needs to be supported is primarily OPT2 templates - i.e. an EHR system doesn’t import raw source form ADL2 archetypes, but fully compiled templates.

The other area of modification is the query processor, but this should be incremental changes over any currently available AQL processor.

Your project may well be the first one to seriously move to ADL/AOM2 in the EHR system space. I think if you go that way, you will get a lot of help from the community, but you will also need to figure in a certain amount of developer time from your team as well.

  • thomas
16

I forgot to mention that we will probably (almost certainly) upgrade the structure of terminology bindings to allow more meta-data, and we will probably upgrade the annotations to allow more data types. Technically speaking, both of these are breaking changes, but as ADL2 is not in use outside of HL7 CIMI right now, I think we can cheat slightly on the usual version rules. If not, then we will have ADL3 :wink:

These two changes are easy to accommodate programmatically, so it will be no big deal in terms of impact.

  • thomas
17

Hi Thomas,

sorry for the late answer, I just came back from my vacation. For our project, we would certainly like to start with commercial openEHR repos for the larger sites. From my understanding, most products of the bigger openEHR vendors are ready for ADL 2. If I'm wrong on that, we need to reconsider this demand. The reason why we would like to use ADL 2 in particular is its improved handling of specialization which we think will be very important for our project.

Can you elaborate a bit on what would need to be done by our local devs?

Thanks and cheers,

18

The ideal is certainly to have a model base that is expressed in ADL2/AOM2 form, because of the numerous improvements of ADL2 over ADL1.4. That can be partially achieved with the new Marand ADL-designer, which will enable your source to be managed in AOM2 internally, with the old-style archetypes being importable, and the old-style OPT being exportable. The down-side is that your source will be in .oet form, which can’t represent languages and various other things properly. I believe a next version of this tool could fairly easily implement ADL2 templates however, but still generate old-style OPTs, based on a ‘null .oet’ that treats the real ADL2 templates as if they were just archetypes. In terms of EHR back-end, I think you have two choices: - thomas