# Missing rule in AOM 1.4 for non-unique sibling nodeIds **Category:** [Specifications](https://discourse.openehr.org/c/specifications/6) **Created:** 2024-03-27 19:30 UTC **Views:** 968 **Replies:** 42 **URL:** https://discourse.openehr.org/t/missing-rule-in-aom-1-4-for-non-unique-sibling-nodeids/5056 --- ## Post #1 by @pablo We are working on modeling questionnaires, which has been an ongoing discussion for some time now. For short, we are reusing a generic `question` archetype in a way that the template (OPT) has a multiple attribute with C_OBJECTs that have the same nodeId but different names (using the name as a differentiator). While reading the AOM 1.4 spec it says: ``` 4.2.3.1. Node_id and Paths The node_id attribute in the class C_OBJECT, inherited by all subtypes, is of great importance in the archetype constraint model. It has two functions: + it allows archetype object constraint nodes to be individually identified, and in particular, guarantees sibling node unique identification; + it is the main link between the archetype definition (i.e. the constraints) and the archetype ontology, because each node_id is a 'term code' in the ontology section. ``` REF: https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_object_node_types But in our case, this "rule" is broken: `guarantees sibling node unique identification` since siblings can't be identified by node_id alone and need the name too. From other sample OPTs in the CKM and the AOM itself, the way we are using the OPT seems correct, since I can't find a rule in AOM 1.4 that says we can't put two C_OBJECT that have the same node_id inside a the same C_MULTIPLE_ATTRIBUTE.children. Though I can't find either a rule that says that node_id plus name should be unique, because now if we allow those two rules, then it's impossible to know with which C_OBJECT inside the C_MULTIPLE_ATTRIBUTE.children a given RM object instance matches (important for validating RM instances against an OPT and also for querying). I think a rule for unique node_id and name should be added to the AOM 1.4 specs, this is crucial for models that reuse the same archetype at the same level, like with questionnaire questions or with laboratory test results analytes With that rule, we can say that an OPT that breaks it is not valid, right now we can't, so systems implement that case in different ways, making behavior unpredictable (note this has to do with conformance). We are actually implementing that rule, and returning an error if the OPT doesn't comply. --- ## Post #2 by @sebastian.garde It may be worth clarifying this rule. Agree that it does not seem to phrased correctly for these cases. Re what is correct: I think the original idea at least was that it does not have to be the *name*, but can be another attribute as well, as long as the result is that the sibling nodes can be uniquely identified. Typically, it is the *name* of course. --- ## Post #3 by @thomas.beale [quote="sebastian.garde, post:2, topic:5056"] Re what is correct: I think the original idea at least was that it does not have to be the *name*, but can be another attribute as well, as long as the result is that the sibling nodes can be uniquely identified. Typically, it is the *name* of course. [/quote] That is correct. --- ## Post #4 by @pablo [quote="sebastian.garde, post:2, topic:5056"] Re what is correct: I think the original idea at least was that it does not have to be the *name*, but can be another attribute as well, as long as the result is that the sibling nodes can be uniquely identified. Typically, it is the *name* of course. [/quote] If the C_OBJECTs that appear in the same C_MULTIPLE_ATTRIBUTE.children comply with the same archetype_id, I guess any constraint that is different on any attribute of the C_OBJECTs could serve as a differentiator. For instance if the C_OBJECTs are for ELEMENTs, and each ELEMENT.value has a different constraint, that might work, though to be sure the constraints codomain shouldn't intersect (that's the allowed values for different constraints like A: 1..10 and B: 3, 21, 50; you see that the value 3 is valid against both constraints, so when you have 3 in a data instance you don't know with which specific C_OBJECT it's mapped to). When the constraints are text-based or code-based it's easier for the modeler to assign texts or codes that don't match (or have intersecting codomains). If that reasoning is correct, I think the specs might be missing a more strict definition (maybe it's there and it's just that I can't find it!). If such rule is added, like an archetype or template validation rule, we can use it to check the validity of such cases of repeating constraints inside C_MULTIPLE_ATTRIBUTES, though I think this also applies when having C_SINGLE_ATTRIBUTES.alternatives, but in that case it's sufficient for the data to match ANY of the alternatives, so the first match is enough. This is also important for querying, since the paths for the C_MULTIPLE_ATTRIBUTE.children might be all the same, even if they have different constraints for attributes like `name` inside, so paths in AQLs might need extra predicates like `name/value=...` or if another attribute is used, `some_attribute/some_field=...`. @thomas.beale what do you think? Going one extra step, and this is a separate topic (I don't want to move the focus from the first question about improving the rules in the spec), if we don't deprecate AOM/TOM 1.4 anytime soon, what do you think about adding another node differentiator? COMPO * content * ENTRY arch_id_1, node_idx_1 * ENTRY arch_id_1, node_idx_2 * ENTRY arch_id_1, node_idx_3 Though I know something like this was added to ADL2, I'm not sure when we will actually stop using 1.4 stuff. --- ## Post #5 by @thomas.beale [quote="pablo, post:4, topic:5056"] the constraints codomain shouldn’t intersect (that’s the allowed values for different constraints like A: 1…10 and B: 3, 21, 50; you see that the value 3 is valid against both constraints, so when you have 3 in a data instance you don’t know with which specific C_OBJECT it’s mapped to [/quote] That's certainly true, for the reason you describe. [quote="pablo, post:4, topic:5056"] If that reasoning is correct, I think the specs might be missing a more strict definition (maybe it’s there and it’s just that I can’t find it!). [/quote] I'll need to look, but one thing to remember is that the semantic definitions are vastly better in ADL2/AOM2 than in the ADL/AOM14 docs. And tooling wise, the preferred path these days is to convert ADL 1.4 archetypes into ADL2 (via Archie or other tool) and then everything that goes on is defined by AOM2 / ADL2 semantics. However, I think you may be right - the question of value constraint overlap is not formally defined from memory, so there is still something else we need to do. [quote="pablo, post:4, topic:5056"] Though I know something like this was added to ADL2, I’m not sure when we will actually stop using 1.4 stuff. [/quote] We created a PR and I think a CR (for a new attribute called sequence_id or similar) but we did not action it so far. --- ## Post #6 by @pablo [quote="thomas.beale, post:5, topic:5056"] However, I think you may be right - the question of value constraint overlap is not formally defined from memory, so there is still something else we need to do. [/quote] I tried to find a reference for this case in AOM and I couldn't. This might be a marginal case that is why others might not focus to much on this, but happens when reusing the same structure in the same place for different things of the same type: like questionnaire questions or laboratory results analytes. [quote="thomas.beale, post:5, topic:5056"] We created a PR and I think a CR (for a new attribute called sequence_id or similar) but we did not action it so far. [/quote] Was that for 1.4? I'll check JIRA, it might worth another try. (UPDATE: I see this one but the change proposed in on RM not on AOM, I would expect the differentiator to be in C_OBJECT https://openehr.atlassian.net/issues/SPECRM-63?jql=text%20~%20%22sequence%2A%22) I believe adding an extra differentiator, at least for this case, would be a simple change in tools, though it also has some repercussions on paths and AQL, but I feel it's worth the improvement since this is generating the need of workarounds and patches outside the specs that might not work everywhere. --- ## Post #7 by @thomas.beale [quote="pablo, post:6, topic:5056"] [quote="thomas.beale, post:5, topic:5056"] We created a PR and I think a CR (for a new attribute called sequence_id or similar) but we did not action it so far. [/quote] Was that for 1.4? I’ll check JIRA, it might worth another try. [/quote] See here. https://openehr.atlassian.net/browse/SPECRM-63 [quote="pablo, post:6, topic:5056"] I believe adding an extra differentiator, at least for this case, would be a simple change in tools, though it also has some repercussions on paths and AQL, but I feel it’s worth the improvement since this is generating the need of workarounds and patches outside the specs that might not work everywhere. [/quote] Many of us have thought it would have been good to add in the past, but it raises interesting and non-trivial questions to do with versioning. The problem is that adding it now would not be easy, because the various vendor products all deal with the requirement in other ways. This is not to say it should not be done, but by now it might be in openEHRv2. Whether it could be done in current openEHR is a cost/value question for platform implementers I guess. --- ## Post #8 by @pablo [quote="thomas.beale, post:7, topic:5056"] , but it raises interesting and non-trivial questions to do with versioning. The problem is that adding it now would not be easy, [/quote] I'm sure it would also affect specialization. I see this one but the change proposed in on RM not on AOM, I would expect the differentiator to be in C_OBJECT [Issue navigator - openEHR JIRA](https://openehr.atlassian.net/issues/SPECRM-63) --- ## Post #9 by @thomas.beale [quote="pablo, post:8, topic:5056"] I see this one but the change proposed in on RM not on AOM, I would expect the differentiator to be in C_OBJECT [Issue navigator - openEHR JIRA](https://openehr.atlassian.net/issues/SPECRM-63) [/quote] Well anything that works like a data instance sequence number needs to be RM level, and you would not normally want to constrain this field. --- ## Post #10 by @pablo But the problem I'm facing is having data items and not knowing to which C_OBJECT it corresponds too. If the differentiator/sequence number is only in the RM data, you still can't point to a specific sibling C_OBJECT inside C_MULTIPLE_ATTRIBUTE.children I think THE solution would be to have the differentiator in the data and in C_OBJECTs so you can find the right C_OBJECT, for instance, when validating that data structure against an OPT, or when indexing data on the database, or when building queries on a query editor and you want to retrieve data that matches one specific C_OBJECT among several sibling ones that all have the same archetype ID and node ID. Of course I might be missing something. --- ## Post #11 by @thomas.beale [quote="pablo, post:10, topic:5056"] But the problem I’m facing is having data items and not knowing to which C_OBJECT it corresponds too. If the differentiator/sequence number is only in the RM data, you still can’t point to a specific sibling C_OBJECT inside C_MULTIPLE_ATTRIBUTE.children [/quote] I realise I did not quite understand your original post properly - I had thought that you wanted an alternative to 'name' for distinguishing data instances derived from the same archetype node. Looking more carefully at your original question, I would advise modelling each question as a distinctly coded (in the archetype) node, e.g. a CLUSTER. Different questions are clearly semantically different things; to model them as instances of the same archetype node with just changes in the name field doesn't correspond with the modelling intent in my view. --- ## Post #12 by @pablo [quote="thomas.beale, post:11, topic:5056"] I realise I did not quite understand your original post properly [/quote] Don't worry, let me create a full example so I can exemplify this better. I'm currently writing an article about this, focusing on questionnaire modeling. --- ## Post #13 by @damoca [quote="thomas.beale, post:11, topic:5056"] Looking more carefully at your original question, I would advise modelling each question as a distinctly coded (in the archetype) node, e.g. a CLUSTER. Different questions are clearly semantically different things; to model them as instances of the same archetype node with just changes in the name field doesn’t correspond with the modelling intent in my view. [/quote] I agree, I think that this topic is more about modeling practices rather than a technical issue. Let me develop it further. An archetype is a general purpose, semantic definition of an information structure. A template is a combination and constraint of archetypes for specific purposes. The key word here is constraint, templates constrain the semantics and accepted data values defined in the archetypes. Then, in practice, we create a template, we clone archetype nodes and rename them to better fit the final use case scenarios. But what are the implications of that renaming? Are we really just adjusting the text to make it more suitable for the final users, or are we creating cloned nodes with new semantics? I think here it is the key question. If the cloned nodes in the template are just adjustments of the name, or of the accepted data values, then identifying them it is not that important, since at the end, semantically they are still defined by the atNNNN/idNNNN code of he original archetypes. But if cloned nodes in a template are used to create completely new elements, with a particular meaning and semantics (I imagine that this is the case of the questionnaires in the original message of @pablo ) maybe templates is not the place to create them. If we are creating new semantic definitions, we have to do it at the archetype level, and each new node will have its own atNNNN/idNNNN code. Or, depending on the case, an specialization, with their atNNNN.X identifiers. The tricky question here would be how we, or the tooling, can differentiate between both cases in order to create faithful structures and validation processes. --- ## Post #14 by @pablo @damoca you touch a very sensible point. What I have tried is to have two archetypes: * COMPOSITION.questionnaire * ADMIN_ENTRY.question The question has an ELEMENT with no constraints (ANY) on the value, and tested two possibilities for the ELEMENT.name: 1. have no constraint in the archetype (when the question will be just interpreted by humans) 2. have a DV_CODED_TEXT in the archetype (when the question needs to be identified by code e.g. for statistical analysis) Then in the template we have many ADMIN_ENTRY.question nodes, one per each question, and each question is semantically different than other questions, the semantics are set by the name of the question which is the textual question: how much do you smoke a day?, how often do you exercise? etc. Now the semantic part: as a modeler you can say all the questions are the same, independently of the text/name of the question (abstract view), or you can say each question is semantically different, depending on the text/name of the question (concrete view). Before you sit on either side, there is another point to consider: this is more similar to a terminology constraint than a data structure constraint. For instance, you can consider each question text/name is an item of a terminology, which is true since the question text is actually a term that means something, though is not an assertion, is a question (we are used to terminologies of assertions or statements like "this is blood pressure" or "this is diabetes", but not so used to terms like "do you have diabetes?"). So my approach is terminological in conjunction to very abstract archetypes, and combining the two I get the final template (I'm writing about this right now). So in the template you will have: * COMPOSITION.questionnaire * ADMIN_ENTRY.question: name = 'do you smoke?' * ADMIN_ENTRY.question: name = 'do you exercise?' * ADMIN_ENTRY.question: name = '....' In that case, COMPOSITION.content has 3 C_OBJECT children, each with a different name constraint. Though because the rule I mentioned above doesn't seem to be in the specs, we need to manually assure the name constraints don't collide, or in other words (and just for my case), that someone doesn't add the same question twice. In parallel, I think this approach applies also to lab results, since we can have a similar generic set of archetypes and define the specific individual test results (analytes) as terminological constraints, which might take advantage of using LOINC. I think this case also has a similar terminological approach than a data structure approach in terms of modeling. --- ## Post #15 by @damoca I completely understand your scenario. It's another example of the complexity of modeling questionnaires :joy: So, back to your initial question, I agree that the non-unique sibling nodeId spec text can be improved to clarify some use cases. And for your proposal of adding an additional node differentiator in the RM, if you don't want to wait for a change in the RM, you should proceed with archetype specializations and not modeling the questions at the template, as I said before. In an specialized archetype you can create as many atN.X codes as you need inheriting the parent node, and constraint them individually. And that should be enough for any validation needs you have. The problem I found is that I couldn't figure how to do this with the Archetype Designer. With LinkEHR we can have this parent archetype: ![image|289x79](upload://lU70cZXEwBX30jSjajxgHbTb0Jd.png) And then create this specialization: ![image|490x131](upload://4O0iJyN8SmH2V0OMaP5IZ8R7pgk.png) --- ## Post #16 by @pablo [quote="damoca, post:15, topic:5056"] And for your proposal of adding an additional node differentiator in the RM [/quote] I proposed the change in the AOM. The proposal for the change in the RM was made by @thomas.beale --- ## Post #17 by @pablo @damoca @thomas.beale this might help understanding my use case https://www.linkedin.com/pulse/patient-questionnaires-openehr-missing-link-pablo-pazos-gutierrez-wnb1f/ --- ## Post #18 by @thomas.beale [quote="damoca, post:13, topic:5056"] Are we really just adjusting the text to make it more suitable for the final users, or are we creating cloned nodes with new semantics? I think here it is the key question. [/quote] Exactly. [quote="damoca, post:13, topic:5056"] If the cloned nodes in the template are just adjustments of the name, or of the accepted data values, then identifying them it is not that important, since at the end, semantically they are still defined by the atNNNN/idNNNN code of he original archetypes. [/quote] Also - that should be the intent of renaming within a template - it's a UI / display level idea, not a semantic one. [quote="pablo, post:14, topic:5056"] What I have tried is to have two archetypes: * COMPOSITION.questionnaire * ADMIN_ENTRY.question [/quote] I would build a Questionnaire as an OBSERVATION (since it's obtaining data from the patient) containing a number of CLUSTERs, each representing a question. Each CLUSTER can define the question language (including translations), the intended semantics of the question, any coding, and the structure & type of the possible answers. The COMPOSITION level would include meta-data about the questionnaire, and also the situation in which it was filled in - at doctor's surgery, at home etc. --- ## Post #19 by @pablo I use ADMIN_ENTRY for it's simplicity. This is a first approach for a full solution (check the article above). --- ## Post #20 by @heather.leslie It is interesting to watch this thread evolve. I went through the process of trying to design a generic questionnaire over 10 years ago - I blogged on the situation in Feb 2014 [here](https://www.atomicainformatics.com/archetypical/2014/02/21/the-questionnaire-challenge). The blog post conclusions are way outdated now and our approach has moved on, but I include it to demonstrate that there has been a long history of trying to solve this problem that precedes this technical discussion. In case you are interested, our current approach is below... I invite my Editorial colleagues to join in if I misrepresent our current approach - @siljelb, @John_Tore_Valand @varntzen. 1. PROMS/PREMS and other validated scores and scales - are carefully represented as standalone OBSERVATIONs that undergo the peer review and publication process. You can find a collection of them in various states of publication in the ['Scores and Scales' project](https://ckm.openehr.org/ckm/projects/1013.30.74) on CKM. You will also find a demo template for PROMIS-29 which aggregates CLUSTERs in a mix-and-match way to represent many permutations and combinations of the PROMIS item components but contained within a single PROMIS framework OBSERVATION. If questionnaires for a specific purpose are identified that will support reuse, even if not ubiquitously, then they are a candidate for this group and the associated modelling/governance process. 2. In recent years, especially triggered by the need for COVID-19 screening, we have slowly been developing a library of screening questionnaires that represent common ways of screening for critical clinical information. They represent ubiquitous topics in a loose way that deliberately balances standardisation/structure with flexibility. Modelling each screening questionnaire concept as a discrete archetype at least supports very high-level querying based on the concept, but has the potential for broader reuse, including common querying. You can find a collection of them, also in various states of publication, in the ['Screening questionnaires' project](https://ckm.openehr.org/ckm/projects/1013.30.90). They have been surprisingly successful and have been reused extensively in several projects, hence the significant number which have been successfully published. The reuse has been focused on initial patient screening use cases but has also been found to be very valuable in secondary use domains such as disease registries and infectious disease surveillance. The other value of this approach is that we strategically align the concepts with archetypes that will capture 'positive presence' as a more detailed persistent model - eg Symptom/sign screening - a 'Yes', can trigger the use of CLUSTER.symptom/sign to capture more information. Discerning where screening starts/stops and what should be left to the persistent model is often the hardest part, to avoid the potential of duplication in different models - we have found this to be a significant governance issue. 3. The notion of a generic archetype that provides a general structure without any semantics has been explored and discarded. We decided that there is essentially no value in a generic 'pattern for pattern's sake' approach - and we did try, pushing this very hard for a long time - but even if an appropriate design could be made, there is little shareable value if most or all of the semantics need to be added in the template. So, for the situation where questionnaires have been developed for a specific organisation or project, and where there will be little, limited or no opportunity for reuse, we recommend modellers build their own archetype and govern it locally. In reality, there will be a myriad of these messy, locally configured archetypes that will come into existence, add value to a local user, product or project, be managed locally and never need to be shared. If it is discovered that there is value in sharing, then they can later be proposed to CKM as per option #1, above --- ## Post #21 by @pablo Thanks Heather. On the article linked above I explored a different path, combining: 1. generic archetypes 2. external questionnaire model, with specific constraints to questions and answers (it's focused on questions, not on other types of information recording) 3. library of questionnaires and questions based on the model in 2. which is managed like an external terminology service would do with concepts and terms but with questions and their related metadata 4. a program that generates a template based on a questionnaire definition, and that follows the generic archetype model (which is more in line with the organization-specific questionnaires) On the template side we explored two options: a. having one question for each ENTRY b. having one ENTRY and all the questions inside as CLUSTERs Option b. has a simpler data structure. Querying on either option is very similar. The only issue is the one that triggered this thread: a limitation on the AOM, which affects data validation and querying. This is all still a PoC but seems to work end-to-end. --- ## Post #22 by @ian.mcnicoll Thanks Heather, Great summary, and having been involved in those complex and painful attempts to develop a generic questionnaire archetypes, I completely agree that the current approach of specific PROMS. a set of themed screening archetypes and ultimately some local Q+A type archetypes is working very well for us. As you say there are some grey areas around when to use the screening archetypes vs. 'semantic/ persistent' equivalents, and it requires a bit of detailed analysis to understand the status of the information being entered. Is it preparatory information capture of medical history, true 'formal recording' of a diagnosis, or at the other end of the process, perhaps a protocol-driven questionaire for registry purposes. @Pablo - I don't really understand the problem you are trying to solve (that is not solved as Heather has detailed above). Even if you can manage a list of 'questions' , and that does somewhat replicate what LOINC is doing, outside the area of simple scores, those questions generally also have some other data beyond present/absent like 'Date of diagnosis' or severity. That was the problem that we found - simple Y/N answers nearly always needed to be extended to cover other datapoints. The ability of the latest CDRs (Better and Ehrbase I understand), to do context-agnostic queries on ELEMENTS will make it easy to cross-query the various flavours of record. --- ## Post #23 by @siljelb Thanks @heather.leslie and @ian.mcnicoll for your responses, I agree completely with you both about the questionnaire question! [quote="heather.leslie, post:20, topic:5056"] PROMS/PREMS and other validated scores and scales - are carefully represented as standalone OBSERVATIONs that undergo the peer review and publication process. You can find a collection of them in various states of publication in the [‘Scores and Scales’ project](https://ckm.openehr.org/ckm/projects/1013.30.74) on CKM. [/quote] Regarding validated/standardised scores and scales, in addition to the OBSERVATION pattern outlined by Heather, there's a sibling pattern for gradings and classifications that are closely associated with specific concepts modelled as ENTRY archetypes. The pattern is described in this Confluence page: [ENTRY-linked gradings and classifications - openEHR Clinical - Confluence](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2192867347/ENTRY-linked+gradings+and+classifications) --- ## Post #24 by @pablo @ian.mcnicoll note the issue I reported is from the specs themselves, not about questionnaire modeling in particular. It's just that while working with questionnaires I bumped into this AOM spec limitation. [quote="ian.mcnicoll, post:22, topic:5056"] @Pablo - I don’t really understand the problem you are trying to solve (that is not solved as Heather has detailed above). Even if you can manage a list of ‘questions’ , and that does somewhat replicate what LOINC is doing, outside the area of simple scores, those questions generally also have some other data beyond present/absent like ‘Date of diagnosis’ or severity. [/quote] The questionnaires we are dealing with are plain questions with single of multiple answers of the same type. There is no context information associated like "do you have diabetes?" then a related question "what's the date of detection" , so there is no severity either. Neither are simple yes/no. Though we have groups for questions, which are CLUSTERs. There we could add context data, but right now there is no need for that for our requirements. The article I shared has more info about this use case. Hope that helps. --- ## Post #25 by @thomas.beale [quote="pablo, post:16, topic:5056"] I proposed the change in the AOM. [/quote] Well we do have a node differentiation in every C_OBJECT in an archetype. It's just that you are cloning at nearly the data level in a template. So you are going around the standard AOM approach to representing semantically different nodes! [quote="heather.leslie, post:20, topic:5056"] You will also find a demo template for PROMIS-29 which aggregates CLUSTERs in a mix-and-match way to represent many permutations and combinations of the PROMIS item components but contained within a single PROMIS framework OBSERVATION [/quote] This is roughly the way I would expect to model questionnaires. There are undoubtedly a more sophisticated approaches that we have not developed yet, but this PROMIS modelling enables semantically distinct and reusable questions within a containing questionnaire, which is usually what is needed. [quote="pablo, post:21, topic:5056"] b. having one ENTRY and all the questions inside as CLUSTERs [/quote] Why not do this as an archetype - then you will get the effect you want? Maybe I am missing something obvious here? --- ## Post #26 by @pablo [quote="thomas.beale, post:25, topic:5056"] [quote="pablo, post:16, topic:5056"] I proposed the change in the AOM. [/quote] Well we do have a node differentiation in every C_OBJECT in an archetype. It’s just that you are cloning at nearly the data level in a template. So you are going around the standard AOM approach to representing semantically different nodes! [/quote] Duplicating sibling nodes in the template is not new. Check the template with multiple sibling SECTION.adhoc https://ckm.openehr.org/ckm/templates/1013.26.376/opt The only differentiator for C_OBJECTs is the name constraint at the section level. I believe I'm using the same technique. [quote="thomas.beale, post:25, topic:5056"] This is roughly the way I would expect to model questionnaires. There are undoubtedly a more sophisticated approaches that we have not developed yet, but this PROMIS modelling enables semantically distinct and reusable questions within a containing questionnaire, which is usually what is needed. [/quote] Having a single archetype for each question or by question + context was explored. If we scale this for new questionnaires we might end up with 100s of archetypes for questions, which we will need to manage in time, and templates will need to be regenerated with each change to an archetype, having also to manage dependencies. IMO the terminology-like approach moves that away from openEHR modeling. Though it's healthy to have and explore different approaches. Though the orthogonal question is what the spec allows and not, and were the spec has limitations for valid cases. We can create a separate thread about different approaches to model questionnaires. From a more general view, what I'm exploring right now is the ability of generating openEHR artifacts based on external requirements, based on other models, which is like domain specific language but for models. It seems this is a semantic level between archetypes and templates. There might be more implementers doing stuff like this, but I couldn't find any papers about it, so might be something new and worth exploring (not only for questionnaires). [quote="thomas.beale, post:25, topic:5056"] [quote="pablo, post:21, topic:5056"] b. having one ENTRY and all the questions inside as CLUSTERs [/quote] Why not do this as an archetype - then you will get the effect you want? Maybe I am missing something obvious here? [/quote] This is done in an archetype, it's just generic. The specific questions are defined in the template on either case (we tested both cases): one specific question per ENTRY and one specific question per CLUSTER inside one ENTRY. Either way the problem of having several siblings with the same archetype ID is still present, the first case at the ENTRY level and the second case at the CLUSTER level. --- ## Post #27 by @siljelb [quote="thomas.beale, post:25, topic:5056"] This is roughly the way I would expect to model questionnaires. There are undoubtedly a more sophisticated approaches that we have not developed yet, but this PROMIS modelling enables semantically distinct and reusable questions within a containing questionnaire, which is usually what is needed. [/quote] Yep, this modelling pattern works well for the PROMIS type of questionnaire, which is one of potentially many predetermined and standardised combinations of predetermined and standardised questions. But it won't work well for your average questionnaire, which usually are semi-random collections of questions with limited standardisation or internal coherence. We need to support those as well, and this is one of the requirements that led to the development of the Screening questionnaire family of archetypes. [quote="pablo, post:26, topic:5056"] Having a single archetype for each question or by question + context was explored. [/quote] That's not how either the PROMIS pattern or the Screening questionnaire pattern work; neither of them (pattern-wise) have archetypes containing only one predetermined question. --- ## Post #28 by @pablo [quote="siljelb, post:27, topic:5056"] [quote="pablo, post:26, topic:5056"] Having a single archetype for each question or by question + context was explored. [/quote] That’s not how either the PROMIS pattern or the Screening questionnaire pattern work; neither of them (pattern-wise) have archetypes containing only one predetermined question. [/quote] I see sets of single questions per cluster e.g. https://ckm.openehr.org/ckm/archetypes/1013.1.4807 That's a single archetype for 4 single questions that are about the same topic, anxiety in this case. So I would use a better terminology: having a single archetype per-topic and a few questions inside. This is what we call "group" in our questionnaire model. So in the process I described, we model these externally (from archetypes), and end up in an auto-generated template with similar constraints as the current PROMIS archetypes, resulting in something very similar, but following different methodology, conceptually and technically. --- ## Post #29 by @joostholslag I’ve encountered a similar requirement as Pablo using modelling of care plans. We decided to use the UID RM attribute for this. (Can’t find exactly which anymore). We used ADL2 so, node identification of sibling nodes in adl2 specialisations (archetype or template idem), but at runtime the order isn’t guaranteed to be stable, and we needed stable identification for linking data. I would suggest first to hasten the migration to adl2.4/3. And second to adopt the pattern from adl2 in adl1.4 in the interim, or at least be very careful to have an easy migration path. --- ## Post #30 by @pablo [quote="joostholslag, post:29, topic:5056"] at runtime the order isn’t guaranteed to be stable, [/quote] Interesting. Do you mean the order of the items in the data, right? I don't think ordering should play a role in this. The issue of not being able to identify sibling nodes with the same archetype_node_id in the AOM side is the first part, then the second part is we need to be able to: given any object in a RM data instance, find the specific C_OBJECT constraint that defines that RM object, which means, we need to be able to store that extra identifier (differentiator) in the RM, and in the AOM to comply with the first part. But that identifier/differentiator in the AOM or RM shouldn't depend on the position (position based identifiers are too 90's hehe). Thinking about this requirement, I guess "sequence" is not a good name, since it implies some dependency on the position of things. I don't know how all that works in AOM 2, but if the second requirement I mentioned above depends on the position of objects, we are screwed... If that's the case, maybe you can mention that to the new ADL3 editors so they can contemplate the requirement hopefully remove any dependency on position/based IDs or indexes. --- ## Post #31 by @thomas.beale [quote="pablo, post:26, topic:5056"] If we scale this for new questionnaires we might end up with 100s of archetypes for questions, which we will need to manage in time, and templates will need to be regenerated with each change to an archetype, having also to manage dependencies [/quote] You will - that's unavoidable if questionnaires are to be properly managed. [quote="pablo, post:26, topic:5056"] IMO the terminology-like approach moves that away from openEHR modeling. [/quote] Well you can still use terminology to represent question texts, descriptions and so on, with the archetype-based modelling style. Unless you are changing questionnaire structures, very few changes will be needed in the archetypes - changes to terminology will take care of most needs. But you'll have properly semantically distinguished questions rather than just data level clones. [quote="pablo, post:26, topic:5056"] Duplicating sibling nodes in the template is not new. Check the template with multiple sibling SECTION.adhoc [Template: International Patient Summary [openEHR Clinical Knowledge Manager]](https://ckm.openehr.org/ckm/templates/1013.26.376/opt) The only differentiator for C_OBJECTs is the name constraint at the section level. [/quote] Right - that is just creating data instance clones that are all instances of one 'adhoc section heading' concept. This is not the same as what you want to do. [quote="joostholslag, post:29, topic:5056"] We used ADL2 so, node identification of sibling nodes in adl2 specialisations (archetype or template idem), but at runtime the order isn’t guaranteed to be stable, and we needed stable identification for linking data. [/quote] How do questions get out of order? --- ## Post #32 by @joostholslag [quote="pablo, post:30, topic:5056"] Interesting. Do you mean the order of the items in the data, right? [/quote] Yes, the sibling identification in specialisations (like templates) has been solved in adl2 in my experience. But just the idx’.x’ syntax doesn’t solve a consistent order in the data. So the problem I described is related but not identical. [quote="pablo, post:30, topic:5056"] we need to be able to store that extra identifier (differentiator) in the RM, and in the AOM to comply with the first part. But that identifier/differentiator in the AOM or RM shouldn’t depend on the position (position based identifiers are too 90’s hehe). Thinking about this requirement, I guess “sequence” is not a good name, since it implies some dependency on the position of things. I don’t know how all that works in AOM 2, but if the second requirement I mentioned above depends on the position of objects, we are screwed [/quote] Agree, and it doesn’t: we used the ELEMENTs LOCATABLE.uid as a constant identifier of a specific node (in data). Many situations, the nodeid in adl2 itself is fine for identification, but if there’s reason to expect changes in the nodeid (order) there’s an optional attribute for consistent identification. [quote="thomas.beale, post:31, topic:5056"] How do questions get out of order? [/quote] Well, the questions in Pablo’s example don’t get out of order if you define them in an (adl2) archetype or template. But the data for a multiple occurrence item can get out of order. In our situation it was parts of an episodic care plan composition with lists of problems, with goals, with actions, grouped by sections, where the order of nodes in the list could be edited by the user to indicate priority. https://archetype-editor.nedap.healthcare/advanced/plan/archetypes/openEHR-EHR-COMPOSITION.plan_element-SFMPC.v1.0.0 https://archetype-editor.nedap.healthcare/advanced/plan/archetypes/openEHR-EHR-COMPOSITION.plan-SFMPC.v0.3.0 --- ## Post #33 by @thomas.beale [quote="joostholslag, post:32, topic:5056"] But just the idx’.x’ syntax doesn’t solve a consistent order in the data. [/quote] Those numbers do not indicate lexical order... but whatever the codes are, the lexical order of archetype nodes in the ADL is significant (hence the 'before' and 'after' operators). [quote="joostholslag, post:32, topic:5056"] Well, the questions in Pablo’s example don’t get out of order if you define them in an (adl2) archetype or template. But the data for a multiple occurrence item can get out of order. [/quote] Right. The archetype cannot guarantee anything about that. --- ## Post #34 by @joostholslag [quote="thomas.beale, post:33, topic:5056"] Those numbers do not indicate lexical order… but whatever the codes are, the lexical order of archetype nodes in the ADL is significant (hence the ‘before’ and ‘after’ operators). [/quote] I thought you might say that, and I don’t know our exact reasoning anymore. And I no longer have access to nedap documentation. @MattijsK do you? But given the complexity of a care plan: multiple parties editing, across organisations, and potentially life long currency on the one hand and the importance of semantic correctness of the link on the other (clinically and potentially for determining authorisation scopes) I still feel it much safer to add a uid to a data node. The spec text states it’s intended for root nodes, but I don’t see much issue with this usage, does anyone? --- ## Post #35 by @pablo [quote="thomas.beale, post:31, topic:5056"] You will - that’s unavoidable if questionnaires are to be properly managed. [/quote] It's different if this is managed by the openEHR process, than an external process specific for this use case. [quote="thomas.beale, post:31, topic:5056"] [quote="pablo, post:26, topic:5056"] IMO the terminology-like approach moves that away from openEHR modeling. [/quote] Well you can still use terminology to represent question texts, descriptions and so on, with the archetype-based modelling style. [/quote] What I wrote in the article is not about using terminologies to handle the question texts, is about using ideas from terminology management to manage complete question definitions. That is why I mentioned "terminology-like approach" than creating a terminology for questions. I think we are getting lost in translation here :) [quote="thomas.beale, post:31, topic:5056"] Right - that is just creating data instance clones that are all instances of one ‘adhoc section heading’ concept. This is not the same as what you want to do. [/quote] That is creating clones of the AOM nodes and adding constraints over the name. This is exactly what I'm doing. I don't think "data instance" apply here, since it's all AOM, not RM. Then when we have a RM data instance, we need to know which C_OBJECT corresponds to each question node in the RM instance, and we need to find the C_OBJECT by the archetype_node_id of the LOCATABLE instance and use the LOCATABLE.name value to find the C_OBJECT that has a constraint that matches that name (the one that validates), the issue is there are two C_OBJECTs which this constraint passes for the sane name value. This is the limitation we are facing. IMO there should be possible to add to the C_OBJECTs, in the archetype or template instance, that fall into this category, an extra differentiator code, ID, etc. And tooling should be able to detect this situation and add those differentiators accordingly. Of course this is not in the current 1.4 spec. --- ## Post #36 by @thomas.beale [quote="pablo, post:35, topic:5056"] What I wrote in the article is not about using terminologies to handle the question texts, is about using ideas from terminology management to manage complete question definitions. That is why I mentioned “terminology-like approach” than creating a terminology for questions. [/quote] Yep, I wasn't precise, but I did get that you are managing question texts in a private terminology-like approach, which makes sense to me. [quote="pablo, post:35, topic:5056"] That is creating clones of the AOM nodes and adding constraints over the name. This is exactly what I’m doing. I don’t think “data instance” apply here, since it’s all AOM, not RM. [/quote] Aha - but AOM structures are somewhere between the reference model (which is just the model of kinds of Lego bricks, and how they stick together) and real data which is Lego dogs, tractors and helicopters. Template structures often get very close to the final data. So it's not a binary distinction, there's a continuum here. [quote="pablo, post:35, topic:5056"] Then when we have a RM data instance, we need to know which C_OBJECT corresponds to each question node in the RM instance, and we need to find the C_OBJECT by the archetype_node_id of the LOCATABLE instance [/quote] So far so good. [quote="pablo, post:35, topic:5056"] and use the LOCATABLE.name value to find the C_OBJECT that has a constraint that matches that name (the one that validates), the issue is there are two C_OBJECTs which this constraint passes for the sane name value. [/quote] This is not the usual thing to do. Consider: what you are trying to do here is semantically disambiguate 2 data instances based on the constraints of their name field. But there's a much easier way to mark data semantically: create it based on semantically distinct archetype nodes, which means: define your nodes (questions or whatever they may be) as proper nodes. Now the node codes (id-codes in ADL2) will be in the data and you can instantly tell them apart. Different name values but same archetype node id means: these are (multiple) instances of the same semantic thing, just distinguished by some other field that corresponds to their creation, typically time, but it could be some other contextual property. [quote="pablo, post:35, topic:5056"] IMO there should be possible to add to the C_OBJECTs, in the archetype or template instance, that fall into this category, an extra differentiator code, ID, etc. And tooling should be able to detect this situation and add those differentiators accordingly. [/quote] There's actually nothing in the AOMs/ADL2 spec that says you can't add new C_OBJECT nodes in a template, but most probably don't handle it, or even prevent it. The reason is that it's always easy just to create some local specialised archetypes to model the local content you want - this will get you archetype code per node. Then build the template to define the questionnaire. [quote="pablo, post:35, topic:5056"] Of course this is not in the current 1.4 spec. [/quote] Most interesting archetype semantics are not in the ADL1.4 spec - we stopped developing it 15 years ago ;) --- ## Post #37 by @pablo [quote="thomas.beale, post:36, topic:5056"] Yep, I wasn’t precise, but I did get that you are managing question texts in a private terminology-like approach, which makes sense to me. [/quote] Just to clarify: what would be a concept or term in a terminology, is a: question text + question answer type + question answer multiplicity + question answer options. All that is one single concept that is managed in the "questionnaire service" like terms or concepts are manged in a "terminology service". [quote="thomas.beale, post:36, topic:5056"] Aha - but AOM structures are somewhere between the reference model (which is just the model of kinds of Lego bricks, and how they stick together) and real data which is Lego dogs, tractors and helicopters. Template structures often get very close to the final data. So it’s not a binary distinction, there’s a continuum here. [/quote] I understand your point. Though the model is almost the same for AOM/TOM in terms of how constraints are defined. I know we are defining the constraints at the template level, and closer to the final data structure in the RM, but the problem with the non-unique sibling nodes is still there. Even if we were not using templates, the archetypes have the same issue. So the problem is not really at which level we are defining the data, which has more to do with the orthogonal discussion about questionnaire modeling, the initial discussion is the AOM identification thing. We are mixing two conversations :) [quote="thomas.beale, post:36, topic:5056"] Different name values but same archetype node id means: these are (multiple) instances of the same semantic thing, just distinguished by some other field that corresponds to their creation, typically time, but it could be some other contextual property. [/quote] Remember we are reusing the same generic archetype for each question, the the specific questions are at the template, complying with that generic archetype. We can go with this discussion forever, the challenge is to define different semantic levels and semantic boundaries as a framework we can use for the discussion. Until we have a mathematical definition of that, there is a grey area. What I see is: the RM is the base semantic level for the structure of general concepts. Archetypes can define more semantics, and different levels of them, since we have specialization, but the boundary is all concepts defined at the archetype level should be general use. Then the 3rd is the final semantic level, that adds semantics and constraints over the archetype level, for specific use. Then there are other semantic levels that are not in the scope of openEHR. Considering that, our questions are for specific use, so my criteria is to put that at the template level, but we need the underlying archetype structure so we can base our templates on something, though we don't need much specific structure there, so the archetypes are pretty generic. Now, with that context, we have the AOM/TOM node identification issue. Of course our hypothesis could be argued, but I consider it makes sense, though I by no means claim this is the only way, though I believe it's conceptually and technically correct. [quote="thomas.beale, post:36, topic:5056"] Most interesting archetype semantics are not in the ADL1.4 spec - we stopped developing it 15 years ago :wink: [/quote] Sadly openEHR focus shifted away from the AOM spec and just recently understood we needed more at that level, and here we are discussing limitations of the most widely used AOM version :slight_smile: --- ## Post #38 by @thomas.beale [quote="pablo, post:37, topic:5056"] Remember we are reusing the same generic archetype for each question, the the specific questions are at the template, complying with that generic archetype. [/quote] Right - but semantically that's a/the problem. The question / answer possibilities 'have you ever smoked?' are not just a runtime data variant of the question / answer possibilities for 'Did you ever have a heart problem?' [quote="pablo, post:37, topic:5056"] the RM is the base semantic level for the structure of general concepts [/quote] Right; it also forms the upper ontology of epistemic primitives for the domain models, expressed as archetypes. [quote="pablo, post:37, topic:5056"] all concepts defined at the archetype level should be general use [/quote] Well - more like use-case independent use. Don't forget, archetypes can be specialised purely for local reasons, e.g. adding some funny data point to the usual collection for heart rate or whatever. So they won't be used outside of the teaching hospital doing that. But within any deployment, locally specialised archetypes are generally applicable - you still need to create templates or other artefacts (e.g. workflows) that use them. [quote="pablo, post:37, topic:5056"] Then the 3rd is the final semantic level, that adds semantics and constraints over the archetype level, for specific use. [/quote] The template level is conceived of as providing two functions to create use-case specific data set definitions: * aggregating elements from specific archetypes (including 'removing' those not needed) * narrowing constraints (particularly terminology) to correspond to local use By convention, template modellers don't add new data points. For one thing, 'template modellers' almost always corresponds to non-domain experts, more like business analysts or even just normal developers. They assume all the semantics have been worked out; they try to build data sets that will provide the data for forms in their software; plus implement local terminology bindings. [quote="pablo, post:37, topic:5056"] Sadly openEHR focus shifted away from the AOM spec and just recently understood we needed more at that level, and here we are discussing limitations of the most widely used AOM version :slight_smile: [/quote] Well all the semantics are in the ADL2/AOM2 specs. Much of the semantics that are implicated in this discussion just can't be accommodated in ADL1.4, because it doesn't do specialisation (in ADL1.4, an archetype is a flat archetype, not a differential). It also has a terrible coding system and other undesirable problems. For any question about how to do archetypes properly, I have always directed people to the ADL2/AOM2 specs, even if concretely they had to find a way to implement the ideal approach in 1.4 tools. Today, the most used tool - Better's AD - has had AOM2 inside it for at least 5 years (I suspect closer to 7 or 8). It's not a perfect system, and it doesn't do everything , but it does have a reasonable amount of internal coherence. --- ## Post #39 by @siljelb I'm struggling to understand how moving the complexities of representing the specific semantics of questionnaire questions (where they matter) from the archetype level to the template level solves anything. To my understanding the only real gain is additional complexity. The current principles for modelling questionnaires in openEHR can be summed up as the following: 1. Most questionnaires are ad-hoc garbage, and their exact semantics don't matter outside of the context of the questionnaire itself and immediate reuse situations. Semantically it doesn't matter too much how these are modelled, but the Screening questionnaire archetypes have been created to simplify the creation of yes/no/unknown structures, together with context information like terminology codes for a diagnosis, and temporal information. As @heather.leslie mentioned earlier, this simplifies the common requirement to transfer questionnaire based information into corresponding positive-presence archetypes such as Problem/diagnosis. 2. Questionnaire questions which have been deliberately designed and verified by research, for example NEWS2 or PROMIS, need to be modelled in such a way that they can be uniquely identified across use cases. This is why these are modelled as specific archetypes, either as a complete tool like NEWS2, or as item banks which can be combined in a template like PROMIS. (Note that the PROMIS question banks are much larger than the current archetypes, and the intent was to grow the archetypes as the remaining questions are required.) Is the problem you're trying to solve the ad-hoc or the deliberate, @pablo? Or is it even a third category that we haven't previously identified? --- ## Post #40 by @heather.leslie +1 @siljelb Despite the significant pushback from the most experienced international openEHR modellers, both in this thread and on LinkedIn, it is concerning that software engineers are intent on solving a technical modelling problem in complete isolation of any collaboration with the modelling community, especially not considering what would improve the current situation, or be sustainable or governable. --- ## Post #41 by @thomas.beale [quote="siljelb, post:39, topic:5056"] Most questionnaires are ad-hoc garbage, and their exact semantics don’t matter outside of the context of the questionnaire itself and immediate reuse situations [/quote] I am reminded of an NHS questionnaire I had to fill out as a new patient in a local GP surgery. It had the question 'have you ever had heart trouble?'. I was thinking - heart attack (no)? Arrhythmia (yes - atrial fibrillation)? Angina (stable, unstable... no)? etc. Anyway, that's a good distinction @siljelb . There's a lot of garbage out there, but a surprising number of well-designed questionnaires as well. In my view, the proof of a 'good questionnaire' is that when filled out by respondents uncoached (except possibly by instructions in the questionnaire text itself), the results are the same for the same real world conditions being reported on. That means the questionnaire can act as a useful triage tool. --- ## Post #42 by @heather.leslie I would frame a 'good' questionnaire simply as one that gets the job done. They can be 'garbage' from a pure design point of view - I really don't mind. Let local archetypes be used as messily and frequently as needs be if they provide value at that local level. But, please, let's all agree not to encourage 'garbage' archetypes or even data elements to be shared or reused. In contrast, I care enormously about how to try to converge the common use cases toward higher quality, standardised models. The approach that we've outlined previously is the current collective modelling view that best suits that goal. Creating a 'questionnaire service' fulfils a technical and theoretical goal to support reuse, but simultaneously misses the semantic goal of : - promoting the reuse of high-quality, semantically unambiguous questions that converges data, and - guiding future modellers on how to build better quality questionnaires, even ones that could be broadly reused in multiple languages. Can we manage a massive questionnaire proliferation? Remember, it is not just adding an archetype here or there, but involves maintenance across languages, terminology binding and governance? What happens where questions conflict - do we care? should we care? I think it is our role to care, and I strongly suspect this approach is unsustainable, or it will not provide the value and end-solution that we all seek. The screening questionnaire family of archetypes in CKM is the starting point for converging common patterns for common concepts - a baby step towards higher quality, standardised questionnaires. Without this approach, the questions in the mindmap, below, are good examples of what would likely be proliferated in the proposed questionnaire service. These questions came from one project I worked on nearly 15 years ago. It has shaped the current clinical modelling approach and I use it as an example of **what not to do** in all my modelling training. ![image|690x321](upload://40janOkP3MxDfx3JraCnVAnZtBF.jpeg) The context: 15 years of questionnaire data captured by a SINGLE organisation. The resulting 83 data dictionaries (published in 83 Excel spreadsheets) represented 7 different cancers. Over those 15 years, they had 4 different data managers, each tweaking and improving the data dictionary ever so slightly… all with the absolute best of intentions! :grimacing: When I was engaged by this client my first step in analysis was to deconstruct each of those 83 spreadsheets to identify common concepts within each. This mindmap is the result of gathering all of the smoking-related questions in one place. The resulting archetypes provided the client with a visualisation of the inconsistency in their data and they were so horrified, that they stopped the project to try to harmonise their data for each disease. The potential number of questions that can be 'questionnaired' is probably never-ending, because no one tends to think of the underlying patterns, nor of the consequences of the question design - they just want 'their question'. This is the same thinking that every vendor has used when they design their unique, special and proprietary data format over the previous 60 years. Instead, we need to find ways to provide some guidance and nudges towards improving quality: - What is the concept? Is the focus on the data collection on cigarette smoking? Tobacco smoking, from all forms? All smoking, including non-tobacco? If tobacco, then is it about smoking or non-smoking use? - Is it about typical use, including episodes of use? Or about actual use - on a specified date, over the past 3 days, average over the past 5 years or amount between the ages of 20-30? - What conclusion can be determined if a single question containing multiple variables has a simple binary answer? There are many examples in that mindmap, designed by experienced and well-published researchers! Common screening topics/patterns already represented in CKM: - Published - -- Diagnostic investigation screening - what tests have you had? -- Exposure screening - what health risks have you been exposed to - smoke, noise, asbestos, infectious diseases? -- Management screening - what has been done to you? -- Medication screening - what are you taking? -- Symptom/sign screening - what are you experiencing? -- Problem/Diagnosis screening - what problems do you have? -- Procedure screening - what operations/surgeries have you had? -- Social context screening - social isolation, dependents, homelessness, interpreter need -- Travel screening - where have you been travelling to, under what circumstances? - In review -- Substance use screening - tobacco, alcohol, other drugs - Draft -- Family history screening - do you have any family health issues we need to know about? -- Medical device screening - do you have any implants we need to know about eg before you get in the MRI? At the very least, each of these OBSERVATIONs focuses common questions into an ENTRY level model that will support potential querying at concept level. The screening questionnaire archetypes are effectively hybrids between a 'single source of truth' archetype and a generic one containing zero semantics. They are deliberately loosely modelled to start to provide some pattern guidance on how to screen for health information. Templates can be then used to support local variations of questions within the context of these common patterns. In the future, maybe we will start to govern templates that are built on these patterns, always aiming towards convergence and governability, rather than random proliferation. As a community, software engineers and clinical modellers (especially the CKM Editorial leaders) need to co-design solutions together, that bring the expertise of both into the openEHR offerings. We need to solve problems by investigating both the technical opportunities and modelling approaches, and then make collective decisions on a joint approach. Unilateral solutions only create divergence, fragmentation, and pulling in different directions. What we also know from Stan's experience is that the CEM proliferation was not governable, so much so that he initiated the CIMI project so that the model governance would be lifted from a single data element to more sustainable groupings, aka CIMI archetypes. We must learn from that experience and not repeat it. --- ## Post #43 by @ian.mcnicoll Without disagreeing with Heather's excellent summary, and re-iterating that this approach is working very well in our projects, it would be good to better understand the sort of use-case you are trying to manage @pablo . Do you have an example of the original questionnaire and the resulting template that you are generating? I do wonder if we are talking at slight cross-purposes? --- **Canonical:** https://discourse.openehr.org/t/missing-rule-in-aom-1-4-for-non-unique-sibling-nodeids/5056 **Original content:** https://discourse.openehr.org/t/missing-rule-in-aom-1-4-for-non-unique-sibling-nodeids/5056