CEN meeting and data types
Hi Sam some responses The first issue to note is the ANY class which contains a number of complex attributes not shown in the package. nullFlavour is dealt with in CEN and openEHR at the ELEMENT level which is far more appropriate in systems - ie test the datavalue, if it is Null then test the flavourOfNull on the element. As HL7 does not have the idea of container, this has to be here. All the other attributes are dealt with at different levels (eg Template Id which may apply to an ELEMENT but never to a data value. Adding these to CEN would cause major duplication, increase complexity without benefit and deteriorate performance. well, the concept of the ISO datatypes (also true for 11404) is that you can have direct and indirect conformance. If you are claiming indirect conformance (which will be true for HL7 and openEHR), then you must provide a mapping that explains how your implementation differs from the ISO datatypes as they stand. I have drafted an openEHR mapping - but it's just a series of notes at this time. But the openEHR mapping would explain all these things above and ANY would not have these properties. The same would apply to 13606. The next issue is the inheritance hierarchy. In systems one would expect to be able to substitute on the basis of specialisation. While we can write invariants occasionally for good reason to prohibit this in some situations, generally this should apply. What strikes me about the inheritence model here is that it is really a way of constraining the large class 'Term' for particular purposes. Take for instance CV - it is a term that has translations added (CD), and then has qualifiers removed (CE) then has translations removed! While there may be use cases when Term has all the attributes it does, this hierarchy cries out for remodelling! Further, is it usable? How would clinicians know which one to use in an archetype? yeah, I have some sympathy for this point. CE/CV are just constraints on CD, and defining them as separate types is rather inelegant. For mapping purposes, I'd simply drop CE and CV from openEHR 13606. Since Term and Translation are private types, that simply leaves CD : coded value. That's not had for clinicians to pick between ;-) Translations are the equivalent of the openEHR mapping. By including all the text and qualifiers in translations one may find a good deal of difficulty understanding the meaning. well, translations may require qualifiers. And the openEHR spec (rightly) allows this too. as for text on qualfiers and translations, this is an interesting point. To be really precise and pedantic, there are use cases for this. But if you aren't really concerned with being pedantic and precise, you should be able to ignore these things. I guess this is something I could usefully add to the spec - that the meaning of the text associated with qualifiers and translations can never have any independent contribution to the meaning of the whole term - I'll have to think about how to phrase that properly. The issue of qualifiers is a large one and while the argument for the HL7 approach is that this provides a syntax for coordination of terms, it is not expressed in the model. CR is ambiguous from my point of view with two terms that are both optional and the value may have translations and qualifiers. Perhaps a computable set of rules will arise for how to control this space but I suspect some gnomes will be required. This approach was first published in GEHR in the early 90s and has been dropped in openEHR as it was deemed unworkable from a semantic point of view. One can argue that the CODE_PHRASE in openEHR is as problematic potentially - but as it is provided by a terminology service, it is far less likely that enthusiastic implementers will start adding data willy nilly. So the HL7 qualifier thing is (mostly) simply a predefined expression syntax for post-coordination. It overlaps with terminologies that have their own expression syntax - such as SNOMED. The HL7 model does allow a richer expression of the details of the construction of the expression - such as which text led to which qualifier, but this is, as I said, for precision and pedantry. Not for normal everyday use. So the question is, is it better to squeeze things into the text of a CODE_PHRASE, or to squeeze things into xml? Either way, you need to have a terminology service to do anything useful with the data. So what's the difference? I don't have a strong feeling about that. Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Dear reader, Healthcare of the future needs ICT-systems of the future. Healthcare needs systems that are: -patient safe, -help respect privacy and -make 'plug-and-play' exchange between systems possible, CEN/tc251 has published part 1 of a new exciting European standard for the EHR. It is CEN/tc251 EN13606 EHRcom. Together with other CEN standards it will make possible 'plug-and- play' semantic interoperability between conforming EHR-systems. 1- ConSys: System of Concepts for Continuity of Care describes the concepts clinicians need to co-operate 2- EHRcom: EHR standard that helps store, retrieve, present, and exchange data, information and knowledge 'plug-and-play' without reprogramming 3- HISA: Health Information Services Architecture that makes co- operation between systems possible. The revolutionary 'plug-and-play' is possible because of a new paradigm: the Archetype Paradigm. Complex and resource intensive processes like IHE will not be necessary to implement many message specifications. It must be clear that deployment of these standards can play an important role to achieve the i2010 goals accepted by all Member States. And is exactly what healthcare of the future needs In the attachment a draft presentation with more information about the CEN standards. March 29 and 30 a tutorial about the new revolutionary European EHR standard and Archetypes will be held in Leiden. More information can be found at: http://web.mac.com/g.freriks/iWeb/conexis - Welcome tutorial at conexis.nl With regards, Gerard Freriks former chairman of CEN/tc251 wg1 conexis --- Gerard Freriks, MD Huigsloterdijk 378 2158LR Buitenkaag the Netherlands M: +31 620347088 gf at conexis.nl -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070306/52209d2d/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Anything dubbed revolutionary raises cautionary red flags. As Adrian Midgley once aptly put it: Ars longa, IT brevis. Karsten On Tue, Mar 06, 2007 at 12:10:09PM +0100, Gerard Freriks wrote: Subject: CEN published En13606-1 EHRcom. Tutorial about Archetypes X-Mailer: Apple Mail (2.752.2) Dear reader, Healthcare of the future needs ICT-systems of the future. Healthcare needs systems that are: -patient safe, -help respect privacy and -make 'plug-and-play' exchange between systems possible, CEN/tc251 has published part 1 of a new exciting European standard for the EHR. It is CEN/tc251 EN13606 EHRcom. Together with other CEN standards it will make possible 'plug-and- play' semantic interoperability between conforming EHR-systems. 1- ConSys: System of Concepts for Continuity of Care describes the concepts clinicians need to co-operate 2- EHRcom: EHR standard that helps store, retrieve, present, and exchange data, information and knowledge 'plug-and-play' without reprogramming 3- HISA: Health Information Services Architecture that makes co- operation between systems possible. The revolutionary 'plug-and-play' is possible because of a new paradigm: the Archetype Paradigm. Complex and resource intensive processes like IHE will not be necessary to implement many message specifications. It must be clear that deployment of these standards can play an important role to achieve the i2010 goals accepted by all Member States. And is exactly what healthcare of the future needs In the attachment a draft presentation with more information about the CEN standards. March 29 and 30 a tutorial about the new revolutionary European EHR standard and Archetypes will be held in Leiden. More information can be found at: http://web.mac.com/g.freriks/iWeb/conexis - Welcome tutorial at conexis.nl With regards, Gerard Freriks former chairman of CEN/tc251 wg1 conexis --- Gerard Freriks, MD Huigsloterdijk 378 2158LR Buitenkaag the Netherlands M: +31 620347088 gf at conexis.nl ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CEN published En13606-1 EHRcom. Tutorial about Archetypes
Dear Karsten, For several reasons I was using that special nasty word revolutionary. -1- To be able to get 'plug-and-play' interoperability as opposed to the very big problem of implementing many messages across vendors in a uniform way, is REVOLUTIONARY. -2- To have a standard with these capabilities that signals a paradigm shift. Paradigm shifts by definition are a disruptive technology. Meaning all old, present, working systems have to be changed completely, rewritten even, to have the full benefit of this new paradigm. This is my second reason to use the word REVOLUTIONARY. Perhaps people become reluctant to read about it, deploy it, etc. But what can I do? Tell a lie? Play nice? With all reservations I will play honest. Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On 6-mrt-2007, at 13:01, Karsten Hilbert wrote: Anything dubbed revolutionary raises cautionary red flags. As Adrian Midgley once aptly put it: Ars longa, IT brevis. Karsten -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070306/ab5f6178/attachment.html -- next part -- ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
openehr at medinfo 2007
Does anyone know if the AMIA os-wg is still alive? Kevin -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sebastian Garde Sent: Wednesday, February 28, 2007 10:28 PM To: For openEHR technical discussions Subject: RE: openehr at medinfo 2007 Andrew, We did an informal openEHR meeting at the MIE in Maastricht last year with those that were at the conference, and I think it was a great success (and great to put faces to the names). We should definitely try to organise a meeting of whatever format at Medinfo too! We probably have to wait until the program is published to see on which day? The evenings look pretty busy with http://www.medinfo2007.org/100113.php, but maybe we can declare Monday or Tuesday evening as the official 'openEHR evening'? :-) Cheers Sebastian -Original Message- From: Andrew Patterson [mailto:andrewpatto at gmail.com] Sent: Thursday, 1 March 2007 3:40 PM To: For openEHR technical discussions Subject: openehr at medinfo 2007 I presume many here will be presenting papers at Medinfo (or attending). Are there any plans for any openehr meetings, BOF sessions etc? We should at least have an openehr-list drinks on one of the nights, as it would be good to be able to put faces to some of the names. Andrew ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
