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? What form would the new spec take, another standard or a profile?
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
