It would also seem that the SVN is also down, or at least very, very, very, very slow.
Heath From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc? Sent: Monday, 22 November 2010 9:22 PM To: For openEHR technical discussions Subject: Re: World Peace 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.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/> Chair Architectural Review Board, <http://www.openehr.org/> openEHR Foundation 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/20101123/039665e6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101123/039665e6/attachment.jpg>
