# Modelling pattern - imaging examination - what do you think? **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2022-05-24 08:06 UTC **Views:** 1133 **Replies:** 40 **URL:** https://discourse.openehr.org/t/modelling-pattern-imaging-examination-what-do-you-think/2648 --- ## Post #1 by @bna There is a new pattern in development for imaging examination. The pattern is based in specialisation. See the structure from this archetype: https://ckm.openehr.org/ckm/archetypes/1013.1.5915 I am ambivalent. In many modelling situations I tend to use expansion by extensions (slots). This is a robust pattern which makes expansions flexible and independent. Still there might be situations where specialisation is the right approach. What I fear with the suggested pattern is an explosion of archetypes. I would love to get some feedbacks from you "specifications-specialists". What is your opinion on the suggested pattern? --- ## Post #2 by @thomas.beale Somewhat technical answer... Specialisation has the following semantics: * specialisation corresponds to the IS-A (or 'a kind of') relationship. * the effect of allowing the data elements from both the specialisation parent and the child to be in the same level of structure - i.e. to be *structurally integrated*. * it also gives you *substitutability*, like in OO programming languages, such that: * a slot to allow some archetype xyz will allow any *specialisation child of xyz*; * this is also true of any mention of the archetype xyz in an AQL query - the same data points should be picked up from data created by specialised child archetypes * in a specialised archetype, you can redefine existing nodes from the parent Using composition (slots) has the following semantics: * composition corresponds to the PART-OF i.e. whole/part relationship. The parts (what goes in the slots) are not 'a kind' of the root archetype. * there is no substitutability in of the parts for the whole in archetype slots or in queries * there is no node redefinition by the sub-part archetypes * it doesn't allow structural mixing as with specialisation; the included parts are always within some sub-structure, usually a CLUSTER * you have to have thought of the possible slots, i.e. the possible joining points, when designing the parent. With specialisation you can freely add what you want in the child after the fact. In the ideal, both specialisation and composition should be used to obtain re-use (of the parent / central archetype data points) plus componentisation. NB: specialisation is only properly (and well) supported by ADL2. Tools like Archetype Designer are ADL2 inside, and CKM is moving to the same situation as well. Nedap's editor (based on Archie) is 100% ADL2. --- ## Post #3 by @siljelb Hi all! First of all, is there a reason we can't have this discussion in a more public part of the Discourse site? After all, it's about modelling patterns and not specifications per se. Second, this is an important discussion to have, and it's timely to have it before or while the archetypes are being reviewed. Then some generic thoughts about the pattern and its implications: 1. This is an identical modelling pattern as in the established [physical] examination finding family of archetypes. That pattern was designed in as specialisations partly based on feedback from DIPS about the need to query a single element in an archetype or its specialisations about a specific body structure using SNOMED CT codes. I believe eyes were used as the primary example. The pattern works quite well for modelling, apart from the ADL 1.4 related hassle of managing specialisations when the parent archetype is changed. As @thomas.beale points out, governing the archetypes in ADL 2 would have made things much easier. Archetype Designer works in ADL 2 internally which makes things easier than they were using Archetype Editor, but native ADL 2 in CKM would have been even better. 2. An explosion of archetypes will happen in this space whether we base our modelling on specialisations or cluster archetypes for insertion in slots. There'll be a multitude of different body structures which need specific data elements for their specific examinations. --- ## Post #4 by @thomas.beale [quote="siljelb, post:3, topic:2648"] An explosion of archetypes will happen in this space whether we base our modelling on specialisations or cluster archetypes for insertion in slots [/quote] Yes indeed - I had meant to add that same comment. The 'explosion' is essentially a consequence of biology + specialisation of clinical investigation, not some information modelling strategy. --- ## Post #5 by @erik.sundvall Great discussion initiative! I agree that it is an important discussion to have. Over the years there has also been shifting thoughts regarding speicialisation v.s. parallell copied patterns in archetypes not formally linked by inheritance (for example regarding smoking, alcohol etc) that could also be included in this discussion. (Composite PART-OF patterns can be combined with both.) [quote="siljelb, post:3, topic:2648"] is there a reason we can’t have this discussion in a more public part of the Discourse site? [/quote] I believe the discussion has now been moved to a public space, available for reading without login etc. right? --- ## Post #6 by @bna [quote="siljelb, post:3, topic:2648"] First of all, is there a reason we can’t have this discussion in a more public part of the Discourse site? After all, it’s about modelling patterns and not specifications per se. [/quote] The intention was to have some feedback from my colleagues in the specification group. If I was the only one with concern about the pattern there where no point in spreading uncertainty. I am ambiguous on this and wanted some initial feedback from my peers since we have been talking about the generic concepts of specialisation and composition over the years. Among other @Seref have some thinking on this. There are no other reason for not going public with the discussion. I can see from the thread that there is lots of competence that could and should be shared with a wider audience. --- ## Post #7 by @bna [quote="siljelb, post:3, topic:2648"] This is an identical modelling pattern as in the established [physical] examination finding family of archetypes. That pattern was designed in as specialisations partly based on feedback from DIPS about the need to query a single element in an archetype or its specialisations about a specific body structure using SNOMED CT codes. I believe eyes were used as the primary example. The pattern works quite well for modelling, apart from the ADL 1.4 related hassle of managing specialisations when the parent archetype is changed. As @thomas.beale points out, governing the archetypes in ADL 2 would have made things much easier. Archetype Designer works in ADL 2 internally which makes things easier than they were using Archetype Editor, but native ADL 2 in CKM would have been even better. [/quote] This need can be achieved with both specialisation and composition IMHO. [quote="siljelb, post:3, topic:2648"] An explosion of archetypes will happen in this space whether we base our modelling on specialisations or cluster archetypes for insertion in slots. There’ll be a multitude of different body structures which need specific data elements for their specific examinations. [/quote] I want an explosion of new information model. Health and care is unlimited in the needs for clinical models. We are developing and sharing new archetypes more or less continuously these days. Thus the term explosion was not precise here. What we need to consider is the level of details or specificity for the models (archetypes) and we need to take into consideration the combination of information models and terminologies/ontologies. This topic is about a cluster for imaging examination. The concept description is: "*Findings on radiological examination of a specified body structure or region*". Looking ahead we will see discussions on when there should be a new (specialised) archetype and when to use compositions to define details about body structures and regions. One archetypes under review is [Imaging examination of an adnexal mass](https://ckm.openehr.org/ckm/archetypes/1013.1.5939). This archetype is third (3th) level specialisation. It does some redefinitions from the parent and add a few elements - as far as I can see. Most of the added definition could be done as suggested or using compositions together with a template. I have not enough competence to say if it is good or bad. Neither from a technical or clinical viewpoint. I just to want to lift the discussion to a wider group of people. The topic is a "real openEHR" topic; it is where clinic meet software - both on specifications and in implementation. That's why we would benefit from an open discussion on the patterns we develop and implements in the models and systems. --- ## Post #8 by @varntzen Hi First: The parent archetype CLUSTER.imaging_exam has just been on review and published, and we're about to put out for review a bunch of specialised archetypes of it. By reading and participating in the review of the parent archetype the content and plan to use specialised archetypes should be known to the community, so the timing of this discussion is not good. The ART-project in Oslo University Hospital which plan to use the specialised CLUSTERs is in a hurry, so I urge anyone with something to say to come with your input as soon as possible. Secondly: Some time ago there were a shift from using CLUSTERs to specialising, and a lot of work were done to reflect this shift in the Physical examination CLUSTERs. The Imaging family or archetypes are made with the pattern from the Physical examination archetypes. There is a hassle with "re-specialising" the child archetypes after the parent is published (or go from v1 to vn), but doable. We found an error in Archetype Designer when doing this yesterday, but Better will hopefully solve it soon. --- ## Post #9 by @thomas.beale One question I have now that I look at the CKM exam archetypes ... Here's the top-level archetype, seen in the workbench: ![Cluster.exam|543x252](upload://wJ5Qexs1zYqPr7KhgcTV5AbTEA0.png) And now the thyroid one: ![exam-thyroid|558x319](upload://bT4cOUEQwM0xlSeGNvZhORYGs5T.png) The only difference is that the coded term for the System or structure examined is overridden with 'Thyroid' (normally mapped to Snomed). There are a lot of exam child archetypes like this - I don't see the point of doing this, since this can just be a runtime choice. Or is it that these archetypes are just waiting for an (in this case) endocrinologist to come along and add more specific data points? I can see this making sense. There are of course child archetypes with real differences, e.g. palpation of cervix. ![CLUSTER.palpation-cervix|550x485](upload://yiUDEltq6378M7oY1QF9C1XHE4g.png) --- ## Post #10 by @siljelb [quote="thomas.beale, post:9, topic:2648"] Or is it that these archetypes are just waiting for an (in this case) endocrinologist to come along and add more specific data points? [/quote] That's exactly the idea 😊 --- ## Post #11 by @bna [quote="siljelb, post:10, topic:2648"] That’s exactly the idea [/quote] Should we do the same pattern for procedure? We use ACTION.procedure a lot. The pattern is to add terminologies to group the type of procedure and the specific procedure within that group. Based on different categories of procedure we expand the details with Cluster archetypes. An example might be the Bowel preparation for colonoscopy. We visited several possible patterns. Create new ACTION archetypes for the domain, specialise, etc. We ended up with the pattern above. First of all it felt good to reuse an already reviewed archetype. The information model is also quite easy to understand. By using extension by composition (slots) it was trivial to extend the reviewed action archetype. For query (to get the data back) there are several AQL patterns to use. You might query using the terminology at category or procedure element. Another approach would be to query entries which contains a specific archetype. Another mechanism is to use information at template level. All the mentioned strategies might be combined depending on the use-case for querying. #openehr is quite flexible on this questions. That's needed to cope with the complexity of healthdata. Just to remind you : The reason why I follow up on this is to understand and learn, and then to make good patterns to be able to govern data for life ❤️👍 --- ## Post #12 by @thomas.beale Another technical thing to think about in this modelling pattern: if you use a parent exam / procedure etc, and make a bunch of 2nd and even 3rd degree children, of course you'll still never get everything. There'll be some annoying hospital needing exam of trigeminal nerve or mandibular foramen. So if they then create their child archetypes in the same way - as specialisations - their data will at least be interoperable with everyone else for the basic data points *without them sharing their archetype*. Their modelling will also be pretty easy, because all they have to do is add their specific items in an intuitive way. So this may be an argument for using this pattern. Don't get me wrong - there are *very good* reasons to use the composition pattern (i.e. using slots), and the combination of the two strategies gives a lot of power. --- ## Post #13 by @thomas.beale [quote="bna, post:11, topic:2648"] The reason why I follow up on this is to understand and learn, and then to make good patterns to be able to govern data for life [/quote] Most quotable openEHR quote ever! --- ## Post #14 by @bna [quote="thomas.beale, post:12, topic:2648"] So if they then create their child archetypes in the same way - as specialisations - their data will at least be interoperable with everyone else for the basic data points *without them sharing their archetype*. Their modelling will also be pretty easy, because all they have to do is add their specific items in an intuitive way. [/quote] I am not ADL2 expert (not even close to 🙄). This statement is the same as with a Template where you redefine elemntes and datatype to be more specific. The archetype remains the same, but the elements are constrained? When you create new specialised archetypes the archetype (root) id will change. If you then query a procedure archetype using AQL you will not get the newly created archetype id. At least not automatically. The developer of the query must relax the constraint on the AQL path to allow all versions and specialisations of the archetype. If we used composition pattern the archetype identifier will remain the same except for versioning. The AQL will still work without modifications. Above I said except for versioning. That's another problem. An archetype going for Vn to Vm has a breaking change. Which means quering is potentially unsafe. You can't know what to expect from a breaking version into a new one. And then: How to handle versioning in a multi layer of specialised archetypes? Is this trivial for the clinical modeller? Do the mainstream tooling support this? If there is a no or maybe answer to one of this : what kind of actions do we need to do to make this work across all layers of clinical data driven applications? --- ## Post #15 by @thomas.beale [quote="bna, post:14, topic:2648"] The archetype remains the same, but the elements are constrained? [/quote] You can also add elements in a specialised archetype, if the parent doesn't prohibit it, which it normally does not. [quote="bna, post:14, topic:2648"] If you then query a procedure archetype using AQL you will not get the newly created archetype id [/quote] The query engine needs to have access to the archetype library, which includes the specialisation relationships. That's a basic requirement. If it's not doing that, it's just missing data, and the responses will be wrong. [quote="bna, post:14, topic:2648"] The developer of the query must relax the constraint on the AQL path to allow all versions and specialisations of the archetype. [/quote] That should be the default, because by definition, data that is an instance of a specialised archetype A' is an instance of its parent A. So not picking up the A' data is an error. [quote="bna, post:14, topic:2648"] An archetype going for Vn to Vm has a breaking change. Which means quering is potentially unsafe. You can’t know what to expect from a breaking version into a new one. [/quote] That's why the major version is considered part of the id, and in that case, the query designer has to decide whether he/she is looking for vN or vN+1 (or later) data. [quote="bna, post:14, topic:2648"] How to handle versioning in a multi layer of specialised archetypes? [/quote] Well tooling can easily detect if any change breaks the specialisation conformance. My ADL Workbench was designed to do primarily this; Nedap's Archie-based tool does it, and anything that uses Archie's library does it. AFAIK, Better's library and Archetype Designer get this right as well, and CKM has its own code and does this checking as well. There's no guaranteed that there are literally 0 bugs in any of this code, but it's been tested for some years now, so it is pretty solid. --- ## Post #16 by @bna [quote="thomas.beale, post:15, topic:2648"] The query engine needs to have access to the archetype library, which includes the specialisation relationships. That’s a basic requirement. If it’s not doing that, it’s just missing data, and the responses will be wrong. [/quote] Not sure about this. AFAIK the query engine doesn't need access to any archetype library. This is needed in design-time for templates and other artefacts for input, and also for the query developer for tooling and guidance. The query engine can work without any such archetype knowledge. It must somehow know about the RM, but that's another story. [quote="thomas.beale, post:15, topic:2648"] That should be the default, because by definition, data that is an instance of a specialised archetype A’ is an instance of its parent A. So not picking up the A’ data is an error. [/quote] I would be happy to know if other implementers do this. This will certainly break most of our applications. Navigation though a hierarchy of archetyped data either with AQL or traversing paths within a composition tend to use the archetype root id as is. Adding some regexp around this adds new level of complexity. What are the experiences from other vendors building clinical applications on this? --- ## Post #17 by @varntzen [quote="thomas.beale, post:15, topic:2648"] Better’s library and Archetype Designer get this right as well [/quote] We've found that Archetype Designer doesn't change an element's occurence in the child archetype, if it has been changed in the parent. Also an error when there has been changes of 'Included' Clusters in a SLOT element in the parent. Better is informed. Otherwise it seems to work. One challenge we might experience in the review of specialised archetypes, is to make the reviewers understand that the inherited elements are "not for review", only the specialised (or added) elements. To clinicians not knowing the way specialisations works, that can be a mystery, I guess. We have to deal with that in the invitation text, and explain. --- ## Post #18 by @thomas.beale [quote="varntzen, post:17, topic:2648"] To clinicians not knowing the way specialisations works, that can be a mystery, I guess. We have to deal with that in the invitation text, and explain. [/quote] Well that requires good visualisation. You can see in the screen shots I posted above in this thread how the ADL Workbench does it - new nodes are in blue, and new or changed constraints in red; nodes inherited unchanged are in grey. So this view shows you the totality of the archetype, but also the subset that you could review. Any visualisation that does the same kind of thing should help users understand specialisation I would think. --- ## Post #19 by @varntzen [quote="thomas.beale, post:18, topic:2648"] Well that requires good visualisation [/quote] Yes, and luckily the CKM has a visual marking of which elements are inherited and which are new or altered. We'll see if the reviewers will catch it! :slight_smile: --- ## Post #20 by @varntzen [quote="bna, post:16, topic:2648"] I would be happy to know if other implementers do this. This will certainly break most of our applications. Navigation though a hierarchy of archetyped data either with AQL or traversing paths within a composition tend to use the archetype root id as is. Adding some regexp around this adds new level of complexity. [/quote] This makes me nervous. I don't have the technical insight or experience from implementation to evaluate what is right and wrong, or the implications. To my knowledge, there is very few specialised archetypes published - I only know of TNM Pathological classification [Clinical Knowledge Manager (openehr.org)](https://ckm.openehr.org/ckm/archetypes/1013.1.4191) which is specialised from TNM Clinical classification. It would surprise me if these aren't already in use somewhere. How have vendors solved this? Calling for @ian.mcnicoll @borut.fabjan @joostholslag @Seref . Any others? --- ## Post #21 by @thomas.beale [quote="bna, post:16, topic:2648"] Not sure about this. AFAIK the query engine doesn’t need access to any archetype library. This is needed in design-time for templates and other artefacts for input, and also for the query developer for tooling and guidance. The query engine can work without any such archetype knowledge. It must somehow know about the RM, but that’s another story. [quote="thomas.beale, post:15, topic:2648"] That should be the default, because by definition, data that is an instance of a specialised archetype A’ is an instance of its parent A. So not picking up the A’ data is an error. [/quote] I would be happy to know if other implementers do this. This will certainly break most of our applications. Navigation though a hierarchy of archetyped data either with AQL or traversing paths within a composition tend to use the archetype root id as is. Adding some regexp around this adds new level of complexity. [/quote] I forgot to mention something important - in ADL 1.4-based systems (currently most vendors today), the query engine can work out if there is data from specialised archetypes just by searching on the top archetype id with any extended form of the concept part of the id, i.e. if the parent is openEHR-EHR-CLUSTER.exam.v1 in ADL 1.4, children are named like openEHR-EHR-CLUSTER.exam-palpation.v1 and openEHR-EHR-CLUSTER.exam-palpation-cervix.v1 So the query engine just has to know to search for `openEHR-EHR-CLUSTER.exam%.v1` or similar (maybe there is something smarter you can do - need to check with SQL experts) - no need to have access to archetype repository. --- ## Post #22 by @Seref [quote="bna, post:6, topic:2648"] Among other @Seref have some thinking on this. [/quote] Yes, but I've been focused on RM, not modelling, and things are different when it comes to these two :) When it comes to your question, it's a difficult one. Some of the points Tom made in response to you deserve another dedicate response, but I'm not sure if I can find the time for that, so I'll try to respond to you (mainly). IHMO the criteria for choosing one of inheritance and composition over the other changes between the software development and data modelling contexts for openEHR. Even though the terms have mainly the same meanings, their mechanics are different when we're talking about object oriented programming languages and openEHR models. I think I can only share some thoughts I consider to be decision criteria, and I'd expect someone to compose those (no pun intended) when making modelling decisions. These are the thoughts of a programmer, not a clinician, but I'd expect my arguments to make sense to clinicians as well. openEHR archetypes are meant to be maximal datasets. They're inclined to grow in content in time, and that growth is meant to ensure clinical data created years later to be compatible with earlier data. Breaking changes in models introduce the essence of "this lump of data is not compatible with that lump of data" problem which we're trying to decrease as much as possible with openEHR, though the problems introduced by breaking changes in archetypes are a lot more isolated and controllable than the case of chasing a retired nurse to ask for the source code of the program they wrote in Delphi, which has been running for 18 years in a department... So a criteria for a modeller is: how important it is for them to ensure data compatibility between versions. This criteria interacts with another one : how much freedom the modeller would like to give to other modellers for reusing their model? If we were to keep adding more data points to an archetype, then inheritance turns that into a convenient set of data points for any archetype specialising it (inheriting from it). This is where the second level of openEHR's design has an advantage over its first level and mainstream OO languages: specialisation can throw away the data points that are not useful/relevant via templating, but there's no such option in implementations of RM or in mainstream OO programming languages: you have to live with what you inherit. So archetype modelling is more robust then data modelling in programming languages, because it can deal with the antipattern known as the god class thanks to templating mechanism. There are gotchas though. If templating and specialisation were all that we needed, openEHR would have one archetype, with an ever growing number of data points, and we'd have templates eliminating everything they did not need, just to keep some data points. Leaving aside the difficulty of navigating such a semantic beast, there's one other criteria that stops this from happening, a modelling criteria which also interacts with the others: is this a mandatory data point? See, mandatory data points the problem from OO languages, because you can't get rid of them by templating, so if you inherit the archetype, you have to live with that data point. Our modeller now has a choice. If they put the mandatory data point into an archetype, the reuse via inheritance comes with a a price. Not only that, but also data based on future versions of that archetype must populate this field, so there's a responsibility to bear for other modellers even if they never inherit from it. (to conclude my point above: if openEHR had a god archetype, it'd have so many mandatory data points, it'd be impossible for downstream users to use templating to produce anything sensible.) Most of the the benefits of composition over inheritance in the OO programming languages land come from avoiding the problems of having to deal with stuff you inherited and cannot omit. My humble opinion is, if you don't have a strong conviction about a data point being mandatory, the combination of specialisation and templating is a nice way of offering reuse for your models. Composition can still come to your help though :) One situation is, when you're making various optional data points available to future specialisations, but there is some semantic cohesion between a subset of your data points. I.e. they're meant to be inherited together to be useful, they relate to each other, or there are some invariants that apply that must hold when a combination of optional data points are used together. You cannot express these without explicitly identifying that semantically coherent group of data points, and if they don't have any dependence (cohesion) with the rest of their siblings, then you may want to switch over to composition over inheritance but introducing a new archetype with these data points, which'd let you make the implicit points explicit. The same applies when a data point being mandatory is conditional upon use or values of other data points. In that case, there's no need to leave a mandatory data point high up in the archetype inheritance/specialisation hierarchy. You can pack data points relevant-to-the-mandatory-one into an archetype, use composition (slots) to reuse it (optionally), but still keep the mandatory data point mandatory within that archetype, but now you've isolated that strong condition to a smaller model rather than forcing it as a contract on all specialisations. I think I saw a comment from @siljelb hinting at this direction, though not entirely: [quote="siljelb, post:3, topic:2648"] *That pattern was designed in as specialisations partly based on feedback from DIPS about the need to query a single element in an archetype or its specialisations about a specific body structure using SNOMED CT codes* [/quote] I think if the element mentioned in the quote above had some relevant data points, there could have been another way to make it available to AQL queries. If the data point and its kin had enough significance to become an archetype, then using composition (slots) to include it in models would make it possible to do `SELECT cls/..data_point_we_want/.../value FROM ... CONTAINS CLUSTER cls[that_extracted_cluster_id]` because the cluster archetype would provide a semantic root from which we can acess the data point, no matter where that semantic root is in any other model including it. Happy to be corrected on this one. So if I was a clinical modeller, these would be the things I'd keep an eye on when making decisions. They may be entirely rubbish of course, in which case I more than welcome some education :) ps: event though I said I'll write a dedicated post, I have to say @thomas.beale : to be specific, subtype polymorphism is undefined in AQL as things stand, as far as I know. If any vendors are implementing it, it'd be interesting to know :slightly_smiling_face: ps2: lots of grammar errors and typos, but I'm really busy, sorry --- ## Post #23 by @varntzen [quote="thomas.beale, post:21, topic:2648"] So the query engine just has to know to search for `openEHR-EHR-CLUSTER.exam%.v1` or similar [/quote] The naming of the specialised archetypes has all (AFAIK) the same pattern as you've found and shown above. If the modellers keep on being as clever as until today and stick to that naming convention, your suggestion will work. --- ## Post #24 by @birger.haarbrandt Hi @bna, EHRbase currently does not allow to use wildcards for the archetype ID and therefore would not catch any entries based on a parent archetype. I think we could add this without breaking things, but its not on the roadmap, yet. --- ## Post #25 by @thomas.beale [quote="birger.haarbrandt, post:24, topic:2648"] EHRbase currently does not allow to use wildcards for the archetype ID and therefore would not catch any entries based on a parent archetype. I think we could add this without breaking things, but its not on the roadmap, yet [/quote] To be clear: my intended meaning is not that the query author has to think of putting in the wildcard; the AQL engine should always do it automatically. --- ## Post #26 by @birger.haarbrandt What would happen in the case someone only wants finds data within the specialized archetype? To my experience, databases rarely work with inheritance. For example, when creating a SQL query to find employees, I might not want to get other entries from a person table but the ones which are relevant for the set of employees. From a clinical safety point of view, I think being explicit about the information need would be desirable. --- ## Post #27 by @bna [quote="thomas.beale, post:25, topic:2648"] To be clear: my intended meaning is not that the query author has to think of putting in the wildcard; the AQL engine should always do it automatically. [/quote] That would be a breaking change in our CDR. Such a requirement (if we agree on it) must be stated clear in the specifications. --- ## Post #28 by @thomas.beale [quote="birger.haarbrandt, post:26, topic:2648"] What would happen in the case someone only wants finds data within the specialized archetype? [/quote] I would say it needs a switch to change the processing. We have to remember: if the query processor fails to pick up data of specialised versions of any archetype, it's a real error, and it may have real-world consequences. [quote="birger.haarbrandt, post:26, topic:2648"] To my experience, databases rarely work with inheritance [/quote] Not sure if this is true. Have a look at [the Postgresql documentation](https://www.postgresql.org/docs/current/tutorial-inheritance.html). You can see that you have to do something special to get instances of the parent kind but not the children kinds (here: CITY is the parent type and CAPITAL is the specialisation): ``` SELECT name, elevation FROM ONLY cities WHERE elevation > 500; ``` --- ## Post #29 by @birger.haarbrandt Ah, sorry, you are right and I misunderstood the case: I was referring to the case where someone queries explicitly for the specialization. I think we have a common understanding that this should only retrieve data from instances of the specialized archetype. For the query on the "parent", it should retrieve data from the specialized instances, too. Fully agree, it should be done this way. --- ## Post #30 by @thomas.beale [quote="birger.haarbrandt, post:29, topic:2648"] I was referring to the case where someone queries explicitly for the specialization. I think we have a common understanding that this should only retrieve data from instances of the specialized archetype. [/quote] Yep, that is certainly true. --- ## Post #31 by @ian.mcnicoll I agree, wild-carding should be supported but not as a default. Example for Better Docs. ```` SELECT bp/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value as systolic, bp/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value as diastolic FROM EHR e[ehr_id/value='e119f88b-36b7-4537-9914-22bb9396e101'] CONTAINS COMPOSITION c CONTAINS OBSERVATION bp[openEHR-EHR-OBSERVATION.blood_pressure.v*] LIMIT 5 ``` and [openEHR-EHR-OBSERVATION.blood_pressure*] [openEHR-EHR-OBSERVATION.*pressure.v1] [openEHR-EHR-OBSERVATION.blood*] so can be used for 1.4 syntactic specialisations. [openEHR-EHR-OBSERVATION.blood_pressure*] --- ## Post #32 by @thomas.beale [quote="ian.mcnicoll, post:31, topic:2648"] I agree, wild-carding should be supported but not as a default. [/quote] Depends on where the wildcarding is. In the 'v*' bit you are right - hidden wildcards would be an error. Also if the engine were to do `*pressure` - that also has to be a user choice. But for any concept of the form `xxxxx`, not automatically retrieving data for the archetype `xxxxx-*` is an error. Note - the '-' has to be there. For ADL2 systems, archetype lookup is needed, since concept names don't follow the xxxx-yyyy-zzzz pattern. --- ## Post #33 by @ian.mcnicoll [quote="thomas.beale, post:32, topic:2648"] But for any concept of the form `xxxxx`, not automatically retrieving data for the archetype `xxxxx-*` is an error. Note - the ‘-’ has to be there. [/quote] From a safety issue, I think I disagree. I would want to explicitly include specialisations, not have them automatically included by default. --- ## Post #34 by @thomas.beale [quote="ian.mcnicoll, post:33, topic:2648"] From a safety issue, I think I disagree. I would want to explicitly include specialisations, not have them automatically included by default. [/quote] From a safety issue, it is the other way around - it can easily be the case that some template is recording exactly the data in a more basic template, using a specialised version of the archetype, and the important data is in the inherited items - which could be the case for CLUSTER.exam-* archetypes. For the query processor not to pick up this data in response to a query using the parent archetype id is unequivocally an error - it's the same data. So the users are just not seeing some of the data *defined by the parent archetype*, just because it happens to be inherited into a specialised child. We need to talk about this, it's a serious issue! I've put it on the SEC agenda for next meeting. --- ## Post #35 by @bna Safety in this manner is IMHO about being consistent. A given query on the same data should give the same vendor neutral result, and also be consistent across versions of the CDRs. There are some important rules to agree upon here. I agree. --- ## Post #36 by @thomas.beale [quote="bna, post:35, topic:2648"] Safety in this manner is IMHO about being consistent. A given query on the same data should give the same vendor neutral result, and also be consistent across versions of the CDRs. [/quote] Agree. But the result also needs to be not wrong ;) --- ## Post #37 by @joostholslag [quote="varntzen, post:20, topic:2648"] This makes me nervous. I don’t have the technical insight or experience from implementation to evaluate what is right and wrong, or the implications. To my knowledge, there is very few specialised archetypes published - I only know of TNM Pathological classification [Clinical Knowledge Manager (openehr.org) ](https://ckm.openehr.org/ckm/archetypes/1013.1.4191) which is specialised from TNM Clinical classification. It would surprise me if these aren’t already in use somewhere. How have vendors solved this? Calling for @ian.mcnicoll @borut.fabjan @joostholslag @Seref . Any others? [/quote] We use specialisation patterns extensively. We’re still implementing AQL and it’s designed to return all data from specialisations. I think it’s the only right design. Since you’re querying for a concept e.g. “imaging exam” and as Thomas explained “imaging exam - of Fallopian tube” ‘is_a” “imaging exam” it should be returned by default. I even struggle to think of a scenario where you don’t want the children, but probably there are edge cases. [quote="birger.haarbrandt, post:29, topic:2648"] I was referring to the case where someone queries explicitly for the specialization. I think we have a common understanding that this should only retrieve data from instances of the specialized archetype. For the query on the “parent”, it should retrieve data from the specialized instances, too. Fully agree, it should be done this way. [/quote] Yes, this is the only convention that makes sense to me. Query on parent returns result of children. Query on child doesn’t give results for parent. There may be usecases where you want the reverse as an option, but I would spend most of my time making sure the default works. As with regards to the wildcard in the archetype ID. I only like the version number wildcard. Using it for specialisations is way too brittle imho. And using *-pressure is hard to imagine to give useful data. E.g. cluster.tyre-pressure used in cluster.device is hardly something useful to query at the same time as blood-pressure. And thus I find this pattern dangerous. I’m not against it even people know what they’re doing, but I wouldn’t recommend it as a pattern for regular queries, e.g. for querying children. --- ## Post #39 by @bna [quote="joostholslag, post:37, topic:2648"] We use specialisation patterns extensively [/quote] It would be great to see some of these archetypes. There are not much specialisation in the available CKM. I would like to see how you are doing it, ie. the granularity and clinical domains. I am also curious on how you handle distributed versioning of a hierarchy of specialisations. One example might be the need to change the parent archetype with a major change like going from v1 to v2. Based on the naming regime for archetype ids you will not be able to see which parent it is specialised from. How do you handle this? --- ## Post #40 by @joostholslag You could have a look at my care plan design: https://discourse.openehr.org/t/obsolete-status-for-care-plan-composition-archetype/1927/25?u=joostholslag Or our covid vac archetypes: https://archetype-editor.nedap.healthcare/advanced/covid-19-vaccine-registration (Register for free account first; Please don’t look at the rest of the design, it’s driven by our limitations e.g. no action support. ) In general my advice would be to specialise on the minor version level, because that way patch updates (typos, etc) will be updated automatically, but breaking changes are not. One reason to specialise patch level is if you have a hardcover ui, where an extra character my break the layout of a text label. Another would be if you don’t want new elements to show up in the ui automatically. Major updates include breaking changes, those should generally be reviewed before updating imho. An exception could be a measurement scale or something that is in itself a concept with versioning (new version of scale means new archetype not new version of an archetype). These recommendations are coming from a scenario where most archetypes are scales where forms are auto generated from ADL2 templates. And the template is often autogenerated from an adl2 observation (wrapped in comp.result-report and adds eval.clinical_assesment). Happy to share more, or explain in detail, since the models are quite complex, and adl2 is so different it may be a challenge to understand from this message alone. --- ## Post #41 by @siljelb [quote="joostholslag, post:40, topic:2648"] In general my advice would be to specialise on the minor version level, because that way patch updates (typos, etc) will be updated automatically, but breaking changes are not. [/quote] I think this is good advice, once an archetype reaches v1. But can we specialise on the minor version in ADL1.4? --- ## Post #42 by @joostholslag [quote="siljelb, post:41, topic:2648"] once an archetype reaches v1 [/quote] This btw is one of the reasons I’d like CKM to do minor and patch versioning for unpublished archetypes. The other is updated archetypes with the same version number can’t be updated in the same cdr (because they have to be unique). @sebastian.garde fyi. --- **Canonical:** https://discourse.openehr.org/t/modelling-pattern-imaging-examination-what-do-you-think/2648 **Original content:** https://discourse.openehr.org/t/modelling-pattern-imaging-examination-what-do-you-think/2648