> This is really great news. I'm glad you think so. Cause the more I think about it, the more pessimistic I get.
> important technical agreed standards should still become > formal standards because, at least here in Europe, they > can be incorporated in laws. y. but is that what we have here? How can we have more than a systems implementation guide for ISO 21090? I'll illustrate by talking about our favourite bugbear, CD For me, CD conflates 3 different notions in it's properties (and that's ignoring the things it gets from ANY and HXIT): * a definitional concept * a context of use of the concept * descriptional stuff to help foreigners work with the thing when they don't know the definitional concept In my systems, I split the first 2 up and struggle with the last. I'll explain. The definitional concept itself is code + codeSystem. This pairing provides the actual meaning. So the first thing I do is normalise this out of CD into a separate table (note, then, that my focus here is relational databases, and working with them). I keep a table of every discrete concept encountered in the system. And I also maintain tables that keep track of implies relationships between these concepts. This means that I can write fast SQL joins that can use subsumption. Again, note the implementation focus I have here. And actually, I maintain a separate table for code systems to help with system maintenance, so I break code+code system up too, and there's a slew of infrastructural things hanging off them. My CD datatype therefore devolves into originalText + primary key for the concept. I ignore the valueset set stuff at the moment, on the basis that it's not in my product's requirements space. The descriptional stuff, I populate from my infrastructure - codeSystemVersion and CodeSystemName. DisplayName, that's a problem. Because in theory I can (and should) generate that from my code system definition tables themselves whenever I need it. (well, I don't actually maintain a table for snomed - I have a cache structure instead). But there's no algorithmic way to turn a snomed expression into a display name. For me, this is ok right now, we're not in the snomed expressions space. Yet. But soon. I'm kind of hoping that the nascent work in that space will start offering something solid about when I need it. And what are translations? I don't think they are any of those other things. I keep track of them as a series of postulates that the underlying concepts may be related. (and who postulated it, cause I'm never sure who's going to believe who) So CD is a cascade of tables for me. Cecil Lynch from Ontoreason does a different cascade, reflecting his different tooling, architecture, and requirements. OpenEHR doesn't split that stuff out - just compresses what it has into a single de-normalised type. I'd never do that. But Gunther, on the other hand, would never normalise it - he just uses the fully denormalised RIM + data types and wouldn't bother understanding why we'd have this discussion at all. (I do use the fully denormalised type in my object models at my exchange points (CDA, HL7 v2, etc), where it makes prefect sense, btw) Anyway, the problem I have is that my tooling, architecture and requirements all change the way that I *implement* the notional ISO 21090 types inside my system. Out of that, we are supposed to be able to write a single specification which is the one correct model for implementing these types in a system? So I don't feel as though we can produce a standard, just an implementation guide. Grahame
