# On Information and Interoperability **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2008-04-18 00:36 UTC **Views:** 2 **Replies:** 6 **URL:** https://discourse.openehr.org/t/on-information-and-interoperability/14732 --- ## Post #1 by @Tim_Cook2 \[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 --- ## Post #2 by @Adam_Flinton 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 --- ## Post #3 by @Tim_Cook2 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\. :\-\) > 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\! ;\-\) Cheers, Tim --- ## Post #4 by @system 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/](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](mailto: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 --- ## Post #5 by @Adam_Flinton 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\. :\-\) > <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\! ;\-\) > OK Adam --- ## Post #6 by @Adam_Flinton Correction "MIF/MIF Mapping" should read "MIF/MOF Mapping" Sorry\. Spotted just as I clicked send\. Adam --- ## Post #7 by @Heath_Frankel3 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\. --- **Canonical:** https://discourse.openehr.org/t/on-information-and-interoperability/14732 **Original content:** https://discourse.openehr.org/t/on-information-and-interoperability/14732