I think the wiki is down 2010/11/22 Thomas Beale <thomas.beale at oceaninformatics.com>
> On 22/11/2010 00:23, Stef Verlinden wrote: > > Dear all, > > As Ed Hammond said it somewhere earlier in this discussion: It's like > World Peace - a great idea but probably not achievable. > > I agree with Ed if we think along the line of ?one solution should fit > all? and I also think that if we create different solutions for different > purposes World Peace is achievable after all. Please let me explain. > > The 21090 standard is a fact, is here to stay and is not going to change > (soon). As William G. said it has been a tremendous accomplishment and > Graham did a hell of job in finding consensus between all parties involved. > Based on the reactions of some in this list and the fact the the majority of > CEN and ISO voted for it, 21090 fits it?s current purpose which is: > > ?provides set of data type definitions for representing and exchanging > basic concepts that are commonly encountered in healthcare environments in > support of information exchange in the healthcare environment? > > > unfortunately this is not the case. If it were, we would already have the > CEN use of these data types sorted out. See the openEHR wiki page on 13606 > and 21090 mapping, about halfway down. > > > > The way I see it, the main point of discussion untill now is the > question: exchange between who and/or what. This is also where the solution > lies. > > Although it isn?t stated specifically the current use of the 21090 seems > to be primarily at the level of functional interoperability (? the ability > of two or more systems to exchange information (so that it is human readable > by the receiver) (ISO/TR 20514:2005)). I?m sure it?s intended use is also at > the level of (some) semantic interoperability but allow me to make this > distinction to explain the need for different solutions. > > What Tom and many others on the list here are striving form is (let?s say > an ?advanced level? of) semantic interoperability (? the ability for > information shared by systems to be understood at the level of formally > defined domain concepts (so that information is computer processable by the > receiving system) (ISO/TR 20514:2005)). > > > Obviously I would like to achieve that as well, but it is not the 21090 > data types that will primarily achieve it. Actually, what we need is simply > data types that do not have all the HL7 specific use case attributes and > value restrictions all through them. For anyone other than HL7v3 messaging > users, the first question is: ok, how do we set all the attributes coming > from HXIT? From ANY? and the various other ones sprinkled throughout? How do > we obey this rule about setting NullFlavor when we don't even want to use > NullFlavor in our context. Etc... > > I am not arguing for anything sophisticated actually, just that the basics > be done properly, so that we (all) would actually be able to use this > standard. > > > > With advanced I mean that systems can not only support but eventually > take over certain critical functions in the medical process. This goes > beyond the level of decision support. In in the (not so far) future also > fully automated systems based on input from several parties will be created. > For instance automated triage of after hours GP visits, assess whether > someone can get a refill prescription, an agent that checks for medication > interaction, automated screening for certain risk profiles, follow up of > patients with a certain diseases, etc, etc. > > Whether we like it or not, systems have to support and even take over > some functions of healthcare providers in order to be able to provide > sufficient care 10-15 years from now. If not for that reason alone, this > type of applications can (hopefully) help to improve the quality of > healthcare. For instance by making personalised medicine possible at a > large scale. > > These advanced systems are (potentially) going to decide on matters of > life and death and therefore they need to be reliable in that the outcome > must be correct and similar in every system that uses the same standard(s). > > > yes, we can't argue with this. If the software is full of ambiguities due > to the developers not knowing how to create the data, due to standards being > full of stuff they cannot use, then this will be dangerous. > > As for proposals about what to do, I would be interested to see what the > list members think. My only addition to Stef's proposal below would be to > say that the scope is much greater than only semantically enabled healthcare > processes, but basic ones too. The way the current specification is written > (I mean the subtractive modelling style, requiring 'profiling') will mean > that everyone profiles differently. Use of RIM-based specifications over the > last few years bear this out. > > - thomas > > > I fully agree with Tom?s remark that this requires an engineered standard > instead of one that is the result of a political process (If you know the > person who would travel on a plane built by 'democracy' rather than > engineering, please introduce us... )) > > > So here?s my proposal > > We leave the 21090 for what it is right now and focus on a datatype > standard for semantic interoperable systems to be used in critical > healthcare processes. This is a new and very specific scope which not only > justifies but calls for a new standard. > > The thing we?re going to do differently is that for the standard creation > process we?re - initially - going to bypass the political process. To do so, > a small group of dedicated engineers (2-3 from all parties involved/ > interested, is composed. Based on the reactions on this list it should be > possible to get at least engineers of HL7, DCM,13606, and openEHR involved. > Preferably this should be extended with engineers from IHTSDO, NHS, the > Swedish implementation group and ?.? Lets say a maximum of 20 people. The > goal of this group is to create a datatype standard for semantic > interoperable systems to be used in critical healthcare processes which > addresses the following requirements: > > - a set of clean, clear core data types > - a set of wrapper types designed to use the core types, optimised for > messaging > - other sets of wrapper types as needed, optimised for other specific > purposes, e.g. storage or whatever > > Also the standard should be modular in order to expand it quickly and > easy in the future if new use cases would require that. > > If all parties involved agree upon the end result, the standard will be > brought to CEN/ISO to be included into the formal standardisation process. > This of course would need some political work after all, since all CEN/ISO > members would need to vote for this need standard in order to make it > official. > > I?m very confident that if the standard is developed and agreed upon by > the selected engineers from all parties described above, that shouldn?t be a > big problem?. > > > So what do you think? Who?s in and is 3 months an obtainable goal for a > first draft? > > > > Cheers, > > Stef > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at > openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > -- > [image: Ocean Informatics] *Thomas Beale > Chief Technology Officer, Ocean Informatics<http://www.oceaninformatics.com/> > * > > Chair Architectural Review Board, *open*EHR > Foundation<http://www.openehr.org/> > Honorary Research Fellow, University College > London<http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS, British Computer > Society<http://www.bcs.org.uk/> > Health IT blog <http://www.wolandscat.net/> > * > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101122/161f6abf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101122/161f6abf/attachment.jpg>
