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) Gooood 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
