World Peace

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’

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)).

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).

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

Hi Stef

yes, I think you have got the correct focus for ISO 21090. It's
certainly what Dipak had in mind when he originally drafted
the words you quoted.

Tom and I have been having an off-list discussion about
doing something like what you propose. One of the things
that isn't clear for me is what the positioning/scope of this
is that you propose.

Is healthcare-data-types-for-systems? For Object models?
for persistence?

How does it differ than the use case for openEHR? Would
it be a better outcome to simply take the openEHR data
types as they are, and publish and maintain a mapping to
ISO 21090? What would your proposal offer as an improvement
over doing that?

And then, why CEN? Why would CEN be an appropriate place?
Why not HL7? Or is there a better place?

btw, I do usually travel on planes designed by an opt-in merit
based democracy. I certainly wouldn't chose to fly on one
designed in a totalitarian/autocratic system - it's too hard for
a single person to get everything right. It's not at all clear that
the plane parable is even accurate, let alone relevant.

Grahame

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
(attachments)

OceanInformaticsl.JPG

I hope not :wink: It might be said that planes are designed and engineered by meritocracies (rule by the competent), but not democracies (rule by everyone). When I said ‘engineering’ was like totalitarianism, I did not mean it in the literal sense of a single ruler, but in the sense that the social structure relates to defined job descriptions, choice of competent people to fill them, and the use of reliable methodologies. Voting in the democratic sense features very little.

I am sitting in a symposium right now listening to Michael Jackson, Barry Boehm, David Parnas, Bertrand Meyer, Erich Gamma, and other notables from the software engineering universe. It is quite clear that the (non-democractic) methods of proper software and systems engineering have barely featured in the creation of many e-health standards we live with today.

  • thomas

Long live Mircosoft.

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics

             Thomas Beale
             <thomas.beale@oce
             aninformatics.com To
             > openehr-technical@openehr.org
             Sent by: cc
             openehr-technical
             -bounces@openehr. Subject
             org Re: World Peace
                                                                           
             11/24/2010 11:34
             AM
                                                                           
             Please respond to
                For openEHR
                 technical
                discussions
             <openehr-technica
              l@openehr.org>