This topic contains 2 replies, has 3 voices, and was last updated by  wfsmith 4 years, 9 months ago.

Who's in the Cloud?

  • Is anyone using Iguana in their cloud apps and willing to talk about their experience? I’m trying to lay out a strategy for implementing Iguana in my current project and I’d like to see what what others are doing. I’m in a bit of a peculiar place because my company is targeting large health systems and smaller provider owned practices. We have a few installations and are using local instances of interfaces (home grown), running on customer managed VMs which connect back to our cloud via our RestFul API. We’ve had challenges, uptime & servicing, with this approach (our current team inherited home grown code) so I’m trying to lay out more reliable & scalable strategy. I’ve used Iguana at previous stop and I feel like this is the right move, but that was supporting an individual instances of an enterprise application installed on each customer network.

    Here are my options as I see them currently.

    1. 1) Centralized Iguana server require clients to connect directly.
      1. a) Use MLLP over SSL for direct HL7 Connections, or
      2. b) Require a Site to Site VPN, or
      3. c) Encourage clients to post HL7 Messages to an HTTPS service (so far I’m not having luck with this discussion).

      -Pros: Reliable technology, Single point of service, Central install, Single instance monitoring, Eliminate VM cost (smaller providers really balk at this)
      -Cons: Customer concerns with SSL; Single point of failure (can mitigate); Extra security for separation of concerns; VPN Maintenance; Web services are a bridge too far for smaller providers & larger ones on old technology stacks.

    2. 2) Run individual Iguanas Nodes Connect to Central Iguana for processing
      1. Channels serve as senders / receivers which post and pull from centralized server in the cloud.

      Pros: Reliable Technology, Single installation for processing, Model is still close to what the customer is “used to”.
      Cons: Single point of failure; Still have serviceability concerns if Iguana is behind a firewall. VM Cost. Less visibility to “connection status” (I know we can write channels to report this). Getting e-mails out of a customer’s network can be a pain.

    3. 3) Run individual Iguanas Nodes Connect to process directly to the cloud.
      1. Basically what I’m doing now, but with each Iguana standing separately and handling messages and processing on its own

      Pros: Reliable Technology. This is the model customers are “used to”.
      Cons: Still have serviceability concerns if Iguana is behind a firewall. VM Cost. Less visibility to errors of any kind. E-mails can problematic.Require touching multiple instances for service / upgrades.

    My questions are:

    1. 1) Is there another option I’m missing?
    2. 2) Does anyone have experience using any of these models?
    3. 3) If so, Have customers been receptive to configurations resembling option 1? Do you connect over SSL or VPN or a mix of both? I’d like to keep it to one solution, but I’m wondering if that’s realistic.
    4. 4) What was the biggest challenges have you had in deploying cloud interface solution? (Network, Security, predicting volume/resources, etc.)
    5. 5) If you’ve put in a model like this using Iguana do you feel like you got significant value out of your investment? We’ll have to justify “buy vs build” acknowledging that our current scheme is a sunk cost.

    I know this is a lot to ask, but I appreciate any advice or guidance anyone is willing to share.

    M.R. McBee

    I thought I would wait to see if anyone came forward. I know of a few clients that customized their installs of Iguana itself to perform the ‘agent’ function – just simple store and forward instances taking in HL7 via LLP and using HTTPS to securely forward into a data center.

    I also know other clients which used VPN connections.

    There are approximately equal effort since VPN connections require agent software – with agents via Iguana you do get a bit more control over how you control and monitor the agent instances.

    Happy to schedule some time to chat about this offline.


    We’re starting an Iguana implementation project where everything will live at AWS. This thread is a bit dated now, but I’d be most grateful if the original authors or any others can contribute some actual experience and lessons learned.

    Right now we’re expecting to expose LLP/SSL connections and SFTP folders as input mechanisms. These inputs would occur via specific, authenticated ports; all other processing will take place within our local VPC at AWS and the data will feed into our analytical systems. Are there hazards to this very simple organization, other than the obvious single failure point, which we could in principle mitigate by a load-balancing interface in front (still at AWS) to distribute traffic to multiple Iguanas?

    Bill Smith

You must be logged in to reply to this topic.