# Practical approach to FOLDER OPTs **Category:** [Ask IEB](https://discourse.openehr.org/c/ask-ieb/37) **Created:** 2022-10-21 03:32 UTC **Views:** 1026 **Replies:** 36 **URL:** https://discourse.openehr.org/t/practical-approach-to-folder-opts/3081 --- ## Post #1 by @pablo Been struggling with this idea for a while, maybe others can help me out. Since FOLDER is LOCATABLE, it can, and actually should, be archetyped, and since most systems work with templates, there should actually be FOLDER OPTs out there saying how the internal structure of different FOLDERs should look like. The first challenge with FOLDERs is they are a recursive structure, though is like SECTION or CLUSTER, there is one big difference: for SECTIONs and CLUSTERs the structure is stable once a COMPOSITION is created, and we have an OPT for each type of COMPOSITION. When we create an EHR.directory instance, it's a FOLDER, that should have an OPT, though it's internal structure will keep changing while subfolders are added (at any level of the EHR.directory tree structure) and items are added to the FOLDERs (also at any level). Creating an OPT for a FOLDER is easy, but then what happens with it's subfolders at the FOLDER.folders list? Each of those should also be archetyped, but is that archetype mentioned in the top-level/root FOLDER OPT? It could, but then, the folders at the 3rd, 4th and so on, levels, should be also archetype in the same OPT? Or each subfolder could have indeed its own OPT? It would be easy to say, let's create a FOLDER archetype that allows anything in its folders attribute, but that won't help when we want to query the folder structure, since we need concrete archetype ids, constraints and paths to know how to query the structure. Another option is to have a FOLDER archetype that in the folders attribute has a SLOT to the same archetype ID, creating a recursive archetype dependency (this could also be a CONSTRAINT_REF to the root of the archetype), then use the archetype as-is in the OPT. The issue is if someone needs to add a constraint, then another archetype ID, or version of the current one, should be added to the allowed archetypes in the archetype slot, and this again should allow that new constraint in the first level of the folders, but also in the Nth level, unless a specific constraint doesn't allow certain archetype IDs, let's say, at the 3rd level. What I want to capture as modeling requirements is: 1. the need of OPTs to formally comply with the openEHR specs 2. the ability of allowing FOLDER-based queries in AQL and other querying formalisms 3. enable systems to create FOLDERs at any level of the EHR.directory, for any EHR, and allow to vary the internal structure of EHR.directory from EHR to EHR (different EHRs could have different OPTs for EHR.directory) I'm just not sure what is a good way of modeling for FOLDERs to allow editing the structure without just having a dummy FOLDER archetype just to be compliant with the specs. I would like to add real constraints to FOLDER archetypes, like the names, but allow users to create folders too. I guess all this comes from the not-so-explored world of FOLDERs in clinical modeling and querying (we still have open discussions about how AQL over FOLDERs could work and I think it's because we didn't use OPTs for FOLDERs extensively). --- ## Post #2 by @pablo @thomas.beale @ian.mcnicoll @Seref @bna @erik.sundvall do you have any opinions about folder modeling? --- ## Post #3 by @ian.mcnicoll I have no personal experience of using FOLDERS but agree that it would be good to be able to define the required structures in a template level --- ## Post #4 by @erik.sundvall [quote="pablo, post:1, topic:3081"] Creating an OPT for a FOLDER is easy, but then what happens with it’s subfolders at the FOLDER.folders list? Each of those should also be archetyped... [/quote] Should --> Could. I think arcehtyping them could still be optional (a lot of current FOLDERs in EHRs are not archetyped). [quote="pablo, post:1, topic:3081"] Or each subfolder could have indeed its own OPT? [/quote] Yes, maybe we don't need to constrain the allowed sub folders (at least not in a first spec iteration). Just being able to add metadata (and query based on it) would be a great addition to Folders and to AQL and cover many use cases. To clarify, based on the image below: * First maybe we should just try specifying the semantics of archetyping/constraining/querying the "details" property of the FOLDER class. That is likely exactly the same implementation and behaviour as for any other ITEM_STRUCTURE. * Later, in a future version of the specs, maybe specify desired behaviour for archetyping/constraining/querying the "folders" property of the FOLDER class. Implementing that is likely more complicated, especially the querying. ![image|690x489](upload://4HyAsj43MVS6kVbEoAOybFTzPuP.png) --- ## Post #5 by @Seref I think they would complicate things. As usual, you did a great job of identifying various edge cases and all I'm seeing in your summary is complexity. The way I see it, clinicians do not require FOLDERs to express clinical concepts in models, so I'd personally leave it out of scope of archetyping/modelling. --- ## Post #6 by @thomas.beale [quote="Seref, post:5, topic:3081"] The way I see it, clinicians do not require FOLDERs to express clinical concepts in models, so I’d personally leave it out of scope of archetyping/modelling [/quote] Not clinical concepts, agree, but standardising ways of arranging / classifying information elsewhere in the EHR, I think you will find that some vendors will want this. DIPS already does it, and I think Code24 does as well; whether they use archetypes or not to create those FOLDER structures I don't know, but it would be the easiest way to do it i.e. since it can just be done in the same tool as everything else, e.g. Archetype Designer. The vendors that don't are probably using some kind of tagging system (e.g. Better). --- ## Post #7 by @erik.sundvall Yes, when building/configuring systems some folder metadata archetyping and associated querying would be very useful for use cases where you want to (possibly hierarchically) group related compositions in a versioned way without changing anything inside the (possibly signed) compositions themselves. Also some metadata is often needed for such groups. I believe @bna has previously detailed how AQL could be extended to use folder based querying with different depths. In use cases where neither hiearchy nor versioning is needed, I assume that "tags" are enough (if they also can be used to filter queries). --- ## Post #8 by @joostholslag [quote="Seref, post:5, topic:3081"] clinicians do not require FOLDERs to express clinical concepts in models [/quote] Well, we intend to use folders to model episodes (collections of progress notes). I already had a go at archetyping folders. To add meta-data like, start date, name of episode, etc.etc. I can dit up the folder archetype if helpful. Main thing missing was to add meaning to a link in the folder. E.g. this problem is the reason for admission. --- ## Post #9 by @thomas.beale [quote="joostholslag, post:8, topic:3081"] Main thing missing was to add meaning to a link in the folder. E.g. this problem is the reason for admission. [/quote] This is the 'how to archetype links' question. I have some proposals for this. --- ## Post #10 by @Seref Now that deserves a discussion :) I was going to go into this last night in response to Tom, but decided not to because it would be just a speculative discussion. Not anymore. [quote="joostholslag, post:8, topic:3081"] Well, we intend to use folders to model episodes (collections of progress notes). I already had a go at archetyping folders. [/quote] I find it interesting that you have a need to model a clinical concept, and you're looking into `FOLDER` to express that semantics instead of other types from the RM. Could you comment on why you're considering the approach you have in mind? (Not implying you're doing anything wrong, genuinely asking). [quote="joostholslag, post:8, topic:3081"] To add meta-data like, start date, name of episode, etc.etc. [/quote] [quote="joostholslag, post:8, topic:3081"] Main thing missing was to add meaning to a link in the folder. [/quote] These two are related and interesting, I think. FOLDER is fit for purpose to point at something and provide some metadata, but that's it. By design, it does not employ the approach used in most of the RM: expressing semantics via dedicated types. I know openEHR takes a lot of criticism because of `OBSERVATION`,`EVALUATION` etc but they express meaning via dedicated types and that's a good thing. Both archetyping and AQL are built on this design: define constraints on types to clarify what you mean :) So they are the meaningful parts in the RM and `FOLDER` is ... meaningless! It's supposed to point at a meaningful thing, or so is my view. Given its design, you would probably have to archetype the metadata of the FOLDER, i.e. an ITEM_STRUCTURE to express the meaning you have in mind, and that feels like a square peg in a round hole to me. My impulsive response (not well thought out at all) would be: "would not it be more idiomatic if you had a cluster archetype to which you pointed at with a folder?" At least you'd be archetyping something that is commonly archetyped :) I.e. a cluster archetype to describe episodic concepts, a folder with N object references, bringing together the compositions and the episode cluster. (though I don't know what kind of composition would host that episode cluster :) ) This is all coming from a programmer's brain, so it may not be valid in the modelling space, but I find myself walking into trouble every time I use different ways of expressing semantics side by side, and the complexity I mentioned in response to @pablo 's question comes from the above situation leading to this mixed-way-of-representing-things. Thanks for allowing me to expand on my answer to Pablo. Please see the above as just food for thought. It'd be interesting to see how your Folder archetype attempts ended up, if you don't mind sharing as you suggested. Np if you cannot. --- ## Post #11 by @erik.sundvall [quote="Seref, post:10, topic:3081"] “would not it be more idiomatic if you had a cluster archetype to which you pointed at with a folder?” At least you’d be archetyping something that is commonly archetyped :slight_smile: I.e. a cluster archetype to describe episodic concepts, a folder with N object references, bringing together the compositions and the episode cluster. (though I don’t know what kind of composition would host that episode cluster :slight_smile: ) [/quote] Well, using "normal" cluster archetypes for the `details`* field in FOLDERs would certainly be possible. The enclosing archetype with possible slot(s) for clusters could/would be a FOLDER-based archetype instead of COMPOSITION-based archetype. That would likely be no different or harder than (what I believe you are proposing) using the `items` property "pointing" to some specific designated COMPOSITION (among all the ones pointed to) containing a CLUSTER with info about the specific folder. [*EDIT: see clarifications by @Seref and @ian.mcnicoll below] --- ## Post #12 by @Seref [quote="erik.sundvall, post:11, topic:3081"] Well, using “normal” cluster archetypes for the `details` field in FOLDERs would certainly be possible [/quote] I thought that `details` is of type `ITEM_STRUCTURE`. Can we put a `CLUSTER` archetype there? Unless I'm missing something, that's not valid as per RM type definitions? --- ## Post #13 by @ian.mcnicoll [quote="Seref, post:12, topic:3081"] I thought that `details` is of type `ITEM_STRUCTURE`. Can we put a `CLUSTER` archetype there? Unless I’m missing something, that’s not valid as per RM type definitions? [/quote] The way this normally works for Composition/context, is to add a Slot to ITEM_STRUCTURE that can then be used to carry a CLUSTER archetype --- ## Post #14 by @Seref Ok, that's very interesting . I'll tread carefully here because I'm sure I am missing something. @thomas.beale can you confirm my understanding of what Ian's saying: they're defining a slot for an RM type's field with a different type than the one declared by RM and there is no subtype relation between ITEM_STRUCTURE and CLUSTER. That would lead to an invalid RM instance being defined/allowed? I am almost always out of brain cells these days, so some help would be great, how does that work? Maybe I'm misunderstanding the OO/Type level definition of what's being described here. Or I'm missing some type hierarchy relationship in the below? ![image|659x500](upload://nzKh17h4U8AOYGqbnZxRdnwZHNP.png) --- ## Post #15 by @Seref Sigh. To reply to myself, Erik and Ian are talking about using a slot for ITEM_STRUCTURE.items, not for the field with the ITEM_STRUCTURE type. Sorry, I was being too strict in my interpretation of what is meant (I think...) --- ## Post #16 by @ian.mcnicoll It looks as if the tooling is correctly injecting an ITEM_TREE to hold the slot definition, ``` context matches { EVENT_CONTEXT matches { other_context matches { ITEM_TREE[at0001] matches { -- Tree items cardinality matches {0..*; unordered} matches { allow_archetype CLUSTER[at0002] occurrences matches {0..*} matches { -- Extension include archetype_id/value matches {/.*/} } } } } } } } ``` --- ## Post #17 by @Seref It looks as if you're omitting the difference between `ITEM_TREE` and `ITEM_TREE.items` :P Sorry, I had to :) Jokeing aside, many thanks to all for patiently explaining what they mean. It makes sense to use `FOLDER` this way. The query side is interesting though, where would users of AQL see FOLDER, under an EHR. As a sibling of Compositions? --- ## Post #18 by @pablo Hi all! thanks for your answers and discussions, I see some would like to use FOLDERs in an ad-hoc way, others would like to have just generic archetypes for FOLDERs, and some would like to have very strict structures to use folders to model certain things like care plans or specific types of episodes. From the querying point of view, not having an archetype would be like not having a schema to query from, so using FOLDERs in an ad-hoc way (not constrained) would lead to also query in an ad-hoc way without knowing the structure of the data being queried, which works if you already now the data, but doesn't on other use cases. From the conformance point of view, archetypes are needed, generic or very specific. So we can create test cases for those archetypes and verify: 1. folders are validated against their archetypes 2. querying folders based on their archetype definition is possible 3. if a folder structure is defined in a template, and this is where things get tricky, does the template define the whole EHR.directory structure or not? For testing conformance too, I would like to define constraints on folder names, folder items, folder subfolders (e.g. can't contain subfolers, can contain N..M subfolders, 0..*, 1..*, ...), etc. The challenge I see in OPTs for folders is defining the whole EHR.directory structure in an OPT could be difficult and will result in a rigid structure, I think that is needed but also at some point we need the flexibility of adding a custom/ad-hoc folder somewhere just because a doctor wants to organize their documents or have some organization/classification for researching and teaching, etc. From the implementation point of view, I'm guessing implementations using folders have other mechanisms than archetypes to define their internal structure and to be able to query that structure. I'll try to come up with more concrete examples so we can discuss them. --- ## Post #19 by @thomas.beale [quote="Seref, post:14, topic:3081"] they’re defining a slot for an RM type’s field with a different type than the one declared by RM and there is no subtype relation between ITEM_STRUCTURE and CLUSTER. [/quote] Generally speaking, 'open' fields have the type `ITEM_STRUCTURE`, e.g. as you see here (and as you know, but just answering anyway, since others might not realise, and it is a very legitimate question) ![ITEM_STRUCTURE|690x383](upload://xtu4x9fh3bjSA9t9gYYHONdvssa.png) We made it the same type in new places, such as `FOLDER`. It's easy to deal with in archetyping - see @ian.mcnicoll 's response above - it's just a wrapping question. In hindsight, if we had not had `ITEM_STRUCTURE` and descendant types (clinical types were sure we needed them in 2003!), we would have just (I imagine) connected straight to `CLUSTER`. We didn't, and in the intervening years, the clinical modelling community realised they really just wanted trees, which could have just been `CLUSTER`. So we live with a bit of annoying wrapping going on here - I see it as the price of not having gotten everything right at the start (and maybe not realising early enough that we could potentially ditch the `ITEM_STRUCTUREs`). It's life. In openEHRv2, things would be as you would like (and many others - @erik.sundvall and others have been agitating for this change for years), it's just that it's a breaking change from a software point of view, so we have to wait for a new major version of openEHR... --- ## Post #20 by @thomas.beale [quote="Seref, post:15, topic:3081, full:true"] Sigh. To reply to myself, Erik and Ian are talking about using a slot for ITEM_STRUCTURE.items, not for the field with the ITEM_STRUCTURE type. Sorry, I was being too strict in my interpretation of what is meant (I think…) [/quote] I see better quality coffee was consumed at some point...! (Meanwhile I was having my own fail, trying for 45 mins to find VirtualBox guest additions, when I finally realised the .iso was already mounted and just needed to have the executable run... one of those days...) --- ## Post #21 by @thomas.beale [quote="pablo, post:18, topic:3081"] From the querying point of view, not having an archetype would be like not having a schema to query from, so using FOLDERs in an ad-hoc way (not constrained) would lead to also query in an ad-hoc way without knowing the structure of the data being queried, which works if you already now the data, but doesn’t on other use cases. [/quote] yep. [quote="pablo, post:18, topic:3081"] For testing conformance too, I would like to define constraints on folder names, folder items, folder subfolders (e.g. can’t contain subfolers, can contain N…M subfolders, 0…*, 1…*, …), etc. [/quote] Also yep... [quote="pablo, post:18, topic:3081"] The challenge I see in OPTs for folders is defining the whole EHR.directory structure in an OPT could be difficult and will result in a rigid structure, I think that is needed but also at some point we need the flexibility of adding a custom/ad-hoc folder somewhere just because a doctor wants to organize their documents or have some organization/classification for researching and teaching, etc. [/quote] Well as long as you don't prevent the addition of other Folders in the archetypes, this will always be possible. Plus, don't forget, there are now multiple independent FOLDER trees (there used to be only one, called `directory`). Whether any particular implem/ product has this depends on whether they have upgraded their [EHR RM to Release 1.1.0 / SPECRM-55](https://specifications.openehr.org/releases/RM/latest/ehr.html#_amendment_record)) --- ## Post #22 by @ian.mcnicoll I had assumed (perhaps quite incorrectly!!) that FOLDER would sit between EHR and COMPOSITION in AQL with CONTAINS??? SELECT c FROM EHR e CONTAINS FOLDER f['Diabetes Care plan'] CONTAINS FOLDER f2[''UnCurated device data] CONTAINS COMPOSITION c --- ## Post #23 by @pablo [quote="thomas.beale, post:21, topic:3081"] [quote="pablo, post:18, topic:3081"] The challenge I see in OPTs for folders is defining the whole EHR.directory structure in an OPT could be difficult and will result in a rigid structure, I think that is needed but also at some point we need the flexibility of adding a custom/ad-hoc folder somewhere just because a doctor wants to organize their documents or have some organization/classification for researching and teaching, etc. [/quote] Well as long as you don’t prevent the addition of other Folders in the archetypes, this will always be possible. [/quote] That's is kind of the sweet spot, having most of the FOLDER internal structure and tree in an OPT without finalizing the structure: allowing additions via extensions to the archetypes inside the OPT and versioning the OPT or in an ad-hoc/custom/runtime way, though those folders added at runtime still have to comply with some archetype and be added to a place where there is an open constraint matches {*} or a slot to that archetype. What shouldn't happen IMO is adding folders that have archetype ID info and the archetype doesn't exists (we can't allow that dummy data in CDRs for is not correct from the conformance standpoint). So I might be answering myself, but I think CDRs should provide (and maybe we need to have them in the CKM) a basic set of generic/unconstrained folder archetypes to be used on those custom cases. I will try to come up with a basic set. Note: FOLDER is not even a type in the CKM ![Screenshot_2022-10-26_21-59-09|263x361](upload://iVefqV1EHd5u9eKZQO4e7731rJr.png) I guess we can't avoid the querying issue: any open constraint is something we can't use to create a query (we don't know which paths will exists in data in order to query over them). [quote="thomas.beale, post:21, topic:3081"] Plus, don’t forget, there are now multiple independent FOLDER trees (there used to be only one, called `directory`). [/quote] I know, just don't want to add multiplicity to the issue, is just too complex as it is, having discussed a 1..1 case we can think of the 1..* case later. --- ## Post #24 by @damoca We had some experience creating FOLDER archetypes (for ISO 13606) around 10 years ago. In that case the objective was not to model the persistence of data, but to have a way to define a view of the EHR in an EHR viewer application. In that context, it worked quite nicely, just as a template to render nodes for each hospital specialty in an EHR tree. The only problem is that we had to introduce an internal patch in order to point to specific COMPOSITION archetypes from each folder in the FOLDER archetype (the problem of 'how to archetype links' previously mentioned by @thomas.beale ). You can try to create FOLDER archetypes in LinkEHR Studio, although I think the FOLDER RM is not completely up to date. We'll fix it ASAP. ![image|465x346](upload://rtGg41lj8CJqKAXSkCaDIwZOXnW.png) --- ## Post #25 by @ian.mcnicoll Nice to know that can be done David, bit I'm not sure in my own head if this sort of archetyping/templating is the right approach, as the main value of Folders that I can see (or indeed tags) is that they are multi-hierarchical. There is a definitely a need to document/formalise their use (and indeed higher-level architectures in general) but is current templating the right language? We are working on a Diabetes care pathway, so we might need to 'tag' a composition a s being inside a number of folders 1. Diabetes care journey 2. Maybe a folder to represent an admission (if the data is about Diabetes and tan admision) 3. Maybe another folder to indicate that this is patient-contributed data that has not been curated And of course a a lot of different variations - so not simple nesting. @joostholslag @sebastian.iancu - it would be interesting to understand your usage and how you document use. Just not sure that .opt is the right direction. --- ## Post #26 by @damoca Defining archetypes/templates for FOLDERS is just a piece of the solution. We could try to solve it by two approaches or a combination of both. In a top-down approach, we need to be able to define which COMPOSITIONS go inside of each FOLDER. This is useful, as in the project we did, to create dynamic views of data, independently of how they are stored in the CDR. There is where we need some kind of additional reference or slot constraint to attach an archetype id or even an AQL. ![image|690x262](upload://foZDB6lHl9QiVlk89TuaFHXKQ5s.png) In a bottom-up approach, we need to define in which folders a COMPOSITION archetype will be persisted. This requires a deeper analysis, but a quick and dirty solution would be to have a pointer from the COMPOSITION class to the IDs of the container FOLDERs. Then, during the templating phase, we could define in which FOLDERs we want to put the instances of those compositions. In order to minimize changes in the EHR, maybe this pointer could be just the current LINK. In that case, we need again a method to express a semantic constraint to that link. Note that the following image is just an example of the idea, not a technical valid implementation. Additionally, we could define as many sibling links as we want to solve the multihierarchy problem of FOLDERs. ![image|582x323](upload://g2x5NXm6TQlcG3bcIR8eimJqODk.png) --- ## Post #27 by @erik.sundvall [quote="pablo, post:18, topic:3081"] 3. if a folder structure is defined in a template, and this is where things get tricky, does the template define the whole EHR.directory structure or not? [/quote] To get some value out of archetyped folders without having to deal with the tricky/messy parts i still think we should specify and implement/test this in two steps/phases... [quote="erik.sundvall, post:4, topic:3081"] * **First** maybe we should just try specifying the semantics of archetyping/constraining/querying the “details” property of the FOLDER class. That is likely exactly the same implementation and behaviour as for any other ITEM_STRUCTURE. * **Later**, in a future version of the specs, maybe specify desired behaviour for archetyping/constraining/querying the “folders” property of the FOLDER class. Implementing that is likely more complicated, especially the querying. [/quote] ...and publish in different RM version releases, where the later step is informed by what we learn from the first. --- ## Post #28 by @erik.sundvall [quote="damoca, post:26, topic:3081"] a quick and dirty solution would be to have a pointer from the COMPOSITION class to the IDs of the container FOLDERs [/quote] I may have misunderstood the specific purpose of the suggested backwards pointer, but in general we would not like to change anything inside a (possibly signed) composition whenever we choose to change what FOLDER a COMPOSITION is placed in. Thus pointing to COMPOSTIONS from a FOLDER (i.e. the way FOLDER already works) is more OK than pointing the other way around to define CONTAINED_IN. --- ## Post #29 by @thomas.beale [quote="erik.sundvall, post:28, topic:3081"] suggested backwards pointer, but in general we would not like to change anything inside a (possibly signed) composition whenever we choose to change what FOLDER a COMPOSITION is placed in [/quote] Indeed - this is not something you want to do - it makes committed clinical content dependent on someone's classification scheme. And don't forget a Composition can be referred to by multiple Folders, e.g. for episode, and also for various research projects or other themes. --- ## Post #30 by @pablo [quote="damoca, post:24, topic:3081"] You can try to create FOLDER archetypes in LinkEHR Studio, although I think the FOLDER RM is not completely up to date. We’ll fix it ASAP. ![image|465x346](upload://rtGg41lj8CJqKAXSkCaDIwZOXnW) [/quote] Nice @damoca , in fact something like that is what I had in mind, though by the comments of others, we need to keep that structure as "not finalized" so other folders could be added at runtime, though I would prefer to have an explicit declaration of an open constraint that allows to add more folders there but complying with any archetype. [quote="ian.mcnicoll, post:25, topic:3081"] the main value of Folders that I can see (or indeed tags) is that they are multi-hierarchical. There is a definitely a need to document/formalise their use (and indeed higher-level architectures in general) but is current templating the right language? [/quote] That multi-hierarchy is what kicked my initial question. @ian.mcnicoll for which cases you don't see archetypes/templates fit? I would like to understand all points, and for me I don't see a limitation of archetyping folder structures if we mix defined constraints and open constraints in the same OPT to allow flexibility. [quote="ian.mcnicoll, post:25, topic:3081"] We are working on a Diabetes care pathway, so we might need to ‘tag’ a composition a s being inside a number of folders [/quote] This doesn't seem to be related to the folder structure itself, but to define which items are included in which folders, which IMO should be a runtime thing, not really a modeling constraint. Another unrelated point we touched some time ago: we would need folders outside ehrs to organize population data (compositions or subcomponents of compositions, from different EHRs inside the same folder). Did the SEC reached any conclusion about this? (I can open a new thread) --- ## Post #31 by @sebastian.iancu [quote="thomas.beale, post:6, topic:3081"] and I think Code24 does as well [/quote] [quote="joostholslag, post:8, topic:3081"] Well, we intend to use folders to model episodes (collections of progress notes). I already had a go at archetyping folders. To add meta-data like, start date, name of episode, etc.etc. I can dit up the folder archetype if helpful. [/quote] [quote="Seref, post:10, topic:3081"] you have a need to model a clinical concept, and you’re looking into `FOLDER` to express that semantics instead of other types from the RM [/quote] [quote="Seref, post:10, topic:3081"] FOLDER is fit for purpose to point at something and provide some metadata [/quote] We also use FOLDER to "organize" and bind COMPOSITIONs to an Episode, or to a Care-plan; for clinical or administrative info (dates, reason, statuses, providers, etc.) we use a COMPOSITION, also binded to same FOLDER. We also use FOLDER to "tag" and organize imported COMPOSITION (from associated legacy systems and EHRs). This is not the same as the other support for tags/labels, which is implemented differently; tags can be associated with COMPOSITIONs (actually anythign that versionable). [quote="Seref, post:10, topic:3081"] “would not it be more idiomatic if you had a cluster archetype to which you pointed at with a folder?” [/quote] That might work, but I think there is a lot of overhead - don't you agree? (trying to reuse a clinical type/sub-structure of a COMPOSITION to persist metadata) --- ## Post #32 by @sebastian.iancu [quote="ian.mcnicoll, post:22, topic:3081"] SELECT c FROM EHR e CONTAINS FOLDER f[‘Diabetes Care plan’] CONTAINS FOLDER f2[’'UnCurated device data] CONTAINS COMPOSITION c [/quote] This was a discussion some time ago indeed. You can see it as FOLDERs sits between ENR and COMPOSITIONs, but actually (technically) they sists next to COMPOSITIONs, which they refer to. So the CONTAINS operator is not completely right here - although I can imagine it be convenient/intuitive when you just look to AQL expressiveness. I'm curious about nowadays opinions on this - but perhaps is worth revisiting this subject in SEC under AQL. --- ## Post #33 by @damoca This is closely related to what it is being discussed here: https://discourse.openehr.org/t/archetyping-links-and-references/3112?u=damoca If we are able to better constrain a link between folders and compositions (or between any RM class through the LINK or REFERENCE), then we will have the technical basis to analyze how to bring that to the AQL. --- ## Post #34 by @thomas.beale [quote="sebastian.iancu, post:32, topic:3081"] This was a discussion some time ago indeed. You can see it as FOLDERs sits between ENR and COMPOSITIONs, but actually (technically) they sists next to COMPOSITIONs, which they refer to. So the CONTAINS operator is not completely right here - although I can imagine it be convenient/intuitive when you just look to AQL expressiveness. I’m curious about nowadays opinions on this - but perhaps is worth revisiting this subject in SEC under AQL. [/quote] [quote="damoca, post:33, topic:3081"] If we are able to better constrain a link between folders and compositions (or between any RM class through the LINK or REFERENCE), then we will have the technical basis to analyze how to bring that to the AQL. [/quote] The more I think about it, perhaps we should reserve CONTAINS for inline (by-value) composition (i.e. in the UML sense). A new keyword could be used, e.g. INCLUDES or similar that covers by-reference inclusions, as well as what CONTAINS matches. The idea that CONTAINS is going to start returning matches from referenced items as well as inline data I would say is wrong - we need to be able to distinguish these. --- ## Post #35 by @ian.mcnicoll [quote="thomas.beale, post:34, topic:3081"] The more I think about it, perhaps we should reserve CONTAINS for inline (by-value) composition (i.e. in the UML sense). A new keyword could be used, e.g. INCLUDES or similar that covers by-reference inclusions, as well as what CONTAINS matches. [/quote] We did discuss that before, and I'd support something like INCLUDES as long as it includes CONTAINS!! I want to be able write queries that are agnostic of the type of association --- ## Post #36 by @sebastian.iancu [quote="ian.mcnicoll, post:35, topic:3081"] like INCLUDES as long as it includes CONTAINS! I want to be able write queries that are agnostic of the type of association [/quote] [quote="thomas.beale, post:34, topic:3081"] CONTAINS is going to start returning matches from referenced items as well as inline data I would say is wrong [/quote] I can get both perspectives, but this turns into a discussion we should have in SEC, perhaps in a AQL subgroup? --- ## Post #37 by @pablo I think, beside the AQL syntax, we need to define the basic requirements for using FOLDER in queries. For instance: 1. query folders by their name 2. by their archetype 3. by contains some other (sub)folder (by name or archetype) 4. by contains some other (sub)folder (just existence of any subfolder) 5. by contains an item of certain type (RM class, COMPOSITION, PARTY, ...) 6. by contains an item for a certain archetype or template 7. by contains an item (just existence of any item) 8. in newer versions of the RM only, query by the folder details (filter by it's data) Those are conditions for the AQL FROM and WHERE. Then the possible projections (SELECT projections) 1. full folder 2. subfolders 3. items 4. certain part of folder 5. certain part of subfolders (including 6 and 7 for the subfolders) 6. certain part of items 7. certain part of the folder details Is there anything else that you can think for supporting FOLDERs in queries? If we have the full list of requirements, we can design the syntax later. --- **Canonical:** https://discourse.openehr.org/t/practical-approach-to-folder-opts/3081 **Original content:** https://discourse.openehr.org/t/practical-approach-to-folder-opts/3081