Hi all, Interesting discussions! I think initially we need to focus on full interoperability between "native" openEHR implementations across different platforms. But in the long run, we need to also make sure that all openEHR system have unified way of doing data exchange with external formats.
Early on, we have done a lot work just to make sure the tools - parsers, serializers and editors have good interoperability. It's quite challenging but it's possible and the benefits are obvious. I particularly want to stress the need to collaborate on these matters in the open space. As a community, we can create synergies by working on a common code base for core components that are crucial for interoperability. Besides the items proposed by Tom, I would like to comment on a more detailed level. There is an on-going work for a (nearly) platform independent way of testing (validating) archetypes based system. Initially the scope is targeting on the kernel, which is the essential pieces of software in any archetypes based system. Archetypes based data creating, validation and querying are validated using platform independent test fixtures and test case specifications. Test runners are the only bits of platform-specific in the framework but hopefully they can be provided as open source implementations for each major platform. Test fixtures and test cases are generated semi-automatically and can be created once and used by any platform. We intend to submit this work to MIE2008 within a week or so and will likely provide a proof-of-concept implementation within the Java project. If it goes well, we would like to demonstrate it on a software workshop at MIE2008. Cheers, Rong On 11/9/07, Greg Caulton <caultonpos at gmail.com> wrote: > > I also agree with Tims comments, we need to stay within scope of > OpenEHR. Obviously anyone building an HIS has an interest in proving > interoperability with other standards - but that should be up to them > not OpenEHR. > > Echoing Berts comment if we can get an early heads up on the > requirements - it does not have to be perfect nor complete, just > something that we can get started with on the design side. > > Demonstrating connectivity at a conference is great but I plan to have > my system running 24/7 on the internet with simulated random data and > it would be *very* cool to have a partner system which was sending and > receiving data - so you could log into either system and see the data > flow... > > On 11/9/07, Bert Verhees <bert.verhees at rosa.nl> wrote: > > <snip> > > (I snipped it away because of readability) > > > How and whether that system performs with HL7v2,CDA,CCD, etc. is > outside > > > the scope of openEHR conformance. > > > > > I must say, I agree with Tim, we must take care that we (only) test to > > openEhr-specs conformance. > > > > I would like to add some remarks. There maybe already thoughts about the > > coming API, can I find some information about that? It is difficult to > > have this discussion without that information. Let me explain: > > > > There are more platforms in which the openEhr specs can be build, .NET, > > Java, Eiffel, also C++ is possible. There are also many platforms on > > which openEhr can run. Linux, Mac and Windows. > > There are many interfacing-possibilities to other services/software. The > > good thing about open standards is that all this is posssible. > > But now an API, which must be platform-independent, because there is no > > platform defined in the specs. How will that look like, from technical > > view: I can imagine, this will be a service as in (http) SOA/SOAP-level > > > > Maybe I am wrong, so please tell me were to read more about it. > > > > regards > > Bert Verhees > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071109/bbe4b03d/attachment.html>
