CIMI archetype examples using latest openEHR AOM ADL
Thanks, Peter, I must have missed the discussion before, and I checked a bit the discussion of December 2012. It was not like I had it in my mind, it was more about the way to avoid archetypeId-clashes then about the archetypeId-clashes itself, as I yesterday suggested. However, in the wiki you link to is first time a ID-system described after the discussion in 2012, but the messages from 2011 and 2009 indicate that the problem was identified before the discussion in 2012, and I was wrong in thinking that I brought the problem under attention. I just brought a possible solution under attention. Thanks for clarifying this. Bert On 02/19/2014 06:00 AM, Peter Gummer wrote: Bert Verhees bert.verhees at rosa.nl wrote: Maybe this discussion has been on this list before December 2012, I must have missed it. Hi Bert, There was a long discussion 18 months earlier than that one: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2011-April/005941.html But a proposed fix for the problem was already being discussed five years ago: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-June/004600.html And note that the wiki page was created at the same time: http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
CIMI archetype examples using latest openEHR AOM ADL
Ian, It is fore most a matter of principle. The question to answer is where are the boundary lines between the different layers of the Semantic Stack. Feel free to blur this anyway you like. I?m a firm believer that we must prevent problems in the future. The RM must be stable and must NOT contain any semantic notions. It must deal with lego-ethical things of storing, retrieving, exchange, etc. All the health specific semantics have to be dealt with in the archetype layer. And the set of standardised super-archetypes we use to specialise all other from. The whole business of taking care of the full semantics is to fluid at this point in time to be frozen in the RM. Gerard Gerard Freriks +31 620347088 gfrer at luna.nl On 18 feb. 2014, at 13:11, Ian McNicoll ian.mcnicoll at gmail.com wrote: Hi Gerard, Good question. The value is not in the classification but in the attributes provided by the class. These save me some work as a modeller, should help the developer optimise some system aspects optimally (e.g by knowing that every ACTION archetype inherits a time and status that can be optimised for querying). The first thing to say is that I do not see a particularly clear distinction between 'classes' modelled in a Reference model and 'top-level' i.e rigid patterns modelled in archetypes. In both cases you are providing modellers with some fixed attributes which are inherited by child archetypes. I am going to use Contsys as an example since this is alternative example of where the modellers have introduced specific classes/top-level patterns to reduce variability and enhance computability. IMO it does not really practically matter whether the Contsys 'Assessed Condition' is modelled in UML as part of the RM or provided as a 'reference archetype' sitting on top of a leaner RM. In both cases, if I want to adhere to the ContSys model, I have to inherit from 'Assessed Condition'. That puts severe constraints on the way that 'Assessed Condition' develops over time. It must remain very stable and carefully managed whether an RM construct or a top-level archetype. So whilst the full-blown generic ENTRY has value, both openEHR and Contsys do offer semi-rigid top-level patterns either via RM or 'reference archetypes'. In fact 'onotologically' there is a pretty close match between the ContSys 'Entry' models and openEHR Entry sub-classes AssessedCondition = EVALUATION Observed/PerceivedCondition = OBSERVATION Activity = ACTION which is unsurprising since both work from the same 'clinical process model'. If we accept that there is some utility in establishing these 'top-level patterns', we are inevitably going to run into use-cases where it is unclear if an ENTRY is an Observation or Evaluation but equally where it is unclear if a Condition is Assessed or Observed (smoking or housing summary being a prime example), or a least where there is variable interpretation. In most case this mixed or muddled classification is not at all important for querying purposes. I am not aware of any situations where I want to query for Observations. I want to query for 'Smoking Summary'., If I happened to model it as an Observation I would get the 'observation time' as part of the RM (or top-levle archetype). If I modelled it as an Evaluation, I would have to create a date recorded/verified' node explicitly in the archetype. So t value of the Classes/top-level archetypes are in the attributes that child archetypes can inherit, saving modelling effort and applying some consistency which can be exploited by developers, but there is little value in the classification per-se, other than as a guide. We do not query on archetype ENTRY sub-classes. Ian On 17 February 2014 23:50, Gerard Freriks gfrer at luna.nl wrote: Ian, Can you answer the question: When 'formal classifications' are unimportant, what is the use of such classifications? we get caught up on the philosophy and do not focus on the utility Caring for the correct meaning is at the same time caring for utility. It is not a philosophical issue. Although some philosophical notions, and linguistic ones are helpful. Practicalities, translated as 'corners quickly cut', 'quick fixes', look nice in the short run. But how about the long(er) run? Gerard Freriks +31 620347088 gfrer at luna.nl On 17 feb. 2014, at 23:17, Ian McNicoll ian.mcnicoll at gmail.com wrote: Hi Bert, I think the problem here is that many people get hung up on the idea of the ENTRY classes being a formal classification upon which some sort of abstract computing will take place e.g. query for all OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the philosophy and do not focus on the utility. In other words if I weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will be lost computationally. ___
CIMI archetype examples using latest openEHR AOM ADL
On 02/19/2014 10:34 AM, Ian McNicoll wrote: The preferred solution was namespacing use reverse-urls but you and others argued for more definitive unique identification via OID/UIDs. I agree Bert
CIMI archetype examples using latest openEHR AOM ADL
On 02/19/2014 10:34 AM, Ian McNicoll wrote: The preferred solution was namespacing use reverse-urls but you and others argued for more definitive unique identification via OID/UIDs. Ooops, send to quickly I am not anymore so sure if it need to be UIDs. I think now, one year later, that organisations need to keep their namespaces tidy, if they do not, chaos is likely to happen on their data. Bert
CIMI archetype examples using latest openEHR AOM ADL
It seems this message didn't reached the list, forwarding :) From: pazospa...@hotmail.com To: gfrer at luna.nl; thomas.beale at oceaninformatics.com Subject: RE: CIMI archetype examples using latest openEHR AOM ADL Date: Sun, 16 Feb 2014 12:34:26 -0300 Hi Gerard, If there are presentation requirements, I would suggest to create UI Templates (as we call them) and put there the panel constructs/semantics **. That would be another semantic layer: RM - AM - OTP - UIT If there is some related data and there is the need to associate an interpretation, I would think of LINKed COMPOSITIONs, thinking about and information system: - in time 0, a data set is created, e.g. a study result (maybe many studies/results in the same dataset)- that should be committed to the EHR- in time 1, data is pulled from the EHR- an interpretation is created, another data set is created- that should be committed to the EHR, at this time we can link the first COMPOSITION with this second COMPOSITION I would prefer to do this at a COMPOSITION level because it is the committal unit. Thinking of a system that links entries, the user should select some specific entries to make an interpretation (if there are more entries than the ones that should be interpreted), but the interpretation itself should be in another COMPOSITION. What you say about the external resource holding the PANEL definition, I would prefer to create a new COMPOSITION with selected entries from other COMPOSITIONs, and the PANEL would be just a TEMPLATE defining the COMPOSITION and reusing the same ARCHETYPES, and maybe another one to model the interpretation of the data. Taking and step back, I guess CIMI what's to solve with structure something that can be solved defining a process, workflow or methodology that defines how to do things from the modeling perspective, instead of where to record things or how to display info on a screen. Sorry if I misunderstood something, I think I don't have the full picture :) ** Just for context, I've been working with presentation of archetyped data for a while, we have designed very simple UI Templates for the EHRGen project, and in 2013 we leaded a project on the Engineering University here in Montevideo to improve the UI Template model and an UI generation tool for different technologies (we have prototypes for Web with HTML5 and XHTML, and .Net with XAML).Now we're writing the paper, but I can show you the raw model. And maybe in a couple of months I can present that to the community to be improved and adopted as another layer in the semantic stack of the dual model, as I said, just for presentation purposes (input and display of openEHR data, and why not 13606 also!). -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: gf...@luna.nl Subject: Re: CIMI archetype examples using latest openEHR AOM ADL Date: Sat, 15 Feb 2014 10:35:54 +0100 To: pazospablo at hotmail.com; thomas.beale at oceaninformatics.com Dear Pablo, As member of the En13606 Association I have access to CIMI meetings from the start. The Entry in Entry (Panel) discussion is an interesting one.I agree fully that Panels are ad-hc constructs using Statements (ENTRIES) as components.On one hand they serve the purpose of collecting items for practical purposes, convenience, short hands, etc.On the other (for some) they serve the purpose that HcP?s want to attach interpretations to a collection of Statements.And then there are practical friends from the USA that want to collect attributes from the component statements in the Panel and prevent duplication of attributes. In summary I see as drivers for this discussion: ad-hoc (Presentation) needs, adding interpreattions to a collection of statements and operational implemantational aspects (saving database space and retrieval times) In my opinion there are at least three possible solutions for the Panel to be modeled using the present structures that the RM allows without any need of changing that RM.The three options are:- Use the Composition/Section mechanism to create ad-hoc collections of ENTRIES.- Use an ENTRY that defines the Panel and its attributes and refer to constituent ENTRIES using the Semantic LINK function of the RM- Use an external resource to hold the definition of the Panel and refer to constituent ENTRIES using the Semantic LINK function of the RM I do not agree with the CIMI proposal to add COMPOUND and INDIVISIBLE Entries to the RM, in order to follow a modeling pattern as used in Intermountain.The present 13606 RM is expressive enough. Gerard Freriks+31 620347088gfrer at luna.nl On 14 feb. 2014, at 23:48, pablo pazos pazospablo at hotmail.com 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
CIMI archetype examples using latest openEHR AOM ADL
Ian, Can you answer the question: When 'formal classifications' are unimportant, what is the use of such classifications? we get caught up on the philosophy and do not focus on the utility Caring for the correct meaning is at the same time caring for utility. It is not a philosophical issue. Although some philosophical notions, and linguistic ones are helpful. Practicalities, translated as ?corners quickly cut', ?quick fixes', look nice in the short run. But how about the long(er) run? Gerard Freriks +31 620347088 gfrer at luna.nl On 17 feb. 2014, at 23:17, Ian McNicoll ian.mcnicoll at gmail.com wrote: Hi Bert, I think the problem here is that many people get hung up on the idea of the ENTRY classes being a formal classification upon which some sort of abstract computing will take place e.g. query for all OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the philosophy and do not focus on the utility. In other words if I weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will be lost computationally. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/92057a3b/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
Hi Gerard, Good question. The value is not in the classification but in the attributes provided by the class. These save me some work as a modeller, should help the developer optimise some system aspects optimally (e.g by knowing that every ACTION archetype inherits a time and status that can be optimised for querying). The first thing to say is that I do not see a particularly clear distinction between 'classes' modelled in a Reference model and 'top-level' i.e rigid patterns modelled in archetypes. In both cases you are providing modellers with some fixed attributes which are inherited by child archetypes. I am going to use Contsys as an example since this is alternative example of where the modellers have introduced specific classes/top-level patterns to reduce variability and enhance computability. IMO it does not really practically matter whether the Contsys 'Assessed Condition' is modelled in UML as part of the RM or provided as a 'reference archetype' sitting on top of a leaner RM. In both cases, if I want to adhere to the ContSys model, I have to inherit from 'Assessed Condition'. That puts severe constraints on the way that 'Assessed Condition' develops over time. It must remain very stable and carefully managed whether an RM construct or a top-level archetype. So whilst the full-blown generic ENTRY has value, both openEHR and Contsys do offer semi-rigid top-level patterns either via RM or 'reference archetypes'. In fact 'onotologically' there is a pretty close match between the ContSys 'Entry' models and openEHR Entry sub-classes AssessedCondition = EVALUATION Observed/PerceivedCondition = OBSERVATION Activity = ACTION which is unsurprising since both work from the same 'clinical process model'. If we accept that there is some utility in establishing these 'top-level patterns', we are inevitably going to run into use-cases where it is unclear if an ENTRY is an Observation or Evaluation but equally where it is unclear if a Condition is Assessed or Observed (smoking or housing summary being a prime example), or a least where there is variable interpretation. In most case this mixed or muddled classification is not at all important for querying purposes. I am not aware of any situations where I want to query for Observations. I want to query for 'Smoking Summary'., If I happened to model it as an Observation I would get the 'observation time' as part of the RM (or top-levle archetype). If I modelled it as an Evaluation, I would have to create a date recorded/verified' node explicitly in the archetype. So t value of the Classes/top-level archetypes are in the attributes that child archetypes can inherit, saving modelling effort and applying some consistency which can be exploited by developers, but there is little value in the classification per-se, other than as a guide. We do not query on archetype ENTRY sub-classes. Ian On 17 February 2014 23:50, Gerard Freriks gfrer at luna.nl wrote: Ian, Can you answer the question: When 'formal classifications' are unimportant, what is the use of such classifications? we get caught up on the philosophy and do not focus on the utility Caring for the correct meaning is at the same time caring for utility. It is not a philosophical issue. Although some philosophical notions, and linguistic ones are helpful. Practicalities, translated as 'corners quickly cut', 'quick fixes', look nice in the short run. But how about the long(er) run? Gerard Freriks +31 620347088 gfrer at luna.nl On 17 feb. 2014, at 23:17, Ian McNicoll ian.mcnicoll at gmail.com wrote: Hi Bert, I think the problem here is that many people get hung up on the idea of the ENTRY classes being a formal classification upon which some sort of abstract computing will take place e.g. query for all OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the philosophy and do not focus on the utility. In other words if I weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will be lost computationally. ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
CIMI archetype examples using latest openEHR AOM ADL
Hi Bert, The reason that I have pushed to introduce an ENTRY class is to avoid having these kind of arguments!! Fundamentally I think your post beautifully highlights the problem. At first you rightly complain about the ad-hoc styling and variability of archetypes i.e we need more consistency, more frameworks. more top-level patterns. In theory, I agree, in practice, I could point to the very many inconsistent java coding frameworks available, the very, very many competing code libraries in the open source space and simply assert that trying to enforce consistent style will be impossible. The experience of clinical modellers and the clinical requirements they are trying to model are just too varied to have any realistic prospect of imposing control. Then at the end you say you want more freedom (via the ENTRY archetype) and to let 'a thousand flowers bloom'. This of course will result in even greater variation in the way that archetypes are modelled with no consistency at all. You may be correct that some useful frameworks emerge through competition, but you can be certain that developers will end up using multiple 'frameworks' just as tends to happen in other developments, simply because no clinical modelling team will ever have the capacity to 'drink the ocean'. As I understand it, the idea of the ENTRY sub-classes was to remove some of this variability in the top-level patterns and strike some sort of balance between your two contradictory wishes. That balance may be wrong but I am struggling to understand how you would reconcile the simultaneous need to reduce 'ad-hoc styling' and to increase innovation - these two wishes are completely opposed. The ENTRY sub-classes is an attempt to introduce some sort of framework to clinical models at a very abstract level. Contsys is attempting to do something very similar. I think we probably agree that having a generic ENTRY class will help reduce angst about 'which class is appropriate' and may help people examine alternative approaches but ultimately this will create more variability not less. Ian On 18 February 2014 07:20, Bert Verhees bert.verhees at rosa.nl wrote: Hi Ian, Maybe it is hard to find an classified evaluated observation. You are right. Maybe this is a bad example. Maybe it is only a matter of art or style, I am talking about. What I see is that there is no congruent style in archetypes. They are (excuse me, no offense meant) a collection of archetypes written by several people in several styles. (Sorry I have to bring in some styling in this message, it is to keep it readable.) - Ad hoc styling of archetypes is bad. - It is not that one writes an archetype, and everyone agrees that is a good one, that there does not exist another way to write also a good one, and for which everyone agrees that it is a good one. So there is no absolute superiority in the individual archetypes itself. There is no best archetype. It is like having a taxi-company and having cars from different branches which were good at the moment of buying, good price/quality. The owner was sharp paying attention, when buying. So all cars are good, more or less. There are other cars on the market which are good too. So all the cars are different, but they have four wheels and are fit and safe to transport people. And then there is a garage maintaining those cars, and for every car the mechanic needs to find another manual. The old mechanic who is in the garage long time has no trouble with this. But younger mechanics, they hate some cars. In fact, carwise, that taxi-company is a mess, all cars are good, but they are all different. Only look how many different types of spare-tires are needed. - Styling of products is good: - This is the same with archetypes, they are good ones (I cannot qualify that anyway), but also the good ones are all different. Developers, programmers maybe know what I mean. There are frameworks, good frameworks, like Turbo C++, old but reliable. There are many of these, also in Java or Pascal, or maybe Eiffel. Developers who don't use frameworks are less productive, make more errors, and write harder to maintain code. Have to invent the wheel many times. When you read frameworked sourcecode, you know at forehand how things are solved, because the frameworks have a preferred way. It would be nice if there could exist congruent frameworks of archetypes. A new competition-playfield would come to life. Which university, which company writes the best framework of medical data-classification and worked out in the best styling of archetypes? Turbo Archetypes! - Change is the only way to improve things. - We are
CIMI archetype examples using latest openEHR AOM ADL
On 02/18/2014 01:36 PM, Ian McNicoll wrote: As I understand it, the idea of the ENTRY sub-classes was to remove some of this variability in the top-level patterns and strike some sort of balance between your two contradictory wishes. I don't think so. It is the wish, I know, of all working on Health-ICT-projects/standards that their standard will serve the whole world, or at least an important part of it. Because if that happens, all the interoperability problems are gone. This strong wish motivates many decisions, which, after some time, need to be adjusted. For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Now, I can read between your lines that variability should not occur. It should be avoided. This reflects the same old wish for one standard for all. But not to focus on you, not to focus on you or OpenEHR, just because this is close on this list. It happens in all other standard-communities. It happens everywhere where they define standards. Maybe you know the joke, I told it a few times: Andrea: Sigh, there are 51 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete. Few months later Carlos: Sigh, there are 52 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete. Few months later Francis: Sigh, there are 53 HL7 standards, this is bad. I am going to solve that, I will create a new HL7 standard which will make all others obsolete. A world that speaks one language and sings Song of Joy before sleeping will not happen. There will be variability, there will be a free market, there will be free software development, there will be good and bad frameworks. This will always be. The best we can do is provide means on which good things can come forward and the world has a chance here and there to do better. By the way, do they in the UK still use British Standard Whitworth? Have a nice day Bert
CIMI archetype examples using latest openEHR AOM ADL
On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. That a stronger/better/different archetype-id system is needed is true in my opinion - but a different story: for starters the archetype-id system predates CKM (or even any vision of it) by many years as far as I am aware. Sebastian
CIMI archetype examples using latest openEHR AOM ADL
On 02/18/2014 03:52 PM, Sebastian Garde wrote: On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do. You also participated in this discussion. I started that discussion about here: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year. That a stronger/better/different archetype-id system is needed is true in my opinion - but a different story: for starters the archetype-id system predates CKM (or even any vision of it) by many years as far as I am aware. It is true that the CKM archetypes are of high quality (as far as I can judge), and that their existence is a good thing. But, archetypes can be much more then only having a specific high quality contents. They can, for example be structured, as I am thinking of, for example in a framework which causes some leaf-nodes to have predictable paths. This can have good effects on system-performance, data-mining, easy development, and other aspects. It is only a thought, not everyone will agree this is necessary, but that does not mean that it is useless to think in such a way. I think it is time to make that step forwards in two level modeling thinking. regards Bert
CIMI archetype examples using latest openEHR AOM ADL
On 18.02.2014 16:48, Bert Verhees wrote: On 02/18/2014 03:52 PM, Sebastian Garde wrote: On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do. You also participated in this discussion. I started that discussion about here: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year. Hi Bert, I am not arguing with that, I am just pointing out that you are relating two things (CKM and the archetype ids) that are not related in the way you said. If anything, the existence of several CKMs around the world now - which can all talk to each other to get each other's archetypes - /highlights /the need for a different archetype id system. As for the one-archetype-per-concept-principle in that discussion you link to: It is what I said in other words above, the lofty aim to agree where possible. It is not one step, but rather a very long process with potentially many archetypes about the same concept in e.g. different regions/countries in the meantime (and likely more than one forever). Sebastian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/85ae6519/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
Hi Bert, I don't think you need to convince anyone that the archetype_id mechanism 'would do'. The question of namespacing/ oids etc started to be discussed long before 2012, although it is blindingly easy to get around most namespace collisions with some 'pseudo-namespace' suffixes e.g. EVALUATION.adverse_reaction_uk.v1. From memory the discussion was about the best solution, not about the need to make some sort of change. If there ever was a vision that a single set of archetypes might rule the world, that has long since disappeared. I think there will be gradual convergence as the economics increasingly dictate that interoperating is better than local but it will take time and a fair bit of confusion/ competition of ideas and frameworks. I think you and i have a similar vision of progress through an open source-like market of ideas. However, you cannot easily square that with your desire for leaf nodes to have predictable paths. The only way for that to be absolutely achieved is to describe those leaf-nodes on the RM e.g ACTION.time or OBSERVATION.origin. The second-best alternative is to construct a hierarchy of top-level 'reference archetypes' (the approach taken by CIMI) but if these are to work consistently, everyone has to use them and their paths have to be fixed and consistent, just as if they had been defined in the reference model. There may be other advantages to using reference archetypes in this way but I can't see that you gain anything over an RM expression of predictable paths. I think there are many aspects of the openEHR class structure that can be simplified and improved but I can't see how you can provide the mix of flexibility and 'fixed leaf node paths' other than declaring them in the RM or in 'reference archetypes' which have to be managed just as strictly as an RM. Either you have a commitment to a framework (however expressed) or you do not. Perhaps I am not understanding .. Can you give a specific example of how you might model differently? Ian On 18 February 2014 15:48, Bert Verhees bert.verhees at rosa.nl wrote: On 02/18/2014 03:52 PM, Sebastian Garde wrote: On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do. You also participated in this discussion. I started that discussion about here: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year. That a stronger/better/different archetype-id system is needed is true in my opinion - but a different story: for starters the archetype-id system predates CKM (or even any vision of it) by many years as far as I am aware. It is true that the CKM archetypes are of high quality (as far as I can judge), and that their existence is a good thing. But, archetypes can be much more then only having a specific high quality contents. They can, for example be structured, as I am thinking of, for example in a framework which causes some leaf-nodes to have predictable paths. This can have good effects on system-performance, data-mining, easy development, and other aspects. It is only a thought, not everyone will agree this is necessary, but that does not mean that it is useless to think in such a way. I think it is time to make that step forwards in two level modeling thinking. regards Bert ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
CIMI archetype examples using latest openEHR AOM ADL
Hi Ian, Not sure if you are agreeing or disagreeing with me, but I couldn't have said this better, total agreement. Cheers Sebastian On 18.02.2014 17:22, Ian McNicoll wrote: Hi Sebastian, I think the original 'one-archetype-per-concept' statement was really applicable within a single repository or 'framework'. Much as we might want there only ever to be one for the world, this was clearly only ever going to be possible in the very long term, and quite impossible for some concepts. Ian On 18 February 2014 16:05, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: On 18.02.2014 16:48, Bert Verhees wrote: On 02/18/2014 03:52 PM, Sebastian Garde wrote: On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do. You also participated in this discussion. I started that discussion about here: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year. Hi Bert, I am not arguing with that, I am just pointing out that you are relating two things (CKM and the archetype ids) that are not related in the way you said. If anything, the existence of several CKMs around the world now - which can all talk to each other to get each other's archetypes - highlights the need for a different archetype id system. As for the one-archetype-per-concept-principle in that discussion you link to: It is what I said in other words above, the lofty aim to agree where possible. It is not one step, but rather a very long process with potentially many archetypes about the same concept in e.g. different regions/countries in the meantime (and likely more than one forever). Sebastian ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Senior Developer Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/3bb3e482/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
Sorry I misunderstood you. Bert Op dinsdag 18 februari 2014 heeft Sebastian Garde sebastian.garde at oceaninformatics.com het volgende geschreven: On 18.02.2014 16:48, Bert Verhees wrote: On 02/18/2014 03:52 PM, Sebastian Garde wrote: On 18.02.2014 14:56, Bert Verhees wrote: For example, in the OpenEHR, the idea was that CKM would serve the world with archetypes, and there would be no need of a strong archetypeId-system, because, all archetypes ever to be taken seriously were in CKM. Now it is recognized that this is not the case, and the proposition regarding archetypeIds changed. Hi Bert, I think you would find a sufficient number of presentations and papers from me and others about managing archetypes from around the time when we started to work on CKM (2007) that would convince you that even then we were far more realistic as to say that the openEHR CKM will serve the world with archetypes. We were and still are just striving towards the (lofty) aim to get as much agreement/convergence as possible as well as unite the archetype development efforts where possible. Hi Sebastian, I remember, it must be a year ago, how much problems I had to convince this community that the archetypeId-system, which was based on only a few serious archetypes worldwide, would not do. You also participated in this discussion. I started that discussion about here: http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2012-December/002797.html Do you see how long ago it was, we needed to have this discussion? Only a bit more then a year. Hi Bert, I am not arguing with that, I am just pointing out that you are relating two things (CKM and the archetype ids) that are not related in the way you said. If anything, the existence of several CKMs around the world now - which can all talk to each other to get each other's archetypes - *highlights *the need for a different archetype id system. As for the one-archetype-per-concept-principle in that discussion you link to: It is what I said in other words above, the lofty aim to agree where possible. It is not one step, but rather a very long process with potentially many archetypes about the same concept in e.g. different regions/countries in the meantime (and likely more than one forever). Sebastian -- *This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.* -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/147406dc/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
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
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
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 :( -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140215/2b3313c4/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
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 :( -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Thu, 13 Feb 2014 17:28:52 + From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org; openehr-clinical at lists.openehr.org Subject: CIMI archetype examples using latest openEHR AOM ADL For those of you following CIMI, there is now a dedicated CIMI space on the openEHR wiki. This page summarises some recent developments on the question of 'panels in panels' and 'Entries in Entries'. Essentially we are trying to merge aspects of the modelling styles of Intermountain Healthcare, openEHR and others, to cover more modelling use cases. The example is provided of BMI as a 'panel' that uses Height and Weight, which are themselves also usable as self-standing Entries, on this page in a series of screen shots and explanation. - thomas ___ 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/20140214/3e8220ca/attachment.html
CIMI archetype examples using latest openEHR AOM ADL
For those of you following CIMI, there is now a dedicated CIMI space http://www.openehr.org/wiki/display/CIMI/CIMI+Home on the openEHR wiki. This page http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern summarises some recent developments on the question of 'panels in panels' and 'Entries in Entries'. Essentially we are trying to merge aspects of the modelling styles of Intermountain Healthcare, openEHR and others, to cover more modelling use cases. The example is provided of BMI as a 'panel' that uses Height and Weight, which are themselves also usable as self-standing Entries, on this page http://www.openehr.org/wiki/display/CIMI/CIMI+panel+in+panel+example+-+BMI in a series of screen shots and explanation. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140213/e3262a13/attachment.html
