hi Heath > I too are concerned, as you know Isolated 21090 is being balloted now, how > should we recommend our member countries vote given this new viewpoint? > Should we at least be requesting a name change?
I don't think it needs a name change. The full name is: Health Informatics ? Harmonizied datatypes for information interchange (nor do I think you can change the name in FDIS) And the scope covers it too, I think. We had a discussion in the ISO committee over this same ground (though probably not expressed quite so clearly as I did below), which lead to Dipak drafting the words that I used for this purpose. And I think the problem is that people don't understand the underlying issues. Fiddling with the name or scope further isn't going to solve that. > What form would the new spec take, another standard or a profile? I don't know what it is yet, nor where it could/should be done, nor what it's final form would be. I'd rather let the technical side mature before thinking about that. Let's see what we come up with What I'd really like discussed is whether Tom and I should try and target a particular system architecture, or whether we should try and target a range. (and I'm still concerned by the question that if the particular system architecture is openEHR, why not just use the openEHR data types, and publish a mapping? It's not what we're talking about, but we would need to be clear - why is what we propose better?) Grahame On Wed, Nov 24, 2010 at 9:24 AM, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > > Heath > >> -----Original Message----- >> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] On Behalf Of Grahame Grieve >> Sent: Tuesday, 23 November 2010 11:54 PM >> To: For openEHR technical discussions >> Cc: Rene Spronk (Ringholm) >> Subject: ISO 21090 >> >> Hi All >> >> I have been having a long discussion with Tom off the >> list about ISO 21090, and we've come to agreement >> about the general picture. >> >> When I teach ISO 21090 tutorials, and I get to the >> implementation part, the first thing I say is that the >> data types are completely denormalised, and that >> I would never implement them as is inside my system >> (as anything but an object model for exchange.) >> >> And Tom says that they are all designed wrong >> to be used as data types inside a system >> >> We're both saying pretty much the same thing. The >> 21090 data types are designed, as Stef pointed out, >> for *exchange*. Specifically, for exchange between >> systems that are otherwise unconnected in any >> effective way. >> >> When you use the data types inside a system, then >> they aren't so appropriate. Now we have to be careful >> about using the term "inside a system" because even >> within systems, we have multiple connection/exchange >> points. So by "inside a system" I mean, for exchange >> between different entities that are connected by a >> common architecture that establishes, to a greater >> or lesser degree, common infrastructure that is used >> to normalise the content. >> >> That normalisation might be >> - the 5 normal forms of classical relational databases >> - moving audit information away from the content to a >> ? specialised audit/logging functionality >> - moving constraint information out of the data into the >> ? system metadata >> - re-organising content that has been conflated by >> ? semantic intent to more clearly draw apart >> ? management concerns. >> - moving concerns out of the data into the code >> >> There's more, but that list will suffice for now. (so it should be >> clear that I am using "normalise" in a somewhat loose >> sense). >> >> Tom sees these gaps, and responds negatively, whereas >> I just accept them, knowing that they exist, and that I have >> plans to deal with them, plans that vary across my different >> systems as their architectures change. >> >> But we do both share the concern that the degree to which >> the 21090 data types are designed and optimised for >> exchange is not understood by casual adopters. It's not that >> it's impossible to adapt non-normalised models built for >> exchange to serve as system architectures (there's an >> active group in HL7 - RIMBAA - doing just that), but that >> you need to know that what you are doing is going to >> present certain challenges you will need to prepare for. >> Users could easily start to implement them in systems and >> find themselves later with a series of bad choices that they >> could have avoided earlier, and then they'd blame 21090.. >> >> It appears that Tom and I may jointly develop a variant >> of ISO 21090, that features the same basic semantic >> content, but in a format that is suitable for use in systems >> rather than for exchange. It will describe clearly how to >> interoperate using 21090, but will be suited for system/case >> design. >> >> I am a little uncertain, because I am concerned that the >> particular normalisations you anticipate will affect the way >> that you design such a variant, and I don't see how to >> pick a particular set - a logical obvious candidate around >> which an implementation community would coalesce. Tom >> and I are still talking about that. >> >> Tom and I hope that this explanation will bring some clarity >> to any observers who have been left confused by our somewhat >> passionate debate to this point ;-) >> >> Grahame >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Grahame Grieve, CTO A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083 P: + 61 3 9450 2230 M: + 61 411 867 065 F: + 61 3 92450 2299 E: grahame at kestral.com.au W: http://www.kestral.com.au
