hi Tom David's points are right on the money. The heart of the matter is "not invented here". A related issue is the fact that the ISO 21090 data types are optimised for exchange, not storage (explicitly a statement in their scope), but the NCI scope includes storage - which raises hard questions about normalization
The implicit message you have is that "therefore openEHR data types are better", whereas the openEHR data types share pretty much the same basic shape as the ISO data types in regards to the issues above (in fact, the overall differences are minor, mainly related to philosophical issues about modeling philosophy, and a few small ones about requirements) I use ISO 21090 in my commercial products. My take is somewhat different than this : it works fine for it's purpose - of course, how could it be otherwise? It certainly carries complexity, but this is inherent in the problem space. I do have a personal list of snits about what I failed to achieve with ISO 21090, which manifest in practical issues when implementing. But perfection is to be found in the next life. Grahame On Sun, Nov 7, 2010 at 12:14 AM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > The NCI's take, from this document? available here on the NCI wiki (blue > emphasis mine): > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ from NCI CBIIT Guidelines for Using the ISO 21090 > Standard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Guidelines > > The use of ISO 21090 data types is encouraged for CBIIT funded projects. > However, given that there are no standard open source implementations that > are available to the project teams, at the time of developing the > guidelines, CBIIT (via ECAT) has determined to validate the standards by > supporting pilot projects. > ISO 21090 data types are required to be considered for analytical services > only and not for data services Please refer to caBIG? compatibility > Guidelines for definition of analytical and data service. > Use of ISO 21090 data types are required only at the ?public interfaces? of > the analytical services (public Application Programming Interfaces (APIs)) > and not for any internal data structures or persistence tiers. > ... > > Steps for Implementing the Guidelines > > The guidelines could potentially be disruptive to many projects that are > underway, either due to contractual requirements or expectations made to the > key stakeholders. > > Additionally, there is a need to develop appropriate information mechanism > (e.g. GForge site) to facilitate the integration of the ISO 21090 data types > in a way that does not add any risk to the project and also does not > compromise project?s business needs. > > [... more] > > Risks on Using the Standard > > Unproven Standard:? The ISO 21090 data type standards have not been > implemented till date in large scale enterprise systems. Hence, it is > important to review progress of the pilot efforts within CBIIT and outside > organizations (E.g. Canada Health Infoway, NEHTA, etc) at frequent intervals > by ECAT to ensure that the standards are implementable and do not cause > unacceptable loss in performance, scale, interoperability and service use. > Heavyweight: The ISO 21090 data types are complex information models. It is > possible that this might make it difficult or even impossible to use as-is. > At the same time, if implementation specific changes are made to the ISO > 21090 data types, then there is a risk that it might jeopardize > interoperability outside CBIIT. The ISO Project Manager will be required to > bring such situations to ECAT in a timely manner for appropriate guidance. > Lack of Tool Support: Integrating the ISO data types in projects may be too > time consuming and require additional tools to be created for ease of use. > The tools could help in integrating the data types into project (via SDK, > caAdapter and caGrid) and also in the semantic infrastructure for metadata > registration. > Cost: The use of ISO 21090 data types will most likely increase development > costs for projects, including creating tool support, maintaining ISO 21090 > data types as separate projects and project coordination activity (via ISO > Project Manager). It is important for CBIIT to review the potential benefits > of the effort with the resources expended, to ensure that that appropriate > return on investment (ROI) is met. This review will be part of the overall > review of the use of ISO 21090 data types that will be conducted > approximately 12 months after the guidelines are put in practice. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > What I take from this document: > > ISO 21090 is seen as complex, unvalidated, and risky > a lot of work and activity - i.e. expense - is predicted within NCI to cope > with it (see the full version of the 'Steps for Implementing the Guidelines' > section) > > I would be interested in hearing of other experiences. > > - thomas beale > > > _______________________________________________ > 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
