Compact XML format...?

Technical (archive)
21

Hi!

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 seems to be exactly what I was looking for.

I will find out about example messages.

Wonderful, if it was possible to get it soon that would be helpful.

The reason for asking is that in a context where openEHR/13606 has
been compared to HL7 (mainly v3 I believe) some parties claimed it
would be easier for vendors to support HL7 than openEHR. In practice,
what they mean is probably that they are used to follow (map their
internal/legacy structures to) specific HL7 xml schemas that come out
after the long HL7 modeling process. I doubt that the vendors in this
case internally are using any HL7 v3 models.

This is sometimes forgotten when comparing HL7 and openEHR.

So far we have had a look at some fairly equivalent examples of XML
instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both
were fairly easy to understand when knowing the underlying models (HL7
RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were
just interested in the blood pressure. To be honest if I was a vendor
not interested in underlying models I'd probably prefer whichever I
was already used to and had people trained to work with - since none
of them tries to make life easier to me by being tailored to the
specific use case.

To validate clinically both were dependent on other artifacts (HL7
Templates or openEHR archetypes). An information provider not
interested in the underlying validation mechanisms could easily
produce data instances that are clinically invalid even though they
are valid from the perspective of the respective XML schemas. Does the
TDS-approach produce an XML schema that enforces more or all of the
specific archetype+template semantics? If not, could it be enhanced to
do that? If so I believe that some safety would be gained - if data
providers do not care to learn the full semantics of openEHR then at
least their schema-based XML-validators would enforce some of the
semantics.

If we could standardize the TDSs and have accompanying standard
determinstic transformation mechanism then openEHR would have a
competitive advantage in the "just give me a simple XML schema and
instance examlpe" use-case. A use case more important than one might
think at first...

Sometimes the use case is to decide on an XML format (for data
exchange) based on one of the following
1. HL7 CDA
2. 13606/openEHR
3. A custom tailored XML schema

Imagine that we using something like TDS could give an easy-to-produce
alternative to 3 that with some deterministic transformations at the
receiver also conforms to 2. (An open or free tool to produce the
schema would be of tremendous help of course.)

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

22

Tim,
I don't know anything about MIRTH but I will assume it does something like
take a HL7 v2 message and turn it into some XML document based on a provided
schema, I would call this a transformation, just not XSLT. Assuming that
the XML Schema used in MIRTH is a Template Data Schema, then you are only
one further transformation away from openEHR. Any integration engine can be
used to implement this approach using whatever mapping tools it provides.

Again I don't know about how MIRTH works but the catch in this is the
Template Data Schemas might be too specific to allow MIRTH to be used
against the TDS in one step. What I mean by this is that a TDS is specific
to a use case such as a Microbiology Report, not a generic Observation
Result equivalent to the HL7 OUR message. When receiving a ORU message you
need to determine that it has a Microbiology observation within and apply
the transform to the Microbiology Report TDS, if it contains a Lipids result
then you need to apply the transform to a TDS containing laboratory-lipids
OBSERVATION archetype in it. You could certainly come up with a template
containing a generic laboratory OBSERVATION archetype in it and map
everything in an ORU to that but you lose some of the semantics of the
specialised archetypes. Using our current integration engine of choice, we
have a mechanism where we can apply logic to determine what kind of lab
report has been received based on data within the message and apply the
appropriate TDS transformation and anything else we don't yet support we
transform to a generic laboratory report TDS. This gives the ability to
take all results from a lab into openEHR but can progressively utilise
specialised archetypes for common results as we develop those transformation
mappings.

The benefit of this Archetype-based Integration approach is that we can
start building a library of HL7 V2 to TDS transformations that can be used
as a starting point for integrating with a specific HL7 interface,
customising to suit the local HL7 and terminology implementation. This
library could be an open resource. This is something that I have not seen
possible in system integration before.

BTW, this approach is not limited to integration with openEHR, but it is the
Archetype that makes it work. The Archetype is the implementation
independent logical concept model that is used derive the implementation to
semantic mapping in and out of the Archetype-based normalised intermediate
format.

Regards

Heath

23

Dear Erik,

The European Institute for Health Records is executing a European project: Q-Rec.
Next to quality labelling and certification we have to set up registries of approved artefacts like:

  • archetypes and templates
  • coding systems
  • EHR related standards
    and
  • XML implementable Information definitions.

I hope and expect that these Template Data Schemas can find a place there to be disseminated.

Gerard

conexis

24

hi

If compliance to a standard does not guarantee interoperabilty with everything
alse that complies to the standard, then what exactly is being standardised?

My point of view is simple. I do this for a living - apply these standards
to make interoperability happen. Without healthcare standards, I must choose
some lower level standards, such as xml, figure out my own data and
process models, agree with someone else, and implement.

Using HL7 v2, v3, or archetypes/templates gives me a pre-existing
language and process model, a set of shared assumptions, and also
allows me to share existing code and information models across
different interoperability implementations.

So they are all interoperability framework standards, rather
than interoperability standards - a lot like the W3C standards;
http, html, soap, xml etc, these are interoperability frameworks.
I think that what we are doing in health stands up well when compared
with W3C and OMG.

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.

so, why complain? the users buy what the users want. It's like complaining
about insecure software. Give a user a choice of a $100 package and a $10000
equivalent that is more secure. Which are they going to choose? Yet people
see this problem as a supplier side problem. I don't understand why.

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.

I'm not convinced that such a standard is actually a better outcome; it's still
going to be shot through with technical flaws, and probably no process for
managing it which is not subject to commercial corruption.

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?

I'm not sure that I can demonstrate it. It's a truism I adapted from Martin
Fowler, though he probably got it from "Fast, cheap, or good; you can have
any two".

My experience is strongly in support of this; there is an inherent tension
between interoperability - being standard, doing things the common way - and
offering a product that delivers features that the users want. You can over
engineer to try and do both, but it takes a huge amount of extra work. So
I think you can't have all three.

As for which I advocate, I'm just a jumped up programmer who makes my
living doing interoperability for customers, so naturally I don't
recommend cheap :wink:

But the reality is that there's only a given amount of money to spend
on healthcare, however it's organised, and given the amount of waste
involved in any human endeavour, cost will always be first and last.

And, err, try doing sales where you say to a customer, "well, we can't
actually solve your business problem because HL7 doesn't support it."
I can assure you, that doesn't help you land the sale.

I am in favour of open source, of course, I believe it offers the best
mix of the three, but it's frustratingly hard to make things align.
I'm still living in hope that the various open source initiatives can come
together productively

Grahame
CTO Kestral Computing
co-chair Infrastructure & Messaging TC (HL7)
editor - HL7 datatypes & templates specifications
Project Lead - Eclipse Open Healthcare Foundation

25

Erik Sundvall wrote:

So far we have had a look at some fairly equivalent examples of XML
instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both
were fairly easy to understand when knowing the underlying models (HL7
RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were
just interested in the blood pressure. To be honest if I was a vendor
not interested in underlying models I'd probably prefer whichever I
was already used to and had people trained to work with - since none
of them tries to make life easier to me by being tailored to the
specific use case.
  

thi is a reasonable statement, practically speaking. The question is\;
if you are vendor that needs to increase the diversity of content being
handled - in other words, you are need semantic scalability - and, if
you need to be able too use other derived products from the same content
models, then the difference starts to manifest itself. There isn't any
easy way I know of to convert a v3 RMIM to an Xform, a PDF, various
kinds of XML and HTML and so on. And before people simply say: 'its just
an XML transform', you must remember that in the RIM/RMIM world, there
are dozens of attributes specifically to do with message transfer that
don't make sense in other representations of the same content. Any
transformation software has to sift through all these, as well as work
out all the context conduction etc. It is not trivial.

To validate clinically both were dependent on other artifacts (HL7
Templates or openEHR archetypes). An information provider not
interested in the underlying validation mechanisms could easily
produce data instances that are clinically invalid even though they
are valid from the perspective of the respective XML schemas. Does the
TDS-approach produce an XML schema that enforces more or all of the
specific archetype+template semantics? If not, could it be enhanced to
do that? If so I believe that some safety would be gained - if data
providers do not care to learn the full semantics of openEHR then at
least their schema-based XML-validators would enforce some of the
semantics.
  

see other responses on this (yes is the answer).

If we could standardize the TDSs and have accompanying standard
determinstic transformation mechanism then openEHR would have a
competitive advantage in the "just give me a simple XML schema and
instance examlpe" use-case. A use case more important than one might
think at first...
  

that's why we made them in the first place :wink: For vendors who just want
to send a bunch of messages (they usually see them as messages), that
can be converted by smart software doing a standard transform,
generating guaranteed correct openEHR content.

- thomas beale

26

Hi Erik,
I will forward a schema based on a Microbiology Result generated using the
Ocean Template Designer separately.

See comments below, you have stated exactly the problem that the TDS was
designed to solve. We are using this approach to integrate existing vendor
software to the Ocean EhrBank where the vendor has no openEHR expertise or
desire to do so (yet), they just want to have an openEHR repository.

Heath

The reason for asking is that in a context where openEHR/13606 has
been compared to HL7 (mainly v3 I believe) some parties claimed it
would be easier for vendors to support HL7 than openEHR. In practice,
what they mean is probably that they are used to follow (map their
internal/legacy structures to) specific HL7 xml schemas that come out
after the long HL7 modeling process. I doubt that the vendors in this
case internally are using any HL7 v3 models.

This is sometimes forgotten when comparing HL7 and openEHR.

So far we have had a look at some fairly equivalent examples of XML
instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both
were fairly easy to understand when knowing the underlying models (HL7
RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were
just interested in the blood pressure. To be honest if I was a vendor
not interested in underlying models I'd probably prefer whichever I
was already used to and had people trained to work with - since none
of them tries to make life easier to me by being tailored to the
specific use case.

[Heath Frankel]
As you know, a template is the knowledge artefact designed for a particular
use case, the TDS is a technical artefact to support the implementation of
that use case.

To validate clinically both were dependent on other artifacts (HL7
Templates or openEHR archetypes). An information provider not
interested in the underlying validation mechanisms could easily
produce data instances that are clinically invalid even though they
are valid from the perspective of the respective XML schemas. Does the
TDS-approach produce an XML schema that enforces more or all of the
specific archetype+template semantics? If not, could it be enhanced to
do that? If so I believe that some safety would be gained - if data
providers do not care to learn the full semantics of openEHR then at
least their schema-based XML-validators would enforce some of the
semantics.

[Heath Frankel]
Most but not all the semantics of the archetypes and templates are
represented in the TDS. The reason it is not all, is due to the limitations
of XML schema to do assertions between XML elements.

If we could standardize the TDSs and have accompanying standard
determinstic transformation mechanism then openEHR would have a
competitive advantage in the "just give me a simple XML schema and
instance examlpe" use-case. A use case more important than one might
think at first...

[Heath Frankel]
The TDS is simply a set of XML elements with names from the archetypes. If
you look at the schema in an graphical XML tool such as Oxygen you will see
a tree that has the same structure as the template tree displayed in the
Ocean Template Designer.

Sometimes the use case is to decide on an XML format (for data
exchange) based on one of the following
1. HL7 CDA
2. 13606/openEHR
3. A custom tailored XML schema

Imagine that we using something like TDS could give an easy-to-produce
alternative to 3 that with some deterministic transformations at the
receiver also conforms to 2. (An open or free tool to produce the
schema would be of tremendous help of course.)

[Heath Frankel]
This is exactly the plan for the TDS.

27

Hi Erik,
I will forward a schema based on a Microbiology Result generated using the
Ocean Template Designer separately.

See comments below, you have stated exactly the problem that the TDS was
designed to solve. We are using this approach to integrate existing vendor
software to the Ocean EhrBank where the vendor has no openEHR expertise or
desire to do so (yet), they just want to have an openEHR repository.

Hi Heath, Tom and others,

I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this ‘easy’ way of integrating openEHR systems, we make it possible for vendors to ignore the ‘hard’ way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn’t contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won’t be possible, e.g. AQL queries of the data.

Also one-template-one-schema seems to imply software changes whenever new templates are introduced. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive.

Regards,
Rong

28

Rong Chen wrote:

Hi Heath, Tom and others,

I clearly see there is a need for TDS based integration. But I am also
concerned with the side-effects of it. By offering this 'easy' way of
integrating openEHR systems, we make it possible for vendors to ignore
the 'hard' way of integrating openEHR systems using archetypes and the
generic RM. As you have indicated TDS doesn't contain all the
semantics of the archetypes and RM, some semantics will be forever
lost when data are received using TDS. Without the knowledge of
archetypes and RM, some intelligent use of the data won't be possible,
e.g. AQL queries of the data.

This unfortunately is a purist view. I know - I used to have it :wink:
Realistically, many vendors of software used in places like laboratories
will only use simple XML or other message-based solutions - they just
will not go into the nice theories or modelling that we are interested
in here. So the TDS approach is designed to allow them to have a simple
schema (i.e. with tags they understand) whose instance data is
guaranteed to map directly into a proper openEHR server. THe developers
who build that software just have to generate conformant instance, and
there is nothing else to do. The data are not widely usable until
converted into openEHR form, which is why this approach is really only
appropriate for source systems feeding to an EHR system. But - that
might be 50% or more of all health information communications in the
world, so it is a major use case.

Also one-template-one-schema seems to imply software changes whenever
new templates are introduced.

well it might at their end, e.g. if the lab wants to create a new lab
message, but that's what they expect. This is good economics of software
building for such vendors.

Such changes will not be necessary if the openEHR RM can be mapped
directly into a generic internal model, which is constrained in
runtime using semantics in the archetypes/templates. So even it seems
to be harder than TDS based integration, it does offer full benefits
of using archetypes and makes the system more adaptive.

Yes, but only some people want adaptive systems. It all comes down to
software engineering economics. If your system only generates 25
different pathology result messages which change very little over the
years (as is true for the basic biochemistry, bloods, micro etc) then it
doesn't make any sense to build a fully adaptive generic system; it will
be far cheaper to more or less hard-wire the messages into some part of
your software. For such vendors, the main game isn't the diversity or
rate of change of the content, it is the volume of throughput, security,
uptime and other such issues that are far more important - as would be
for the case for any large lab company with a contract with e.g. a
regional or state government health service. The semantics are not the
most important thing for suppliers whose systems only deal with a
relatively small section of health data types.

- thomas beale

29

I also think the problem is that we have to accept the pragmatics of the current situation in health care where companies are not immediately going to re-engineer their systems to become openEHR compliant, no matter how much we would like that. In time, many companies will re-engineer their software, and other new applications will arrive on the scene that are fully openEHR compliant.

In the meantime, this pragmatic approach allows for archetypes and templates to completely model clinical medicine and to enable everyone to participate at, initially, minimum cost and effort. The exciting thing about the openEHR approach, is that these Template Data Schemas are not hand coded, but are generated directly from templates and archetypes using tools. In Australia, we are using this approach to enable the completely tool driven generation of CDA R2 documents (because in a pragmatic world, we have to interact with everyone!) with data going both in and out of CDA. Of course we are doing this with openEHR as well.

Hugh Leslie

Thomas Beale wrote:

30

Hugh, Tom, Heath, et.al.

I agree that openEHR systems MUST interact with everyone else. I also
agree that MOST healthcare information providers only have a small
segment of healthcare information to consider. I agree that if we (as an
openEHR community) do not work with the broader, more established world
we will be isolated (no matter that our approach is superior :-> ).

However, (I always have a BUT or a HOWEVER to present) "I do think" that
it is more prudent to do these translations INSIDE an openEHR
implementation instead of trying to coax outside entities into doing
them to communicate with openEHR implementations?

A different approach says that; openEHR can translate ANYTHING thrown at
it via these really cool translations (TDS?). Instead of trying to get
various vendors to support our (strange) formats that they do not
understand.

We certainly know that not many vendors are providing HL7 v3 messages at
this point. Shouldn't we concentrate on providing HL7 v2 lab, rad, etc.
input to EHR's/PHR's instead of trying to convince the uninformed world
that they should be giving us openEHR EHR_Extracts or even transformed
XML data?

Thanks,
Tim

31

Rong,

XML documents populated against a Template Data Schema are turned into pure openEHR, so you do not lose any semantics. There is enough meta data in the TDS to maintain the semantics. What you may lose are some of the ADL assertions which cannot be expressed in XSD, but these will be picked up by an openEHR kernel before being committed. The schema provides enough constraints to get a non-openEHR developer started.

All this will become clear when we publish a draft of the TDS generation and transformation rules on the wiki.

Heath

32

Hi Tim

Yes, I absolutely agree with this - our tools are capable of receiving V2 messages and producing openEHR data - we did this at MedInfo for the interoperability demo. The problem with V2 is that the ability to put clinical content in there is limited (which is why all the work on v3!) and so we are also working on these other methods. As I said previously we are currently capable of creating and sending CDA R2 messages from openEHR and so as soon as there are applications out there capable of receiving them, we are capable of sending.

regards Hugh

Tim Cook wrote:

33

All this will become clear when we publish a draft of the TDS
generation and transformation rules on the wiki.

Out of curiosity. Do you have any idea of a time frame for this
publication?

Thanks,
Tim

34

Hello Hugh,

Thanks for the reply.

I think we have a communications issue though. My questions/comments
weren't about the technical aspects.

As I understood the proposition. It was to encourage other system
vendors to create these templates in order to communicate with an
openEHR based application.

My argument is that the world of healthcare data exchange has been built
(so far) on HL7 v2.x If my understanding of your proposal is correct
then I will argue that we will have very little success in getting these
vendors to incorporate a message format for openEHR. I believe it is
better to just continue doing what you are now by consuming HL7
messages.

Again, I "think" we are saying the same things but I'm not positive. :slight_smile:

Cheers,
Tim

35

My argument is that the world of healthcare data exchange has been built
(so far) on HL7 v2.x If my understanding of your proposal is correct
then I will argue that we will have very little success in getting these
vendors to incorporate a message format for openEHR. I believe it is
better to just continue doing what you are now by consuming HL7
messages.

I don't think we should be so pessimistic. The course that Hugh is describing
offers a graceful way to become involved with openEHR, a way that allows
for gradual development of piece meal solutions into an already existing
ediface in a business friendly fashion. I think it makes a lot of sense
for both parties to find this common ground.

Grahame

36

No time set yet, still refining it and updating the associated
documentation.

Heath

37

Were HL7 messages exist and are working, we will continue to consume them
using the TDS intermediate form. As stated previously, the TDS is not
intended for information exchange, but as a tool for integration.

Heath

From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Tim Cook
Sent: Tuesday, 27 November 2007 11:11 AM
To: For openEHR technical discussions
Subject: Re: Compact XML format...?

Hello Hugh,

Thanks for the reply.

I think we have a communications issue though. My questions/comments
weren't about the technical aspects.

As I understood the proposition. It was to encourage other system
vendors to create these templates in order to communicate with an
openEHR based application.

My argument is that the world of healthcare data exchange has been built
(so far) on HL7 v2.x If my understanding of your proposal is correct
then I will argue that we will have very little success in getting these
vendors to incorporate a message format for openEHR. I believe it is
better to just continue doing what you are now by consuming HL7
messages.

Again, I "think" we are saying the same things but I'm not positive. :slight_smile:

Cheers,
Tim

> Hi Tim
>
> Yes, I absolutely agree with this - our tools are capable of receiving
> V2 messages and producing openEHR data - we did this at MedInfo for
> the interoperability demo. The problem with V2 is that the ability to
> put clinical content in there is limited (which is why all the work on
> v3!) and so we are also working on these other methods. As I said
> previously we are currently capable of creating and sending CDA R2
> messages from openEHR and so as soon as there are applications out
> there capable of receiving them, we are capable of sending.
>
> regards Hugh
>
> Tim Cook wrote:
> > Hugh, Tom, Heath, et.al.
> >
> > I agree that openEHR systems MUST interact with everyone else. I also
> > agree that MOST healthcare information providers only have a small
> > segment of healthcare information to consider. I agree that if we (as

an

> > openEHR community) do not work with the broader, more established

world

> > we will be isolated (no matter that our approach is superior :-> ).
> >
> > However, (I always have a BUT or a HOWEVER to present) "I do think"

that

> > it is more prudent to do these translations INSIDE an openEHR
> > implementation instead of trying to coax outside entities into doing
> > them to communicate with openEHR implementations?
> >
> > A different approach says that; openEHR can translate ANYTHING thrown

at

> > it via these really cool translations (TDS?). Instead of trying to get
> > various vendors to support our (strange) formats that they do not
> > understand.
> >
> > We certainly know that not many vendors are providing HL7 v3 messages

at

> > this point. Shouldn't we concentrate on providing HL7 v2 lab, rad,

etc.

> > input to EHR's/PHR's instead of trying to convince the uninformed

world

> > that they should be giving us openEHR EHR_Extracts or even transformed
> > XML data?
> >
> > Thanks,
> > Tim
> >
> >
> >
> >
> > > I also think the problem is that we have to accept the pragmatics of
> > > the current situation in health care where companies are not
> > > immediately going to re-engineer their systems to become openEHR
> > > compliant, no matter how much we would like that. In time, many
> > > companies will re-engineer their software, and other new

applications

> > > will arrive on the scene that are fully openEHR compliant.
> > >
> > > In the meantime, this pragmatic approach allows for archetypes and
> > > templates to completely model clinical medicine and to enable

everyone

> > > to participate at, initially, minimum cost and effort. The exciting
> > > thing about the openEHR approach, is that these Template Data

Schemas

> > > are not hand coded, but are generated directly from templates and
> > > archetypes using tools. In Australia, we are using this approach to
> > > enable the completely tool driven generation of CDA R2 documents
> > > (because in a pragmatic world, we have to interact with everyone!)
> > > with data going both in and out of CDA. Of course we are doing this
> > > with openEHR as well.
> > >
> > > Hugh Leslie
> > >
> > > Thomas Beale wrote:
> > >
> > > > Rong Chen wrote:
> > > >
> > > >
> > > > > Hi Heath, Tom and others,
> > > > >
> > > > > I clearly see there is a need for TDS based integration. But I

am

also
> > > > > concerned with the side-effects of it. By offering this 'easy'

way

of
> > > > > integrating openEHR systems, we make it possible for vendors to
ignore
> > > > > the 'hard' way of integrating openEHR systems using archetypes

and

the
> > > > > generic RM. As you have indicated TDS doesn't contain all the
> > > > > semantics of the archetypes and RM, some semantics will be

forever

> > > > > lost when data are received using TDS. Without the knowledge of
> > > > > archetypes and RM, some intelligent use of the data won't be
possible,
> > > > > e.g. AQL queries of the data.
> > > > >
> > > > >
> > > > This unfortunately is a purist view. I know - I used to have it

:wink:

> > > > Realistically, many vendors of software used in places like
laboratories
> > > > will only use simple XML or other message-based solutions - they

just

> > > > will not go into the nice theories or modelling that we are

interested

> > > > in here. So the TDS approach is designed to allow them to have a
simple
> > > > schema (i.e. with tags they understand) whose instance data is
> > > > guaranteed to map directly into a proper openEHR server. THe
developers
> > > > who build that software just have to generate conformant instance,

and

> > > > there is nothing else to do. The data are not widely usable until
> > > > converted into openEHR form, which is why this approach is really

only

> > > > appropriate for source systems feeding to an EHR system. But -

that

> > > > might be 50% or more of all health information communications in

the

> > > > world, so it is a major use case.
> > > >
> > > >
> > > > > Also one-template-one-schema seems to imply software changes
whenever
> > > > > new templates are introduced.
> > > > >
> > > > >
> > > > well it might at their end, e.g. if the lab wants to create a new

lab

> > > > message, but that's what they expect. This is good economics of
software
> > > > building for such vendors.
> > > >
> > > >
> > > > > Such changes will not be necessary if the openEHR RM can be

mapped

> > > > > directly into a generic internal model, which is constrained in
> > > > > runtime using semantics in the archetypes/templates. So even it
seems
> > > > > to be harder than TDS based integration, it does offer full

benefits

> > > > > of using archetypes and makes the system more adaptive.
> > > > >
> > > > >
> > > > >
> > > > Yes, but only some people want adaptive systems. It all comes down

to

> > > > software engineering economics. If your system only generates 25
> > > > different pathology result messages which change very little over

the

> > > > years (as is true for the basic biochemistry, bloods, micro etc)

then

it
> > > > doesn't make any sense to build a fully adaptive generic system;

it

will
> > > > be far cheaper to more or less hard-wire the messages into some

part

of
> > > > your software. For such vendors, the main game isn't the diversity

or

> > > > rate of change of the content, it is the volume of throughput,
security,
> > > > uptime and other such issues that are far more important - as

would be

> > > > for the case for any large lab company with a contract with e.g. a
> > > > regional or state government health service. The semantics are not

the

38

Hi Heath,

As stated previously, the TDS is not
intended for information exchange, but as a tool for integration.

This may be getting too philosophical for my small brain.

I do apologize for being so "dense". But I cannot reconcile the
difference you are claiming between "information exchange" and
"integration".

Isn't 'integration' the process of validating/coordinating 'information
exchange'?

Cheers,
Tim

39

Integration is not necessarily only about messaging and information exchange between systems. Integration also includes making two software components work together within a system, such as a middleware component and a presentation portal that are source from different vendors. Anytime two system components have different underlying information models and need to be made to work together you transform one components information model into the other using integration components (or adapters). This is also why integration is different to interoperability, if two component were interoperable then you wouldn't need the integration components. When an existing software system is not interoperable with openEHR we can use a TDS pipeline to integrate with openEHR.

Heath

40

Hi Heath,

> As stated previously, the TDS is not
> intended for information exchange, but as a tool for integration.

This may be getting too philosophical for my small brain.

I do apologize for being so "dense". But I cannot reconcile the
difference you are claiming between "information exchange" and
"integration".

Isn't 'integration' the process of validating/coordinating 'information
exchange'?

Heath is just using this terminology to distinguish between local systems that
feed into EHR systems from self-standing EHR/EMR systems which might talk to
each other. Actually, the division is not that clear - we use the TDS message
to handle CDA documents from some sources (which may be EMR-like) because it
works better, and writing a generic transform for CDA level 3 (fully
structured) is hard.

- thomas beale