I have read the PPT from Thomas which is linked in http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern
I have some remarks on that. My two cents: The proposal is written from the point of view of OpenEHR. Although, I cannot comment on medical content, only from the point of view of information/developer. Unknown future use-cases must be implementable. The OpenEHR RM is too semantic to be flexible on the long term. So, all arguments, coming back a few times, about no need to change the RM can safely be dismissed. Why would one not want to change the RM, when the use of the RM changes. It is better to have an optimal RM for its purpose, than misusing an RM which was designed with other goals in mind. It is better to learn a lesson than to get stuck on a suboptimal legacy RM. Thomas agrees in Option 6, which I think is his preferred Option. So the lesson is: No semantics in the Reference Model. Also, because of the unknown use-cases, no other constraints on the reference-model itself, but still we need predictable query-paths. This means, the RM cannot provide in this, so predictable query-paths should be in the archetype modeling instead of the reference model. The enforcement of consistent/predictable paths has to be done by the information-analyst when writing or choosing archetypes. The RM only need to give as much room as possible to do so. To the Options: Option 1: Because of the no changing of the RM, but no use of semantic RM-classes we stick to GENERIC_ENTRIES for this? The point that the PANEL-information needs to be distinguished from TEST-entries is not a real disadvantage. Because we are, in this option, not talking about another RM, it must be that we are talking about an consistent Archetype-Model. An archetyped schema. SO it is all in the SECTIONs. For developing a kernel there can be consequences when an Archetyped Schema is used, there can be kernel-layer which is optimized for using that schema. For example, it can be optimized to know where to find the PANEL information. Maybe that is a good approach, having a kernel-layer optimized in this way. Software is then aware of the (by archetypes) enforced structure. This layer be a semantic rich API on a generic working kernel. Option 2 is ignoring that the COMPOSITION-class is a good class as it is, and making a kind of ENTRY-class of it. Plus, that the level of possible depth-levels is reduced. Instead of the step in between of SECTION, we jump right away to ENTRY-CLUSTER. Also the query-path will not be stable because of the archetype-node-ids and the CLUSTER will need to be overloaded with semantic information. I think this is a poor option. Option 3, the Uber Model, looks attractive, but there are some disadvantages, as I understand well. Lets assume I understand well: The "Uber" archetype will contain lots of unused entries, maybe only 10% or less is used in a specific case. Although this delivers a predictable path-structure. But then the kernel-software needs to check that many times, for example during data-entry, and also at query-time. This checking could be avoided if there was an index-entry at the top of the Uber-Archetype which would contain information about which entries are used. So to say, a meta-information-entry in the Uber-Archetype. Option 4 with LINKS does not attract me much because it will need subqueries, which will make datamining difficult. The advantage of TESTS which can stand independently also can exist in the Uber-model. For Option 5, I cannot imagine a use-case. It seems hypothetical to me. So we arrive at Option 6, which seems, considered against the previous 5, having best of all worlds. And it does not try to keep the RM unchanged, although it can be done in an older RM. But it seems a bit similar to Option 2, which also has no SECTIONs. In my opinion Option 3 and Option 1 are the best options, but both could need an extended specific kernel-layer which is able to use the archetype-modeling-structures optimized. Option 2 and Option 4 are more or less just flattening the structure, which will be a disadvantage when there is a parallel need to handle other Archetyped Schemas as well. I don't recognize a need to do that. Best regards Bert Thomas Beale schreef op 15-2-2014 13:12: > > Hi Pablo, > > I don't personally particularly agree with this approach either. There > are two other approaches that could be used: the COMPOSITION / SECTION > / multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an > earlier suggestion of Ian's and mine). I am going to build these > models as CIMI archetypes as well, and document the results on the > wiki as well. Then we can see the outcomes and judge objectively. > > - thomas > > On 14/02/2014 22:48, pablo pazos wrote: >> Hi Thomas, >> >> Overviewing the content on the wiki, IMO panels are an specification >> of sections. >> >> Is very weird from the modeling point of view to have a composite >> pattern (ENTRY, COMPOUND_ENTRY, ...) inside a composite pattern >> (CONTENT_ITEM, SECTION, ENTRY), is like defining a tree inside a tree >> in the model, but the initial model can also model the second, is >> just redundant. And IMO it doesn't add semantics to the model. >> >> It is also stated that "a panel is not a Section; it has specified >> and fixed [potential] content", so it could be a templated section >> maybe (?). Without that statement, is clear that a collection of >> observations is just a SECTION with slots to OBSERVATIONS (archetyped >> or templated). >> >> Also, the name "panel" makes me think of an user interface element, >> not a data structure. It would be nice to know why they need this new >> composite structure there, and if the requirement comes from >> structural needs or from information display needs. >> >> As I see it, CIMI is mixing SECTIONS and ITEM_STRUCTURES. >> >> >> OT, I tried to get closer to CIMI, but it seems difficult to >> participate from outside the EURO zone :( > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140216/7033d7f3/attachment.html>
