Thanks Ian and David, The conclusion for these would be:
1. The clinical modeler intent when constraints are not added, is that anything is permitted where constraints are not defined, of course in validity with the RM. 2. To define a closed structure, clinical modelers need to explicitly define the whole structure in templates, maybe mark some nodes as mandatory, and constraint the cardinality of collections to allow only the defined nodes there (but this is more difficult, for instance on INSTRUCTION.activities if cardinality is 1..2, and just one ACTIVITY is defined and marked as min occurrences = 1, another ACTIVITY with a different structure can be added at runtime on INSTRUCTION.activities, on these cases of collections is really difficult to express "only these types of nodes are allowed and no others"). All this would be done at the template level. 3. Each implementation would need to state what's the interpretation of accepting an OPT, even if the template is a more generic than the defined constraints (allows extra nodes to be added but are not defined in the template). So implementations, on their conformance statement need to say "we interpret OPTs as closed and accept only the structure defined by the OPT" or "we interpret OPTs as open and accept the OPT nodes and any other valid nodes that can be added at runtime". Interesting point on dynamic validation, but I think that is a RM validation only, since there are no AOM/TOM constraints to validate against, IMO data might be a little insecure with this approach. On my case, I'll need to add to my conf. statement that the interpretation is "closed". Thanks everyone, this helped me a lot, and hope this discussion help other people in the future. Best, Pablo. On Fri, Jul 6, 2018 at 4:27 AM, Ian McNicoll <[email protected]> wrote: > Hi all, > > Good question Pablo. > > There is definitely a use-case for an open composition content slot, > though it would probably have a little more context data. > > The prime example is a GP Encounter when the potential content is very > open i.e you have no idea what Observations, in particular, might be > required. > > However, this of course leaves CDR servers with a validation problem and I > suspect most CDRs actually validate directly against the templated content > i.e extra content will be rejected. > > In these situations we tend, therefore to build maximal dataset templates > which is a little clunky but technically correct. I understand that a > couple of vendors have/are experimenting with dynamic > validation i.e. the template is in some way rebuilt to reflect the content > but I don't know the details. > > So in practice, although technically open slots are valid, I think most > CDRs treat them as closed. Dynamic validation would be really useful and I > think ADL2 allows us to constrain slots as closed. > > Ian > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: [email protected] > twitter: @ianmcnicoll > > > Co-Chair, openEHR Foundation [email protected] > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > On Fri, 6 Jul 2018 at 07:57, David Moner <[email protected]> wrote: > >> >> >>> As I mentioned on my previous message, my case is not when an ANY / {*} >>> appears in the ADL, but when there is no definition at all, I'm talking >>> this: >>> >>> definition >>> COMPOSITION[at0000] matches { >>> category matches { >>> DV_CODED_TEXT matches { >>> defining_code matches {[openehr::433]} >>> } >>> } >>> } >>> >>> 1. I'm not sure if that is interpreted as ANY allowed in >>> COMPOSITION.content. >>> >>> For instance the AE doesn't allow to put a "content matches {*}" there, >>> which was my interpretation of what you called ANY. >>> >>> >> Yes, if you don't constrain anything, then the underlying model rules. >> And that's equivalent to saying ANY, that's why I insist on that :D >> >> >> >> -- >> David Moner Cano >> >> Web: http://www.linkedin.com/in/davidmoner >> Twitter: @davidmoner >> Skype: davidmoner >> _______________________________________________ >> openEHR-clinical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> > > _______________________________________________ > openEHR-clinical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > > -- *Ing. Pablo Pazos Gutiérrez* [email protected] +598 99 043 145 skype: cabolabs Subscribe to our newsletter <http://eepurl.com/b_w_tj> <https://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com
_______________________________________________ openEHR-clinical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
