On 08/29/2013 09:00 PM, Talmon (CRISP) wrote: > Bert > > Archetypes were conceived to support SEMANTIC INTEROPERABILITY. The 13606 is > a communication standard, but of course you can also use it to build systems. > OpenEHR had 13606 as it root (Thomas Beale was also involved in 13606 as > (co-)author of the archetype and ADL parts of the standard) As far as I know, > and EHR extract can be wrapped in an HL7 message body (a blob) and > transmitted to an other system. In principle archetypes should ease the > communication, since you have not define in detail all the data elements in a > message, but make the message self explainable. > > So it is not a new use case that should be treated differently.
You have a good point in this. But does that mean that every data-item in isolation should have an unambiguous meaning? Doesn't it mean that archetypes must be seen as complex data-items which items can become quite meaningless in isolation? This is how I understood it always. An address is just a street with a number, but it becomes meaningful if the rest of the archetype tells you that there is an hospital on that address with some services. Don't pin me on the example, it is just to explain. But how can you know that the rest of an archetype describes an hospital, and the address becomes meaningful? You will have to study the archetype and interpreted it. And is the address the emergency-entry, or the fire-exit-door? Oh yeah, maybe there is a code for that, somewhere. It depends very much on your specific situation which one you want to find. There is no machine which can figure this out. Archetypes are thus, in my opinion, made for humans, and they are fit for semantic interoperability, in that way, they are, in a complex, self-explanatory (for humans). I believe however, that the promise of flexible automatically/machine interpretable interoperability is not true. An archetyped data set remains something that should be judged by humans. As you know, I am not an academic researcher trying to find the stone of philosophers. This is only my opinion, from my experience and daily practice. I am building systems based on OpenEHR and also EN13606, yes indeed. I deal with practical wishes, I want my software to run, and I don't think what you think OpenEHR is, will ever be possible. And why should it be? Any well defined message can do the trick. My attraction in OpenEHR lies in its flexibility: two level modeling! another very important goal. That is well reached, the archetype-editors could be better. OpenEHR, and also an well build EN13606 kernel can fit flexible in the ever changing requirements of health care. I think, it has to also some connection with the idea of one world wide archetype-repository. But we found out in discussion, this will never happen. So now, in the new ADL-standard, 1.5, there will be room for namespace. Archetypes will not be centralized maintained, but every company will have its own set. This means, also something for the view on semantic interoperability. My opinion in software building is: don't let rigid datastructures keep you from innovating healthcare. Software should be able to follow the practice, at low costs, and also quick. Archetyped systems make this possible. But maybe, for this reason, I should not interfere in this academic discussion. Sorry if that is the case. Bert
