# Compact XML format...?
**URL:** https://discourse.openehr.org/t/compact-xml-format/14705
**Category:** Technical (archive)
**Created:** [23 November 2007 14:47 UTC](https://discourse.openehr.org/t/compact-xml-format/14705 "2007-11-23T14:47:11Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [23 November 2007 14:47 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/1 "2007-11-23T14:47:11Z")
Hi!
During Medinfo2007 I believe Ocean Informatics presented a compact XML
format for interchange of predefined information snippets that was
used for integration purposes. I do not believe it was based on the
official RM-schemas that cover everything but instead a compact form
for a specific purpose (e.g. using a specific template or set of
archetypes). Does anybody understand what I am referring to or was I
just dreaming?
Could somebody please send a snippet with an example of that format
and possibly some description or documentation. I believe a brief
discussion regarding this on the list could be valuable since there
are use cases where having a standardized such a format would be of
value.
Best regards,
Erik Sundvall
erisu@imt.liu.se [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-227579
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [23 November 2007 15:28 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/2 "2007-11-23T15:28:36Z")
Hi Erik,
I understand what you are saying. It seems to be a customized XML Schema for data exchange. The schema is not a full-blown openEHR schema and used when the receiving system is not interested to understand the full semantics of the openEHR reference model and archetypes.
Regards,
Rong
---
### Author:  [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [23 November 2007 15:53 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/3 "2007-11-23T15:53:56Z")
Hi All,
This conversation is interesting (not in a good way).
Why / what / how did Ocean Informatics introduce a schema exchange model
at MedInfo that is not part of the specifications but yet introduced it
as openEHR?
We have the EHR Extract documents and though it isn't under ARB control
yet (as I believe it should be), it is a starting point.
I do not believe that the openEHR Foundation could support any
individual company promoting any type of interchange model that has not
been vetted.
IHMO, any system that is "not interested in the full semantics of the
openEHR model" is not compliant with openEHR and is just a stand alone
system. Much like the various HL7 implementations that require
interface engines to make the transition.
Cheers,
Tim
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [23 November 2007 18:17 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/4 "2007-11-23T18:17:03Z")
I believe you are referring to what we call Template Data Schemas
(TDSs). These are an alternate schema-per-message approach, where one
template generates one schema - in such schemas, you find tagnames
coming from the archetypes, e.g. "systolic" rather than the generic
openEHR tag names. This is similar to HL7, except that here the message
schemas are generated from content models (archetypes & templates)
rather than hand-built as in HL7. What this does is provide a message
capability to openEHR based on the content models, just like any other
generated artifact, e.g. Xforms or HML or code skeletons. We have only
just developed this capability (it is still under test), and we expect
it to be attractive to certain types of provider, e.g. pathology
software vendors and labs, since it means they can use 'simple XML' to
transfer their result messages, rather than having to understand all
that weird openEHR stuff. This approach means any message (e.g. anything
currently expressed in HL7 or Edifact) can now be generated from
archetypes and templates (obviously the literal XML is different, we
don't use RIM-based XML, but the logical purpose is exactly the same).
I will find out about example messages.
I would expect that we will provide the relevant specifications for this
process to openEHR.org at some point, when it has stabilised.
- thomas beale
Erik Sundvall wrote:
---
### Author:  [@Heath\_Frankel3](https://discourse.openehr.org/u/Heath_Frankel3)
#### Post date: [23 November 2007 18:47 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/5 "2007-11-23T18:47:56Z")
Just to clarify one thing about these Template Data Schemas, they are NOT
intended for exchange across system boundaries. They are used as an
intermediary format, which is normalised based on archetypes and templates,
for the purposes of integration between system components (note that I use
the term system in the sense of a system of systems within an enterprise).
For example, to import HL7 V2 messages into openEHR it is easier to move the
data into an intermediate form and then into openEHR. Similarly, to export
data from a proprietary database to openEHR, you can go via a intermediate
form. The key here is that the intermediate form are based on normalised
content models and can be the same for different data sources. It allows
developers to work with the content models without being openEHR experts,
resulting in reduced barriers to the take up of openEHR. The real clincher,
is that there is a single transformation from any of these template-based
XML schemas into openEHR. We are refining the rules for generating these
schemas and the openEHR transformation and will share it with the openEHR
community soon.
Regards
Heath
Heath Frankel
Product Development Manager
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
ph: +61 (0)8 8223 3075
mb: +61 (0)412 030 741
email: heath.frankel@oceaninformatics.com
---
### Author:  [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)
#### Post date: [24 November 2007 06:45 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/6 "2007-11-24T06:45:30Z")
In een bericht met de datum 23-11-2007 16:55:12 West-Europa (standaardtijd), schrijft [timothywayne.cook@gmail.com](mailto:timothywayne.cook@gmail.com):
> IHMO, any system that is “not interested in the full semantics of the
> openEHR model” is not compliant with openEHR and is just a stand alone
> system. Much like the various HL7 implementations that require
> interface engines to make the transition.
This seems only relevant to compare with the HL7 v2. V3 has no various implementations, but one standard implementation of messages. The v3 content can vary, similar to archetype variations.
Sincerely yours,
dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)
phone + 31654614458
fax +3133 2570169
Dutch Chamber of Commerce number: 32121206
---
### Author:  [@Stef\_Verlinden1](https://discourse.openehr.org/u/Stef_Verlinden1)
#### Post date: [24 November 2007 07:21 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/7 "2007-11-24T07:21:55Z")
Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog ([http://hl7-watch.blogspot.com](http://hl7-watch.blogspot.com)/, the text is also underneath). Probably I don’t understand it correctly, so if you could enlighten me that would be very helpful.
I think that we all agree that a good standard should have only one implementation
Cheers,
Stef
---
### Author:  [@Heath\_Frankel3](https://discourse.openehr.org/u/Heath_Frankel3)
#### Post date: [24 November 2007 08:47 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/8 "2007-11-24T08:47:06Z")
There is only one openEHR implementation, the template data schemas are just a tool to transform data from other formats into and out of the openEHR reference model using the semantics of the clinical archetypes models. The TDS are not intended to replace openEHR, but enable it for those that are not openEHR compliant. The result of using a TDS is openEHR for standard information sharing. The reality is, most systems are not built on a particular standard reference model such as HL7 or openEHR, they are proprietary models which move their data into these standard models for interoperable exchange. The TDS provides a means for these systems to move their data into clinical data models and mechanically transform them into technical data models, such as openEHR. Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline.
Heath
---
### Author:  [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [24 November 2007 08:59 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/9 "2007-11-24T08:59:11Z")
Thanks for your explanations Heath. I had misunderstood what Erik was
asking about and jumped to the totally wrong conclusion.
Regards,
Tim
---
### Author:  [@williamtfgoossen](https://discourse.openehr.org/u/williamtfgoossen)
#### Post date: [24 November 2007 09:15 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/10 "2007-11-24T09:15:35Z")
In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef@vivici.nl:
> > V3 has no various implementations,
>
> Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog ([http://hl7-watch.blogspot.com](http://hl7-watch.blogspot.com/)/, the text is also underneath). Probably I don’t understand it correctly, so if you could enlighten me that would be very helpful.
>
> I think that we all agree that a good standard should have only one implementation
>
> Cheers,
>
> Stef
Hi Stef,
Yes, here you have a point!
Sincerely yours,
dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
email: [Results4Care@cs.com](mailto:Results4Care@cs.com)
phone + 31654614458
fax +3133 2570169
Dutch Chamber of Commerce number: 32121206
---
### Author:  [@b.cohen](https://discourse.openehr.org/u/b.cohen)
#### Post date: [24 November 2007 16:14 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/11 "2007-11-24T16:14:57Z")
No. A good standard should ensure that all implementations that satisfy it are
mutually interoperable (see, for example, the Whitworth stanard for nuts and
bolts!). This requires that:
1. the standard include the the tests that supposdly conformant implementation
must pass;
2. that test be necessary and sufficent to guarantee compliance; and
3. Proven compliance to the standard be necessary and sufficient to guarantee
interoperability.
One way to do this is to for the standard to overdetermine implementation to
such an extent that exactly one implementation satisfy it. This is how 'de
facto standards' work.
But I was of the impression that that was not the intention of the international
health care community. Am I wrong?
Quoting Williamtfgoossen@cs.com:
---
### Author:  [@Stef\_Verlinden1](https://discourse.openehr.org/u/Stef_Verlinden1)
#### Post date: [24 November 2007 21:13 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/12 "2007-11-24T21:13:35Z")
> No. A good standard should ensure that all implementations that
> satisfy it are
> mutually interoperable (see, for example, the Whitworth stanard for
> nuts and
> bolts!). This requires that:
> 1. the standard include the the tests that supposdly conformant
> implementation
> must pass;
> 2. that test be necessary and sufficent to guarantee compliance; and
> 3. Proven compliance to the standard be necessary and sufficient to
> guarantee
> interoperability.
I agree. I guess I should have written 'a good standard' should have
only one version that is used by all who underwrite that standard. Of
course it must comply to these 3 requirements above
> One way to do this is to for the standard to overdetermine
> implementation to
> such an extent that exactly one implementation satisfy it. This is
> how 'de
> facto standards' work.
> But I was of the impression that that was not the intention of the
> international
> health care community. Am I wrong?
Can you please elaborate on this statement? My feeling is that your
right but don't know what you mean exactly. As far as I know there
are at least 3 different openEHR implementations on 3 different
software platforms (Eiffel, .net and Java (and soon one on Ruby)),
and these should be able to communicate seamlessly. So it seems that
openEHR meets at least the first 2 the requirements and, if I'm
correct, complying to the third is well on it's way
Cheers,
Stef
---
### Author:  [@grahamegrieve](https://discourse.openehr.org/u/grahamegrieve)
#### Post date: [24 November 2007 21:48 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/13 "2007-11-24T21:48:55Z")
> No. A good standard should ensure that all implementations that satisfy it are
> mutually interoperable (see, for example, the Whitworth stanard for nuts and
> bolts!).
should it? I'm not so sure that this is the correct definition of a good standard.
While I certainly see it's appeal, it seems to me that there's a tension between
interoperable and flexible, and the business managers - the people that actually
spend money on systems - do not wish to have systems that are fully locked down.
In this sense, standards that lock things down are not what is desired, and the
standards need to search for a happy medium.
\> This requires that:
> 1. the standard include the the tests that supposdly conformant implementation
> must pass;
\> 2. that test be necessary and sufficent to guarantee compliance; and
\> 3. Proven compliance to the standard be necessary and sufficient to guarantee
\> interoperability.
Out of idle interest, would you care to nominate an IT interoperability standard
that actually meets your criteria?
> One way to do this is to for the standard to overdetermine implementation to
> such an extent that exactly one implementation satisfy it. This is how 'de
> facto standards' work.
I don't agree with that either. In fact, if only one implementation can satisfy
it, it's not an interoperability standard.
As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move
things along, and contribute to the overall picture, instead of whining
about such trivia as version management. Of course the problem he describes
is painful, but this problem is not new, nor specific to HL7.
Other HL7 naysayers have gone and done something useful at least; that's why
we're on this list. (though, strictly, the doing something useful came first.
That's why I've stopped bothering to read Barry Smith)
> But I was of the impression that that was not the intention of the international
> health care community.
in as much as such a diverse group can be said to have an intention, it wanders
somewhere between cheap, flexible, and interoperable. But you can only have two
of those three.
Grahame
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [24 November 2007 23:14 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/14 "2007-11-24T23:14:15Z")
This is how I see it as well. Realistically, various vendors implement
only some pieces of larger, more comprehensive systems - like compay A
makes nuts and company B makes bolts, but the standard for nuts + bolts
must either be one standard or 2 totally compatible standards. Any given
implementation in e-Health is likely to be responsible for just a few
things out of the universe, e.g. some kinds of messages, patients, who
knows what. Bigger vendors may implement a substantial amount, but I
don't expect any single implementation will be the one stop shop -
because no implementation can satisfy all business needs, even if it
completely satisfies the standards.
On the other hand, if you take an interoperability component, like the
openEHR kernel, or some message parser or whatever, is there any sense
in having more than one good, free, and open implementation in each of
the major technologies, i.e. .Net, Java, Python...(add your favourite)?
I think the more related to interoperability the component is, and the
more widely it is needed, the less argument there is for multiple
implementations, since they don't serve any purpose. Good quality can be
achieved by an engineering-based open source approach like Eclipse does;
once you have an open component, then all other requirements can be
engineered into it, rather than companies inventing their own varieties.
For components not needing to be directly interoperable, e.g. an
enterprise EHR server (most of the software is about data storage and
local serving), and also satisfying varied business needs, competition
is more appropriate. I am coming to the view that open source projects
for full domain specific systems like EHR, etc do not make sense - all
they do is try to replicate commercial systems for a given business
context - this is ok for small systems, but for fully scalable EHR,
knowledge services, etc I don't see it. Reusable components seemn to me
to be the the more sensible purview of open source in a specialised
domain. (Things like Apache are different - they are not domain specific
and the business context is pretty much the same everywhere.)
- thomas beale
b.cohen wrote:
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [24 November 2007 23:21 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/15 "2007-11-24T23:21:00Z")
Grahame Grieve wrote:
> in as much as such a diverse group can be said to have an intention, it wanders
> somewhere between cheap, flexible, and interoperable. But you can only have two
> of those three.
\*not a bad summary. Especially if 'flexible' can be read as 'scalable'...
- thomas
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [24 November 2007 23:29 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/16 "2007-11-24T23:29:00Z")
Dear Bernie,
The experiences that I have had the last 13 years in HL7, CEN/tc251
and ISO/tc251 indicate that many standards depend on many other
standards.
And many times the standard defines things on an abstract level,
needing other standards to make it concrete in a particular situation.
In other words things are not so simple and straightforward as the nut
and the bold standard.
What you describe is a specific extreme situation.
In the case of the latest European standard for the EHR produced one
implementable specification for this EHR standard.
In the case of HL7v2 and HL7v3 message standards it has been proven
necessary that an organisation like IHE was needed to produce for a
specific context one specification to be used for implementation.
One of the reasons is that standards are consensus products for the
general case of requirements.
In particular contexts the open ends need to be closed and specified.
In the near future it will become clear that in order to create
semantic interoperability that flexibly can support the ever changing
requirements in healthcare the standardisation processes and the
process leading to an implementable specification will not be enough.
In addition to the above we need databases where the most recent (and
old) local context specific constraints are kept and published.
Semantic interoperability in healthcare (and outside it) needs other
more flexible organisations and publication methods to keep pace with
developments in healthcare.
The next weeks and months I will be involved in the creation of all
this for Europe in the European Institute for Health Records.
Greetings,
Gerard
---
### Author:  [@b.cohen](https://discourse.openehr.org/u/b.cohen)
#### Post date: [24 November 2007 23:31 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/17 "2007-11-24T23:31:56Z")
Quoting Grahame Grieve \:
> \> No. A good standard should ensure that all implementations that satisfy it
> are
> \> mutually interoperable (see, for example, the Whitworth stanard for nuts
> and
> \> bolts!).
>
> should it? I'm not so sure that this is the correct definition of a good
> standard.
> While I certainly see it's appeal, it seems to me that there's a tension
> between
> interoperable and flexible, and the business managers - the people that
> actually
> spend money on systems - do not wish to have systems that are fully locked
> down.
> In this sense, standards that lock things down are not what is desired, and
> the
> standards need to search for a happy medium.
If compliance to a standard does not guarantee interoperabilty with everything
alse that complies to the standard, then what exactly is being standardised?
> \> This requires that:
> \> 1. the standard include the the tests that supposdly conformant
> implementation
> \> must pass;
> \> 2. that test be necessary and sufficent to guarantee compliance; and
> \> 3. Proven compliance to the standard be necessary and sufficient to
> guarantee
> \> interoperability.
>
> Out of idle interest, would you care to nominate an IT interoperability
> standard
> that actually meets your criteria?
That's not an idle question. Merely asking it reveals serious problems that have
plagued the IT industry for over half a century, re programming languages,
operating systems, comms protocols, office applications, databases, etc. etc.
These problems arise mainly through the industry's failure to address these
three criteria, which necessarily introduce concepts of formal definition and
proof that have been beyond the capability, and even comprehension, of most IT
systems suppliers and their customers.
> \> One way to do this is to for the standard to overdetermine implementation
> to
> \> such an extent that exactly one implementation satisfy it. This is how 'de
> \> facto standards' work.
>
> I don't agree with that either. In fact, if only one implementation can
> satisfy
> it, it's not an interoperability standard.
On the contrary. A standard that's defined by an implementation guarantees
interoperability among the users of that implementation. That's how MS won its
market share.
> As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move
> things along, and contribute to the overall picture, instead of whining
> about such trivia as version management. Of course the problem he describes
> is painful, but this problem is not new, nor specific to HL7.
>
> Other HL7 naysayers have gone and done something useful at least; that's why
> we're on this list. (though, strictly, the doing something useful came first.
> That's why I've stopped bothering to read Barry Smith)
>
> \> But I was of the impression that that was not the intention of the
> international
> \> health care community.
>
> in as much as such a diverse group can be said to have an intention, it
> wanders
> somewhere between cheap, flexible, and interoperable. But you can only have
> two
> of those three.
Can you demonstrate that these three properties are necessarily mutually
incompatible? And, if it is indeed so, which of them would you advocate
prioritising in the domain of healthcare?
---
### Author:  [@system](https://discourse.openehr.org/u/system)
#### Post date: [24 November 2007 23:34 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/18 "2007-11-24T23:34:07Z")
Dear Graham,
I’m of the opinion that deployment of the European standard for the EHR/openEHR will make systems dramatically cheaper to produce and maintain; extremely flexible because of the archetype and template mechanism; and create semantic interoperability between conformant systems without a strong dependency on the co-operation of the software vendor.
Gerard.
– –
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
---
### Author:  [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [25 November 2007 00:58 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/19 "2007-11-25T00:58:30Z")
Very true. Much of the contextual relationships can be lost simply in
how the information is persisted. If information is broken up too finely
then it can't be put back together in the same context (based on current
implementations of SQL databases) simply due to performance issues.
Tim
---
### Author:  [@Tim\_Cook2](https://discourse.openehr.org/u/Tim_Cook2)
#### Post date: [25 November 2007 07:34 UTC](https://discourse.openehr.org/t/compact-xml-format/14705/20 "2007-11-25T07:34:38Z")
> Think of it as standard mechanism for data transformation rather
> than a standard data exchange, where the semantics of the archetypes
> are maintained at each stage in the pipeline.
Would it be fair to say then that when working with HL7 v2 messaging.
I would want to use this data transformation process against the XML
output of MIRTH ( [http://www.mirthproject.org/](http://www.mirthproject.org/) )so that I can use all
the management facilities of MIRTH and only have to have (essentially)
one transform??
Cheers,
Tim
[Next page](https://discourse.openehr.org/t/compact-xml-format/14705.md?page=2)