tag:blogger.com,1999:blog-733074358901582680.post7068288145661947907..comments2024-03-23T05:28:35.472-04:00Comments on Healthcare Standards: Hard vs. Easy and Real MetricsKeith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-733074358901582680.post-920872353310310872009-11-04T04:56:17.912-05:002009-11-04T04:56:17.912-05:00Hi Keith,
I regularly follow your great blog - an...Hi Keith,<br /><br />I regularly follow your great blog - and this time I have a little comment on the SOAP vs REST debate. <br /><br />One thing is to clearly distinguish application code from interfacing. Clearly developing a full-fledged production-ready XDS registry and/or repository is much more than just the bare minimum of domain logic the XDS profile imposes on you. Most of the time, your application not just acts as a pure backend thing (as you mentioned, there's OSS stuff available), but also to provide added value (e.g. some graphical user interface). At the end, from a vendor's perspective, you have to make the difference in competition.<br />The second thing is to discriminate the protocol level and the business level of an interface. SOAP vs REST is only about the protocol level. (I consciously ignore discussing the choice of ebXML here). While the business level (i.e. data model) probably wouldn't change at all, XDS seems to be a perfect fit for a resource-oriented interface to me - it would be a nice exercise to reexpress the transactions that way. I'm not saying the decision for SOAP was wrong (after all, before XDS.a, SOAP was cutting-edge, and REST not). But I'm very convinced that dealing with SOAP (and one of the numerous WS frameworks) distracts your attention much more than necessary from the real business value that your XDS-compliant application is supposed to deliver. (And I'm haven't even mentioned platform interoperability, which - even in times of WS-I - is just annoying).<br /><br />To support your Open Source affinity, I'd like to add the Open eHealth Integration Platform (IPF, http://gforge.openehealth.org/gf/project/ipf/) to the list. Its dedicated IHE support encapsulates both client- and server-side interfaces into very few Java/Groovy statements, e.g.<br /><br /> // Entry point for Retrieve Document Set<br /> from('xds-iti43:myService')<br /> // Validate and convert the request<br /> .validate().iti43Request()<br /> .convertBodyTo(RetrieveDocumentSet.class)<br /> // everything below is your business logic<br /> <br />for receive a RetrieveDocument request including ATNA auditing, proper handling of large documents, request validation and transformation from the raw ebXML into an object model very close to what is specified by XDS. No need to directly deal with SOAP WebServices anymore. The XDS tutorial (http://repo.openehealth.org/sites/ipf/manuals/ipf-2.0-rc1/XDS%20repository.html) demonstrates how a (admittedly very simple) registry and repository can be done in far less than 1000 LOCs...<br /><br />best regards<br />Christian OhrChristian Ohrhttps://www.blogger.com/profile/07068033984184164751noreply@blogger.com