# Option to record free text as choice against DV_CODED_TEXT - do we need DV_PLAIN_TEXT **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2020-04-30 10:07 UTC **Views:** 2232 **Replies:** 72 **URL:** https://discourse.openehr.org/t/option-to-record-free-text-as-choice-against-dv-coded-text-do-we-need-dv-plain-text/623 --- ## Post #1 by @ian.mcnicoll There is an established use of the DV_TEXT/DV_CODED_TEXT choice pattern to allow 1. extension/replacement of internal code lists (better solved by the proposed changes to allow for 'extensible' etc. 2. To allow a free text to be used in place of a coded text, where none is available. As an example, the Adverse reaction archetype is intended to be used in the UK with a very strict SNOMED valueset, so that it can power decision support across systems . So in this case the valueset is 'required' and not 'extensible', However we do recognise that very occasional allergies need to be recorded against drugs that currently have no coded terms e.g new medications, trial drugs, foreign products. in FHIR the 'extensible' valueset binding allows for a free text extension (against their CodableText datatype) but that would not work for us technically , and also is, for me, not quite right semantically. In the UK use-case I want ot strictly control the coded valueset so it should be 'required' and not 'extensible'. The good news is that with the changes to valueset binding strength, we can make the DV_TEXT/CODED_TEXT option work for this. The bad news is that it leaves open a problem that Fabio highlighted in Braunschweig -- If we leave DV_TEXT as an alternate through to run-time (or a template-level) it can always potentially be sub-classed to a DV_CODED_TEXT, and therefore subvert any existing constraints on the existing DV_CODED_TEXT valueset bindings. i.e I could then use any coced valueset I wished. This is one of the issues that is blocking full adoption of ADL2 in AD. Possible solutions... 1. Add an attribute to DV_TEXT this signifies it as 'final' ie. not able to be sub-classed to DV_CODED_TEXT 2. Add new sub-class to DV_TEXT alongside DV_CODED_TEXT as DV_PLAIN_TEXT. In practical terms when, as modellers we want to use the Choice option, we would use DV_PLAIN_TEXT/DV_CODED_TEXT as the normal choice. I think this solves Fabio's issue. --- ## Post #2 by @Seref [quote="ian.mcnicoll, post:1, topic:623"] DV_PLAIN_TEXT [/quote] I think option 2 of having a DV_PLAIN_TEXT is the better one. openEHR by design prefers types over codes to express semantics (or that's my incorrect view of it :) ) A type fits better into overall methodology, tooling and implementations for this particular requirement. No runtime surprises for DV_PLAIN_TEXT since it has no descendants, communicates a modeller's explicit request/wish to use free text. Sounds good to me. --- ## Post #3 by @ian.mcnicoll There are some possible use cases for DV_PLAIN_TEXT where we do explicitly want to prevent the use of coded_text e.g. a narrative comment. --- ## Post #4 by @thomas.beale [quote="ian.mcnicoll, post:1, topic:623"] The bad news is that it leaves open a problem that Fabio highlighted in Braunschweig – If we leave DV_TEXT as an alternate through to run-time (or a template-level) it can always potentially be sub-classed to a DV_CODED_TEXT, and therefore subvert any existing constraints on the existing DV_CODED_TEXT valueset bindings. i.e I could then use any coced valueset I wished. [/quote] i.e. sub-classed to create an 'alternate' DV_CODED_TEXT constraint, alongside the other one that you already created? (Just trying to remember the details of the problem here). If I understand the need correctly, neither of the solutions helps, because they are in RM-land. Instead we would need something extra in the AOM2 model that relates to RM type removal or similar, [as explained here in the ADL2 spec](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_remove_specified_subtypes). In theory, if you just put something like the following it should work: ``` value ∈ { DV_CODED_TEXT[id4] ∈ { ... } DV_TEXT[id5] occurrences ∈ {0} } ``` I don't have an example of this in the spec, and it's unusual (that's because DV_TEXT is a concrete, i.e. instantiable type, which is not that common in good OO models); I also have never tried it in tools. Would be interesting to see what Archie does - maybe @pieterbos could make a little test? I'll try in ADL WB when I get the chance. BTW, we did have DV_PLAIN_TEXT a long time ago, and every so often I think of putting it back in, if we want to represent a 'text' type that can never be instantiated by a coded text object at runtime. But I can't see how it helps the problem described here. --- ## Post #5 by @pieterbos Yes you can do this in ADL 2. I just tried with Archie and our editor: parent archetype: value ∈ { DV_TEXT[id5] } Now if you create the following child archetype: value ∈ { DV_CODED_TEXT[id5.1 ] ∈ {.....} } DV_TEXT[id5] will be gone and replaced by DV_CODED_TEXT[id5.1] in the flat form. This is because of ADL 2 spec, section 9.2.5, object node constraints, case REFINE an existing node. Basically anything with effective_occurrences () returning {1} in the parent will be replaced in case of specialisation, and that's the case for a single valued attribute. So occurrences matches {0} is not needed here, done automatically If you want to keep both the DV_CODED_TEXT and the DV_TEXT option, all of the following will work in Archie in ADL 2: - Add a DV_TEXT[id5.2] to the child archetype after or before the DV_CODED_TEXT - Add a new DV_TEXT[id0.1] node to the child archetype, after or before the DV_CODED_TEXT - specialize the ELEMENT instead of the value, so you get two elements (perhaps not desirable) I would prefer the first option, although the semantics of this case are perhaps not entirely described in the spec. If I remember correctly, Archie handles these kinds of specialisation of nodes exactly the same as the ADL workbench. If you could check with this example @thomas.beale? I would say this does not need fixing in ADL 2, but might need a bit of clarification specifically for these cases. If anyone wants to play around with these things in ADL 2, send me a message on slack and I'll give you access to our ADL 2 editor. It allows you to edit by GUI and by text editor, it validates archetypes, displays differential, flat and operational template forms, plus JSON data examples of the resulting RM data. Bit of an expert tool, but I would say this is the right audience for that. And Archie usually follows the spec meticulously with these things. --- ## Post #6 by @pieterbos Oh and if your parent is: value matches { DV_TEXT[id4] DV_CODED_TEXT[id5] } Then in the child archetype or template you can do: value matches { DV_TEXT[id4] occurrences matches {0} DV_CODED_TEXT[id5.1] ∈ { ... } } To get rid of the dv_text while specializing the coded text. --- ## Post #7 by @ian.mcnicoll That's not the issue though, I can already remove the DV_TEXT constraint if I wish (not sure what happens under te hood) I want to keep the original DV_CODED_TEXT constraint AND the original DV_TEXT but do not want it to be allowed to be sub-classed to a DV_CODED_TEXT constraint. I need to keep the option open of having the original DV_CODED_TEXT constraint OR 'plain text'. --- ## Post #8 by @thomas.beale In that case, apologies, I have misunderstood your original post... So if you want to be able to end up with a 'coded-only' constraint and a 'text-only' constraint, but not one that can be turned into a coded-text instance, then we would need an RM class of which that is an instance, i.e. DV_PLAIN_TEXT. I'm still not sure I get why the remaining DV_TEXT is a problem in the Archetype Designer though... because even if it still says DV_TEXT in the archetype, at runtime, you can always instantiate a DV_CODED_TEXT, since its a technical sub-type. Is there a reason to block that? It seems to me what you are really after is something that says 'this here DV_CODED_TEXT constraint is the only one allowed, no alternatives (of the same RM type)'? --- ## Post #9 by @ian.mcnicoll [quote="thomas.beale, post:8, topic:623"] So if you want to be able to end up with a ‘coded-only’ constraint and a ‘text-only’ constraint, but not one that can be turned into a coded-text instance, then we would need an RM class of which that is an instance, i.e. DV_PLAIN_TEXT. I’m still not sure I get why the remaining DV_TEXT is a problem in the Archetype Designer though… [/quote] Yes .. exactly. [quote="thomas.beale, post:8, topic:623"] because even if it still says DV_TEXT in the archetype, at runtime, you can always instantiate a DV_CODED_TEXT, since its a technical sub-type. Is there a reason to block that? [/quote] Because I have already defined a 'required' codeset but also need to keep a plain text option open but do not want that DV_TEXT to be redefinable downstream. Ultimately I do really want to say This DV_CODED_TEXT constraint OR any DV_PLAIN_TEXT (semantically, speaking) --- ## Post #10 by @pieterbos But it is always possible to add a node in a child archetype, so you can **always** add a new DV_CODED_TEXT and remove the DV_TEXT, even with a new 'final' text data value type. To do what you want you would probably need add a way to block redefining the constraint and block adding new object constraints to the attribute. Also I am not sure why you do want want the DV_TEXT to be redefinable downstream. Why wouldn't you, and what goes wrong if someone does make it a DV_CODED_TEXT? --- ## Post #11 by @pablo In programming languages that is solved with the "final" keyword, that makes a type to not be extendable. I like solution 1. In openEHR, the "final" keyword could be applied in archetypes or templates, in the C_OBJECT type. So a constraint for a DV_TEXT could be "final" without having a new type. Also I think by adding that keyword, we extend the constraint model with a very common object-oriented constraint we currently don't support. --- ## Post #12 by @Seref Please note that final keyword (and its synonyms) applies to classes in most OO languages. Using it here would mean the semantics would have to hold during runtime, most likely for a field of a class and result in breaking the Liskov substitution principle. In other words, implementation of this for validation and runtime representation in OO languages look problematic to me. Happy to be corrected if I'm missing something here --- ## Post #13 by @ian.mcnicoll Hi Pieter, What goes wrong is that I want to lockdown the system to a) A choice of coded texts from a required external valueset i.e only SNOMED CT codes which are either allergy codes or medication codes OR b) a piece of free text. I do not want to allow someone to be able to enter any other coded_text. If I leave DV_TEXT in the final constraint, alongside the DV_CODED_TEXT external valueset which I currently need to do to satisfy (b) , then that can be sub-called at runtime and allow the system to add any code they like. I'm not talking about adding new nodes in a child archetype, this is very largely about templating. --- ## Post #14 by @pieterbos In our implementation it's not so hard to build - just change the validation to do exact type checking when final, instead of exact or subclass in these cases, and change the archetype/template validations to not allow subclasses here. If you use archetypes to generate OO models/classes, that could be more difficult. But something like this is not enough: value matches { final DV_TEXT[id4] DV_CODED_TEXT[id5] matches {....} } Since you can still add DV_CODED_TEXT[id0.1] in a specialized archetype. You actually need to do something like: value no_new_c_objects_in_specialisations matches { final DV_TEXT[id4] DV_CODED_TEXT[id5] matches {....} } Since you probably do want to be able to specialize the DV_CODED_TEXT to limit the options available in a template. I really wonder if this does not cause more trouble than it solves. Modelling and templating already requires people to know what they are doing. Isn't this just part of modeling guidelines or advice, under the heading 'please don't'? --- ## Post #15 by @Seref [quote="pieterbos, post:14, topic:623"] just change the validation to do exact type checking when final, instead of exact or subclass in these cases, and change the archetype/template validations to not allow subclasses here. [/quote] That's my point. The programming artefact, i.e. some facade to RM instances or the RM implementation itself is allowing assignments of subtype values to a field of type X, but then it fails during runtime due to validation. We could always throw more tooling at it, but the essence of my objection is it is all because we'd be going against the nature of the underlying programming language. Why fight that uphill battle and deal with many complexities when adding a new type can solve the problem with less conflict? It is a design choice at the end, we may have different views of pros/cons, but your response helps me clarify mine, so thanks for it. --- ## Post #16 by @pieterbos I don't think a new type will solve this issue. You can then still do: value matches { DV_CODED_TEXT[id4] DV_PLAIN_TEXT[id5] } And specialise it with: value matches { DV_PLAIN_TEXT[id5] occurrences matches {0} DV_CODED_TEXT[id4] occurrences matches {0} DV_CODED_TEXT[id0.2] } In ADL 2 you can do this even in a template - no problem. --- ## Post #17 by @thomas.beale [quote="ian.mcnicoll, post:13, topic:623"] If I leave DV_TEXT in the final constraint, alongside the DV_CODED_TEXT external valueset which I currently need to do to satisfy (b) , then that can be sub-called at runtime and allow the system to add any code they like. [/quote] Right, technically that's true. But I agree with @pieterbos - you can program badly in every language under the sun, or do it well. Part of writing good models surely has to be good practice? Anyway, at the start you mentioned a technical problem with this structure in Archetype Designer that Fabio mentioned in Brauschweig. If we knew what is breaking in the tool, it might make it clearer what is 'wrong' with this structure? --- ## Post #18 by @thomas.beale [quote="Seref, post:15, topic:623"] The programming artefact, i.e. some facade to RM instances or the RM implementation itself is allowing assignments of subtype values to a field of type X, but then it fails during runtime due to validation. We could always throw more tooling at it, but the essence of my objection is it is all because we’d be going against the nature of the underlying programming language. Why fight that uphill battle and deal with many complexities when adding a new type can solve the problem with less conflict? [/quote] Right - going against basic OO polymorphic binding is not likely to be a good idea. (The reason 'frozen' works in some OOPLs is that it relates to code, not data items - I don't think doing this will help us here) So I would agree that having a DV_PLAIN_TEXT type is a more obvious option to achieve a 'pure text' DV type. But as @pieterbos pointed out, you can go on specialising forever... I think we need to look at changes that: * don't have unexpected side effects in normal models; * are not over-complex for tooling; * are intuitive for modellers. --- ## Post #19 by @ian.mcnicoll Sure, but it will not conform or validate correctly against the original template. - for a shared definition across a community. I want to be able to clearly state the rules around coding/ free text without resorting to implementation guidance and for that to be testable, as far as possible. We need to be able to hide the complexity of our space behind as simple a layer as we possible can without 'insider knowledge' , particularly as the scope of a CDR consumer goes beyond a single app developer, and into increasingly 'naive devs'. --- ## Post #20 by @ian.mcnicoll * don’t have unexpected side effects in normal models; * are not over-complex for tooling; * are intuitive for modellers. As this would be a new class it should not have any backwards compat issues. Any existing DV_TEXT could be (and should be left alone). I think this is much more intuitive for modellers. What we do now is really quite difficult to explain, especially as we already subvert the DV_TEXT choice to be sub-classed to DV_CODED_TEXT to get around the extensible valueset issue. We are solving that one of course. Use DV_TEXT if you cannot be sure if you will want or need codes. Use DV_CODED_TEXT if you will only ever want coded items ()but can be optionally extended) Use DV_PLAIN_TEXT if you want to enforce free text. Use DV_CODED_TEXT/DV_PLAIN_TEXT if you want to enforce coded valuesets (esp 'required' valuesets) but allow a free_text only get-out. That is way easier to understand and explain than the current situation - I will ask on the modelling channels for thoughts. In terms of TD and AD tooling, I think it would be pretty easy - DV_PLAIN_TEXT would just be another alternate datatype to be offered. The UI could be made more user-friendly but a minor tweak to what is there at the moment would work ok. --- ## Post #21 by @thomas.beale Thinking a bit more about this... if it's going to help, it's a reasonably easy change to make to the RM, we could add it into 1.1.0. Is the group convinced (apart from @ian.mcnicoll ;) ? I'm ok with the change, so if the consensus is to do it, we might as well do it sooner rather than later. It is also an easy change to make to the BMM files, and that is what drives ArchetypeDesigner, so the change will appear more or less instantly. It would be interesting to know if making the addition to the BMM (e.g. as a test) indeed fixes the problem @borut.fabjan reported last year. --- ## Post #22 by @pablo [quote="Seref, post:15, topic:623"] but then it fails during runtime due to validation. [/quote] Isn't that the whole idea of the AOM to validate RM instances? I don't see the issue, this is what we've been doing since day one in openEHR. The RM is just a container, the AOM is what allows to make sense and validate whatever you put in the RM. What I'm concerned about is to add solutions to modeling issues by changing the RM instead of the AOM, which is the model for modeling. If we need more constraints over the RM, we know that is at the AOM level. I would be happy to change the RM if we really need new RM semantics (new constructors), but not for new constraints. --- ## Post #23 by @thomas.beale [quote="pablo, post:22, topic:623"] Isn’t that the whole idea of the AOM to validate RM instances? I don’t see the issue, this is what we’ve been doing since day one in openEHR. [/quote] Just to be clear: yes ;) The sense of your response is 100% correct. It seems that modellers need a 'pure text' type (which we did actually have in an earlier design). I'm still not clear myself how this change would fix a problem in ArchetypeDesigner but hope we can find that out. --- ## Post #24 by @Seref Please re-consider the part of my response before the "but..." Let me try to rephrase my previous responses. We'd like as much of the validation to be done as early as possible during the software development lifecycle. If validation can be projected to programming language level, this stops the programmer from creating invalid data. Validation can always catch errors at a later stage, but by then, time is spent, code is written and figuring out what went wrong will take time. Especially if code created an instance of RM, then serialised it and pushed it to some openEHR API implementation. Now the error is caught by validation that happends all the way into some other system's stack, behind a REST api etc. Some constraints used in openEHR modelling are easier to map to programming languages and artefacts, some are harder. Using some sort of 'final' modifier at the modelling level is hard to enforce at the programming language level as I tried to briefly explain. Possible, but harder than the case where we introduce a dedicated RM type. Therefore, my preference to avoid a 'final' approach is based on my view of pros/cons of implementability. It is also based on an assumption of mainstream, statically typed programming languages such as C# or Java. Hope that clarifies it. --- ## Post #25 by @ian.mcnicoll Hi Thomas, Currently .oet based templates support the DV_CODED_TEXT/DV_TEXT construct, where coded_term constraints are introduced at template-level. This is not supported by ADL2, and my understanding from Fabio was that he was reluctant to add this capacity to AD, precisely because of the issue of people potentially working around strict coded_text constraints. Right now we can constrain a DV_TEXT to a DV_CODED_TEXT at template level in AD, but we cannot maintain any existing DV_TEXT 'choice' whether that exists in the original archetype, or we would like to be persisted as we subclass DV_TEXT to DV_CODED_TEXT. So it is not a limitation of the tool per-se but that Fabio was reluctant to implement the current arrangement until this was clearly support in ADL2 (along with some other issues that I have raised elsewhere). I may have go that wrong, and I'll try to get Fabio to confirm, but that's my understanding. As I understand it, this would resolve Fabio's discomfort, which I do understand. From a modelling perspective I have no preference re an attribute on DV_TEXTvs. a sub-class. I think the sub-class is easier to understand, particularly when we have to explain sub-classing of DV_TEXT to modellers anyway. There are definitely a few use-cases for PLAIN_TEXT apart from that. --- ## Post #26 by @thomas.beale [quote="ian.mcnicoll, post:25, topic:623"] Currently .oet based templates support the DV_CODED_TEXT/DV_TEXT construct, where coded_term constraints are introduced at template-level. This is not supported by ADL2, [/quote] This doesn't sound right to me. An [ADL2 template](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_example) is just more archetypes, with the addition of a structure that allows overlays to be 'inline' for the template (as we designed some years ago;). So there's no problem to add the same kind of coded term constraints as you can in an archetype. Or - are we talking about the strict v non-strict idea of 'introducing coded constraints' in a template? If that's so, we agreed on the fix for that, which is to add a `strength` attribute to `C_TERMINOLOGY_CODE` and a function to indicate `required()` (so a quick check can be done), as per [this discussion](https://discourse.openehr.org/t/dv-coded-text-with-open-extensible-set-of-codes-value-set/403/12?u=thomas.beale). So assuming we implement that, is there still a problem for AD? [quote="ian.mcnicoll, post:25, topic:623"] There are definitely a few use-cases for PLAIN_TEXT apart from that. [/quote] I'm fine with that. But let's deal with each issue in turn... --- ## Post #27 by @ian.mcnicoll I think we have (had) 3 issues around current .oet/.opt functionality that Fabio saw as a blocker. 1. THe issue around sub-classing DV_TEXT, as discussed here 2. the issue with 'loosening' coded_term constraints 'binding-strength' that we have resolved. 3. The ability of .oet to include 'in-line, extensional codesets (not bindings) i.e. rather than creating an internal list of atCodes, I can create an 'internal list' of SNOMED terms Example [here])https://ckm.apperta.org/ckm/templates/1051.57.259) under significant co-morbidities. We have started discussing this, but I don't think we have got it fully thought through. It is a bit of a complex space that includes the discussion on bindings/mappings. My understanding is that once these are resolved we are in a much better position to mode quickly to adopting AOM2 as the primary 'template' formalism. In discussion with Fabio, there were a couple of other 'technical' gaps related to embedded templates but nothing that would be a major blocker. --- ## Post #28 by @thomas.beale [quote="ian.mcnicoll, post:27, topic:623"] The ability of .oet to include 'in-line, extensional codesets (not bindings) i.e. rather than creating an internal list of atCodes [/quote] If I am not mistaken, this is about the question of what codes you actually want in the data - the at-codes or some 'native codes' that are in use, or even just SNOMED codes. This is about representation in data, not archetypes or template per se. [This is discussed in the ADL2 spec](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_from_constraints_to_concrete_codes_in_data). The reasoning there might need to be updated, so don't take it as gospel. However, the basic idea is that the choice of what kind of codes to store in the data (i.e. what do `CODE_PHRASE` instances look like) should be made in a stage of OPT generation. See the above discussion for examples. --- ## Post #29 by @ian.mcnicoll I'll have another look at that but choosing the optimal mapping/binding/defining_code into instance data approach, will ultimately need to be done on a per-element basis. It's not a generic per-template setting than can be applied. --- ## Post #30 by @thomas.beale Agree with that - take a look at the ref to see how it could be done (not saying there aren't better ways). --- ## Post #31 by @sebastian.iancu off-topic: Unfortunately I did not notice this thread in the last weeks, so I could not reply in time. For some unknown reason, lately I don't get right notification in discourse and neither new/active thread are not marked as new/unread. From my point of view, if we could somehow avoid having that new class DV_PLAIN_TEXT would be better, because I think otherwise it will make not much sense for newbies or clinical modeler, when they have to pick DV_TEXT vs DV_PLAIN_TEXT. Even with proper explanation, they will have to have good understanding of the ADL / AOM / archetype / template, or very clear user-friendly tooling. Plus, if we going to introduce this, I also expect that in next period a lot of (published) archetypes are going to be changed to follow the new pattern, which eventually will cause a chain reaction (or at least a presure) on RM/AQL/persistance implementations. From my point of view, if the goal is to block the extension of DV_TEXT alternative, then is reasonable to work on AOM / ADL for a 'final' kind of keyword. --- ## Post #32 by @ian.mcnicoll Thanks Sebastian, From a modelling POV, it probably does not matter too much in terms of education/training etc. We still have to explain the idea of sub-classing re DV_CODED_TEXT. Either way I would expect the tooling to help people do the 'right thing' e.g. if DV_TEXT wa sub-classed to DV_CODED_TEXT, I would expect the tooling to offer, either DV_TEXT with 'final' preset or DV_PLAIN_TEXT, as the default. Make it hard for people to do the wrong thing. We can make it easier still by asking very direct questions such as 'Do you want to allow free text, alongside this codelist' - the only disadvantage is that you disconnect the modelling view a little from the technical constraint that is given to devs which can then be hard to communicate. I also doubt very much if we would (either way) do a major retrospective routine update of archetypes. That should be non-breaking, in any case. So, I would consider this a purely technical decision. The impact on training/tooling etc is, I think going to be much the same, and manageable. I really do not have a strong preference between PLAIN_TEXT and 'final'. --- ## Post #33 by @ian.mcnicoll DV_NARRATIVE_TEXT as an alternative name? --- ## Post #34 by @sebastian.garde [quote="ian.mcnicoll, post:32, topic:623"] I also doubt very much if we would (either way) do a major retrospective routine update of archetypes. That should be non-breaking, in any case. [/quote] If we change it from DV_TEXT to DV_NARRATIVE_TEXT (or whatever we can call it), I think that needs to be considered as a breaking change (even if conversion is trivial where DV_TEXT is not a DV_CODED_TEXT)? DV_NARRATIVE_TEXT or maybe simply DV_UNCODED_TEXT sounds better to me than DV_PLAIN_TEXT in the light of the recent changes to DV_TEXT's *formatting* attribute. Having said that, I am still not sure I see a need that strong here that it justifies a new data type... If someone really wants to provide additional information by coding the alternative free text as well, is this really so bad that we need to prevent this at the cost of introducing a new data type? --- ## Post #35 by @thomas.beale Assuming we go ahead with this addition, I think DV_PLAIN_TEXT is still a better name, we just need to document it clearly to say that it's about text not something coded, i.e. the 'plain' is in contra-distinction to 'coded' (text). If we had our time again we might have gone for something like this: * DV_TEXTUAL * DV_TEXT * DV_CODED ... but we didn't... I'd say keep it simple and move on... --- ## Post #36 by @Seref I took some time to think about this discussion this morning and realised that I could not really see where exactly the problem is. I understand the mechanics of the issue, but I cannot see how that turns into a problem. I also thought about the pros and cons briefly discussed in yesterday's meeting and realised that we're looking at some hairy downstream changes in tooling and runtimes no matter which way we go. Can we have a description of the problem with clear definitions of actors affected by it and how exactly they are affected? Who ends up in a less than ideal situation and why? --- ## Post #37 by @thomas.beale Most of us had the same problem. Have a look at the first post again, Ian's bit on Fabio's problem in the tooling. So a little bit of clarity + coffee for me this morning made me realise the following: if you have an RM class (eg. DV_TEXT) that can itself be concretely instantiated and also has a concretely instantiable child(ren) (e.g. DV_CODED_TEXT), to enable a constraint to *enforce* the runtime instance to conform to the parent class, we need an ability to constrain a node to an instance of 'just this class', i.e. no child class instances. This is a generic OO model property, it's not specific to openEHR in any way, as all the devs/tech people here will know perfectly well (i.e. the fact that you can easily have instantiable parent classes, not only abstract ones up the inheritance hierarchy). To fix this, we need an additional constrainer flag on C_OBJECT in the AOM, something like 'rm_type_fixed'. Now, that is more or less the 'final' keyword that @sebastian.iancu was suggesting, and I think someone suggested 'frozen' as well. @Seref and I were against this, but I now think the variant I am talking about i.e. 'rm type fixed' is needed - maybe 'rm type frozen' or 'rm type final' are better names (I would agree). However... this doesn't fix everything... see @pieterbos's post (#16) above - you could still add another alternative, i.e. by this: ``` value matches { DV_PLAIN_TEXT[id5] occurrences matches {0} DV_CODED_TEXT[id4] occurrences matches {0} DV_CODED_TEXT[id0.2] } ``` We have another need: to be able to prevent the addition of any more 'alternatives' (single-valued attribute) or other children (container attribute). We [do have this on ARCHETYPE_SLOT](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_archetype_slot_class) already, it's called `is_closed`, i.e. closed to more 'filling'. I think we need this kind of idea but on C_ATTRIBUTE. That would prevent the situation Pieter was talking about. However, we are not done yet! @pieterbos thought of another case related to this, [see SPECAM-59](https://openehr.atlassian.net/browse/SPECAM-59). The idea here is to prohibit instances of some specific RM type while allowing others. I don't think this applies to our current case, since we don't want to prevent instances of DV_CODED_TEXT, we want to prevent *new constraints* for that type, subverting the existing constraint. I just mention this here for completeness, in case anyone thinks it does apply. So, I think to achieve everything @ian.mcnicoll and the clinical modellers want, we need to be able to write the following: ``` value closed matches { DV_CODED_TEXT[id4] matches {} DV_TEXT[id5] rm_type_final matches {} } ``` Those two keywords 'closed' and 'rm_type_final' achieve what we need: * no new alternative constraints e.g. in the template (or a child template) that could subvert the 2 constraints we have * no redefining of the DV_TEXT into DV_CODED_TEXT. I think this gets us out of needed any DV_PLAIN_TEXT. In any case, the above AOM capabilities can be justified with respect to any OO RM, so I think we should add them. If we still want DV_PLAIN_TEXT later, that will be another matter. Obviously how we make this 'easy to understand' on a tool UI is a question for tool designers. SEC: see if you can break this analysis; would be good if we can get @borut.fabjan to have a look as well. --- ## Post #38 by @Seref [quote="ian.mcnicoll, post:1, topic:623"] The bad news is that it leaves open a problem that Fabio highlighted in Braunschweig – If we leave DV_TEXT as an alternate through to run-time (or a template-level) it can always potentially be sub-classed to a DV_CODED_TEXT, and therefore subvert any existing constraints on the existing DV_CODED_TEXT valueset bindings. i.e I could then use any coced valueset I wished. [/quote] @thomas.beale I'm trying to follow this while debugging some code written by an idiot (named Seref according to git commit history) so I'll just say that you're still discussing the mechanics of the cure, without commenting on those said mechanics. What I cannot see in Ian's relayed message from @borut.fabjan is how a dv_coded_text constraint can be weakened. if a field is declared dv_text, it won't declare any terminology constraints. so the modeller should use a dv_coded_text, which cannot be implicitly overriden. Someone has to create a new archetype to weaken the term-set bindings of that. no sneaking up here. if the field is dv_text, the modeller already gave up on the option of constraining its value set/term set. This is why I'm confused. I cannot see the case the modeller is unable to protect their constraints via existing mechanisms. --- ## Post #39 by @thomas.beale [quote="Seref, post:38, topic:623"] if the field is dv_text, the modeller already gave up on the option of constraining its value set/term set. [/quote] So the starting point is the very common pattern: ``` value matches { DV_CODED_TEXT[id4] matches {} DV_TEXT[id5] matches {} } ``` which is intended to say: * EITHER match this terminology constraint * OR a plain text is ok (maybe limited in length or whatever) The design intention of the DV_TEXT in this circumstance really is 'just plain text here!!!' And that's the problem - you can always redefine a DV_TEXT in an archetype to be a DV_CODED_TEXT in a template or more specialised archetype, and that latter DV_CODED_TEXT can always subvert the constraint in a DV_CODED_TEXT node that you already have. --- ## Post #40 by @Seref I did write a comment expecting this, then deleted it, because I expected Ian to write this. The modeller, as I see it, is defining two options here. One of them is strictly controlled in terms of its terminology bindings, the other not. As per my comment yesterday, the archetype path of this node, along with its name, implies that the semantics of both options are the same, but in this case, they are not. so they should not be alternatives, they should have their own paths. Yes, someone can extend dv_text even then, and introduce a relaxed set for terminology values but that's clearly using the wrong node in the model when there is a dedicated node to provide coded data. The modeller can save a whole lot of others by making their concern explicit. There'll be some inconvenience to live with but compared to complexity of the remedies we're discussing here, I'd go for what I said above. Unless I'm missing something here. ps: I'd assume it would not be too difficult to catch this tricky condition in the modelling tools and warn the modeller. --- ## Post #41 by @thomas.beale [quote="Seref, post:40, topic:623"] As per my comment yesterday, the archetype path of this node, along with its name, implies that the semantics of both options are the same, but in this case, they are not. so they should not be alternatives, they should have their own paths. [/quote] Not sure I understand this bit - the two alternative constraints have distinct paths: * `.../value[id4]` * `.../value[id5]` You might be thinking in ADL1.4 terms, but in AOM2, every node has an id-code (it's just that not all id-codes have terminology definitions). So in the final data you can always tell which node the instance data conformed to. Indeed, you could have a DV_CODED_TEXT in the data containing a term that *doesn't match* the `id4` constraint, and it would still be allowed to match the `id5` constraint, since a `DV_TEXT` constraint node means 'a DV_TEXT instance, or an instance of any RM sub-type is ok here'. Which is exactly the thing we are trying to prevent, which is why we need to do something special. So for now, I am proposing only additions to the AOM, nothing on the RM. [quote="Seref, post:40, topic:623"] that’s clearly using the wrong node in the model when there is a dedicated node to provide coded data. [/quote] We humans know that, how to tell the tools that? :) --- ## Post #42 by @Seref Ok, I see what you mean now. I think my point re the misuse of [id5] still stands though, and it is not easy to enable that misuse either, unless you're using some sort of form generator approach that automatically allows a UI widget etc to offer dv_coded_text based input for every dv_text node in the archetype. I (currently) think, if we are to disallow this, some AOM level annotation approach would be the cleanest option, after having this discussion, but I'm very reluctant to make use of that anywhere but validation. Implementers can choose to do whatever they want of course, but there be dragons.. Anyway, this is all I can contribute today, hopefully I'll go over this again, if the above comments don't make sense, just ignore them on account of being made with less attention than the issue deserves. --- ## Post #43 by @ian.mcnicoll [quote="Seref, post:38, topic:623"] if the field is dv_text, the modeller already gave up on the option of constraining its value set/term set. [/quote] Ah but that is the key issue. In the UK allergies context I want to enforce the use of agreed terminologies but I also have t to accept that there are cases where only free text can be used (foreign drugs, experimental drugs). What I don't want to be used is any other kind of terminology. It's either use our agreed terminology constraints or free text - no other terminologies allowed. and I'm happy with the AOM suggestion. There is possibly some additional value beyond just the terminology issue. There are a few places where being able to prevent the use of codes in a DV_TEXT constraint i.e prevent sub-classing to DV_CODED_TEXT, would be valuable e.g where the purpose of the element is to carry pure narrative. --- ## Post #44 by @Seref I'm being very rude, I know, but how about telling the software implementer not to allow coded entry to dv_text field and let validation take care of your terminology constraint for the other field? It is not like models are thrown into a magic room where software comes from another room. these things are not meant to be and never turned into software fully automatically. I wish they could, we'd then all find new jobs and have normal lives... --- ## Post #45 by @ian.mcnicoll You are being rude but in this case 'English rude' but not 'Turkish/Scottish rude' , which is a whole other thing :wink: In the context of a single developer environment you are probably correct but it a world where we are trying establish the rules for a wide range of different downstream suppliers, the less we have to depend on written guidance, the better. We definitely need to get @borut.fabjan into the discussion as this was a real concern for him which he raised in Braunschweig. --- ## Post #46 by @thomas.beale [quote="ian.mcnicoll, post:43, topic:623"] There are a few places where being able to prevent the use of codes in a DV_TEXT constraint i.e prevent sub-classing to DV_CODED_TEXT, would be valuable e.g where the purpose of the element is to carry pure narrative. [/quote] So I think my `rm_type_final` proposal, or something close to it, will do what you want, even in circumstances other than the DV_CODED_TEXT + DV_TEXT situation. [quote="Seref, post:44, topic:623"] I’m being very rude, I know, but how about telling the software implementer not to allow coded entry to dv_text field and let validation take care of your terminology constraint for the other field? [/quote] Well sometimes you do want to allow this - maybe with other RM types like PARTY_PROXY and subtypes, or classes in another RM entirely. We need to be able to signal either design intention to the tools. --- ## Post #47 by @sebastian.iancu @thomas.beale proposal above seems to me a good one, and it might avoid introducing a new class as a patch (for the problem), and like @Seref mentioned, is a cleaner solution to the real problem. --- ## Post #48 by @matijap The not-yet-quite-expert-panelist @borut.fabjan does not seem to have access to this category. Could somebody grant that access to him? Does it matter whether he somewhat-formally agrees to his status of an expert? :slight_smile: --- ## Post #49 by @thomas.beale Not anymore. He can now see everything... --- ## Post #50 by @pieterbos For us the closed/rm_type_final part would be much easier to implement than a new data type - just add the changes in the AOM and the grammar, add two archetype validations and an RM object validation and this is fully supported. DV_PLAIN_TEXT would require changes to be made in any app that could potentially encounter the data type. If any apps exist that allow for a DV_TEXT to be replaced with a DV_CODED_TEXT at data entry time, so without template or specialisation, that will require work - but those require work for a DV_PLAIN_TEXT type as well. However, I still fail to see that this solves a real problem, and not just a theoretical one. We could also add a warning to the archetype validation if someone tries to specialise a DV_TEXT in a DV_CODED_TEXT in the specific case that another DV_CODED_TEXT alternative is already available, explaining why doing this is generally a bad idea and why any recorded data will fail to validate against the parent archetype. --- ## Post #51 by @thomas.beale [quote="pieterbos, post:50, topic:623"] We could also add a warning to the archetype validation if someone tries to specialise a DV_TEXT in a DV_CODED_TEXT in the specific case that another DV_CODED_TEXT alternative is already available, explaining why doing this is generally a bad idea and why any recorded data will fail to validate against the parent archetype. [/quote] I did also think of this, and indeed, we could go as far as stating it as a rule. It seems sensible but I suppose someone might eventually come up with a reason why it should not apply in some other circumstances... --- ## Post #52 by @Seref [quote="pieterbos, post:50, topic:623"] We could also add a warning to the archetype validation if someone tries to specialise a DV_TEXT in a DV_CODED_TEXT [/quote] [quote="Seref, post:40, topic:623"] ps: I’d assume it would not be too difficult to catch this tricky condition in the modelling tools and warn the modeller. [/quote] (here you go discourse. the post is not empty anymore happy? longer than 10 chars as well. never mind the above quotes you idiotic piece of code, force me to type this insisting the post can't be empty....) --- ## Post #53 by @ian.mcnicoll Thx Pieter, It would be good to get @borut.fabjan views as he was te one who raised the technical/philsophical concern. A closed flag is fine for me. I don't think it is a completely obscure or purely theoretical use-case. Possibly not a single company level but when developing cross-org standards being precise like this as per my allergies example, is something that experienced informaticians get angsty about!! I'm not too bothered about the warnings - that feels like a fair amount of work. As long as I can capture the requirements correctly and pass them on, that's enough for me. --- ## Post #54 by @pieterbos [quote="ian.mcnicoll, post:53, topic:623, full:true"] I'm not too bothered about the warnings - that feels like a fair amount of work. As long as I can capture the requirements correctly and pass them on, that's enough for me. [/quote] Archetype validators generally already have the ability to add warnings, and generally have all the necessary data available in its validators already, and tools can usually already show warnings. That means adding a warning is very little work, modelling tools do not need new features in their user interface, and modellers do not need to learn new concepts. It is less work than adding a feature to the AOM/ADL. I would say a new data type is even more work than that, but others might disagree. I think the choice of solution depends on a couple of things. If we use need a solution for this one single use case, adding a warning could be very well a very simple and effective solution. You do not have to do anything different when modelling - just when people try to specialise a DV_TEXT when there is already a different DV_CODED_TEXT they will automatically be warned that this usually is a bad idea unless you know exactly what you are doing, and if it could show these warnings in the CKM governance could be easy as well. If we need a closed/final keyword for more use cases, and/or if this really needs to be enforced and a warning is not enough, then that could be a better solution. I personally do not really like the idea of a new data type just for this purpose. I think it makes things more complicated to understand. --- ## Post #55 by @ian.mcnicoll Thanks Pieter, I guess I am seeing this more through the lens of regional/national standards development where the downstream consumers of the archetypes and templates or other derived artefacts/documentation will probably not be using archetype tooling. If I cannot capture 'nosubclassing' as part of the computable definition, I am reliant on implementation guidance. --- ## Post #56 by @pieterbos [quote="ian.mcnicoll, post:55, topic:623, full:true"] I guess I am seeing this more through the lens of regional/national standards development where the downstream consumers of the archetypes and templates or other derived artefacts/documentation will probably not be using archetype tooling. [/quote] Could you explain what you mean with not using archetype tooling? How are they going to specialise a DV_TEXT without using archetype tooling, especially when using ADL 2? --- ## Post #57 by @thomas.beale [quote="pieterbos, post:54, topic:623"] I think the choice of solution depends on a couple of things. If we use need a solution for this one single use case, adding a warning could be very well a very simple and effective solution. You do not have to do anything different when modelling - just when people try to specialise a DV_TEXT when there is already a different DV_CODED_TEXT they will automatically be warned that this usually is a bad idea unless you know exactly what you are doing, [/quote] This does seem like the preferable thing to do at this stage. --- ## Post #58 by @ian.mcnicoll At application runtime they can chuck any coded text at the CDR - the validation rules say that is fine. You can use 'this'coded Valueset or any free text or any other coded_text by sub-classing dv_text at run-time. --- ## Post #59 by @thomas.beale [quote="ian.mcnicoll, post:58, topic:623"] At application runtime they can chuck any coded text at the CDR [/quote] You mean that application code could break the original design intention by supplying a DV_CODED_TEXT for the DV_TEXT field - but to stop that being saved, we'd have to have the archetype constraint check prevent it. Which means that we are talking about more than a design-time tool warning... --- ## Post #60 by @pieterbos That would not be solved using the aom/ADL changes. That means changes to the validation logic. I wonder how many frameworks or cdrs consider that subclassing to be correct - I'm not even sure what Archie does here. It is also not specific at all to adl2 - what was suggested in the first few posts. --- ## Post #61 by @thomas.beale [quote="pieterbos, post:60, topic:623"] That would not be solved using the aom/ADL changes. That means changes to the validation logic [/quote] Yes, I was not clear, that is indeed what I meant: a new VXXX rule, with a validator check to implement it (phase 2 in my system). The rule by the way can be made to apply regardless of RM type - it's something like this: * VURMST: unique RM sub-typing - a node of RM type T may not be instantiated as a subtype T1 if there are also constraints for type T1, and the instance does not conform to one of those constraints. --- ## Post #62 by @pieterbos That could work. It may need some further restrictions because obviously this does not apply to items in a cluster - is this only for single valued attributes? Or only when marked as 'this cannot be subclassed' the archetype? Or specific parts of the RM? --- ## Post #63 by @pieterbos So https://openehr.atlassian.net/browse/SPECAM-68 adds a constraint_status, which corresponds to the fhir value set binding strength. I wonder if that can be used in a new validation rule, something like: if a DV_CODED_TEXT constraint is present and its constraint_status is required, it is not allowed to create any other DV_CODED_TEXT in a child archetype or in corresponding RM data that does not conform to that DV_CODED_TEXT, unless that new DV_CODED_TEXT is a specialisation of the parent DV_CODED_TEXT. That would mean you could create different constraint_status of DV_CODED_TEXT/DV_TEXT combinations to solve the different use cases. Note for currently all DV_CODED_TEXT have required constraint_status by default because it is the only supported binding strength currently, so not sure what that would mean for current archetypes and specializations. If this does not solve it, or perhaps is a bit ugly solution, I would prefer the final keyword here :) --- ## Post #64 by @ian.mcnicoll That's not a bad suggestion Pieter but I might suggest slight change. Currently FHIR extensible means you can extend the valueset either with new codes or with free text. So perhaps we have what we need just with combination of CODED_TEXT = extensible/required and TEXT. a) TEXT => anything including CODED_TEXT b) TEXT CODED_TEXT = extensible => Any code from the CODED_TEXT valueset, any other code or free text b) TEXT CODED_TEXT = required => Any code from the CODED_TEXT valueset or free text This makes the requirement clear, although technically the TEXT could still be sub-classed at run-time and practically makes this an 'extensible'. I can live with that as at least the requirement is clear even if it cannot be technically enforced. --- ## Post #65 by @sebastian.garde Your (Ian's) examples b) and c) sound like direct applications of Pieter's validation rule to me? I think the validation rule makes a lot of sense (and is not that ugly either). --- ## Post #66 by @pieterbos One thing: The ADL 2/AOM 2 specification is entirely independent of the RM specification, without any domain classes or concepts, so a rule that specific cannot be in AOM validation rules - while that would be necessary for this solution - in fact the implementation would mean specific code for the OpenEHR RM, outside of the BMM model. Or would there be another place where this can be specified and implemented? The final keyword might still be easier? --- ## Post #67 by @ian.mcnicoll I think the thing here is that the binding strength is actually a property of the Valueset not the DV_CODED_TEXT as such a) TEXT => anything including CODED_TEXT b) TEXT VALUESET = extensible => Any code from the valueset, any other code or free text b) TEXT VALUESET = required => Any code from the valueset or free text Does that help validation by being domain neutral? THomas's suggested rule would also work but appreciate there are broader issues around where it should apply --- ## Post #68 by @pieterbos it's on the c_terminology_code, not the value set, so the same thing as in fhir (which is good for easier mapping!) But that doesn't help, same problem. But perhaps there is an easy way to do this. --- ## Post #69 by @ian.mcnicoll I'm starting to think that we can just leave this as guidance, forget about validation, if that is problematic. I think we have clear way of communicating the designers' wishes in term of extensibility / use of free text which was a bit vague before. --- ## Post #70 by @thomas.beale OK - a reasonable version of the changes for `required | preferred` etc constraint strengths: * [ADL2](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_amendment_record) * [AOM2](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_constraint_strengths) --- ## Post #71 by @thomas.beale Following recent discussions in the real world relating to solving this problem in tools (mainly Better's AD tool), I have re-read this topic, and have the following synthesis to offer. Please review and comment w.r.t your various tools: @pieterbos , @borut.fabjan , @ian.mcnicoll , @sebastian.garde , @yampeku ... anyone else interested. Assumptions ----------------- The following are assumptions we should keep in mind in existing openEHR tools & systems. 1. A rule that is only mentioned briefly in the ADL2 spec is that runtime-validation of data instances **uses the most specific RM class it can**, for the given instance. The [example in the spec is a PARTY hierarchy](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_reference_model_type_matching). With respect to our pattern of interest, i.e. ``` value ∈ { DV_CODED_TEXT[id4] ∈ {[ac1]} DV_TEXT[id5] ∈ { ... } } ``` If a `DV_CODED_TEXT` data instance is created at runtime, it **must** conform to the `DV_CODED_TEXT` constraint. If this were not the case, the more specific RM type constraints have no weight. We sometimes forget this (even I do), but it is almost a second 'golden rule' of archetyping. 2. In general, **multiple constraints for the same RM type** are allowed (and are normal). Example: ``` -- -- pre-tuple style of handling different units -- value ∈ { DV_QUANTITY [id14] ∈ { property ∈ {[openehr::151|temperature|]} units ∈ {"deg F"} magnitude ∈ {|32.0..212.0|} } DV_QUANTITY [id15] ∈ { property ∈ {[openehr::151|temperature|]} units ∈ {"deg C"} magnitude ∈ {|0.0..100.0|} } } ``` More generally, any typical constraint within a container attribute is also often a bunch of 'alternative' constraints on the same RM type, e.g. ``` HISTORY[id2] occurrences ∈ {1} ∈ { periodic ∈ {False} events cardinality ∈ {*} ∈ { EVENT[id3] occurrences ∈ {0..1} ∈ { } -- 1 min sample EVENT[id4] occurrences ∈ {0..1} ∈ { } -- 2 min sample EVENT[id5] occurrences ∈ {0..1} ∈ { } -- 3 min sample } } ``` It's just that more than one alternative could be used within a container attribute, whereas in a single-valued attribute, you have to pick one. Problem (re)statement ------------------------------- Allow a pattern like DV_TEXT + DV_CODED_TEXT to be defined in the child of a parent that has just DV_TEXT, such that any DV_CODED_TEXT instance provided at runtime *must conform to only* the DV_CODED_TEXT constraint, and is not allowed to 'sneak through' as an instance of the DV_TEXT constraint. This was @borut.fabjan 's original worry. Problem Interpretation ------------------------------- According to assumption #1 above, the intended effect will be achieved anyway, as long as alternative `DV_CODED_TEXT` constraints are not added in further children in order to escape the `DV_CODED_TEXT` defined in the first child. So the thing we really need is to be able to define a constraint on an RM type that is a descendant of another type, such that it is *the only constraint for that RM type* - no alternatives allowed. Candidate solutions --------------------------- From the original long discussion, we have 3 possible kinds of solution: * A: fix the RM, using `DV_PLAIN_TEXT` as a sibling of `DV_CODED_TEXT`, and make `DV_TEXT` an abstract type. This fixes the problem by getting rid of the situation of two concrete classes in a parent-child inheritance relation in the RM; impractical from a backwards compatibility point of view; * B: my [initial solution](https://discourse.openehr.org/t/option-to-record-free-text-as-choice-against-dv-coded-text-do-we-need-dv-plain-text/623/37) - 'closed' attribute + 'RM type final'. This might work, but is clunky and not too intuitive. * C: @pieterbos 's solution ([here](https://discourse.openehr.org/t/option-to-record-free-text-as-choice-against-dv-coded-text-do-we-need-dv-plain-text/623/63)) - a smart rule like this: if a DV_CODED_TEXT constraint is present and its constraint_status is required, it is not allowed to create any other DV_CODED_TEXT in a child archetype or in corresponding RM data that does not conform to that DV_CODED_TEXT, unless that new DV_CODED_TEXT is a specialisation of the parent DV_CODED_TEXT (generalised to any RM types obviously). Of the above @pieterbos 's solution is the nicest - it's minimal and reasonably intiutive - except that it cannot be applied generally, since it breaks assumption #2 mentioned at the top. It's close to what my 'rm_final' flag was trying to do. So to have a rule like this means it needs a keyword to indicate it is operating, possibly something like this: ``` value ∈ { DV_CODED_TEXT[id4] unique ∈ { ... } DV_TEXT[id5] ∈ { ... } } ``` That 'unique' keyword means: this is the sole constraint specified for any `DV_CODED_TEXT` instance (including any instance of child RM types, if such existed). A child archetype could redefine this, but can't add another independent `DV_CODED_TEXT` constraint - i.e. it is saying to apply Pieter's rule 'here'. EDIT: if people think 'frozen' or 'final' makes more sense than 'unique', fine with me. We can vote on it. I believe that this is the most minimal thing we can do, consistent with current semantics, and that won't break any existing archetypes or RM implementations. Over to the group. --- ## Post #72 by @yampeku One problem I can see is that constraint_status value is assumed to be 'required' if not explicitly stated otherwise, which in the end: A) could make every existing archetype non-specializable as they are right now, requiring the modification of every archetype B) could make decision difficult if we cannot tell apart if the constraint_status has been put as required by making explicit something that was non-existing in the archetypes (see A) or it was explicitly put by the editor in the archetype Also, I don't know if alternatives of C_TERMINOLOGY_CODE are really allowed, and what is the outcome of the constraint_status proposed rule in that case (and if the constraint_status can differ in the alternatives) I think alternatives of C_TERMINOLOGY_CODE should be allowed, and allow different constraint_status, with this we could add examples and the actual constraints in the same parent archetype --- ## Post #73 by @wouterzanen Hi, Have been reading this topc because in the Netherlands the same question popped-up. Basically the we have a more conceptual definition of care building blocks (Zibs) which are only defined in UML. It allows for CODED_TEXT this can be required or extenisble. Problem is that if it is Extensible you can extended it with any other code system and or text. But this is not what is needed in practice. Because you would like to strictly adhere to a code list and only use free text when no code is suitable in the list. So a similar challeng. I can see in th OAM2 document: ``` ELEMENT[id22] occurrences matches {0..1} matches { value matches { DV_CODED_TEXT[id58] matches { defining_code matches {extensible [ac2]} -- use ac2 value-set if there is a match } -- or another code from same terminology DV_TEXT[id59] -- or plain text } } ``` That it seems to be solved in this way. Now the value set that is used is a constraijt list from |SNOMED CT: <[260787004](https://terminologie.nictiz.nl/art-decor/snomed-ct?conceptId=260787004)|Physical object||. So now the questions: 1. Does the extensibility mean that now all values from SNOMED CT are posibble as an extension, but not from anyother code systems? (This seems to still leave it quite open what codes can be used) 2. And maybe this is not a topic for here, but did anybody try to constraint this in Fhir as well or has a pattern to do this? Or do we leave it up to the system storing the data (openEHR or legacy) to solve this. 3. It seems that the adl2 description is somewhat in conflict with the oam2: ``` extensible Data item value should satisfy constraint, i.e. a term in constraint is to be used if it covers the data item meaning (including more generally); if not, another code may be used, including from **another** terminology. Enumeration value = 1. ``` Where in th oam2 definition it says: or another code from **same** terminology --- **Canonical:** https://discourse.openehr.org/t/option-to-record-free-text-as-choice-against-dv-coded-text-do-we-need-dv-plain-text/623 **Original content:** https://discourse.openehr.org/t/option-to-record-free-text-as-choice-against-dv-coded-text-do-we-need-dv-plain-text/623