General question on use of specialisation (particularl in Clusters)

Clinical
,
1

I was perusing CKM recently looking for archetypes to plug into a slot whose logical definition is ‘any kind of physical examination’. This seem doable, since CKM has a specialisation hierarchy:
ckm-exam-hierarchy

However, I see no specialisation for some other archetypes where I would expect to see it, e.g. the genetic ones below:
ckm-other-hierarchy

If I wanted to create a slot whose design intent is ‘Genetic anomaly’ (or whatever the preferred term is for that), it seems I can’t do it, since there is no parent.

I see similar things with ‘microscopic findings’, ‘PROMIS xxx’ and so on. Are these archetypes being morphed slowly to specialisation hierarchies? Not being a CKM modeller, I don’t know what to tell people about this!

1 Like
2

There is a specialisation hierarchy of Examination findings (of “normal” body parts, ie not of fluids, excrements, or things that are known to be pathological), because these examinations all have a common set of information requirements.

The genetic variants aren’t specialised because there’s no single set of information elements that are common to all of them, if I remember correctly. If you want to include information about a genetic variant in an archetype (for example in the Laboratory test result archetype), you’d use the “Genetic variant result” archetype. The other variant archetypes are intended to be used within that. We have a (slightly outdated) example template showing how this is intended to be used.

In general, we only make specialisations if there is a significant overlap in actual information requirement between two or more concepts. One recent example of this is cTNM and pTNM. We generally don’t specialise in an ontological way, based on whether the elements are ontologically related, unless there is significant information overlap.

1 Like
3

I think that is an important and insightful statement. It’s not universally true but bery largely, I’d agree. Our specialisations represent where the information structures are aligned and there is need for common querying, not necessarily the biomedical relationships involved (which is what I think you meant by ontology)

1 Like
4

It does make it hard to define (some) slots however.

We talked a long time ago about a ‘semantic slot’, which would take account of archetype ‘ontological’ relationships that were defined external to archetypes, but not implemented to date (or even properly analysed).

I’m not clear though why 'ontological specialisation would cause any problems in the archetypes, even if there were only 1 or even 0 overlapping data elements.

5

It probably wouldn’t. The main question is if it’s worth the additional modelling and governance overhead. Specialisations are currently rather cumbersome to govern (this will get somewhat better with ADL2), and if we were to create more complex specialisation hierarchies this would be orders of magnitude worse.

2 Likes
6

Hi Thomas,

  • Clinically an assessment or conclusion that a genetic ‘anomaly’ exists would be recorded using the EVAL.problem_diagnosis archetype.
  • As Silje rightly points out, the details of the genomic code mutations or variations will be recorded using the evolving family of specific genetic variant CLUSTERs nested within the generic ‘Genomic variant result’ CLUSTER, in turn nested with the Lab test result OBSERVATION.
  • Findings on physical examination that have a genetic cause would still be recorded using the physical findings family of archetypes.

There are tried and tested modelling patterns that underpin all of these. Modelling the genomic domain has in fact confirmed that our established patterns work here as well.

I understand that this may be frustrating from an engineering POV, but it reflects the reality of the messiness of clinical medicine. And maybe a little bit that ontologies are not all they’re cracked up to be as well.

TBH I’m not so sure that if we’d started with something more akin to ADL2 we’d have done things much differently… The models also need to make sense to clinicians, modellers, domain experts, reviewers etc so compromises would always have been needed.

1 Like
7

I agree. ADL1.4 does make specialisations harder to manage, I think with experience, that has not been the real reason for their general lack of use. It is hard to pin down exactly why that has been tth e case but my broad sense is that significantly ontologising information models is not all that helpful (other than what we have in the RM), in particular is_a relationships.

Where ADL2 might prove much more useful is in providing specialisations based on aggregations. ‘compound archetypes’.

We have some of that that already with embedded templates, of course, but they have always been a bit ‘fiddly’!!

1 Like
8

Well it’s not for me to say how clinical modelling should be done in terms of any clinical semantics of course, I’m just pointing out that similar principles apply as in software structures where classes refer to other classes. Very often class A refers to ‘abstract’ class B, which is a supertype of a number of substitutable subtypes.

In archetype-land, this idea applies, and exists already in some places - any slot whose specification is a general archetype type like ‘CLUSTER.examination’ or similar.

In software we have to think about this consciously, and quite often we create an abstract parent class of the concrete classes whose instances we want to be substitutable at runtime.

I’m really just wondering if we need to think about this a bit more for archetypes - possibly even introducing an abstract marker.

9

Actually very rarely do we enforce this sort of pattern. I’m not sure that the overhead of handling abstract classes justifies the efort - do we have some good use-cases?

10

Well I raised this on the basis of some of @danielle.santosalves’s obstetric archetypes e.g. ante-natal appointments that look to me if they would have various slots. I don’t have a good feel for the need yet, and was wondering about the wider group. Technically and toolwise it would be easy, but that doesn’t mean we should do it. Just thinking around the problem for now.

1 Like
11

Pardon my boldness, but I tend to agree with @thomas.beale’s point, even as a clinician.
It’s also obvious, from this discussion, that clinical modellers aren’t happy with the way specialisations work, at least in ADL 1.4.
Ontologies confer meaning, and are one of openEHR greatest strenghts (e.g. archetype classes, naming, paths, etc). Although I understand the fear of ‘over-ontologizing’, we all feel the pain of ‘under-doing-it’.

After opening and taking screenshots of all 547 openEHR artifact mindmaps in International Community’s and Apperta’s CKMs (for the sake of quick browsing), I must say the repositories feel a bit ‘flat’ inside each class.
Besides nesting (almost) all exam findings as such, the archetype list is a bit hard to navigate. For the least acquainted, it gets quite hard to find what you are looking for. It’s even harder to be sure there is not a structure defining what you need - which is a common use case for us, and probably for all modellers.

It’s curious that our team discussed this topic exactly after noticing the different pattern of archetype governance in those two (somehow) similar modelling subjects: physical exam and genetics. In both scenarios, the main goal is to describe a reality, pointing out specially what doesn’t conform to the ‘normal’ pattern. We settled in the opinion that, in the second case, the goal was just to identify the anomaly, not to describe the full genome (or even a part of it).

Besides allowing for intelligible repositories, this seems like a good policy ‘tech wise’, for the sake of querying data or retrieval of task planning elements in each instance of a work plan.

So, wrapping up, it feels like ‘is_a’ relationships should be part of the metadata of archetypes - and the ‘semantic slot’ could be very helpful in some use cases. In what measure that depends on specialising archetypes? I really have no idea.

PS: if anyone is interested in the images I mentioned, I’ll gladly share it with you

12

Hi Pedro,

I think we have to separate 2 ideas here.

  1. Classifying the archetypes in terms of some sort of browsable/ searchable criteria

  2. The patterns and value of inheritance within the models themselves.

CKM does actually have quite a sophisticated and adaptable ‘ontology’ to cover (1) but we found, in practice that it is actually quite difficult to categorise things in a way that is truly helpful. I think we can do better but it is surprisingly difficult to categorise something like e.g blood pressure

We could certainly think in terms of broad groupings , in the way that FHIR artefacts are presented but I suspect this will have quite limited value. It is probably much more helpful for templates than archetypes, and my own feeling is that bundling things into projects and exemplar templates is more helpful than a true ontology.

That issue of categorisation for searchablility is somewhat different from deciding when specialisation to provide inheritance adds value in run-time querying. Important we do not mix them up IMO.

Can you give some concrete examples where you might do things differently?

2 Likes
13

Hi Ian,

Thanks for your clarification. I see the difference, and my post did mix up the discussion.

You’re right: groupings would be more helpful for templates than for archetypes. I also agree with you in that it’s hard, if not impossible, to present a polihierarchical structure in a tree-like view. Tags of some sort seem more appropriate for that matter, but I read somewhere in the forum that this strategy seems to bring along some troubles of its own.

But (1) could eventually benefit from (2) being more informative about the relations between archetypes. The strict rules for naming, in itself, make archetype names very meaningful. The strategy of adding a ‘-’ after the parent archetype allows for an easier aggregation of all elements within the parent cluster. I would guess this decision had ‘cluster querying’ in mind.

As you probably noticed in other discussions (anatomical location, for example), I tend to favour bringing ontologies into the model. I can’t phrase it very well, but I can’t see the fault of assuming that the finger is a part of the hand, which is a part of the arm. When thinking ‘interface-wise’, I do find a lot of benefits from it. You could argue that it’s not openEHR’s job to define anatomy. But, anatomy being one of the core (and most stable) fields in medicine, couldn’t the information model benefit from assuming it in a more ‘knowledgeable’ way?

Anyway, this subject is obviously a part of ‘uber-modelling’, or governance. And you’ve all been reflecting about this for so long, that it gets awkward to try and make a point. I am sorry if my (evolving) level of understanding is not helping the discussion. But I thought a viewpoint from down here could help you put everything in perspective.

14

Uber-modelling discussions are good - please keep going!! Bear in mind that this is all very new and novel for all of us. THere has been a fair bit of learning and experience but I certainly welcome being challenged, so please keep poking us!! We absolutely do not have all of the answers (or indeed quite a few of the questions!!).

That is actually a specific technical requirement which indicated a physical specialization hierarchy, so we can’t use it to indicate something which is a softer idea of grouping or category.

but I can’t see the fault of assuming that the finger is a part of the hand, which is a part of the arm.

Nor can I!! This is a very good positive case for ontology and ontological modelling. Complex relationships with lots of is_a and part_of relationships. In a perfect world I would probably agree that anatomical location should be fully handled be SNOMED-CT or other ontology, including post-coorrdinating things like laterality. That is the right tool for that job, not the information model IMO but the world is imperfect. SNOMED-CT licensing is a barrier and the lack of widespread ability to handle post-coordination too. That’s why we need to handle the very common requirement of side/laterality and some other properties but I would be really anxious about trying to model more detailed anatomical relationships in an information model.

Please keep the debate going!!

15

Just to add a bit of an ontology reality check - even where the recorded information (which is what archetypes are about) is closely related to some anatomy, the relevant archetypes still won’t be definitional in the sense of giving you the full (say) bone anatomy of the hand, or say the colon. A colonoscopy report will clearly include what is found in terms of location, lumen, ulcers or other anomalies in the wall etc, but will (AFAIK) not report in detail all the parts that are normal (apart from gross indicators like lumen). I don’t know whether it is standard, but I guess the order of reporting of features will follow the time order of the endoscope travel into the body.

Archetypes for this kind of information will need to draw on some anatomical description of colon anatomy, but they won’t repeat anything basic or obvious - the doc already knows his/her anatomy.

So there are two effects of clinical practice that distinguish it from ontological description:

  • no/limited need to describe anything that’s ‘normal’
  • no need to recapitulate textbook descriptions of relationships, structures - the doc already knows them - just name the things that need to be mentioned.

So EHR data is always going to be some sparse ‘view’, with abnormalities emphasised, w.r.t. a textbook ontological description of the thing it investigates.

Hence why this is so much fun :wink:

2 Likes
16

I think that is changing as we move into more protocol driven records. Normal recording, indeed ‘not done’ , ‘not asked for’ are increasingly part of standard recording requirements. Even imaging, which has traditionally been very narratiuve-driven, positives only is becoming more structured and prompt driven.

2 Likes