Andrew McIntyre wrote: > Tim Churches wrote: >> Tom Bowden <[EMAIL PROTECTED]> wrote: >>> Model 1. Messages are created to a defined >>> specification/standard/implementation by the originating practice >>> management system. They are then sent by a messaging system that (prior >>> to signing and sending them), checks them (for structural conformance >>> only) against the published standard. Messages are not changed by the >>> intermediate system. The proponent of this system argues that the task >>> of ensuring that the message structure is correct and complete belongs >>> to the originating system and that most of the originating systems are >>> now capable of sending appropriately structured messages and thus are >>> capable of being used for this purpose. >>> >>> Model 2. The second option includes a messaging system that >>> incorporates an interface engine capable of transforming messages. The >>> proponent argues that end point systems are not capable of sending or >>> receiving standardised messages and therefore a message transformation >>> service is needed in the middle. Due to perceived deficiencies in the >>> end-point-systems the original messages are transformed by the >>> intermediate system to remedy the perceived deficiencies. >> I'm at an open-source in health conference in Kuala Lumpur right now and >> have seen MIRTH in action and have to say it is the ant's pants and can >> handle both of the above with ease and elegance. All free, open-source, well >> supported (by the vendor in the US, but it's well written open-source so no >> reason why it can't be supported locally if a support company wanted to pick >> it up), and they have a nifty "appliance" version the size of a hardback >> novel which just plugs in to your network, draws about 5 watts of power and >> handles all messaging. See http://www.mirthproject.org > > Hi Tim, > > I have had a play with MIRTH as well and its quite good. Medical-Objects > can interoperate with Mirth and we have been in touch with the > developers to try and standardise GELLO a bit as we have both written a > GELLO compiler. > > Its fine to connect 2 sites and does have interface engine abilities, as > they realize its needed as well. However any PKI setup of addressing is > quite manual, or at least it was previously. In many ways it similar to > Kestrals HL7Connect, which we also interoperate with. > > Having a centrally maintained online directory and key store makes > setting up new end points easy and I think thats whats lacking from > Mirth at the moment, although I have not looked at it for a few months.
I agree that it currently lacks LDAP support, which is a curious omission, but this is coming in version 1.5 in a few months as part of its support for the US IHE interoperability initiative. As it stands, it is still a very good way to create point-to-point interconnections, which are what are most demanded as interim measures in developing and transitional countries and in the hyper-fragmented US system. More developed countries ought to proceed directly to *one* shared PKI-aware directory (and *not* one per messaging service provider or one per PKI provider, which is what we currently have here in Oz, but we're not really a developed country, are we? I mean, not in the same way that NZ is.). It is very easy to write plug-in transformation modules in Mirth, in Javascript, Python or Java, for specific message sources and sinks, and in the US end-users are beginning to write these themselves, open-source them and mutual combine and improve them. Thus the development of the transformation modules needed to interface specific systems actually work in the real world is not rate-limited by the capacity of the Mirth developers. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
