Hi all, I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events. It is not very often I find a requirement that cannot be managed within these structures.
They aren't perfect, but every time I have to model a complex archetype the power of the RM plus the ENTRY specific attributes makes the modelling a relative breeze. I only need to worry about the clinical content itself. Keep in mind, that I am speaking as a *non-technical clinician modeller*. And in openEHR, I will always argue that the most appropriate archetypes will be developed by the clinical community. Models developed by technical modellers are structured quite differently, not necessarily representing the real clinical world and often trying to define abstract patterns that don't exist in the clinical space. The barrier to entry for non-technical modellers to a 13606 or CIMI RM is much greater. We will see the outcome in the archetypes produced, believe me. So anything that ensures that the RM is represented consistently and allowing consistent modelling approach for clearly identifiable clinical data patterns. In reality I don't consider the ENTRY classes to carry semantics, and often the names are misleading - perhaps they should have been named Model A, B, C etc. My 2c Heather -----Original Message----- From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: Wednesday, 25 June 2014 9:53 AM To: openehr-clinical at lists.openehr.org Subject: Re: Link between goals and other clinical concepts Hi Hugh, It is indeed a discussion which runs for several years. I mentioned 13606 but it can also be done in OpenEHR. OpenEHR also has lists, trees, clusters, elements, all derived from Locatable, thus archetypeable. So you can define (what I call) an information model, based on the generic structures in OpenEHR. Say you want to conform to HISA, is that possible in the Composition-package? I am not sure, I read it once, some years ago, and I saw some problems, say (imagine) HISA will conform more in direction of ContSys, how do you handle this in the OpenEHR composition-package, and we all know, it will not stop there. It is an illusion to think that an information model will last for ever. Maybe there are concurring information models, maybe you want a kernel to support more, simultaneously, maybe you want to write an API to a specific information model? Imagine HL7, for example, VMR, based on archetypes? I once did that, for a customer. I did not write an API for that, just the archetypes, but I could write an API for that. I am afraid you will find the composition package restrictive. It represents a good information-model, as far as I can judge (it is not my specialty), but is just AN information model. There can be more which are good too. That is why I think, semantics do not belong in the reference model, but in a constructed archetype/template-based information model. You could also model the OpenEHR information model, which now resides in the reference model, in such constructed archetype/template-based information model, using only structure-based archetypes. You say that information models will be defined over and over again. This can happen, but it is, in my opinion, not likely to happen in professional environments where the choice will always be kind of standardized model. You mention that software will be too complex when a reference model with no semantics is used. I am softwaredeveloper, I think opposite. I think a kernel should eat any archetype (with valid ADL) and should eat any dataset conforming to an archetype. So, there is no problem. There is no change needed in the kernel. I think an API can be defined conforming to an information model, which is represented in a set of archetypes. It can do its checks, that is not much of complexity. I think a screen/report-generator can be build on base of a trust-able set of archetypes/templates, and screen-parts can be used as lego-blocks And then you find a customer which says: "Yes, we want to do CLEVER-MEDINFO version 2, an information model and API defined in the University of CleverVille, most famous for medical information." And three months further, it is ready. As I say many times when talking about this subject: Let thousand flowers bloom. And don't forget, OpenEHR is just AN information model, it is not THE information model. So, you will need a decent message standard anyway for interoperability. And for the future, we will not be able to stop it. I think, this what I describe, is going to happen. Restrictions or Semantics on kernel level will become obsolete for two reasons I can think of now: - It is not necessary to do that on kernel-level, because it can be done on archetype level. - It is fixed too much, it is very hard to conform to new standards, it does not stimulate innovation. Best regards Bert Hugh Leslie schreef op 24-6-2014 23:22: > Hi Bert, > > I assume you are talking about those types of semantics that are currently in > the openEHR reference model like observation and instruction. > > This argument has been around for a while. My issue with this is that if you > start to control some way of modelling generic archetypes for these types of > semantic structures, then you are in exactly the same space as doing it in > the reference model but without the same level of governance or control. > CIMI have also suggested this approach. This is likely to be more difficult > for developers as there is a much higher likelihood of multiple types of > instructions/actions/observations that will need to be dealt with rather than > one reference model based way of doing it. > > I actually would contend that these structures are not domain specific, > although they may have domain specific names. We want the reference model to > tell us how to construct compositions and entries as well as a consistent way > of defining tables or tree structures so that software can be written once to > handle all possibilities. These openEHR constructs that seem to cause such > controversy, just make explicit things that are going to be modelled over and > over in the same way as these other things. If we don't put these things in > the reference model, then we will have to accept that there will be an > increased variability in the way that they are modelled which is likely to > make software more complex. > > Its an argument/discussion that we will continue to have I suspect. > > Regards Hugh > > . -----Original Message----- > From: openEHR-clinical > [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Bert > Verhees > Sent: Tuesday, 24 June 2014 6:25 PM > To: openehr-clinical at lists.openehr.org > Subject: Re: Link between goals and other clinical concepts > > On 24-06-14 02:28, pablo pazos wrote: >> creating CLUSTERs for all the stuff than ..... > I missed a part of the discussion, but maybe I get the point, or I see > my hobbyhorse everywhere. ;-) > > I have been thinking about this some time, and I started a few times a > discussion about this subject. But I must say, there is not much enthusiasm > for this idea on this list. > Let me explain compactly. > > Take a look at the EN13606 RM which is already much more generic then > OpenEHR. You can model archetypes for it with the LinkEHR archetype-editor. > > For a developer, it is nice to have a generic reference model, it can help > you create generic code in the application/kernel. > For a domain-modeler (a medical-information-specialist, f.e.) it is nice to > have semantics in the reference model. It helps thinking about how to model > an archetype for a specific purpose. > > There is a way in between, which can serve both groups: > You need to bring order in the chaos of generic CLUSTER_archetypes. You can > do a lot with archetype-slots with defined reg-expressions, so in this way, > the generic archetypebase canconsolidate in an information-model which can be > used by the domain-modeler. > This information-model needs to be defined, controlled and documented. > > Then you reach the area of proprietary. > Domain-modelers need besides adapting the reference model, conforming to your > defined proprietary information model. > > And, on second thought, anyway, you need to adapt a good message-model, > because not the whole world will run OpenEHR. > > The nice thing about two level modeling is that, this is all possible. > > good luck > Bert > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene > hr.org > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene > hr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
