Ok Jan, that is your opinion, and with good reason, especially if you look at the history of EN13606 and also, less emphasized, also OpenEhr.
OpenEhr has also as target, being a two level modeling system, as I wrote, really being a big convenience. Now there is a movement in En13606 of being a two level modeling data storage too. The kernel I wrote takes EN13606 and OpenEhr data sets, even simultaneous, also queryable, even in one query, different reference models, also CDA, as long as it is expressible in ADL, I can store it and query it. This flexibility is very important. I never understood why Nictiz messages aren't good enough, they are written for use for large variety of Non-HL7 systems, lots of them with very old and rigid data models. Systems at hospitals, nursing houses, GP's, dentist, farmacies, etc. The whole shebang of Dutch healthcare must be able to use them. They were designed to save lifes, 1800 lifes every year because of avoiding medication errors. Nictiz worked 10 years on them, they spend 500 million Euro. Is the message that they are useless? Is it a failure? Because, if they are useful, and many systems can use them, why wouldn't it be good enough for an OpenEhr system? Why then emphasizing that OpenEhr should be interoperable on dat-items inside complex data sets? Isn't this a legacy requirement? Especially, as I wrote, since the central maintenance of archetypes is in fact given up since the introduction of namespaces in archetypeIds. I would like to hear how interoperability can be achieved under these circumstances, and if that is still a goal in the way you expect it. Bert Op donderdag 29 augustus 2013 schreef Talmon (CRISP) ( talmon at maastrichtuniversity.nl): > Bert > > Each data-item in isolation should indeed have a unambiguous meaning. That > doesn't mean that knowing what the meaning is, is helpful. Just that one of > the data-items in a bloodpressure data set is the systolic bloodpressure > supports semantic interoperability, not necessarily allows for a proper > clinical assessment, because the context is missing (was it at rest or > after exercise, how many minutes of rest, position of the patient, cuff > size). But still we know it is systolic bloodpressure and when you receive > it and store it in your system you have to address the unknows. > > An address archetype is just an address archetype, but there may be > different variants. One with a street + number as one item, the other with > street, number, city, postal code, province, country. Still you need to > define which item represents what, in such a way that it is interpretable > in a consistent way. > > A hospital may be described by its address as well as some other items > that are relevant, like the services that are provided. Still each slot > needs to be defined in such a way that when you receive a set of data > structured according to a specified archetype, you need to know the > semantics of that archetype. You can say that is for humans to interpret, > but I would be nice if your system would be able to receive an archetypes > based set of data and be able to populate your system with the received > data. > > Items that are not recognized may need human intervention to be handled > (or just stored as a blob, together with (a reference to) the archetypes. > > Jan > > > > On 29 aug. 2013, at 21:53, Bert Verhees <bert.verhees at > rosa.nl<javascript:;>> > wrote: > > > 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 > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org <javascript:;> > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org <javascript:;> > > 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/20130829/5309205f/attachment.html>
