The Return of Internet Explorer

Yes, it’s true. With the latest release of Iguana, version 5.0.9, Internet Explorer 8 and 9 are now officially supported (again)!

For those of you who read our blog and/or our wiki, you probably know that we have a bit of a love-hate relationship with IE around the office.

Editor’s Note: Since this article was published there was a recount and it’s actually just a hate relationship: the first ballot was confusing to some of our more “senior” team members.

Anyone with experience in web development can tell you that supporting IE – particularly the older versions like IE6 and IE7 – requires a significant amount of trickery, hacks and effort. That support often means sacrificing development hours that could be spent on features, innovations and optimizations. It’s a burden that many developers would be happy to live without.

That’s why, a few years back, we saw a surge in anti-IE campaigns springing up across the web. You may remember campaigns like:

http://www.ie6nomore.com
http://hey-it.com/

That was a fun grassroots movement which was embraced by everyone from small start-ups all the way up to the likes of Google.  Within the healthcare IT and enterprise world however, it’s definitely a case of easier-said-than-done.

When you’re dealing with major institutions and hospitals, it’s occasionally impossible for the individual user or the integration team as a whole to use anything other that IE. So, while on a personal level we might not love IE, today we are releasing the latest version of Iguana with support for IE8 and IE9. We’ll continue listening and working to ensure all of our corporate users – including those who run IE – are able to take advantage of Iguana and all of the amazing features of the Iguana Translator.

We’d love to hear from the community though. What do you think? Is IE still the dominant browser in your office? Is it IE8 or IE9 – or are you still using the dreaded IE6?

You can download Iguana 5.0.9 today. Happy browsing and integrating!

-Art

My Dad Mervyn Muir – A pioneer meta integration engineer

The question of meta programming and modeling in health-care is a hot issue with HL7 v3 and the Reference Information Model (RIM).  When ever it comes up I think about my Dad’s TV remote.

My dad Mervyn was the personification of think different long before Apple ever trademarked the term.

He worked his entire career for the New Zealand (NZ) DSIR as a geo-physicist. Topical given the recent events in Christchurch and Japan. Science does not pay well. So my father had a certain thrifty resourcefulness when it came to problem solving.

His resourcefulness was often uninhibited by aesthetic considerations. Growing up as a slightly insecure adolescent it was hard to appreciate at the time. I was mortified at the time he turned up in Auckland for my graduation using black plastic rubbish bags for his luggage.

My father had knack for finding solutions to problems that other people wouldn’t think of.

The Brave New World of Middleware – Part 5

Part 5: Redesigning the Modern Interface Engine

As HIMSS is right around the corner, I’m growing increasingly excited to showcase Iguana v5: our redesign of the modern interface engine.

In previous posts in this blog series, I’ve explored the headaches faced by integration engineers, the complexities in the economics of integration and the failed promise of graphical mappers.

I challenged myself to question the old assumptions of integration. I challenged my company to refuse to accept the limitations of integration engines in terms of visibility and control that users can have over their interfaces.

We changed the question we were asking ourselves from “How can we achieve integration without code?” to “How can we make code based integration work better?“. Not only did we find the answer, we’ve also opened the door to endless integration possibilities in the process.

Now I ask you to challenge yourself. Challenge not only what you expect from an interface engine but also challenge what you can do when integration is truly made easy.

I invite you to begin that challenge with Iguana v5. To explore more about what the latest version of Iguana offers please visit our Re-Thinking Integration page.

We will be proudly demonstrating the capabilities of Iguana v5 at HIMSS in Orlando next week. I personally encourage you to take the time to stop by our booth #3621 to see it in action.

I would also like to express my appreciation to those of you who have reached out to me over the past few weeks to offer your opinions and support of our new approach to middleware. I’ve thoroughly enjoyed the discussions that we’ve had.

Eliot Muir
President and CEO, iNTERFACEWARE™

Remember to subscribe to our blog or follow us on twitter (twitter.com/interfaceware) for product updates, future resources and discussions.

The Brave New World of Middleware – Part 4

Part 4: The failed promise of graphical mapping

In the first post of this blog series, Re-thinking Integration, I explained how I have spent a great deal of time examining my assumptions about what middleware needs to deliver.

At the forefront of my original assumptions was my belief that the majority of mapping could be done graphically with only a small fraction requiring scripting.

The reality that I’ve personally observed in my customer’s integration projects tells a very different story. The amount of code used greatly exceeded the amount of work that was being done graphically. In fact, it was looking more like 90% scripting and 10% graphical mapping.

It was quite humbling to be honest. Here we were trying to deliver graphical mapping tools when customers relied heavily on scripting.

While I recognize the error in this misconception, it is one that is shared across our industry.

The entire middleware industry is built up on the promise that integration can be achieved “without programming”, that it can all be done with graphical point-and-click mapping.

It’s a nice and enticing marketing message. Unfortunately, it does not appear to be true.

Why do graphical mappers fail to deliver on their promise?

The Brave New World of Middleware – Part 3

Part 3: The Integration Engineer

An old friend and customer of mine once told me that the two most important tools in his job as an integration engineer were Iguana and his phone but not in that order.

The majority of his time was spent talking to his customers to determine the requirements needed to integrate his system at their site.

Off the shelf applications that instantly meet the unique needs of a given healthcare institution’s workflow are scarce at best. Interfacing can be accurately viewed as ramming a square peg into a round hole, complete with all the sweat and frustration.

My friend, as I’m sure many other integration engineers do, found himself at odds with the development and quality assurance teams in his company. They are often more formally process driven and simply don’t have the same customer facing perspective that is required of him.

Integration engineers have to be very focused on understanding the needs of their customers and be able to deal with problems as soon as they are discovered. As a result, their primary focus is the customer, not the integration tools.

The Brave New World of Middleware – Part 2

Part 2: It’s all about economics

There is an old joke I enjoy, that I think has a lot of relevance to software.

There was a guy who always cut his pot roast in half before cooking it. His wife was curious as to why he always did it that way. He replied that this was the way his mother had always done it. His wife went to her husband’s mother and asked her why she did this. The mother replied that this was the way that her mother had always done it. Finally, the wife went to her husband’s grandmother and asked her why she did this.

The grandmother replied, “It was because I didn’t have a dish large enough to put an entire pot roast in!”.

In software we often make this mistake. Our products evolve and have features added without questioning the original assumptions and decisions that led to the existing design.

This easily leads software companies to lose sight of the actual problems that they are trying to solve for their customers. I found it helpful to remind myself why people find value in purchasing middleware. At the crux of it all, it’s about economics.

Normal software economics are wonderfully profitable. Once you have sold enough units, every additional unit sold thereafter yields pure profit.

With this economic model, the cost of actually developing software can be very high as it doesn’t have to be the most efficient process.

But when you sell your software into a market where it has to be integrated, this rosy picture all comes crashing down.

The Brave New World of Middleware – Part 1

Part 1: Re-thinking Integration

There is a great deal of excitement around the offices of iNTERFACEWARE these days and I wanted to personally reach out to you and explain what all the buzz is about.

Over the past few years, I have invested a great deal of time and energy into re-thinking my assumptions about what middleware needs to deliver.

My expectations of what is needed are drastically different now than they were back in 1997, when I wrote the first version of Chameleon.

In fact, nearly a decade and a half later, there is only one core assumption that remains unchanged. The goal of middleware remains the same: to provide value by minimizing the cost of maintaining interfaces.

Unfortunately, in software it is all too easy to get lost in the weeds and lose sight of the real-world problems of your customers while you wrestle with the internals of your own code. By stepping back and seeing the actual problems for what they are, we can often find more elegant solutions.

What if… HL7 was truly made easy?

Today, we here at iNTERFACEWARE are very pleased to announce the launch of our newly redesigned website: http://www.interfaceware.com

The first thing people seem to notice from our website – and the same goes for our appearances at trade shows and other industry events – is our tag line: “HL7 Integration Made Easy“. I can’t tell you how many conversations I’ve had that have started with: “…you had me at Easy!”.

One of the things we’re most proud of here at iNTERFACEWARE is the fact that we’ve been able to make HL7 workable, understandable, implementable, … and even easy for our customers.

For those who are just starting their HL7 explorations and may be wondering, “How do you make HL7 easy?”,  I thought I’d put a new video together to help you get started.

What does an HL7 message look like?

When I created my first animated video – How does HL7 work? – I never imagined it would have the reach and impact it did.  In the few short weeks since it was released, the video has found its way onto dozens of corporate blogs, industry publications and personal sites.  It seems the interest in HL7 – especially when explained in plain English – is very high!

As the comments rolled in, a number of viewers requested a more technical HL7 overview video.   Not wanting to disappoint my “fans”, I thought I’d give it a shot.

It’s a good thing I’m always up for a challenge because as much as I love HL7 – and really, don’t we all – creating an HL7 tutorial to explain an HL7 message’s pipes, carets, tildes and ampersands isn’t exactly an easy task.

Have a look at my follow-up video – What does an HL7 message look like? – and let me know what you think.  Did I manage to capture the important elements of an HL7 message in a fun way?

How does HL7 work?

Whenever I travel for work, one of the most common questions I hear is “How does HL7 work?”

HL7 is not always one of the sexiest subjects, but as interoperability and connectivity continue to be huge drivers in the health care space, the questions of HL7 are going to continue to be asked.

So, after a little thought, I thought I’d create a fun – and hopefully useful – video describing what HL7 is and what it does.