This topic contains 8 replies, has 2 voices, and was last updated by  jibu314e 8 years, 6 months ago.

Support for IHE ITI 141 transaction – Server Side

  • I have a question about whether Iguana support the Server Side Implementation of the IHE ITI 141 transaction. I can see the example that shows the creation of a CCD and invoking the NIST server to submit the CCD. I don’t however see any examples that indicate that it can act as the Server Side to recieve these requests for Provide and Register Transaction set. Any help in this area would be much appreciated.

    It can do it but we don’t provide a complete implementation for this out of the box. You’ll need to write code…

    Hi Elliot,
    Do you have any sample code, framework etc that you can share on this? Or are we developing pretty much the entire server side transaction set and using the iguana infrastructure to host the WebService that we develop?


    It’s very straightforward to write code to consume an CCD document since you can power it off the data. Create a From HTTPS channel to listen on a URL then do something along these lines:

    local Request = net.http.parse{data=Data} — Data is the inbound HTTP request with the CCD in it.

    — Assuming the CCD is in the body of the request parse the XML with something like:
    local Document = xml.parse{data=Request.body}

    Now get the data out of the Document object which has all the nice properties of the translator with auto-completion and browsability that you get in the translator.

    Best thing would be to get on the phone with the sales team and actually get in depth with you want to do and how to best achieve it.

    Hi Elliott,

    What you are outlining is not a standard implementation of the IHE ITI 141 transaction though is it? It would mean that the person sending you the CCD will have to deviate from the standard would it not? or am I missing something?


    I haven’t read the spec for IHE ITI 141 transaction. Probably be helpful to provide a link? At the end of day it’s going to be plain old data coming in and plain old data going out. From memory this stuff uses SOAP so it will be necessary to parse the SOAP header – at the end of the day SOAP is just extra cruft that tends to be a bit finicky. Lovely thing about SOAP is that no two SOAP frameworks are 100% compatible.

    From Iguana’s point of view though SOAP is just XML so you’d use the same xml.parse to parse the incoming data and get at the CDA payload.

    There are handy tools like SOAP UI which can help in analysing the WSDLs and so on:

    If you search SOAP in our wiki:

    You’ll get a variety of resources. Anyways if you are serious then arrange a time to talk with our sales team and they can help get you the resources you looking for.


    Thank you – you are right about the soap message being XML, and I agree that if we are just trying to get at the CCD payload and not really implement the provide and register transaction and other transactions you can implement a minimal set of code to do this and expand to process the rest of the SOAP header as needed to support your use cases.

    I do appreciate the help Eliot – Thank you very much.


    Do you work for an existing customer Jibu or are you considering Iguana for a new project?

    Hi Eliot,

    We are working to propose a solution to an existing customer who already owns Iguana.


You must be logged in to reply to this topic.