One of my staff had an interesting experience many years ago.  He had an internship at a life insurance company.

The company maintained a huge array of virtualized AS400 machines that were running a number of legacy COBOL applications which described life insurance policies. The company needed to maintain all these applications for the life time of the actual policy holders. i.e. over a 60-70 year span.

The rules regarding the benefits for the policies and so on were so strictly tied to the actual software applications written in COBOL that it was more economical to keep all these applications going rather than attempt to try and convert the policies over to run within a new application.

These applications represented hundreds of millions of dollars worth of liabilities and benefits.

What does that tell us about interoperability standards?

From what I have looked at, the information in the insurance segments of HL7 is far from being a comprehensive insurance data model.  The fields which are present are more about giving hints to the healthcare provider who the claims should be submitted to, rather than really giving a full picture of a patient’s actual coverage.

Given the clear challenges that the insurance companies themselves have achieving data portability of their own policies it seems unlikely that anyone could ever come up with an adequate data model to fully describe insurance data.  Ironic given the HIPAA act. I guess if people change companies that they can reasonably expect changes in their coverage – but not if they are staying with the same company.

This is just one domain area that covers electronic medical records. As you drill into each area of medicine I think similar challenges arise.

So given these realities how do you make interoperability standards that can embrace all this complexity?

My thoughts are that it’s a losing battle to try and encompass everything. Instead focus on getting the ‘scaffolding’ right.  Interoperability standards which can define the core-backbone that maps out information in a logical manner are doing something useful.  In a sense that is what HL7 2.x insurance information already does, since it really is just reference information. It only solves one problem key to healthcare providers which is to locate who to bill and submit claims to.

Having extensible standards that allow additional information to be added is a benefit or a necessary evil.  Your stance on this depends on whether you’re a glass half full or a glass half empty sort of person.

Standards should cover the broad areas and make it possible to ‘glue’ things together in a manner which makes it easy to recall information, but subtleties from the existing software will always be felt. How important those subtleties are will come down the nature and value of the information concerned.

Electronic healthcare records need to be extensible and display information ‘as is’ from a variety of systems.  In the world of HL7 2.x the extension mechanism is what are called custom ‘Z segments’.  The problems of Z segments will be the topic of my next blog entry…

I gave the latest snapshot of Iguana a spin today to get a peek at some of the new features that will be part of 5.0.7 release.

I put some screen shots into the wiki under the What’s New section.

The code navigation is exciting. It goes well beyond what traditional IDEs like Visual Studio offer.  It allows you to navigate through the calls into the functions rather than just the functions themselves. That adds a lot of power into understanding the logic flow within a mapping script.

It is quite jaw dropping seeing what the team is achieving with the translator.  IDEs are an area of software which in my opinion haven’t shown a lot of innovation in the last 5 years. A big part of the problem is a lack of viable business models for companies in this area.  Things have stagnated into just Visual Studio and Eclipse. These environments have gotten large and complicated.

Our focus on integration provides a great engine to push things forward in this area.

Visual Studio and Eclipse have too many developers working on them.  They support an overwhelmingly wide range of languages and functionality. All this weighs heavily when it comes to having the freedom to innovate. In a sense these products have reached a point that it’s hard to move them forward without breaking compatibility with all their existing behavior. They feel like web browsers before Google showed us how minimalist a brower could be.

One of the over-riding goals we have with the translator is to keep it a very simple environment that flows naturally even as we add new features. All the new functionality like the error trace window, docking of dialogs and code navigation are in harmony with that goal. The new functionality is cleanly integrated in a natural manner making it easy to discover these features when and as you need them.

Let us know what you think. Of the new features, which do you think you will find the most useful?

We’re looking to fill two additional development positions in Toronto, Canada to work on our Iguana engine. To give you a bit of a taste for the technology involved please take a few minutes to view these short videos of the Iguana translator:

• http://www.interfaceware.com/iguana.html
• http://www.interfaceware.com/iguana_translator.html

As you can see it’s a very interesting application of web based technology to transform data. Historically we have been a purely healthcare integration engine but with the flexibility of our translator technology we plan to become a middleware engine in industries other than just healthcare.  We have well over 10,000 deployed sites and over 300 direct business clients including Fuji Medical, GE Medical Systems, MD Andersons and the NHS.

We look for developers who are creative, focused, attentive to detail, and possess a strong commitment to completing tasks in a timely manner. We often will take on board people that either have experience developing robust, scalable, concurrent, multi-platform C++ software (Windows, Posix) or who have significant web development experience.

Our approach to software development focuses on user-centered design and software development fundamentals. Our back-end code is written in portable C++, and our front-end is written in cross-browser HTML, CSS and Javascript. We have well thought out, consistently applied coding standards, and continually invest in improving the quality of existing code. We restrict ourselves to a relatively simple subset of C++, avoiding platform dependencies and allowing newcomers to become productive quickly without having to become C++ gurus. The result is a consistent and highly modularized code base, which allows for easy reuse, refactoring, extension and automated unit-testing. We also have top-notch infrastructure, including multi-platform automated builds, regression tests, source control, wiki and a ticketing system. We care about the quality of our products and our code.

As a company we have a strong commitment to aesthetics and we seek developers that appreciate this.

You must be physically based in Toronto. If you are interested or if you know of a colleague that would be appropriate, please contact me. I will be forwarding your contact details to my development team who will do the actual screening.

To contact us please send your resume to the email address careers AT interfaceware.com. Replace AT with @.

HL7 maintains a number of tools for maintaining the HL7 Version 3.0 RIM.

One of the tools is 1999 version of Rational Rose with an associated Microsoft Access database.  There are Eclipse plugins etc. I lose track of them all to tell the truth.

One of the big problems with the RIM is that it requires these specialized tools to maintain it.  Apart from being against the spirit of HL7 which is to be tool and vendor agnostic it poses some big practical problems for the development of the HL7 standards.

Using specialized tools means that many potential volunteer contributors are excluded from participating in the standards development process.  The volunteer workforce available to HL7 is most likely in a poisson distribution which means the majority of potential contributors have very little time to contribute.  If you soak their time up learning specialized tools you have cleverly eliminated most of the potential labor pool.

That labor pool might not be people that can develop the standard themselves but transparency will always assist in quality.  The more people than can understand the standard the higher likelihood there is of finding and correcting mistakes and defects in the standard. There is tremendous value in making material accessible to the widest possible audience.

The tools divert focus and resources away from the solving the core domain problem of healthcare integration.  Clearly HL7 does not have the resources to keep these tools themselves up to date.

The other problem these tools create is they make it tempting to engage in automatic generation of XML Schema and other artifacts from the data in the models.  Code generators tend to produce ugly code since you have a layer of machine indirection in play.  See my father’s TV remote.

Less is more.

By going back to a more simple approach of maintaining the RIM using basic technology like Microsoft Word documents or better still an easy to use Wiki would be better for the HL7 standard.