CIMI archetype examples using latest openEHR AOM & ADL
Thomas Beale schreef op 16-2-2014 14:18: > just to clarify, this PPT was created by the CIMI - it's based on the > CIMI model, not the openEHR reference model. I have only made comments > about it, not authored it. > Hi Thomas, I am sorry for that, I was apparently too hasty reading it. I really was seeing an openEHR-like RM mixed with 13606-like RM in it. I don't know where I started misunderstanding, but the further contents did not force me to correct my assumption. Anyway, the Option 6 in the PPT is stating that this is not able to address the information-structure needs of CIMI. (really stupid, how can such a mistake happen...? never read email before breakfast) Gd Morning Amsterdam.! But it is not as bad as it seems. The PPT did start me thinking, things which were on my mind for longer time. > well it depends on what we mean by 'changing' the RM. The archetype > method relies on not changing (i.e. incompatibly with the past) the > existing RM. But there is no reason not to add to the RM. It is indeed dangerous that a changing RM can be the cause for incompatibility, because with the change, the need to have software based on it the old can vanish, and old datasets could be left orphaned. So the solution as you say: - added classes OR (my suggestion) - a new/other RM but with another name/background/version, which does not stand in the way of the OpenEHR-RM. Why is that? > My view is that 'domain-invariant semantics' should be included (for > whatever you say your domain is, e.g. EHR, health data etc), and that > variable semantics should go into archetypes. As far as concerning the semantics, I was indeed referring to domain-invariant semantics. Do they exists? Or is it possible that a new way of structuring health-data can come to life with no clear use for the semantic rich ENTRY-classes. We see already that for CIMI new classes are needed, is there a solution for this in relation to OpenEHR? I think we are in a bit curious situation. We have two two-level-modeling RM's. One is OpenEHR and the other is EN13606. The first carries too much semantics (in my opinion) and is therefor candidate for further grow, and the second has hard times getting rid of its messaging purpose-history, and has therefor no classes for relationships in demographics. Why don't we mix the both, replace the OpenEHR composition semantics by the 13606 composition-generics and keep the demographics? We can than express new and old structuring health-data in the archetypes and create complete archetyped schemas. (This will not be the complete picture, after that there might be some addition needed.) Bert
CIMI archetype examples using latest openEHR AOM & ADL
Thomas, That is fully correct. Even a ?one? and ?zero? have a well defined meaning, as do their associated voltage levels in the CPU. In our domain of eHealth it must be clear that when we speak about ?Semantic' we mean health related semantics, the clinical aspects. I am a firm believer in a separation of concerns between the various layers in the semantic stack. The RM must address the legal and ethical aspects of document structure of any thing. Archetypes/Templates deal with the eHealth/Clinical semantics inside these structures. There is nothing misleading. It is wrong to mix general legal ethical aspects, document structure aspects, with specific health specific semantic aspects. It is a wrong idea to mix these aspects. The domain specific but invariant aspects must be dealt with in standardised patterns we use to construct (clinical, administrative, management, re-use) archetypes and templates. And some parts of the semantics, as you advocate, in the RM and others in archetype patterns is wrong. That is my opinion. Gerard Freriks +31 620347088 gfrer at luna.nl On 16 feb. 2014, at 14:18, Thomas Beale wrote: > > this is a common but misleading idea! There are semantics everywhere. Even > the type 'Integer' has some semantics. The question is what semantics should > be in the RM versus what should not be. My view is that 'domain-invariant > semantics' should be included (for whatever you say your domain is, e.g. EHR, > health data etc), and that variable semantics should go into archetypes. The > trick is to work out where that boundary actually is. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140216/3f886873/attachment-0001.html>
CIMI archetype examples using latest openEHR AOM & ADL
On 16/02/2014 09:24, Bert Verhees wrote: > I have read the PPT from Thomas which is linked in > http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern just to clarify, this PPT was created by the CIMI - it's based on the CIMI model, not the openEHR reference model. I have only made comments about it, not authored it. > > 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. well it depends on what we mean by 'changing' the RM. The archetype method relies on not changing (i.e. incompatibly with the past) the existing RM. But there is no reason not to add to the RM. E.g. if we want to model structures that would occur in CDISC and also Query return structures, we should add these to the RM. I am in favour of that. > 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. No argument there. The CIMI group however I think is trying to obtain an optimal RM for authoring shareable archetypes in a clean way that supports conversion and reuse in concrete existing formats. > > Thomas agrees in Option 6, which I think is his preferred Option. > > So the lesson is: No semantics in the Reference Model. this is a common but misleading idea! There are semantics everywhere. Even the type 'Integer' has some semantics. The question is what semantics should be in the RM versus what should not be. My view is that 'domain-invariant semantics' should be included (for whatever you say your domain is, e.g. EHR, health data etc), and that variable semantics should go into archetypes. The trick is to work out where that boundary actually is. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140216/b9515c48/attachment.html>
CIMI archetype examples using latest openEHR AOM & ADL
ation >> 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>
