On Information and Interoperability

Technical (archive)
1

[extracted from the thread "Archetype documentation using XML + XSLT"]

Tim Cook wrote:

>>
>
> ADL does semantically describe the AOM.
>

No reason why XML could not.

It can suffice for anything from a webform (e.g. XForms) to a vector
graphic (e.g. SVG) to an object model to formatted text (e.g. XHTML)
to
an office file (e.g. ODF or OOXML) to a process such as XSLT.

Hi Adam,

Please let me start by saying that I would be foolish in challenging
your expertise in using the XML family of specifications and tools to
represent and communicate data. You are certainly more knowledgeable in
this than I.

On the surface you may well be able to represent the AOM in XML. I will
propose though that this is not the best way in real implementations to
do so. IMHO it is akin to the philosophy that using a SQL database to
persist any kind of data is appropriate because everyone else is using
them. This is simply an incorrect and inefficient approach as well
evidenced by the fact that 30% or more of an application goes into just
translating an object model into a SQL model. This also increase the
machine resources needed as well as the maintenance resources of the
application.

There are important differences between data and information. To
understand the significance of the mismatch between flat message
protocols and a hierarchical semantic model of information you may want
to review some of the concepts in information sciences.

Much like the knowledge of physics has evolved since Issac Newton, the
knowledge of information science has evolved since Claude Shannon. Most
of this work has been done under the umbrella of Philosophy.

One of the most comprehensive yet concise documents I have found in this
area is in the Stanford Encyclopedia of Philosophy:
http://plato.stanford.edu/entries/information-semantic/

I do believe that the use of the term “semantic information” is
unfortunate because (IMHO) information by definition must have semantic
integrity. But that point we'll leave to the philosophers. :->

How this applies to healthcare is that healthcare information must
contain truth. That truth is fully dependent on the complete context of
where, when and how it was recorded. This context needs to be
understood in all spatial and temporal instances where this information
is or may need to be used. I am certain that the openEHR Reference
Model and the Archetype Object Model definitions are currently
incomplete. Some things we know about and some we have yet to learn.
But I can almost assure you that they will grow even more complex over
time.

If you can show that the XML family can meet these needs and be more
understandable and functional than ADL I will be one of the first to
jump on board. My favorite language is Python. It has one of if not
the best sets of tools for manipulating XML.

[NOTE] You will also need to address the issues that Thomas Beale just
presented, in the referenced thread, regarding the real world as well.

Cheers,
Tim

2

Tim Cook wrote:

[extracted from the thread "Archetype documentation using XML + XSLT"]
  

Tim Cook wrote:

ADL does semantically describe the AOM.
  

No reason why XML could not.

It can suffice for anything from a webform (e.g. XForms) to a vector
graphic (e.g. SVG) to an object model to formatted text (e.g. XHTML)
to
an office file (e.g. ODF or OOXML) to a process such as XSLT.

Hi Adam,

Please let me start by saying that I would be foolish in challenging
your expertise in using the XML family of specifications and tools to
represent and communicate data. You are certainly more knowledgeable in
this than I.

On the surface you may well be able to represent the AOM in XML. I will
propose though that this is not the best way in real implementations to
do so. IMHO it is akin to the philosophy that using a SQL database to
persist any kind of data is appropriate because everyone else is using
them. This is simply an incorrect and inefficient approach as well
evidenced by the fact that 30% or more of an application goes into just
translating an object model into a SQL model. This also increase the
machine resources needed as well as the maintenance resources of the
application.

Stepping outside of well supported standards increases maintenance
requirements much much more.

Heck why not write your ADL handling etc in PICK ?
You might find it hard to get Dell et all to support Pick on your choice
of hardware so why not try & build your own hardware with Pick optimised
chips while you're at it?

I am assuming that you would feel OK about running on top of a commodity
OS itself running on top of commodity hardware?

At one stage I hsd to use Cache & on another it was IBM's IMS but
hierarchical db's never took the world by storm & their (now) non
standard nature ipso facto increase maintenance costs

If you want to write your very own persistence mechanism/db I cannot but
admire your ambition but I would caution wrt expecting others wishing to
use it vs spending a bit more on hardware.

There are important differences between data and information. To
understand the significance of the mismatch between flat message
protocols and a hierarchical semantic model of information you may want
to review some of the concepts in information sciences.

Yup. See my reply to Tom wrt our looking at only sending the changeable
data in an HL7 message (i.e. if it's always the same.....why send it?)

We are getting this (look for "folding") after mucho shoving into the
new HL7 XML ITS R2.

Much like the knowledge of physics has evolved since Issac Newton, the
knowledge of information science has evolved since Claude Shannon. Most
of this work has been done under the umbrella of Philosophy.

One of the most comprehensive yet concise documents I have found in this
area is in the Stanford Encyclopedia of Philosophy:
http://plato.stanford.edu/entries/information-semantic/

I do believe that the use of the term “semantic information” is
unfortunate because (IMHO) information by definition must have semantic
integrity. But that point we'll leave to the philosophers. :->

& politicians...& earnest english language students.

How this applies to healthcare is that healthcare information must
contain truth. That truth is fully dependent on the complete context of
where, when and how it was recorded. This context needs to be
understood in all spatial and temporal instances where this information
is or may need to be used.

An obvious response would be that Heisenberg would argue with the above.

Wrt being understood.....I take it doctor's notes in a text box are
verboten then as If I go to Finland & have to go see a doctor & he
enters a record which is accessible back here in the UK, the coding can
be used to tell my clinician things but unless I get lucky & my doctor
understands Finnish....

  I am certain that the openEHR Reference
Model and the Archetype Object Model definitions are currently
incomplete. Some things we know about and some we have yet to learn.
But I can almost assure you that they will grow even more complex over
time.

I have 0 (nada, zero null, no) problem with the AOM. Having delved into
both HL7 & OpenEHR in some depth I have to say I prefer the OpenEHR model.

However the whole point of an object model (as opposed to an object
implementation) is that it is implementation neutral.

If you can show that the XML family can meet these needs and be more
understandable and functional than ADL I will be one of the first to
jump on board. My favorite language is Python. It has one of if not
the best sets of tools for manipulating XML.

BTW As an aside:

I note from :

http://linuxmednews.com/1005015308/index_html

That you are keen on OSS & once more would just like to draw your
attention to:

http://www.bjhcim.co.uk/news/2008/n804023.htm

"The open source developer community, Open Health Tools (OHT), has
announced a collaborative effort to develop common healthcare IT
products and services. Its 26 members consist of national health
agencies, government-funded organisations and agencies, major healthcare
providers, international standards organisations and companies from
Australia, Canada, the United Kingdom and the United States.

The members include NHS Connecting for Health (CfH), BT, IBM, Oracle and
HL7, among others. Formed in November 2007, OHT's mission is to provide
software tools and components that will accelerate the implementation of
electronic health information interoperability platforms, which improve
patient quality of care, safety and access to electronic health records
(EHR).

The results will be available under an open source agreement so anyone
may use them to provide interoperable healthcare platforms that will
link clinics, hospitals, pharmacies and other points of care to make
healthcare systems more efficient.

OHT's health interoperability framework will use standardised, open
interfaces and a set of reusable software components that can be
assembled into systems and products by health systems and vendors."

I obvious appologise for :

"As part of its commitment to OHT, NHS Connecting for Health has
contributed an XML processing engine"

<G>

[NOTE] You will also need to address the issues that Thomas Beale just
presented, in the referenced thread, regarding the real world as well.

I have done so.

Adam

3

Hi Adam,

Stepping outside of well supported standards increases maintenance
requirements much much more.

Well, I am not certain I would say much much more but in any case there
are reasons why new standards are developed.

Heck why not write your ADL handling etc in PICK ?
You might find it hard to get Dell et all to support Pick on your choice
of hardware so why not try & build your own hardware with Pick optimised
chips while you're at it?

I assume you meant to surround this with sarcasm tags.

If you want to write your very own persistence mechanism/db I cannot but
admire your ambition but I would caution wrt expecting others wishing to
use it vs spending a bit more on hardware.

This wasn't the subject. I used the SQL database use as an analogy. I
don't need to create my own (even if I could) object databases prove
themselves very useful in implementation.

> How this applies to healthcare is that healthcare information must
> contain truth. That truth is fully dependent on the complete context of
> where, when and how it was recorded. This context needs to be
> understood in all spatial and temporal instances where this information
> is or may need to be used.

An obvious response would be that Heisenberg would argue with the above.

Well, I am not a quantum physicist and would not argue with him in that
domain of course. However, a lot has changed in information processing
since he passed away in 1976. I would venture to guess that he might
have made some adjustments to his uncertainty principle in the process.

There is certainly a great deal of vagueness in healthcare information
and the ARB has had MANY discussions about handling these situations.
But I still maintain that vagueness nor uncertainty negates the expected
truth value of healthcare information. The truth of healthcare
information exists in the context of which it is collected. It may
later proved to be incorrect but if the complete context of the
information is known, it will be understood by the receiver.

An interesting subject indeed but we are drifting off the subject to
some extent. :slight_smile:

However the whole point of an object model (as opposed to an object
implementation) is that it is implementation neutral.

True. But the implementation must faithfully represent the semantics of
the model or it isn't an implementation.

"As part of its commitment to OHT, NHS Connecting for Health has
contributed an XML processing engine"

I look forward to your work be proven in implementations. I think it
COULD be wonderful to use XML.

> [NOTE] You will also need to address the issues that Thomas Beale just
> presented, in the referenced thread, regarding the real world as well.
>
>
I have done so.

I agree with your format vs. design comments there. But, your examples
lead me to believe that you are still focusing on sending messages with
limited context and have not considered implications regarding storage
and retrieval of healthcare information for decision support, public
health analysis, etc.

I look forward to continued to discussions/education on your XML
progress.

Now back to our regularly scheduled work! :wink:

Cheers,
Tim

4

Dear all,

The EHR is about documenting and archiving data and information from a health/care process.
There are good well developed standards from the Documenters/archivers domain.
http://www.interpares.org/

Many requirements are defined that most messages do not address.
And most systems that rely on messages for communication do conform to the requirements from Interpares.
Requirements for messages that update data bases are never completely the same as those for ICT-systems that document data and information.
Data and information that is searchable, usable correctly and safely after 20 years and surviving many changes in society and IT technologies.

Gerard

I agree with your format vs. design comments there. But, your examples
lead me to believe that you are still focusing on sending messages with
limited context and have not considered implications regarding storage
and retrieval of healthcare information for decision support, public
health analysis, etc.

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

5

Tim Cook wrote:

Hi Adam,

Stepping outside of well supported standards increases maintenance
requirements much much more.

Well, I am not certain I would say much much more but in any case there
are reasons why new standards are developed.

Oh indeed however there are some givens wrt stds etc:

A) Binary stds (esp "on the wire") stds have died off (CORBA, COM etc) &
formatted text has taken off as a result of the plethora of langauges &
uses. I used to be a big OpenDoc/SOM person & then I used to like RMI
etc but....test messaging is a more "survivable" approach when people
look at systems with long shelf lives (which is esp the case in terms of
things like the CFH program).

Like Python.....OK this will work with it....Perl? OK......C++?
OK....etc.etc.

Being able to read a text file/stream is just about the lowest common
denominator wrt inter-systems comms.

B) wrt XML the std mark up of an element <> </> etc & attributes as
basically properties/ini format of x="y" is so std now (esp wrt the
prevalence of HTML) that I can not see much shifting that.
Wrt actual low level designs etc within that sphere (W3C Schema vs Relax
or XSLTv1 vs V2 etc) & then the higher level (e.g. HL7 Mif or XMI or SVG
etc) will be subject to change & the strady growth in new standards. The
recent ODF/OOXML fight is an example of this.

Heck why not write your ADL handling etc in PICK ?
You might find it hard to get Dell et all to support Pick on your choice
of hardware so why not try & build your own hardware with Pick optimised
chips while you're at it?

I assume you meant to surround this with sarcasm tags.

Only just. Once you start down the "roll your own" route where do you stop?

If you want to write your very own persistence mechanism/db I cannot but
admire your ambition but I would caution wrt expecting others wishing to
use it vs spending a bit more on hardware.

This wasn't the subject. I used the SQL database use as an analogy. I
don't need to create my own (even if I could) object databases prove
themselves very useful in implementation.

See above.

How this applies to healthcare is that healthcare information must
contain truth. That truth is fully dependent on the complete context of
where, when and how it was recorded. This context needs to be
understood in all spatial and temporal instances where this information
is or may need to be used.
      
An obvious response would be that Heisenberg would argue with the above.
    
Well, I am not a quantum physicist and would not argue with him in that
domain of course. However, a lot has changed in information processing
since he passed away in 1976. I would venture to guess that he might
have made some adjustments to his uncertainty principle in the process.

There is certainly a great deal of vagueness in healthcare information
and the ARB has had MANY discussions about handling these situations.
But I still maintain that vagueness nor uncertainty negates the expected
truth value of healthcare information. The truth of healthcare
information exists in the context of which it is collected. It may
later proved to be incorrect but if the complete context of the
information is known, it will be understood by the receiver.

An interesting subject indeed but we are drifting off the subject to
some extent. :slight_smile:

<G>

  

However the whole point of an object model (as opposed to an object
implementation) is that it is implementation neutral.

True. But the implementation must faithfully represent the semantics of
the model or it isn't an implementation.

No argument from me. However to take the example of UML (& please note I
am not a great fan of UML as it is more of a "meta-standard" (try
taking a xmi/model from one "UML" tool to another....)) you can design
your class diagram etc & then persist/implement that model in all sorts
of ways. So long as you can faithfully re-create that model then......

e.g. A mate of mine called Bob has built this:

http://umlspeed.sourceforge.net/

Which I often use for quick modelling.

As an example from the above, Were there an AOM/MOF mapping then in
theory you could persist an archetype out as XMI.

BTW sidenote: I have looked at both a "MIF/MIF Mapping " (I like the
name if not the result <G>) & an AOM MOF.

Dave Carlson of the VA has done much more on the HL7 part & that will
(hopefully) help towards the creation of a consistent MOF/EMF model for
HL7 wrt doing our eclipse tooling.

I will raise this as a different thread.

"As part of its commitment to OHT, NHS Connecting for Health has
contributed an XML processing engine"
    
I look forward to your work be proven in implementations. I think it
COULD be wonderful to use XML.

It could indeed.

[NOTE] You will also need to address the issues that Thomas Beale just
presented, in the referenced thread, regarding the real world as well.

I have done so.
    
I agree with your format vs. design comments there. But, your examples
lead me to believe that you are still focusing on sending messages with
limited context and have not considered implications regarding storage
and retrieval of healthcare information for decision support, public
health analysis, etc.

oh don't go there......I have had months of fun wrt the above & do not
wish to revisit that. I will say in summary that if one were to keep all
info & to wish to retrieve that then it would be unworkable & that the
reality is that it's a matter of working out what to keep & what to
discard period irrespective of language etc.

I look forward to continued to discussions/education on your XML
progress.

Now back to our regularly scheduled work! :wink:

OK

Adam

6

Correction

"MIF/MIF Mapping" should read "MIF/MOF Mapping"

Sorry. Spotted just as I clicked send.

Adam

7

Adam,
If binary standards have dried up then why is W3C producing the Efficient
XML Interchange http://www.w3.org/XML/EXI/? There is also ISO standard
based on ASN.1 (http://asn1.elibel.tm.fr/xml/finf.htm) that also produces a
binary encoding of XML. Perhaps there is a need to reduce XML document
size?

Heath

From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Adam Flinton
Sent: Friday, 18 April 2008 11:21 PM
To: timothywayne.cook@gmail.com; For openEHR technical discussions
Subject: Re: On Information and Interoperability

Tim Cook wrote:
> Hi Adam,
>
>
>>
>> Stepping outside of well supported standards increases maintenance
>> requirements much much more.
>>
>>
>
> Well, I am not certain I would say much much more but in any case there
> are reasons why new standards are developed.
>
>
Oh indeed however there are some givens wrt stds etc:

A) Binary stds (esp "on the wire") stds have died off (CORBA, COM etc) &
formatted text has taken off as a result of the plethora of langauges &
uses. I used to be a big OpenDoc/SOM person & then I used to like RMI
etc but....test messaging is a more "survivable" approach when people
look at systems with long shelf lives (which is esp the case in terms of
things like the CFH program).

Like Python.....OK this will work with it....Perl? OK......C++?
OK....etc.etc.

Being able to read a text file/stream is just about the lowest common
denominator wrt inter-systems comms.

B) wrt XML the std mark up of an element <> </> etc & attributes as
basically properties/ini format of x="y" is so std now (esp wrt the
prevalence of HTML) that I can not see much shifting that.
Wrt actual low level designs etc within that sphere (W3C Schema vs Relax
or XSLTv1 vs V2 etc) & then the higher level (e.g. HL7 Mif or XMI or SVG
etc) will be subject to change & the strady growth in new standards. The
recent ODF/OOXML fight is an example of this.

>> Heck why not write your ADL handling etc in PICK ?
>> You might find it hard to get Dell et all to support Pick on your

choice

>> of hardware so why not try & build your own hardware with Pick

optimised

>> chips while you're at it?
>>
>>
>
> I assume you meant to surround this with sarcasm tags.
>
>
Only just. Once you start down the "roll your own" route where do you

stop?

>> If you want to write your very own persistence mechanism/db I cannot

but

>> admire your ambition but I would caution wrt expecting others wishing

to

>> use it vs spending a bit more on hardware.
>>
>>
>
> This wasn't the subject. I used the SQL database use as an analogy. I
> don't need to create my own (even if I could) object databases prove
> themselves very useful in implementation.
>
>
See above.

>>> How this applies to healthcare is that healthcare information must
>>> contain truth. That truth is fully dependent on the complete context

of

>>> where, when and how it was recorded. This context needs to be
>>> understood in all spatial and temporal instances where this

information

>>> is or may need to be used.
>>>
>
>
>> An obvious response would be that Heisenberg would argue with the

above.