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 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 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 in a lucky time, we have two-level-modeling software. We can write our own frameworks. We can express ideas about classes and ideas about styling. But there are still some legacy-ideas: maybe good ideas, but still, they do not fit on some new ideas which might be good too, so these legacy-ideas are blocking innovation. Because they are enforced in the RM. And of course, most medical data-analyst like the (in Netherlands we call it SOEP) idea of four nouns to classify medical data. It is not for them freedom is important. They just want to be productive. Those are important people, they cure other people. But there are also people, who want to rethink things. Some of those write the guidelines for tomorrow. To have true and innovative advantage of two level modeling, we need a RM that stands back as much as possible. Let thousands flowers bloom, and let for example, CIMI, trying to be one of these blooming flowers. But as Thomas already mentioned yesterday, we will get the generic ENTRY-class, I don't know how it looks like, but that seems good news. Maybe it was not meant for this, it will surely fit in the idea to give freedom in innovation. I still wonder why the OpenEHR-community decided to have a concrete ENTRY-class. Best regards Bert Ian McNicoll schreef op 17-2-2014 23:17: > 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. > > I think there is value in having a true generic ENTRY since it avoids > getting into these kind of marginal ontological discussions but I > still think there is place for the more complex constructs where these > make sense i.e when data requires a consistent date/event pattern as > in OBSERVATION or to support consistent state machine behaviour as in > ACTION. > > I'm not sure that you gain a whole lot from moving th
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 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 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 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. >
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 02:56 PM, Bert Verhees wrote: > By the way, do they in the UK still use British Standard Whitworth? In response of my own rather cynical looking post, I must say that I am not cynical at all. I have other expectations. I think the health-ICT should focus on interoperability on base of independent systems. Thus, one or some system-independent message-formats. System developers should write routines to import/export them. And besides that, health-ICT should make fabulous platforms, which serve their customers and their needs. I think, archetypes, two level modeling are a great tools from this perspective. So the world should be grateful for the work of the OpenEHR community, and that is my honest opinion. I am proud to be involved even for just this little bit Best regards, Bert Verhees
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 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
CIMI archetype examples using latest openEHR AOM & ADL
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 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 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 > 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
fforts 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 > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- *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/0bb9982e/attachment.html>
