very interesting thread. And yes TDS seem to be a very helpful and
pragmatic way to start with openEHR. This pragmatism and step-wise
approach is what helped HL7 CDA R2 to be relatively successful! Now,
we have an answer for this strong (IMHO the strongest) CDA argument.
As mentioned previously it will depend on the use case (and its
economics) whether an implementor uses it to stepwise change their
systems to a "full", adaptive openEHR solution or whether every time
clinical requirements (expressed as archetypes and templates) change
the software is re-implemented. Regarding interoperability it won't
make a difference as in both cases the resulting data is fully openEHR
compliant.
One theoretical question (probably you Ocean guys have already looked
into it), would it be possible to generate a second schemtron schema
to express the asseration type constraints that can't be expressed
with XML schema. If possible, by validating against both schemas 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 place in an XML based environment
at the client side.
One theoretical question (probably you Ocean guys have already looked
into it), would it be possible to generate a second schemtron schema
to express the asseration type constraints that can't be expressed
with XML schema. If possible, by validating against both schemas 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 place in an XML based environment
at the client side.
[Heath Frankel]
No reason why you couldn't use schematron as far as I can see. We choose to
use the kernel.
I think we are saying the same thing. What I was trying to say was that we see the ability for openEHR systems to continue to consume HL7 v2 messages as being very important and that our tools support this now. However, where the HL7v2 message isn’t going to cut it, rather than jump into a full blown openEHR implementation, this is another way of approaching it that is easier.
After spending the day harrassing the entire development staff of
OpenMRS regarding the creation, use and management of "Concepts". http://openmrs.org/wiki/Category:Concept I have realized that what you
are describing with TDSs are the answer to the exact use case of sharing
information with and implementation like OpenMRS.
