that corresponds to the reverse of the current
TDS generator. It would need access to the templates and archetypes,
that's all.
- thomas
- TDS XML form, known as TDD
o - XML will be an instance of each TDS, where there is one TDS
for each Template
o all instances of a given TDS conform to that TDS, but of course
not to another TDS
o TDD - canonical data transform is needed to put the data
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080502/cef37e6e/attachment.html
Hi!
Which projects and products out there support TDS (Template Data Schema)?
And do they support conversion of TDDs (Template Data Documents) to
standard canonical openEHR RM instances (in e.g. XML)? Is there any
available XSLT, webservice or other thing that can convert bidirectionally
between
On 14/06/2013 12:12, Gerard Freriks wrote:
Dear Thomas,
Why do we (CIMI) need a TDD?
Isn't a TDD a transformation that is used during the implementation of
a Template.
I have to admit I was surprised to see all this talk of TDD-like things
in CIMI. TDS/TDD is more than just a specification
Hello Hugh and all other readers,
i still have some doubts about the right application of openEHR schema
definitions.
Please see my comments inline!
Hugh Leslie schrieb:
The TDS schema is not generic like the openEHR schema - it relates
exactly to a particular use case (template) including
On Mon, 2007-11-26 at 15:52 +0100, Heath Frankel wrote:
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
--
Timothy Cook, MSc
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080428/20165f5d/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: OceanInformaticsl.JPG
Type: image/jpeg
Size: 5828
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
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
of the transformation
rules, and an XSL transform. The other factor is that the source of this
transform is an Operational Template document, which is yet to be stabilised
as we are awaiting the next draft of the Template Specification. I suspect
that the TDS transformation will be published after this. I
(Template Data Document) is
something different. It's not an XML instance of the canonical (i.e. RM)
information model XSD, it's an instance of a transform of that, called a
TDS (Template Data Schema).
A TDS is something like a 'green CDA' schema but /generated /from the
AOM template structure
Hi!
I believe TDS is a very nice approach for som especific integration
purposes. Simple and wonderful invention (the best ones are often
simple...) For those new to TDS there was a thread regarding this
earlier: http://www.openehr.org/mailarchives/openehr-technical/msg03116.html
Are there any
Hi
We designed the process to allow ant XML schema generated to be transformed to
openEHR with a single transform.
I expect it may well be possible to do the reverse. At least it would be
possible to get to a consistent flattened form.
The reason for the TDS is to validate data using XML tools
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
Hi Heath,
On Tue, 2007-11-27 at 11:32 +0100, Heath Frankel wrote:
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
names come from the archetype element names, but there is
That is fine, but I can't wait for that now. I really have to finish my
work on this in short time.
When the TDS will be released, I will study it and probably implement it
then.
Now I will go on with my schema, which, by the way, works
Hi Daniel,
I should have been more precise. I still don't see how it would be possible
to create a single generic Canonical XML - TDD transform. It should be
possible, however, to generate a per-TDD schema (TDS) transform ,by
applying the same sort of generic rules that are used to create a TDS
with integration data easier, but a TDD (TDS XML
document) - canonical transformer harder to write (it has to look up
more from the archetypes.)
Some users are happy with a fully featured schema that enables a
nearly trivial TDD - canonical converter to be written.
Some users want specific
Hi Heath,
On Tue, 2007-11-27 at 11:32 +0100, Heath Frankel wrote:
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
at liu.se wrote:
Hi!
Which projects and products out there support TDS (Template
Data Schema)? And do they support conversion of TDDs (Template
Data Documents) to standard canonical openEHR RM instances
(in e.g. XML)? Is there any available
be good to make this part of the managed standard and public spec .
Ian
On 30 May 2013 10:21, Erik Sundvall erik.sundvall at liu.se wrote:
Hi!
Which projects and products out there support TDS (Template Data Schema)?
And do they support conversion of TDDs (Template Data Documents
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
collect of archetypes)
where
the XML element names come from the archetype element names, but there
is
That is fine, but I can't wait for that now. I really have to finish my
work on this in short time.
When the TDS will be released, I will study it and probably implement it
then.
Now I
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
Let me clarify a few things here.
There are many possible TDSs that can be generated from a given
template. Some users want a 'flat schema' with minimal meta-data, which
makes working with integration data easier, but a TDD (TDS XML document)
- canonical transformer harder to write (it has
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
Tom
Many thanks for this -- are there examples of TDS schemas or instances
available?
Also are there any example document instances available -- particularly for the
draft Extract schema, but any instances or instance fragments would be useful.
All the best
Charlie
Charlie McCay, charlie
there
wouldn't be a need to use an openEHR kernel component in this
integration by TDS scenario. But maybe this is (1) to complicated or
(2) superflous as the data is checked anyways with a kernel before
being committed. The only advantage would perhaps be that a more or
less complete validation could take
I am out of the office until 24.06.2013.
Note: This is an automated response to your message Re: TDS (and TDD)
implementations? sent on 14.06.2013 9:56:28.
This is the only notification you will receive while this person is away
to describe the AOM, but you cannot have
an XSD to describe an archetype and check a dataset with it.
you can, it's called a Template Data Schema (TDS), and is generated from
the Template Designer and I think the new Marand ADL-designer. Its
intended exactly for checking data sets...
whether
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
-Original Message-
From: openehr-technical-bounces at openehr.org
of archetype, template or terminology.
There is a different kind of machine-generated schema which we call the
Template Data Schema (TDS); any openEHR template can have this generated
for it. This enables messages to be created specific to a template, e.g.
a specific kind of path result. The data
On 14/06/2013 12:31, Daniel Karlsson wrote:
Gerard, Ian, Thomas, thanks for all answers.
On Fri, 2013-06-14 at 11:17 +0100, Thomas Beale wrote:
Such a standard TDS/TDD would have made the Swedish 2009-10 quality
registry project significantly easier and a lot of the criticism towards
Hello Hugh,
thank you for the quick answer!
I do not understand the TDS approach yet. I have the following questions
related to your answer:
- why should one produce data (i.e. out of a legacy sytem) that conforms
to TDS and then convert it to standard openEHR content format when it
can
--
Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI
Clinical Director
Ocean Informatics Pty Ltd
M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W:
www.oceaninformatics.com
Charlie McCay wrote:
Tom
Many thanks for this -- are there examples of TDS schemas
. Though at this point it is a proof of concept not
a long term solution (which may use the TDS instead).
I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all the code
involved, and with no interface change at most
On 14/06/2013 10:54, Gerard Freriks wrote:
Templates are mostly EHR-EXtracts with Compositions inside.
I imagine that is probabaly true in 13606-land. It's so far uncommon in
openEHR, but should be used more, and I think will become common with
the growing use of the openEHR EHR Extract
One simple example:
I can have an archetype slot that is filled at run-time as allowed by a regular
expression or a hand entered list of possible archetypes that can fill that
slot.
But there are more examples.
Gerard Freriks
+31 620347088
gfrer at luna.nl
On 14 jun. 2013, at 13:01, Daniel
The best example is:
One ENTRY archetype node that can have one ore more Clusters added to it - when
allowed -of course-via Archetype slots at run- or design time.
Gerard Freriks
+31 620347088
gfrer at luna.nl
On 14 jun. 2013, at 13:01, Daniel Karlsson Daniel.Karlsson at liu.se wrote:
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
Hi,
While we are at it.
-1-
Why do we need a TDD?
Isn't a Template just a Composition archetype with Sections archetypes and
ENTRY archetypes and Cluster archetypes and Element archetypes plus data types.
In addition as many possible degrees of freedom need to be constrained so as to
reflect
On 14/06/2013 12:19, Diego Bosc? wrote:
Well, in ADL specialization allows extension
From here
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADLAOM1.5-SpecialisationSemantics)
extensions, i.e. object constraints added to a container attribute
with respect to the
the data contains defining_code etc. The override
is valid in openEHR but breaks the TDS schema - this is expected and
we just ignore these validation errors.
If you email your TDD privately I would be happy to test it here.
Ian
On 3 March 2014 08:27, Birger Haarbrandt birger.haarbrandt at plri.de
datasets:
It is possible to have an XSD to describe the AOM, but you cannot
have an XSD to describe an archetype and check a dataset with it.
you can, it's called a Template Data Schema (TDS), and is generated
from the Template Designer and I think the new Marand ADL-designer.
Its intended
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
plus data
types.
IAN: Yes. That is true in both ADL1.4 and ADL 1.5 operational templates. We
do not need TDDs but we have found them very helpful when working with
non-openEHR specialists as they considerably simplify the target for them
to work with, particularly for integration projects. The TDS
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
On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
Hi,
While we are at it.
-1-
Why do we need a TDD?
Isn't a Template just a Composition archetype with Sections archetypes
and ENTRY archetypes and Cluster archetypes and Element archetypes
plus data types.
With ADL 1.5, yes I
but not Saxon EE 9.5.1.2
The problem seems to be that the latter does an initial validation
check which fails (expected) because we are overriding a DV_TYEXT with
a DV_CODED_TEXT i.e the data contains defining_code etc. The override
is valid in openEHR but breaks the TDS schema
On 12/11/2018 16:04, Bert Verhees wrote:
On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated
from the Template Designer and I think the new Marand ADL-designer.
Its intended exactly for checking data sets...
Of course you can write any
, FRACGP, FACHI
Clinical Director
Ocean Informatics Pty Ltd
M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W:
www.oceaninformatics.com
Charlie McCay wrote:
Tom
Many thanks for this -- are there examples of TDS schemas
to be customised a lot to
respresent as many of the archetype and template constraints as
possible. After submission of the instance it will be additionally
checked against the whole template data schema (TDS) on the
server-side.
I did a first test of this generator. For more details look on the
wiki
be quicker but
more prone to break. Though at this point it is a proof of concept not
a long term solution (which may use the TDS instead).
I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all the code
involved
data - i.e. the protobuf
equivalent of Template Date Schema (TDS).
- thomas
On 29/06/2018 21:48, Bert Verhees wrote:
On 29-06-18 10:27, Thomas Beale wrote:
The intention is certainly a good one. It just needs to be the
reference model and the Abstract Platform Specification
<http://
On 12-11-18 17:59, Thomas Beale wrote:
On 12/11/2018 16:04, Bert Verhees wrote:
On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated
from the Template Designer and I think the new Marand ADL-designer.
Its intended exactly for checking
by using an
openEHR server for data validation instead of W3C schema validation
against TDS.
I will follow of course the nice offer and get into contact with Peter
to learn how they achieved things.
Thank you very much again for giving me a good start.
Kind regards,
Birger
Am 02.09.2013
.
4. Heath Frankel (programming lead at Ocean Informatics) and I have
thought about using the Template Data Schemas (TDS) that can be
generated from templates (using the template designer) as the basis
for the XForms model. Tests are needed whether the currenty availble
XForms engine implementations
Informatics wrote a set of
customizable/extendable XSLT scripts that creates a generic read-only
view of openEHR instance data.
4. Heath Frankel (programming lead at Ocean Informatics) and I have
thought about using the Template Data Schemas (TDS) that can be
generated from templates (using the template
the XML would be quicker but
more prone to break. Though at this point it is a proof of concept not
a long term solution (which may use the TDS instead).
I am going to use a temporary solution, to get my data into my system.
It is not that important, it is only maybe 1% percent of all
json-schema
should be an output format from something similar to the TDS (template
data schema) approach?
I guess my assumption is that ADL will always use the most efficient and
human readable form (the proper 'n..m' form), while XML will probably
require the atttributes rm_attr_name='xxx
(HL7 V2 needs to be
converted to XML using an integration component such as Mirth) into a
Template Data Document (TDD) as defined in my presentation. The TDD is
validated against the Template Data Schema (TDS) generated from a Template
defined in the Ocean Template Designer, which augments
message (HL7 V2 needs to be
converted to XML using an integration component such as Mirth) into a Template
Data Document (TDD) as defined in my presentation. The TDD is validated
against the Template Data Schema (TDS) generated from a Template defined in the
Ocean Template Designer, which augments
See below
Gerard Freriks
+31 620347088
gfrer at luna.nl
On 14 jun. 2013, at 11:09, Daniel Karlsson daniel.karlsson at liu.se wrote:
On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
Hi,
While we are at it.
-1-
Why do we need a TDD?
Isn't a Template just a Composition
Hi Gerard,
see below...
On Fri, 2013-06-14 at 11:54 +0200, Gerard Freriks wrote:
See below
Gerard Freriks
+31 620347088
gfrer at luna.nl
On 14 jun. 2013, at 11:09, Daniel Karlsson daniel.karlsson at liu.se
wrote:
On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
Hi,
(according to TDS) or I?ll
have to make some ehr_extract equivalent? If using ehr_extract is needed,
is there any example on how to use it? I read some parts of the
documentation and found
https://github.com/openEHR/adl-archetypes/blob/master/Example/openEHR/ehr_extract_template/Working/Templates
by
populating (normally via xslt) from your source data. There is a standard
transform (from any TDS) to 'canonical' openEHR XML, available at
http://openehr.codeplex.com/SourceControl/latest#TRUNK/TemplateDataDocument/src/TDDAdapter/XSL/TDD_to_openEHR.xsl
You can then persist this to any openEHR xml
vice definition. This would enable the machine generation of
message definitions corresponding to any openEHR data - i.e. the
protobuf equivalent of Template Date Schema (TDS).
I am not sure what you mean here. Maybe it gets clear when I read the
code from Pieter.
In my current point of view in pro
erface. An interface of similar simplicity, but /generated/ from
templates using those archetypes however would be interesting...
The first is to generate APIs from templates, in the same way we
generate a TDS (Template Data Schema, which is an XSD) from a
template. All we need to do to
first email of this thread with this subject.
The first is to generate APIs from templates, in the same way we
generate a TDS (Template Data Schema, which is an XSD) from a
template. All we need to do to build a transformer, not hand-build
APIs (that's last century thinking). This means we woul
with the clinical content of CCR.
This allows integration of CCR into the openEHR space in a controlled
manner with validation via the TDS.
As we have a growing number of Archetype to CDA transforms this allows
production of CDA documents from the openEHR environment in a reusable
manner
of standard
archetypes. From this, a specific schema (Template Data Schema) can be
presented which should ideally map 1:1 with the clinical content of CCR.
This allows integration of CCR into the openEHR space in a controlled
manner with validation via the TDS.
As we have a growing number
this, a specific schema (Template Data Schema) can be
presented which should ideally map 1:1 with the clinical content of CCR.
This allows integration of CCR into the openEHR space in a controlled
manner with validation via the TDS.
As we have a growing number of Archetype to CDA transforms
to download, TDS can be generated, some
work using a good XML tool can produce an instance fairly quickly. The TDD
to openEHR transform is available on openehr.codeplex.com, you can use you
language of choice to load the instance into an XML DOM, validate it
against the schema to inject the default
Well, in ADL specialization allows extension
From here
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADLAOM1.5-SpecialisationSemantics)
extensions, i.e. object constraints added to a container attribute
with respect to the corresponding attribute in the parent
can reasonably say that we have some handle on generating
developer-usable artefacts, i.e. things like TDS, TDO etc, but they are all
content related. These are starting to be standardised now.
The openEHR of today needs to leverage new work such as ABD (or something like
it) to achieve
merging from one of the leading institutions in the world that has
historically specialised in workflow and decision support.
openEHR as it is today is just a semantic content + querying platform,
and I think we can reasonably say that we have some handle on
generating developer-usable artefacts, i.e.
between the
informatician and the software developer, archetypes and templates are the
lingua franca of between the domain experts and the informaticians. The
problem that GreenCDA and the openEHR TDS/TDO equivalents are IMO largely
about isolating the RM complexities from developers who have neither
one of the leading institutions in the world that has
historically specialised in workflow and decision support.
openEHR as it is today is just a semantic content + querying platform,
and I think we can reasonably say that we have some handle on
generating developer-usable artefacts, i.e. things
79 matches
Mail list logo
