# New ADL/AOM proposals to solve some old problems **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2013-04-24 17:03 UTC **Views:** 1 **Replies:** 15 **URL:** https://discourse.openehr.org/t/new-adl-aom-proposals-to-solve-some-old-problems/15252 --- ## Post #1 by @thomas.beale In openEHR we use custom syntax in archetypes to express ordinal constraints, quantity constraints and coded text constraints - i..e constraints on what are probably the most ubiquitous data types in health. I have been mulling over feedback from previous debates here and in CIMI about the 'undesirability' of this syntax. I have posted some new ideas on how to solve this [here](http://www.openehr.org/wiki/display/spec/ADL+1.5+Power+Syntax+Proposals). The executive summary is: - let's treat 'code' as a built in type, like a Date or a Uri; this then makes an AOM type that constrains this trivial; - ADL can be augmented in a generic way to enable tuples to be constrained, which would better solve the Quantity constraint problem - The Ordinal constraint syntax would be replaced by a combination of both of the above. Feedback welcome. - thomas --- ## Post #2 by @system Very interesting thoughts Tom! My initial impression of the proposal is very positive. If I understand things correctly this will enable shorter and more readable serializations not only in ADL but also in other formalisms. If we consider ADL being a [DSL](http://en.wikipedia.org/wiki/Domain-specific_language) mainly targeted for constraining health-related RMs then simplifications towards that goal are welcome. The only potential catch is implementation issues. Have you already tried implementing a parser for this in some language? (If so, please provide a link.) I guess the suggestion could make some implementation parts easier and some a bit trickier. Best regards, Erik Sundvall LiO: [erik.sundvall@lio.se](mailto:erik.sundvall@lio.se) [http://www.lio.se/Verksamheter/IT-centrum/](http://www.lio.se/Verksamheter/IT-centrum/) LiU: [erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) P.s. [/daydreaming] It might be interesting to connect a future updated AOM 1.5 in Java with (de)serialization using Jackson, see [https://github.com/FasterXML](https://github.com/FasterXML) Jackson already supports several highly configurable serialization format options, perhaps ADL or ODIN databindings would be possible too ;-) RM bindings might be a more interesting use case than AM bindings though... --- ## Post #3 by @thomas.beale well actually I am thinking of ADL as a domain-independent formalism. Today we do have some health-IT oriented extras, but that would disappear with the proposal I am making here, and would be replaced by a) a built-in type (essentially a special kind of string) representing a terminology code, and b) the tuple constraint capability. Although the former may look like a health IT specific, I would argue that it is applicable in any industry, where there is any kind of coding going on. That surely has to be increasing. I haven't done anything in the ADL parser to support this, but I think it will be easy to handle for leaf level tuples. For tuples of complex objects, it will probably be harder, but I think that is of less utility anyway. The main annoyance will be re-processing existing archetypes on the fly, but that's life.... Before I do any work on it, I think it would be useful to get more feedback. - thomas --- ## Post #4 by @yampeku As you know, I'm not a big fan of domain types, so take my comments with a grain of salt ;\) I understand that back in the day when archetypes were hand crafted domain types could serve a purpose\. But in my opinion ADL should not be written by hand nowadays\. Tools should be the ones that 'hide' the 'verboseness' and provide the user with a simple interface to simulate domain types if you want/need that\. Also, the difference in file size is negligible \(if archetypes pass from 16kb to 20kb I wouldn't worry that much\.\.\.\)\. If you ask me I would get rid of them completely and make ADL completely model agnostic\. This is why I can agree with the second point completely: There you are making ADL better, more powerful\. But I see a problem with the first point as it still requires an external definition of the 'mappings' between how we understand codes in each one of the standards \(and which information we can constraint about them\)\. With this new syntax, can we constraint mappings between codes? \( How do I say that I don't want to allow the mappings in certain coded text?\) and what about the code qualifiers? What if your RM defines another kind of attribute for codes interesting to be put into the archetypes but not supported by this code syntax? If both visions \(codes as a type and codes as a full structure\) coexist then we have the same problem as we have now \(or worse\)\. PS: BTW, by definition a leaf constraint type \(the new proposed 'C\_TERMINOLOGY\_CODE' or whatever\) does not have node id, I don't see how one would be able to define alternatives of codes from different terminologies or specialize that\.\.\. PPS: \.\.\.which is the exact same problem that domain types have \(as they also lack node id\) --- ## Post #5 by @yampeku PPPS: How you define an AQL filter over a domain type? --- ## Post #6 by @thomas.beale I'm not worried about size, up to a point. But there some truisms about formalisms - the main one is that if the context free grammar of a formalism only has a complicated way to do something, then any structural representation will also be complicated. Additionally, if it's complicated to express a simple thing in the formalism, it's probable that no users or developers understand it clearly. Consider these dichotomies: well that's true, but it's already true for types like Date, Time, DateTime and Duration. Note that a Datetime with timezone has 7 pieces of information in it, and a lot of implied validity rules. Is it a leaf type or a complex type? We just use ISO8601 strings for all of these, and let other tools work out the obvious mappings between various RMs with TS (HL7), DATE/TIME types (openEHR), XSD gXXX types (FHIR), and so on. Proposing the idea of a 'terminology code' made up of a terminology id and a code or code-phrase (as a string expressed in e.g. the SNOMED CT Compositional grammar) as a built-in type doesn't seem a great leap in the semantic age. I'm not exactly sure what constraint you want to express here: can you be more precise? well in openEHR we have always modelled code terms as syntax, not a complex model of qualifiers. See the CODE_PHRASE type. it depends on what are trying to do. The 'normal' thing that 90% of archetypes need to do is this: ELEMENT[at0021] occurrences matches {0..1} matches { -- Certainty value matches { DV_CODED_TEXT matches { defining_code matches { [local:: at0022, -- Suspected at0023, -- Probable at0024] -- Confirmed } } } } If this is written without the 'custom syntax' then you have: ELEMENT[at0021] occurrences matches {0..1} matches { -- Certainty value matches { DV_CODED_TEXT matches { defining_code matches { CODE_PHRASE matches { terminology matches { TERMINOLOGY_ID matches { value matches {"local"} } code_string matches { "at0022", -- Suspected "at0023", -- Probable "at0024" -- Confirmed } } } } } } Either way, there is no at-codes on the possibilities, and there's no need. Of course, you can always do this: ELEMENT[at0021] occurrences matches {0..1} matches { -- Certainty value matches { DV_CODED_TEXT [atNNNN] matches { defining_code matches { ... } } DV_CODED_TEXT [atNNNN] matches { defining_code matches { ... } } } } which might possibly make sense in some situation. - thomas --- ## Post #7 by @thomas.beale How do you define an AQL filter over a date time? Well, ok, it's not quite as simple as that. With a coded term type (in particular) you want operators like 'in set', 'in subsumption', and 'in subset'. But why do we see this as being specific to health? - thomas --- ## Post #8 by @yampeku > > As you know, I'm not a big fan of domain types, so take my comments > with a grain of salt ;\) > I understand that back in the day when archetypes were hand crafted > domain types could serve a purpose\. But in my opinion ADL should not > be written by hand nowadays\. Tools should be the ones that 'hide' the > 'verboseness' and provide the user with a simple interface to simulate > domain types if you want/need that\. Also, the difference in file size > is negligible \(if archetypes pass from 16kb to 20kb I wouldn't worry > that much\.\.\.\)\. > If you ask me I would get rid of them completely and make ADL > completely model agnostic\. > > I'm not worried about size, up to a point\. But there some truisms about > formalisms \- the main one is that if the context free grammar of a formalism > only has a complicated way to do something, then any structural > representation will also be complicated\. Additionally, if it's complicated > to express a simple thing in the formalism, it's probable that no users or > developers understand it clearly\. > > Consider these dichotomies: > > OWL \(readable\) v RDF \(hideous\) > JSON \(simplistic, but readable\) v XML \(hard to read, tricky inheritance > model, tricky containment semantics, \.\.\.\) > Ruby / Python \(readable, according the young generation at least ;\-\) v C\+\+ > \(much harder than it should be\) > Ecore syntax \(human readable and computable\) v XMI \(no need to say anything > here\)\. > > One thing we can learn from this is that where clear abstract syntaxes are > not found, there you find confusion\. > "readability" seems like a too subjective measure, and depends mostly of the person/program writing it on the first place\. > This is why I can agree with the second point completely: There you > are making ADL better, more powerful\. > But I see a problem with the first point as it still requires an > external definition of the 'mappings' between how we understand codes > in each one of the standards \(and which information we can constraint > about them\)\. > > well that's true, but it's already true for types like Date, Time, DateTime > and Duration\. Note that a Datetime with timezone has 7 pieces of > information in it, and a lot of implied validity rules\. Is it a leaf type or > a complex type? We just use ISO8601 strings for all of these, and let other > tools work out the obvious mappings between various RMs with TS \(HL7\), > DATE/TIME types \(openEHR\), XSD gXXX types \(FHIR\), and so on\. > Dates are mostly represented as strings with more or less restrictions\. The classes to represent the codes are more complicated than that \(codes, terminology, mapping\(s\), qualifiers, etc\) > Proposing the idea of a 'terminology code' made up of a terminology id and a > code or code\-phrase \(as a string expressed in e\.g\. the SNOMED CT > Compositional grammar\) as a built\-in type doesn't seem a great leap in the > semantic age\. > > With this new syntax, can we constraint mappings between > codes? \( How do I say that I don't want to allow the mappings in > certain coded text?\) > > I'm not exactly sure what constraint you want to express here: can you be > more precise? > Have a template or specialized archetype that the codes in my target system will have exactly one mapping \(from a standard terminology to a local one, for example\) > and what about the code qualifiers? What if your > RM defines another kind of attribute for codes interesting to be put > into the archetypes but not supported by this code syntax? > If both visions \(codes as a type and codes as a full structure\) > coexist then we have the same problem as we have now \(or worse\)\. > > well in openEHR we have always modelled code terms as syntax, not a complex > model of qualifiers\. See the CODE\_PHRASE type\. > I know how openEHR does it, but others may or may not model it like that\. > PS: BTW, by definition a leaf constraint type \(the new proposed > 'C\_TERMINOLOGY\_CODE' or whatever\) does not have node id, I don't see > how one would be able to define alternatives of codes from different > terminologies or specialize that\.\.\. > PPS: \.\.\.which is the exact same problem that domain types have \(as > they also lack node id\) > > it depends on what are trying to do\. The 'normal' thing that 90% of > archetypes need to do is this: > >                             ELEMENT\[at0021\] occurrences matches \{0\.\.1\} > matches \{ \-\- Certainty >                                 value matches \{ >                                     DV\_CODED\_TEXT matches \{ >                                         defining\_code matches \{ >                                             \[local:: >                                             at0022, \-\- Suspected >                                             at0023, \-\- Probable >                                             at0024\] \-\- Confirmed >                                         \} >                                     \} >                                 \} >                             \} > > If this is written without the 'custom syntax' then you have: > >                             ELEMENT\[at0021\] occurrences matches \{0\.\.1\} > matches \{ \-\- Certainty >                                 value matches \{ >                                     DV\_CODED\_TEXT matches \{ >                                         defining\_code matches \{ >                                             CODE\_PHRASE matches \{ >                                                 terminology matches \{ >                                                     TERMINOLOGY\_ID matches \{ >                                                         value matches > \{"local"\} >                                                     \} >                                                 code\_string matches \{ >                                                     "at0022", \-\- > Suspected >                                                     "at0023", \-\- > Probable >                                                     "at0024" \-\- Confirmed >                                                \} >                                             \} >                                         \} >                                     \} >                                 \} >                             \} > > Either way, there is no at\-codes on the possibilities, and there's no need\. > > Of course, you can always do this: > >                             ELEMENT\[at0021\] occurrences matches \{0\.\.1\} > matches \{ \-\- Certainty >                                 value matches \{ >                                     DV\_CODED\_TEXT \[atNNNN\] matches \{ >                                         defining\_code matches \{ >                                             \.\.\. >                                         \} >                                     \} >                                     DV\_CODED\_TEXT \[atNNNN\] matches \{ >                                         defining\_code matches \{ >                                             \.\.\. >                                         \} >                                     \} >                                 \} >                             \} > > which might possibly make sense in some situation\. > > \- thomas > Sure, you can make alternatives of coded\_text, the domain type here is the codePhrase\.\.\. I think this could be a perfect valid example \(ignore random codes\) defining\_code existence matches \{1\.\.1\} matches \{                                                     \[SNOMED\-CT::                                                     123456,                                                     11234561,                                                     1002123456,                                                     61234563,                                                     98752;                                                     233233\]                                                     \[LOINC::                                                     72693\-5,                                                     1234\-5,                                                     3254\-8,                                                     6548\-1,                                                     44563\-7;                                                     3254\-8\]                                                     \[local::                                                     at1000,                                                     at1001,                                                     at1002,                                                     at1003,                                                     at1014;                                                     at1001\]                                                 \} You cannot define a node id for each defining code\. But specializing it should be allowed \(define a subset of the parent seems like an obvious thing to do on codephrases\) The same thing applies to C\_DV\_QUANTITY for example ELEMENT\[at1005\] occurrences matches \{0\.\.1\} matches \{ \-\- Tilt \(degrees and radian\)                                         value existence matches \{1\.\.1\} matches \{                                             C\_DV\_QUANTITY <                                                 property = <\[openehr::497\]>                                                 list = <                                                     \["1"\] = <                                                         units = <"°">                                                         magnitude = <|\-90\.0\.\.90\.0|>                                                         precision = <|0|>                                                     >                                                 >                                               >                                              C\_DV\_QUANTITY <                                                 property = <\[openehr::497\]>                                                 list = <                                                     \["1"\] = <                                                         units = <"c">                                                         magnitude = <|\-2PI\.\.2PI|>                                                         precision = <|0|>                                                     >                                                 >                                               >                                         \}                                     \} C\_DV\_QUANTITY\[atXXXX\]<\.\.\.> is not correct\. And looking at the example, after all this years I have yet to find a good explanation of why domain types can have things like "property" which cannot be defined in standard ADL --- ## Post #9 by @yampeku You can generate operations to deal with domain types, but then AQL would be openEHR specific \(you can call it OQL then\)\. What I say is that generating a path to specify a filter \(and accessing it\) is direct when the domain type has been expanded, and not so easy if you take it as it is\. If you get the expanded path each time then the user won't be able to tell where the AQL path comes from \(it'll have attributes he doesn't know about\)\. I only see disadvantages working with domain types in AQL\. --- ## Post #10 by @thomas.beale > You can generate operations to deal with domain types, but then AQL > would be openEHR specific \(you can call it OQL then\)\. What I say is Diego, there is nothing openEHR\-specific today in AQL, and allowing more complex primitive types like dates or codes or URIs doesn't change that\. It will work just as well with any reference model from any industry\. So I don't get your point here\. > that generating a path to specify a filter \(and accessing it\) is > direct when the domain type has been expanded, and not so easy if you > take it as it is\. If you get the expanded path each time then the user > won't be able to tell where the AQL path comes from \(it'll have > attributes he doesn't know about\)\. I only see disadvantages working > with domain types in AQL\. > but in that case you should be arguing that we should remove the Date/Time types and URIs etc\. It's true, we can just limit ourselves to Integer / Real / String / Character / Boolean / Binary, but\.\.\. why? It's just making life needlessly difficult as far as I can see\. \- thomas --- ## Post #11 by @thomas.beale >> Consider these dichotomies: >> >> OWL \(readable\) v RDF \(hideous\) >> JSON \(simplistic, but readable\) v XML \(hard to read, tricky inheritance >> model, tricky containment semantics, \.\.\.\) >> Ruby / Python \(readable, according the young generation at least ;\-\) v C\+\+ >> \(much harder than it should be\) >> Ecore syntax \(human readable and computable\) v XMI \(no need to say anything >> here\)\. >> >> One thing we can learn from this is that where clear abstract syntaxes are >> not found, there you find confusion\. >> > > "readability" seems like a too subjective measure, and depends mostly > of the person/program writing it on the first place\. Nevertheless, the unreadable examples from the list above are all infamous for their difficulty of learning, difficulty of understanding, complexity, and for being things everyone wants to \(and eventually does\) replace\. It's not by accident that this happens\. >> This is why I can agree with the second point completely: There you >> are making ADL better, more powerful\. >> But I see a problem with the first point as it still requires an >> external definition of the 'mappings' between how we understand codes >> in each one of the standards \(and which information we can constraint >> about them\)\. >> >> well that's true, but it's already true for types like Date, Time, DateTime >> and Duration\. Note that a Datetime with timezone has 7 pieces of >> information in it, and a lot of implied validity rules\. Is it a leaf type or >> a complex type? We just use ISO8601 strings for all of these, and let other >> tools work out the obvious mappings between various RMs with TS \(HL7\), >> DATE/TIME types \(openEHR\), XSD gXXX types \(FHIR\), and so on\. >> > > Dates are mostly represented as strings with more or less > restrictions\. The classes to represent the codes are more complicated > than that \(codes, terminology, mapping\(s\), qualifiers, etc\) only if you think it has to be a class model\. But in fact, 99% of all codes on the planet are just single codes\. A small number have some qualifiers / modifiers, and the standard way to do this in both the ontology and terminology communities is with different kinds of syntax \- either OWL\-based or IHTSDO based\. CLass models always fail in this area, because they can never predict what new things terminology code phrases need to be able to represent\. I am not saying that you could not keep using the explicit CODED\_TERM model\-based approach as well, just that it's getting in the way 99% of the time\. >> I'm not exactly sure what constraint you want to express here: can you be >> more precise? >> > > Have a template or specialized archetype that the codes in my target > system will have exactly one mapping \(from a standard terminology to a > local one, for example\) well the normal way to do that is with terminology bindings\. The following example would be a pretty dangerous thing to do, especially in health, and in any case, it would be hard to find any real world example that could look like this, because LOINC and SNOMED\-CT don't really overlap or code for the same things at all\. The better way to do that is definitely with bindings\. > Sure, you can make alternatives of coded\_text, the domain type here is > the codePhrase\.\.\. > > I think this could be a perfect valid example \(ignore random codes\) > > defining\_code existence matches \{1\.\.1\} matches \{ >                                                      \[SNOMED\-CT:: >                                                      123456, >                                                      11234561, >                                                      1002123456, >                                                      61234563, >                                                      98752; >                                                      233233\] >                                                      \[LOINC:: >                                                      72693\-5, >                                                      1234\-5, >                                                      3254\-8, >                                                      6548\-1, >                                                      44563\-7; >                                                      3254\-8\] >                                                      \[local:: >                                                      at1000, >                                                      at1001, >                                                      at1002, >                                                      at1003, >                                                      at1014; >                                                      at1001\] >                                                  \} > You cannot define a node id for each defining code\. But specializing > it should be allowed \(define a subset of the parent seems like an > obvious thing to do on codephrases\) > > The same thing applies to C\_DV\_QUANTITY for example > > ELEMENT\[at1005\] occurrences matches \{0\.\.1\} matches \{ \-\- Tilt > \(degrees and radian\) >                                          value existence matches \{1\.\.1\} > matches \{ >                                              C\_DV\_QUANTITY < >                                                  property = <\[openehr::497\]> >                                                  list = < >                                                      \["1"\] = < >                                                          units = <"°"> >                                                          magnitude = > <|\-90\.0\.\.90\.0|> >                                                          precision = <|0|> >                                                      > >                                                  > >                                                > >                                               C\_DV\_QUANTITY < >                                                  property = <\[openehr::497\]> >                                                  list = < >                                                      \["1"\] = < >                                                          units = <"c"> >                                                          magnitude = > <|\-2PI\.\.2PI|> >                                                          precision = <|0|> >                                                      > >                                                  > >                                                > >                                          \} >                                      \} > >   C\_DV\_QUANTITY\[atXXXX\]<\.\.\.> is not correct\. actually, you can set at\-codes on the DV\_QUANTITY blocks above, but it's kind of ugly\. But the proposals I am suggesting make all this go away\. > And looking at the example, after all this years I have yet to find a > good explanation of why domain types can have things like "property" > which cannot be defined in standard ADL it's very simple: with a plug\-in constrainer type, you can have all kinds of special constraining attributes that are not in the RM at all\. E\.g\. here 'property' is not actually a property of DV\_QUANTITY \(arguably it should be but that's another argument\)\. Similar thing happens with things like C\_STRING \- there is the regex and the list way of constraining a String value\. There is nothing called 'pattern' in the String type\. \- thomas --- ## Post #12 by @yampeku >> >> You can generate operations to deal with domain types, but then AQL >> would be openEHR specific \(you can call it OQL then\)\. What I say is > > Diego, > > there is nothing openEHR\-specific today in AQL, and allowing more complex > primitive types like dates or codes or URIs doesn't change that\. It will > work just as well with any reference model from any industry\. So I don't get > your point here\. > I'm not saying there is something openEHR specific right now in AQL, I'm just saying that including additional requirements to deal with domain types would make more difficult the implementation of a AQL engine, and the queries generated this way \("domain type"\-based queries if you want\) only would work in a environment ready to use domain types\. My whole point is, domain types will give you more headaches in the long run \(problems with specialization, AQL, mapping, etc\.\) than benefits\. >> that generating a path to specify a filter \(and accessing it\) is >> direct when the domain type has been expanded, and not so easy if you >> take it as it is\. If you get the expanded path each time then the user >> won't be able to tell where the AQL path comes from \(it'll have >> attributes he doesn't know about\)\. I only see disadvantages working >> with domain types in AQL\. >> > but in that case you should be arguing that we should remove the Date/Time > types and URIs etc\. It's true, we can just limit ourselves to Integer / Real > / String / Character / Boolean / Binary, but\.\.\. why? It's just making life > needlessly difficult as far as I can see\. > Implied semantics will give you problem always \(again, talking about paths\)\. The advantage of date/time & uris over codes is that the former are strings which can be treated with convenient functions\. Codes would depend on the underlying archetype reference model to be interpreted correctly\. --- ## Post #13 by @yampeku >> >>> Consider these dichotomies: >>> >>> OWL \(readable\) v RDF \(hideous\) >>> JSON \(simplistic, but readable\) v XML \(hard to read, tricky inheritance >>> model, tricky containment semantics, \.\.\.\) >>> Ruby / Python \(readable, according the young generation at least ;\-\) v >>> C\+\+ >>> \(much harder than it should be\) >>> Ecore syntax \(human readable and computable\) v XMI \(no need to say >>> anything >>> here\)\. >>> >>> One thing we can learn from this is that where clear abstract syntaxes >>> are >>> not found, there you find confusion\. >>> >> >> "readability" seems like a too subjective measure, and depends mostly >> of the person/program writing it on the first place\. > > Nevertheless, the unreadable examples from the list above are all infamous > for their difficulty of learning, difficulty of understanding, complexity, > and for being things everyone wants to \(and eventually does\) replace\. It's > not by accident that this happens\. > I disagree, everything has a place in this world\. You would not be programing in eiffel it that wasn't the case ;D >>> This is why I can agree with the second point completely: There you >>> are making ADL better, more powerful\. >>> But I see a problem with the first point as it still requires an >>> external definition of the 'mappings' between how we understand codes >>> in each one of the standards \(and which information we can constraint >>> about them\)\. >>> >>> well that's true, but it's already true for types like Date, Time, >>> DateTime >>> and Duration\. Note that a Datetime with timezone has 7 pieces of >>> information in it, and a lot of implied validity rules\. Is it a leaf type >>> or >>> a complex type? We just use ISO8601 strings for all of these, and let >>> other >>> tools work out the obvious mappings between various RMs with TS \(HL7\), >>> DATE/TIME types \(openEHR\), XSD gXXX types \(FHIR\), and so on\. >>> >> >> Dates are mostly represented as strings with more or less >> restrictions\. The classes to represent the codes are more complicated >> than that \(codes, terminology, mapping\(s\), qualifiers, etc\) > > only if you think it has to be a class model\. But in fact, 99% of all codes > on the planet are just single codes\. A small number have some qualifiers / > modifiers, and the standard way to do this in both the ontology and > terminology communities is with different kinds of syntax \- either OWL\-based > or IHTSDO based\. CLass models always fail in this area, because they can > never predict what new things terminology code phrases need to be able to > represent\. > > I am not saying that you could not keep using the explicit CODED\_TERM > model\-based approach as well, just that it's getting in the way 99% of the > time\. > If getting in the way means write 5 lines instead of 1 then I give you that\. I don't really see which is the big gain of this         CODED\_TEXT matches \{\[local: at0111, at0012, at0013, at0014, at0015\]\} over making it completely generic and leaving headaches behind with this CODED\_TEXT matches \{             terminology\_id matches \{                 TERMINOLOGY\_ID matches \{                     value matches \{"local"\}                 \}             \}             code matches \{"at0111", "at0012", "at0013", "at0014", "at0015"\}         \} >>> I'm not exactly sure what constraint you want to express here: can you be >>> more precise? >>> >> >> Have a template or specialized archetype that the codes in my target >> system will have exactly one mapping \(from a standard terminology to a >> local one, for example\) > > well the normal way to do that is with terminology bindings\. The following > example would be a pretty dangerous thing to do, especially in health, and > in any case, it would be hard to find any real world example that could look > like this, because LOINC and SNOMED\-CT don't really overlap or code for the > same things at all\. The better way to do that is definitely with bindings\. > Was a quick example, if you one a little more real take SNOMED and RxNorm for example\. Something like "valid medications for a given disease"\. I don't really think that the requirement could be done with bindings by the way\. If I have in my an object that supports codes with mappings then archetyping that to require one and only one mapping is trivial in ADL\. >> Sure, you can make alternatives of coded\_text, the domain type here is >> the codePhrase\.\.\. >> >> I think this could be a perfect valid example \(ignore random codes\) >> >> defining\_code existence matches \{1\.\.1\} matches \{ >>                                                      \[SNOMED\-CT:: >>                                                      123456, >>                                                      11234561, >>                                                      1002123456, >>                                                      61234563, >>                                                      98752; >>                                                      233233\] >>                                                      \[LOINC:: >>                                                      72693\-5, >>                                                      1234\-5, >>                                                      3254\-8, >>                                                      6548\-1, >>                                                      44563\-7; >>                                                      3254\-8\] >>                                                      \[local:: >>                                                      at1000, >>                                                      at1001, >>                                                      at1002, >>                                                      at1003, >>                                                      at1014; >>                                                      at1001\] >>                                                  \} > >> You cannot define a node id for each defining code\. But specializing >> it should be allowed \(define a subset of the parent seems like an >> obvious thing to do on codephrases\) >> >> The same thing applies to C\_DV\_QUANTITY for example >> >> ELEMENT\[at1005\] occurrences matches \{0\.\.1\} matches \{ \-\- Tilt >> \(degrees and radian\) >>                                          value existence matches \{1\.\.1\} >> matches \{ >>                                              C\_DV\_QUANTITY < >>                                                  property = >> <\[openehr::497\]> >>                                                  list = < >>                                                      \["1"\] = < >>                                                          units = <"°"> >>                                                          magnitude = >> <|\-90\.0\.\.90\.0|> >>                                                          precision = <|0|> >>                                                      > >>                                                  > >>                                                > >>                                               C\_DV\_QUANTITY < >>                                                  property = >> <\[openehr::497\]> >>                                                  list = < >>                                                      \["1"\] = < >>                                                          units = <"c"> >>                                                          magnitude = >> <|\-2PI\.\.2PI|> >>                                                          precision = <|0|> >>                                                      > >>                                                  > >>                                                > >>                                          \} >>                                      \} >> >>   C\_DV\_QUANTITY\[atXXXX\]<\.\.\.> is not correct\. > > actually, you can set at\-codes on the DV\_QUANTITY blocks above, but it's > kind of ugly\. But the proposals I am suggesting make all this go away\. > I'm curious how\. codePhrase can also have a node id? Some domain types can and others can't? >> And looking at the example, after all this years I have yet to find a >> good explanation of why domain types can have things like "property" >> which cannot be defined in standard ADL > > it's very simple: with a plug\-in constrainer type, you can have all kinds of > special constraining attributes that are not in the RM at all\. E\.g\. here > 'property' is not actually a property of DV\_QUANTITY \(arguably it should be > but that's another argument\)\. > > Similar thing happens with things like C\_STRING \- there is the regex and the > list way of constraining a String value\. There is nothing called 'pattern' > in the String type\. > Well, doesn't feel the same way\. I would use a binding to a local openEHR terminology to represent 'property' instead of putting that on a attribute\. --- ## Post #14 by @mikael Hi Tom, Is the intention that the new data type TERMINOLOGY_CODE also can contain a post-coordinated code so it, for example, can contain a expression in SNOMED CT compositional grammar? (See [www.snomed.org/tig?t=rfg_expression_scg](http://www.snomed.org/tig?t=rfg_expression_scg) for more details about SNOMED CT compositional grammar.) Greetings Mikael --- ## Post #15 by @thomas.beale yes exactly. Technically I suppose it should be called TERMINOLOGY_CODE_PHRASE or TERMINOLOGY_CODE_STRING or something like that. It's the same idea as the openEHR CODE_PHRASE, the point here is to have an AOM type that is minimal, and just can represent a basic constrainable terminology code idea, and be easily mapped to actual RMs. - thomas --- ## Post #16 by @mikael Hi Tom, That sounds really nice. Regards Mikael --- **Canonical:** https://discourse.openehr.org/t/new-adl-aom-proposals-to-solve-some-old-problems/15252 **Original content:** https://discourse.openehr.org/t/new-adl-aom-proposals-to-solve-some-old-problems/15252